Flutter design. UX e sviluppo

Inizio parlando dei due team e degli strumenti principali che utilizzano.

Dev team

Gli strumenti di coding principali usati per lo sviluppo mobile in Flutter sono Android Studio e/o Visual Studio Code.
Simulatori e telefoni per poter emulare l’applicazione direttamente su dispositivo (iOS e Android).

UX team

Tralasciando la fase creativa e di analisi, il team di UX concretizza le prime bozze di interfaccia tramite Adobe XD.

Ora arriva il bello…

UX + Dev = come si fa?

Sappiamo tutti (o almeno chi è del settore) quanto l’integrazione tra questi due mondi sia sempre un elemento cruciale in ogni progetto.

Designer che sognano in grande e developer che “no questo non si può fare”.
Developer che cercano di rispettare standard e pattern di sviluppo e designer che “no questo button lo dobbiamo mettere li”.

A mio avviso la soluzione è prima di tutto guidata dal buon senso e dal reciproco rispetto. Nella mia storia professionale, tante volte ho assistito a ‘scontri’ tra team che dimenticavano troppo spesso di lavorare per la stessa azienda e di avere gli stessi obiettivi! Ma questa è tutta un’altra storia…

Di seguito il nostro metodo!

Integrazione ux & dev in Flutter.

Oltre ad avere un gruppo coeso e professionale, abbiamo impostato il lavoro seguendo i seguenti punti fermi.

• definizione di standard (nomi file, struttura progetto).
• utilizzo di Adobe XD per la realizzazione della UX.
• utilizzo da parte del team Dev di Adobe XD + Adobe XD to Flutter plugin.
• utilizzo da parte del team UX di Android Studio + simulatore.

Vediamo nel dettaglio i 4 punti sopra elencati.

Definizione di standard

Per avvicinare due mondi con metodologie e pensieri differenti, ma con un unico scopo, è necessario a mio avviso impostare un ponte che permetta di poter comunicare in maniera semplice e diretta.

Tecnicismi e nomenclature, piuttosto che concetti propri di un determinato contesto, non sono sempre facilmente intuibili da chi non ne fa parte.

È quindi fondamentale individuare degli elementi standard in modo da essere chiari e immediati nella comunicazione.

Sembrerò esagerato, ma ho visto troppe riunioni tra esperti che, senza aver definito prima una base di comunicazione, provano a dialogare senza arrivare alla fine a nessun risultato utile. O peggio, arrivare ognuno convinto di qualcosa di diverso!

Abbiamo quindi optato per queste semplici definizioni:

• tutti i file Flutter che contengono elementi di esposizione dei contenuti sono definiti VIEW (nomefile_view.dart, NomeFilView per la classe)
• tutti i file Flutter che contengono i dati e quindi la logica di business sono definiti MODEL (nomefile_viewmodel.dart, NomeFileViewModel per la classe)
• i Decoration, gli Style e in generale tutti i widget Flutter che contendono opzioni di stile li definiamo STYLE (nomefile_style.dart, NomeFileStyle per la classe)
• Gli stili che valgono per tutta l’app sono definiti nel TEMA dell’applicazione

Ovviamente c’è molto di pattern architetturale in queste definizioni. Usiamo principalmente il MVVM (model — view model — view). Qui un link sul pattern (https://medium.com/flutterdevs/design-patterns-in-flutter-part-3-mvvm-a310de4eb83).

Dall’immagine sopra possiamo vedere una parte di alberatura di progetto.
Sotto ui sono presenti tutti elementi di esposizione.
shared contiene widget cross e di base (per esempio appbar)
theme contiene file di stile per l’intera applicazione.
view contiene tutti gli oggetti di interfaccia a sua volta divisi in cartelle raggruppate per concetto/oggetto funzionale.

Al suo interno sono presenti ulteriori strutture di styles e widget.

Mi rendo conto che è una definizione di standard più orientati allo sviluppo, ma il punto fondamentale è che i designer la conoscono. Sanno cosa intende il dev quando parla di style e/o di widget. Non devono occuparsene direttamente (loro useranno XD), ma la comunicazione è immediata.

Utilizzo da parte del team Dev di Adobe XD + Adobe XD to Flutter plugin.

Qui si realizza la vera unione.
Il team degli sviluppatori ha configurato nel proprio ambiente anche Adobe XD.
Scarica il progetto (versionato) con il disegno dell’interfaccia e…magia!

Un plugin XD permette di poter esportare direttamente il codice Flutter degli oggetti presenti sui file xd.
A questo indirizzo potete trovare il plugin per Adobe e annesse informazioni di setup e utilizzo -> https://github.com/AdobeXD/xd-to-flutter-plugin

In rete sono presenti innumerevoli tutorial. Non voglio quindi scrivere l’ennesimo how to in tal senso (anche perché risulta davvero facile da usare). Semmai aggiungo un paio di considerazioni.

• Attualmente non sostituisce il lavoro dei dev. E personalmente sono anche contento.
  Ovviamente i componenti esportati devono integrarsi nel codice seguendo le linee guida architetturali utilizzate dal team di sviluppo. Difficilmente il copia incolla è sufficiente. Anzi è spesso necessario scompattare ulteriormente gli elementi esportati.
• Occorre lavorare sul responsive.
  Le nuove versioni dei plugin sono migliorate in tal senso, ma Flutter predilige l’utilizzo di elementi relativi al contrario di alcune impostazioni assolute di XD. Occorre quindi apportare delle modifiche (come per esempio usare in flutter Row e Column), ma nulla di sconvolgente o complicato.
• Tutto STYLE.
  Quello che esportiamo e integriamo nel codice flutter sono per lo più oggetti di stile come Decoration e Style. Anche solo questo vale parecchio!!

Utilizzo da parte del team UX di Android Studio + simulatore.

I due team hanno ora definizione di base che permettono di fare allineamenti veloci evitando noiose perdite di tempo.
I developer hanno configurato Adobe XD e utilizzano il plugin Flutter per velocizzare l’integrazioni di elementi grafici e di ux.

Anche i designer, a loro volta, hanno configurato l’ambiente di sviluppo (Android Studio) e sanno far partire il progetto! In questo modo possono verificare l’integrazione fatta tra quanto realizzato su XD e quanto riportato in Flutter.

Non solo!
Avendo definito quali specifici file contengono le impostazioni di stile, il designer, avviando anche lui l’applicazione su emulatore, può eventualmente intervenire per piccole modifiche o accorgimenti (come per esempio aumentare dimensioni, effetti blur, sfocature ecc).
Anche solo per veloci verifiche.

Conclusioni

Ovviamente queste considerazioni valgono alla data attuale e con le competenze ad oggi acquisite.
Sicuramente si può e si deve migliorare ed eventuali suggerimenti sono ben accetti.

Ad oggi possiamo comunque dire che l’integrazione sta funzionando e stiamo ottenendo ottimi risultati sia in termini di qualità di quanto sviluppato sia in termini di lavoro di squadra.

Investiremo, come sempre, sulla formazione di tutti cercando di mantenere un corretto equilibrio tra competenze verticali di ognuno e trasversalità di conoscenze che permettono, senza ombra di dubbio, di poter comunicare e lavorare al meglio in team.

Scrivi a info@codeploy.it o a andrea.ciaccia@codeploy.it per ulteriori approfondimenti.