Realizzare un’App basandosi sulla UI design Consistency

Giulio Cinelli app mobile, coding, soluzioni digitali

L’IMPORTANZA DELLA CONSISTENZA NELL’UI DESIGN


Per consistenza di un elemento grafico (UI Consistency) di design della nostra app si intende l'unificazione di design, colori forme e comportamenti che questo elemento assume all'interno del nostro ecosistema, e in relazione agli altri elementi.


Lato utente


Esistono vari tipi di consistenza per la UI, come quella di base (aspetti grafici), quella di comportamento degli elementi, esempio un bottone (visual consistency) e la funzionalità (functional consistency).
Inoltre ci sono diverse versioni della propria idea: app, web, desktop etc. Unificare questi elementi porta l'utente a utilizzare indistintamente uno di questi sistemi senza sentirsi smarrito.


Image

Sviluppo


Ognuno di questi sistemi ha però le proprie caratteristiche e particolarità grafiche (material design per Android o le linee guida Apple per iOS) per questo si parla di external consistency, che dipende dalla tipologia di utente e/o dalla piattaforma (iOS e Android).

Quindi anche lato sviluppo tener conto della UI consistency è molto importante, perché

  • Un progetto App che tiene conto della consistenza è più facile da sviluppare e più facile da imparare per i nuovi membri del team.
  • La consistency riduce la frustrazione di dover rimettere mano a elementi già creati ma non documentati, oltre a permettere risparmio di tempo e denaro per l'intero progetto

Come fare?


Bisogna definire una linea guida di design: metriche, colori, forme, dimensioni che il tuo prodotto deve usare. Inoltre è importante che tutti i team di sviluppo (ad esempio Android e iOS) siano sempre allineati e condividano la stessa nomenclatura.


Andate a vedere in GitHub primer  styleguide.io o alexpate su GitHub.


IL CASO YELP E YELP FOR BUSINESS


In questo caso d’uso vedremo come è stato gestito lo sviluppo UI delle App di Yelp, piattaforma per ricercare e recensire attività commerciali.

Questo servizio si presenta sotto forma di 2 app: Yelp e Yelp for Business (entrambe sia per iOS che Android). La prima è quella utilizzata dall’utente, mentre la seconda è dedicata agli esercenti che hanno registrato la loro attività sulla piattaforma.

In alcuni contesti però capita che un utente debba passare dall’app standard a quella Business, per esempio quando ad un potenziale utente Business viene segnalata la sua attività e invitato a registrarsi. L’azione finale avviene poi su Yelp for Business.

Pur essendo due app distinte, è necessaria una forte consistenza tra le due app perché l’utente non si perda e non si senta smarrito. D'altra parte la difficoltà di una soluzione del genere è anche quella di non creare confusione all'utente tra le due applicazioni nel caso in cui risultino troppo uguali.
Figura fondamentale per la realizzazione di un'app con queste esigenze è il lavoro del designer. Lo studio dei colori da utilizzare deve garantire uniformità ma anche diversificazione, per questo ogni colore deciso viene taggato in base all'utilizzo che se ne farà: web/mobile o background o bottoni.

La stessa cosa deve essere tenuta presente per iOS e Android, quindi per la consistenza esterna. Ci deve la consistenza anche se gli elementi vengono presentati in maniera “specifica” per la piattaforma. Prendiamo il menu. Mentre per Android il menu dettato da Google con il material design appare da sinistra verso destra, in iOS si comporta esattamente al contrario. È in questi elementi che va tenuto conto che consistenza significa coerenza e non vuole dire uguaglianza.


Design


Per ogni elemento grafico si può quindi parlare di API dell'elemento. Come avviene per ogni altra parte dell'app, questi elementi devono essere documentati e ne deve essere ristretta la modifica (onde incappare in errori a cascata su tutta l'applicazione).

Prima di creare un elemento, la strategia utilizzata da Yelp è quella di partire da queste domande:

  • posso riusarlo?
  • è visibile all'utente?
  • si deve/può mantenere?

Successivamente si va a sviluppare il componente. Per ogni componente aggiuntivo o modifica ad uno già esistente ci si comporta come segue:

    • si lavora prima alle risorse che servono (stringhe e stili) <resource >
    • si definisce il tema come sub-theme del tema padre: ogni componente deve poter essere copincollato e deve far vedere qualcosa anche senza nuovi elementi grafici perché lo prende dal tema di default padre.
    • nel codice si fanno le logiche di view nei setter non nel costruttore.
    • per lo <style> si fa over-ride dello stile di default di solo le parti che interessano.

    Inoltre il sistema integrato fa build della palette di colori e delle icone in svg per tutti i sistemi (web, Android, iOS)


    Image

    Build


    Per poter buildare e pushare viene richiesto di fare un test durante la pull request per chiedere informazioni su quello che si sta cercando di pushare. Per esempio, “è integrato o no?” “si può usare senza che entri in conflitto?”

    La strumentazione impiantata da Yelp è pensata per supportare anche i nuovi sviluppatori, in modo che non possano neanche per sbaglio pushare in remoto qualcosa che non sia conforme alle linee guida predefinite dal team. 
    Per esempio si può fare in modo che l'ide ti avverta se non stai usando il componente interno ma ne stai creando uno nuovo di tuo pugno (nuovo bottone).

    Ogni componente deve essere poi testabile con Espresso.


    Share


    Parte fondamentale del processo è quella di condividere i componenti creati con il resto del team. Oltre a condividere la sintassi per la corretta realizzazione grafica è anche importantissimo creare della documentazione in merito a comportamenti (cosa succede quando faccio una certa azione?), funzionalità e eventuali estensioni possibili (con o senza icona?).
    Per la documentazione è possibile seguire questi step:

    • javacod
    • screenshot
    • document attributes
    • document style

    La cattura degli screen può avvenire per fasi:

    1. manuali
    2. automatizzati locali
    3. automatizzati con CI

    La necessità di fornire uno showcase di come il componente potrà essere utilizzato è utile per tutte le parti del team sia che siano developer che designer.
    Per automatizzare il processo di screen ci si può affidare ad Espresso che durante i test può catturare gli screen dell'elemento nei suoi vari stadi.


    CONCLUSIONI


    Il concetto di consistenza è molto utile per poter concentrarsi sulle parti di BL senza preoccuparsi di dover reinventare componenti grafiche per ogni schermata nuova, dando anche uniformità vera all'applicazione.

    Di contro però queste linee guide devono poter essere flessibili, permettere cambiamenti ed essere abbastanza robuste da non crollare. Il concetto più difficile è che non devono essere una gabbia per nessuno.