Quando si può rilasciare un'applicazione cross-platform che supera le prove di qualità, supera la revisione delle app store e tuttavia delude gli utenti nei primi cinque minuti. Il login funziona. La navigazione funziona tecnicamente. Il API restituisce i dati. Eppure le recensioni dicono che l'app sembra lenta, goffa o inaffidabile.
Quel divario è dove esperienza dell'utente dell'app vive.
Capacitor e gli sviluppatori di Electron incontrano spesso questo problema perché la consegna di funzionalità è visibile all'interno del team, mentre la frizione si manifesta all'esterno di esso. Un WebView richiede un tempo di reazione troppo lungo per diventare interattivo. Una finestra desktop si ripristina in uno stato strano. Un spinner di form non spiega se il lavoro sta avvenendo o è bloccato. Un aggiornamento risolve un bug ma lascia metà della base utenti su un bundle più vecchio per giorni. Nessuno di questi problemi sembra drammatico in una demo di sprint. Insieme, definiscono se le persone continuano ad utilizzare il prodotto.
Pessima UX non è più un problema estetico. Rapporto di Adjust secondo cui il 90% degli utenti ha dichiarato che la scarsa prestazione era la ragione principale per cui hanno smesso di utilizzare un'app nella sua guida all'esperienza utente nei dispositivi mobili. Per i team di ingegneria, ciò cambia la conversazione. L'UX non è un layer che si aggiunge dopo che l'app funziona. È il risultato operativo della prestazione, della affidabilità, della chiarezza e della velocità con cui gli utenti raggiungono il valore.
Per i team cross-platform, ciò crea sia il rischio che l'opportunità. Il rischio, perché un codice unico può diffondere la stessa frizione su iOS, Android e desktop. L'opportunità, perché un fix misurato può migliorare il percorso in ogni luogo se si strumentano i momenti giusti e si inviano aggiornamenti in modo sicuro.
Tavola dei contenuti
- contesto: Pagina/area: Sito web di marketing Capgo. Ruolo: Etichetta breve o elemento di navigazione. Visto in: pagina blog/[slug].astro. Chiave di messaggio `table_of_contents` (Tavola dei contenuti).
- Perché questo si trova nell'ambito dell'ingegneria, non solo della progettazione grafica e dell'esperienza utente moderna
- Come misurare l'esperienza dell'utente di un'app con metriche azionate
- Strategie pratiche per migliorare l'esperienza UX cross-platform dell'app
- Ruolo delle aggiornamenti affidabili nell'ottimizzazione continua dell'esperienza UX
- Mettilo tutto insieme: il tuo primo ciclo di miglioramento UX
Introduzione: perché un'app funzionante non è sufficiente
Un'app funzionante completa le attività. Una buona app aiuta le persone a completare le attività senza esitazione, confusione o secondi pensieri. Non sono la stessa cosa.
Molte squadre scoprono questo dopo il lancio. I tester interni conoscono bene il prodotto, quindi si muovono attraverso il flusso con pazienza e contesto. Gli utenti reali no. Arrivano freddi, su uno schermo piccolo, tra riunioni, con una connessione debole o con una batteria del laptop quasi morta. Non si curano che l'architettura sia elegante se l'azione utile iniziale richiede troppo tempo o se l'interfaccia utente si blocca brevemente quando toccano.
Il costo nascosto di un UX tecnicamente accettabile
Il stack cross-platform esaspera questo problema in modi specifici. Le app Capacitor spesso ereditano le assunzioni web che non valgono nella condizione mobile nativa. Le app Electron possono diventare pesanti, soprattutto quando le squadre trattano il desktop come un ambiente illimitato e accumulano lavoro di avvio, sincronizzazione di background e pacchetti front-end ingombranti.
Il risultato non è sempre un crash. Spesso è qualcosa di più tranquillo:
- L'attesa: Gli utenti si fermano perché il passo successivo non è chiaro.
- Latenza: Un pulsante risponde troppo tardi, quindi le persone premere di nuovo.
- Mancanza di fiducia: I dati sembrano essere datati, quindi gli utenti si chiedono se la sincronizzazione sia andata a buon fine.
- Abbandono: L'onboarding è tecnicamente completato, ma le persone non raggiungono mai il valore fondamentale del prodotto.
Regola pratica: Se gli utenti descrivono l'applicazione come “clonica”, di solito stanno segnalando una catena di piccole decisioni di ingegneria e prodotto, non un problema di design visivo singolo.
Perché questo si trova nell'ambito dell'ingegneria, non solo del design:
In prodotti cross-platform, molti dei problemi UX di impatto più alto derivano da dettagli di implementazione. La invalidazione della cache influenza se i contenuti sembrano affidabili. La dimensione del pacchetto influenza il tempo di interazione. La persistenza dello stato influenza se gli utenti si sentono orientati quando riaprono l'applicazione. La consegna degli aggiornamenti influenza velocemente come scompare la frizione nel campo.
Perché i team maturi trattano l'esperienza dell'utente dell'applicazione come lavoro condiviso tra prodotto, design, QA e ingegneria. I designer definiscono le flussi. Il prodotto priorizza gli esiti. Gli ingegneri decidono se l'esperienza rimane veloce, stabile e ripristinabile nelle condizioni reali.
Latency: __CAPGO_KEEP_0__
Se l'app funziona solo quando tutto va bene, gli utenti la chiameranno comunque rotta.
I Quattro Pilastri dell'esperienza utente moderna dell'applicazione
Il modo più semplice per evitare che l'esperienza utente diventi vaga è dividerla in quattro pilastri: usabilità, prestazioni, affidabilità e valoreSe uno di essi è debole, gli utenti lo sentono anche quando gli altri sono forti.
L'usabilità significa che la strada è ovvia
L'usabilità riguarda se gli utenti sanno cosa fare successivamente e se riescono a riprendersi quando commettono un errore. Ciò include le etichette di navigazione, la posizione dei controlli, il comportamento dei form, gli stati vuoti e se l'app rispetta le aspettative della piattaforma.
In un'app Capacitor, una cattiva usabilità spesso si manifesta quando gli squadre copiano un'interazione web in mobile senza adattarla. Le ipotesi di hover non esistono. Le pagine di impostazioni dense diventano esaustive. I bersagli di tap si sentono stretti. Una pila di modali che sembra buona sul desktop diventa disorientante su un telefono.
Una buona usabilità non è appariscente. È l'assenza di attrito.
Le prestazioni e l'affidabilità plasmano la fiducia
Le prestazioni rispondono a se l'app sembra rispondente. L'affidabilità risponde a se si comporta in modo prevedibile. Gli utenti raramente separano questi concetti in modo netto. Sanno solo se hanno fiducia nell'app.
A uno schermo che compare istantaneamente ma fallisce durante la sincronizzazione, l'esperienza è ancora cattiva. Un'applicazione stabile che richiede troppo tempo per diventare interattiva perde anche le persone. Questo è il motivo per cui l'analisi a livello di sessione è importante. Nell'articolo su punteggio UX, Dynatrace descrive un modello che classifica ogni sessione come Soddisfacente, Frustrante o Tollerabile combinando l'analisi delle prestazioni e la detezione degli errori in un unico metrica. È un modo di pensare utile per i sviluppatori perché la velocità media della pagina non ti dice quali percorsi sono stati interrotti.
Per i team di Electron, ciò spesso significa osservare il comportamento di avvio, la pressione della memoria e la risposta del renderer. Per i team di Capacitor, significa prestare attenzione alla sequenza di avvio, alle chiamate del ponte e a come le schermate dipendenti dalla rete si degradano in modo graduale.
Un utente non esperisce il tuo diagramma di architettura. Esperisce una sessione alla volta.
È il valore la ragione per cui le persone tornano
L'applicazione può essere utilizzabile, veloce e stabile, ma ancora sottoperformante se ritarda il momento in cui gli utenti ottengono ciò per cui sono venuti. Il valore è il livello di risultato. L'utente ha completato la task, risolto il problema o raggiunto il beneficio che ha giustificato l'apertura dell'app?
Molti prodotti con molte funzionalità spesso inciampano: i team aggiungono superfici, impostazioni e personalizzazione prima di stringere il percorso di base. L'applicazione si allarga senza migliorare.
Un modo utile per valutare le quattro colonne è chiedersi queste domande:
| Pilastro | Domanda fondamentale | Modalità di fallimento comune cross-platform |
|---|---|---|
| Utilità | Possono gli utenti capire cosa fare successivamente? | Flussi di tipo web copiati in mobile o desktop senza modifiche |
| Performanza | context | Pagina/area: Sezione del problema/soluzione della home page. Ruolo: Intestazione di sezione o pagina. Visualizzato in: pagina premium-support.astro. Chiave di messaggio `ps_help_performance_title` (Ps Aiuto Performance Titolo). |
| Risposta rapida abbastanza da sentire vivo? | Pacchetti pesanti, lavoro di avvio bloccato, transizioni lente | Affidabilità |
| Possono gli utenti fidarsi dell'app per continuare a funzionare? | I utenti raggiungono lo scopo per cui l'hanno installata? | Onboarding lungo, attivazione ritardata, percorsi di feature rumorosi |
I quattro pilastri tengono anche le conversazioni di squadra ferme al suolo. Invece di dire “il UX ha bisogno di miglioramenti”, si può dire che il percorso di onboarding è comprensibile ma troppo lento, o che la feature è utile ma non affidabile su connessioni deboli. È questo il livello in cui le squadre possono migliorare l'esperienza dell'utente dell'app.
Come misurare l'esperienza dell'utente dell'app con metriche azionate
La via più veloce per evitare i problemi di UX è guardare ai conti di installazione e ai totali di coinvolgimento generici senza misurare la frizione. I download non dicono se le persone si sono bloccate, sono diventate impazienti o sono partite prima di raggiungere il valore.
Per le app cross-platform, le metriche più utili collegano il comportamento tecnico ai risultati dell'utente. Si vuole sapere se un'esperienza povera proviene da crash, interfacce bloccate, onboarding confuso o da un gap di aggiornamento che lascia gli utenti su una versione più vecchia.
Misura la frizione prima di misurare la scala
Inizia con i segnali che espongono il dolore durante l'uso reale. Nella sua guida alle metriche di analytics importanti per le app mobili UXCam raccomanda di tracciaretasso di utenti senza crash con un obiettivo di 100% oltre il 99% di quotidianità, congelamento dell'interfaccia utente definito come non rispondente per 2+ secondi, e tasti di rabbia definito come 4+ tocchi in un secondo sull'elemento stesso. Lo stesso orientamento dice che gli utenti che raggiungono il loro evento di attivazione in meno di 60 secondi della prima sessione conservano a tassi molto più alti.
Quei metriche sono insolitamente utili perché si collegano direttamente a ciò che gli utenti sentono:
- Tasso di utilizzo senza crash ti dice se l'instabilità è diffusa o isolata.
- Congelamento dell'interfaccia utente rivelano momenti in cui gli utenti pensano che l'app abbia smesso di ascoltare.
- Tasti di rabbia espongono controlli che sembrano disponibili ma non rispondono chiaramente.
- Tempo per la prima azione significativa ti dice quanto velocemente gli utenti raggiungono il primo vero payoff.
Per le squadre che stanno implementando l'instrumentazione, un punto di partenza pratico è quello di configurare la monitoraggio delle prestazioni nei Capacitor app e rendere visibili gli eventi della prima sessione sia ai prodotti che all'ingegneria.
Un set di metriche pratico per prodotto e ingegneria
Not tutti i team hanno bisogno di una grande tassonomia di analisi. La maggior parte ha bisogno di un piccolo set che fidano e rivedono ogni rilascio.
| Categoria di Metrica | Metrica Chiave | Cosa Misura | Perché è importante per l'esperienza utente |
|---|---|---|---|
| Salute tecnica | Tasso di utenti crash-free | Quanti utenti completano le sessioni senza crash | La stabilità è un'aspettativa di base |
| Salute tecnica | Sessioni crash-free | Quante sessioni finiscono senza un crash | Mostra se gli errori sono concentrati o diffusi |
| Salute tecnica | Congelamenti di interfaccia | Momenti in cui l'interfaccia non è rispondente | Cattura della sensazione di lentezza, non solo il timing del backend |
| Salute tecnica | Tasti di rabbia | Tasti ripetuti sullo stesso elemento in un breve intervallo | Segnala confusione o mancanza di feedback |
| Attivazione | Tempo per la prima azione significativa | Quanto velocemente gli utenti raggiungono la prima azione utile | Mostra se i ritardi di onboarding hanno un valore |
| Partecipazione | Durata della sessione | Quanto tempo gli utenti rimangono attivi | Utile quando abbinato al contesto delle attività |
| Partecipazione | Utenti attivi e comportamento di ritorno | Se le persone tornano ripetutamente | Indica abitudine, utilità o entrambi |
| Funzionale | Conversione di ogni fase di flusso chiave | Completa a ogni stadio di flusso chiave | Identifica punti di sbarco esatti |
| Analisi del viaggio | Flussi e percorsi di schermo | I percorsi che gli utenti effettivamente seguono | Esponi loop, punti morti e deviazioni |
Alcune cautele sono necessarie qui.
Prima, non considerare automaticamente le sessioni più lunghe come buone. In un'app di supporto, una lunga sessione può significare confusione. In un'app di contenuto, può significare soddisfazione. Il contesto conta.
Secondo, non lasciare che un solo valore medio nasconda il dolore degli utenti. Un tempo di caricamento mediano può sembrare accettabile mentre uno schermo di onboarding specifico si congela su dispositivi Android più vecchi o uno schermo di sincronizzazione desktop si blocca dopo il risveglio.
Segui i momenti in cui gli utenti perdono fiducia, non solo i momenti in cui il tuo dashboard sembra sano.
L'obiettivo non è raccogliere tutto. È costruire un layer di misurazione che ti aiuta a decidere cosa riparare per primo.
Strategie pratiche per migliorare l'esperienza UX cross-platform
I team spesso cercano di migliorare l'esperienza UX aggiungendo prima la lustratura. Nuove animazioni, più illustrazioni di stato vuoto, impostazioni più ricche, personalizzazione extra. Queste modifiche possono aiutare, ma raramente salvano un'esperienza debole.
Per i prodotti cross-platform, i fondamenti vincono più spesso. La velocità che gli utenti possono sentire. I feedback che spiegano cosa sta succedendo. Flussi che sopravvivono a reti povere. Interfacce che rispettano le convenzioni del dispositivo su cui si eseguono.
Risolve la velocità percepita in primo luogo
La prestazione percepita è dove l'ingegneria può creare guadagni UX senza riscrivere l'intera app. Gli utenti non hanno bisogno di ogni byte caricato istantaneamente. Hanno bisogno di una rapida evidenza che l'app è pronta, rispondente e in movimento verso il loro obiettivo.
Di solito significa:
- Mostra un feedback immediato: I pulsanti dovrebbero cambiare stato non appena premuti. Se inizia il lavoro, dìlo.
- Usa i scheletri con cautela: Lavorano quando il layout finale è prevedibile. Non aiutano quando nascondono ritardi di backend evitabili.
- Ritarda il lavoro non critico: L'inizializzazione degli analytics, le richieste secondarie e gli asset di bassa priorità non dovrebbero bloccare la prima schermata utile.
- Riduci il peso degli asset: Le team cross-platform spesso trasportano immagini, fonti e dipendenze front-end troppo grandi, più a lungo di quanto si rendano conto.
Più tardi, quando avrete bisogno di spiegare un cambiamento ai stakeholder o ai revisori dell'app store creare demo di prodotto di alta qualità aiuta a rendere visibili miglioramenti UX in un modo in cui le schermate spesso non possono.
Un walkthrough visivo più approfondito può aiutare le squadre a mettersi d'accordo su cosa dovrebbe essere “veloce abbastanza” nella pratica:
Progettare per reti deboli e dispositivi disuguali
Molte consigli UX presuppongono una connettività stabile e hardware attuale. Gli utenti reali non vivono in quel mondo. Il pezzo di Prototypr su questioni di usabilità mobile trascurate calls out a neglected question: how the app behaves with no network, poor network, or expensive data. That’s especially important for Capacitor teams shipping to broad mobile audiences.
Modelli pratici di resilienza includono:
- Caching lo stato utile più recente: Se non è disponibile dati freschi, mostrare lo stato noto buono con un chiaro stato di attualità.
- Intenzione dell'utente in coda: Se qualcuno redige, invia o modifica una preferenza offline, conserva l'azione e sincronizza in seguito dove appropriato.
- Spiegare gli stati di sincronizzazione in modo chiaro: "Salvato localmente" e "in attesa di sincronizzazione" riducono l'ansia dell'utente più di un spinner senza testo.
- Riduci il rumore di rete: Aggiungi richieste in batch dove possibile e evita i modelli di ricarica a schermo intero dopo azioni piccole.
Per i dettagli di interfaccia utente che si traducono meglio tra iOS, Android e layer web condivisi, vale la pena esaminare le pratiche di interfaccia utente e esperienza utente cross-platform per le app Capacitor.
La affidabilità in condizioni avverse spesso conta più di aggiungere un'altra scheda di funzionalità.
Mantieni i modelli di interazione noiosi nei posti giusti
Questo è il lato contraddittorio. Una grande esperienza utente dell'app non sempre deriva dalla novità. Spesso deriva dalla moderazione.
La navigazione dovrebbe corrispondere alla piattaforma a meno che non ci sia un motivo forte per non farlo. Il comportamento del tasto Indietro dovrebbe essere predittibile. Le finestre del desktop dovrebbero ripristinarsi pulite. I modelli di conferma dovrebbero riservare la frizione per le azioni rischiose, non per quelle quotidiane.
Capacitor e Electron rendono facile la condivisione di code. Non eliminano comunque la necessità di rispettare il contesto. Gli utenti si aspettano ancora che i dispositivi mobili e desktop si comportino come se stessi, non come una piattaforma mediana compromessa.
Il Ruolo delle Aggiornamenti affidabili nella Migliorazione Continua dell'esperienza utente
La miglioramento dell'esperienza utente non è un progetto di design con una linea di arrivo. È una disciplina di rilascio. Si misura la frizione, si invia una correzione, si osserva cosa è cambiato, e si ripete.
Questo ciclo è ancora più importante nel lavoro cross-platform perché molti problemi di UX sono piccoli ma urgenti. Un stato di caricamento rotto, un feedback di bottone ritardato, un testo obsoleto, uno stato vuoto povero, o un passaggio di onboarding scomodo possono non giustificare un ciclo di sottoscrizione completo se la correzione vive in JavaScript, CSS, configurazione o risorse. Ma lasciarla nel campo ancora ferisce gli utenti.
Una correzione UX ha senso solo quando gli utenti ricevono effettivamente la correzione
Molti team parlano della velocità di iterazione come di un metro interno. Gli utenti l'esperienza in modo diverso. A loro la domanda è semplice: l'app è migliorata velocemente, o lo stesso problema fastidioso è rimasto per settimane?
Glassbox nota nel suo riassunto di metriche di app mobili che l'esperienza utente moderna delle app è giudicata da un utilizzo ricorrente, una completa di canale e affidabilità, con una percentuale di sessioni crash-free superiore al 99,5% e una percentuale di mantenimento del 30° giorno Riteniamo che l'esperienza utente sia un processo continuo e che la velocità di iterazione sia solo un aspetto di questo processo. come indicatori primari di successo. Questa prospettiva sposta l'attenzione dall'invio di volumi e verso il fatto che le migliorie raggiungano il percorso dell'utente in tempo utile.
Aggiornamenti affidabili fanno parte di ciò. Se la metà del tuo pubblico rimane su un bundle web più vecchio, i tuoi metrici si confondono. Il prodotto mostra comportamenti misti. Il supporto non può spiegare perché alcuni utenti ancora colpiscono un problema risolto. L'ingegneria perde fiducia nell'impatto della rilascio.
Usa il controllo del rilascio come parte del workflow UX
Un modello migliore è trattare le meccaniche di consegna come parte dell'esperienza utente dell'applicazione stessa.
Ciò significa fare cose come:
- Rilascia in modo ristretto per primo: Invia un cambiamento UX agli utenti interni, ai gruppi beta o a un segmento definito prima della rilascio ampio.
- Guarda l'adozione e le fallite: Hai bisogno di visibilità sulle dispositivi aggiornati, quelli falliti e quelli che sono tornati indietro.
- Lega i gruppi di rilascio al comportamento: Confronta l'attivazione della prima sessione, la completa del percorso del funnel o i segnali di frustrazione prima e dopo il cambiamento.
- Preserva un percorso di rollback veloce: Esperimenti di UX sono ancora modifiche di produzione. Se un nuovo flusso confonde le persone, annullalo velocemente.
Per le squadre che lavorano nell'ecosistema Capacitor, i servizi che spiegano come funzionano gli aggiornamenti in tempo reale per Capacitor rendono questo ciclo di rilascio più facile da operare. Una possibilità è Capgoche fornisce pacchetti web firmati per canali specifici per Capacitor e applicazioni Electron, applica gli aggiornamenti alla prossima esecuzione e fornisce funzionalità di rollback e di osservabilità. È utile quando il cambiamento UX vive nella layer web e hai bisogno di iterazione controllata senza dover attendere un ciclo di archiviazione completo.
La iterazione rapida aiuta solo quando la sicurezza di rilascio è sufficiente per cui la squadra si assicurerà di spedire la correzione.
L'osservabilità forte e la affidabilità degli aggiornamenti si incontrano. Le migliori squadre di UX non identificano solo la frizione. Le eliminano mentre possono ancora misurare la differenza chiaramente.
Mettere Tutte Le Cose Insieme Il Primo Ciclo Di Miglioramento UX
Molti team non hanno bisogno di un'overhaul di UX. Hanno bisogno di un ciclo stretto che dimostri che il processo funziona.
Inizia con un viaggio che gli utenti colpiscono presto e spesso. Primo avvio, onboarding, accesso, ricerca, acquisto, completamento di un modulo, o tornare a un compito in corso sono tutti buoni candidati. Scegli quello che più direttamente influenza se gli utenti raggiungono il valore.
Inizia con un viaggio, non con l'intera app
A una prima passata pratica, si presenta così:
- Scegliere un metro di esito: Il tempo per la prima azione significativa è un candidato forte per molti app.
- Rivedere i segnali di attrito intorno a quel flusso: Cercare crash, congelamento, ripetute tap, loop confondenti e punti di abbandono:
- Definisci un fix ristretto: Ridurre il lavoro di avvio, chiarire una schermata, eliminare un passo bloccante o migliorare il supporto offline per un'azione:
- Invia a un pubblico limitato: Tenere la zona di impatto piccola abbastanza da poter imparare in sicurezza.
- Confronta il comportamento dopo la rilascio: Cercare la completamento di un percorso più pulito e meno indicatori di frustrazione.
Questo impone la disciplina. Le squadre smettono di discutere l'esperienza utente in astratto e iniziano a testare se una specifica implementazione ha migliorato un percorso di viaggio utente specifico.
Avvia un piccolo ciclo e impara velocemente
La chiave è rendere il ciclo abbastanza noioso da ripeterlo. Non iniziare con un grande ri-design. Quelli spesso mescolano troppi fattori e rendono difficile capire cosa ha funzionato.
Invece, migliora un percorso alla volta e costruisci abitudini condivise basate su prove. Il prodotto dovrebbe sapere quale metrica conta. L'ingegneria dovrebbe sapere quale evento segna il successo. Il supporto dovrebbe sapere cosa è cambiato e come rilevare le disallineazioni degli aggiornamenti. Se si coordina la comunicazione di rilascio intorno a un nuovo workflow o capacità, un playbook di introduzione di un nuovo prodotto può aiutare le squadre a sincronizzare la comunicazione, le aspettative di rilascio e la preparazione interna. Un buon esperienza utente di app emerge in questo modo. Non da un singolo ri-design brillante, ma da molte correzioni misurate che eliminano la titubanza, ripristinano la fiducia e aiutano gli utenti a ottenere valore più velocemente.
Se si stanno inviando __CAPGO_KEEP_0__ o applicazioni Electron e si ha bisogno di un modo più sicuro per iterare sull'esperienza utente in produzione
Capacitor Capgo Continua da App User Experience: A Guide for __CAPGO_KEEP_0__ & Electron Teams
Keep going from App User Experience: A Guide for Capacitor & Electron Teams
App User Experience: A Guide for __CAPGO_KEEP_0__ & Electron Teams App User Experience: A Guide for Capacitor & Electron Teams per pianificare il lavoro dei plugin nativi, connettilo con Capgo Directory dei Plugin per il flusso di lavoro del prodotto nel Capgo Directory dei Plugin, Capacitor Plugin da Capgo per i dettagli di implementazione in Capacitor Plugin da Capgo Aggiungere o Aggiornare i Plugin per i dettagli di implementazione in Aggiungere o Aggiornare i Plugin, Sostituti dei Plugin Enterprise Ionic per il flusso di lavoro del prodotto in Sostituti dei Plugin Enterprise Ionic, e Capgo Costruzioni Native per il flusso di lavoro del prodotto in Capgo Costruzioni Native.
