La documentazione tecnica e di prodotto è destinata a essere pubblicata sempre più spesso anche online, in particolare su dispositivi mobili e oggetti IoT (Internet of Things, internet delle cose): ecco perché ritengo utile approfondire le linee guida del design di applicazioni per il mobile partendo dal libro di Theresa Neil, Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps, O’Reilly Media, Sebastopol, CA, USA, 2015.
Dal libro di Theresa Neil emergono spunti rilevanti per la comunicazione tecnica e di prodotto:
• L’importanza dei pattern ai fini dell’usabilità
• Il peso crescente dei contenuti visuali
• L’aspettativa dell’utente di poter manipolare direttamente i contenuti per fruirne in base alle sue esigenze (ricerca, ordinamento, filtro, zoom, ecc.)
• Il trend verso la cosiddetta ricerca implicita, ovvero la capacità dell’applicazione di proporre contenuti proattivamente, in base al profilo e al contesto operativo dell’utente
• La tendenza a supportare strumenti di input supplementari a quello testuale, in grado di collegare immediatamente mondo fisico e contenuti digitali (QR code [il più utilizzato], bar code, foto di prodotti, scansione della carta di credito, ecc.)
• L’accettazione da parte degli utenti solo di help contestuali e specifici, incentrati ognuno su un unico topic, redatto secondo un approccio di learning-by-doing (e, laddove applicabile, di gamification)
• L’importanza della raccolta e dell’ascolto del feedback degli utenti ai fini del miglioramento continuo dell’applicazione.
Argo CMS - Come duplicare e riclassificare una Revisione
Comunicazione tecnica e di prodotto: design per il mobile
1. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
1
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
Comunicazione tecnica e di prodotto:
design per il mobile
La documentazione tecnica e di prodotto è destinata a essere pubblicata sempre più
spesso anche online, in particolare su dispositivi mobili e oggetti IoT (Internet of
Things, internet delle cose): ecco perché ritengo utile approfondire le linee guida
del design di applicazioni per il mobile partendo dal libro di Theresa Neil, Mobile
Design Pattern Gallery: UI Patterns for Smartphone Apps, O’Reilly Media,
Sebastopol, CA, USA, 2015.
Dal libro di Theresa Neil emergono spunti rilevanti per la comunicazione tecnica e
di prodotto:
• L’importanza dei pattern ai fini dell’usabilità
• Il peso crescente dei contenuti visuali
• L’aspettativa dell’utente di poter manipolare direttamente i contenuti per
fruirne in base alle sue esigenze (ricerca, ordinamento, filtro, zoom, ecc.)
• Il trend verso la cosiddetta ricerca implicita, ovvero la capacità
dell’applicazione di proporre contenuti proattivamente, in base al profilo e al
contesto operativo dell’utente
• La tendenza a supportare strumenti di input supplementari a quello testuale,
in grado di collegare immediatamente mondo fisico e contenuti digitali (QR
code [il più utilizzato], bar code, foto di prodotti, scansione della carta di
credito, ecc.)
• L’accettazione da parte degli utenti solo di help contestuali e specifici,
incentrati ognuno su un unico topic, redatto secondo un approccio di
learning-by-doing (e, laddove applicabile, di gamification)
• L’importanza della raccolta e dell’ascolto del feedback degli utenti ai fini del
miglioramento continuo dell’applicazione.
2. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
2
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
Nell’introduzione alla seconda edizione del suo libro, Theresa Neil nota che nel giro di qualche anno le
metafore mutuate dal mondo desktop/web hanno lasciato il posto a metafore specifiche delle interfacce
mobile, e che si è compiuto il passaggio dal design neutrale rispetto al sistema operativo (SO) a convenzioni
grafiche distinte per i singoli SO, in particolare per quanto concerne la navigazione.
Seguire i pattern significa rendere più facilmente riconoscibili all’utente la struttura e le funzionalità della
app, semplificandone l’uso: l’interfaccia tende a diventare invisibile, non causa attrito, e l’utente può
concentrarsi sullo svolgimento dei compiti che si è prefissato.
Navigazione
Theresa Neil sottolinea l’importanza di distinguere con rigore fra tab bar, che contiene gli elementi della
navigazione primaria, e tool bar, che contiene gli strumenti di cui l’utente dispone nel contesto di una
videata e/o di un contenuto.
La navigazione è primaria ed eventualmente secondaria, persistente (sempre visibile) oppure a scomparsa.
La navigazione persistente orizzontale è indicata in questi casi:
• Gerarchia piatta (voci di pari grado)
• Poche voci (tendenzialmente 3 in Android, 5 in iOS)
• Esigenza di indicatori di stato (es. presenza di notifiche)
• Necessità di visibilità costante e di accesso rapido.
La navigazione persistente verticale è indicata in presenza di un numero maggiore di voci e/o quando le
etichette più lunghe o composte da titolo e descrizione di dettaglio. Tuttavia, ruba spazio ai contenuti,
soprattutto se le etichette sono lunghe e/o composite (le etichette solo grafiche occuperebbero meno
spazio, ma rischiano di non essere chiare).
Theresa Neil raccomanda che la tab selezionata differisca graficamente da quelle non selezionate per
indicare all’utente la posizione in cui si trova.
Navigazione a scomparsa:
• Tendenzialmente è laterale, a sinistra. Può essere collocata anche a destra oppure in alto (nel qual
caso non deve coprire per intero la videata), mai in basso
• Alla prima apertura della app è opportuno aprire il menu, cosicché l’utente ne scopra l’esistenza.
Successivamente, il menu può essere aperto/chiuso mediante un apposito bottone
• Può essere gerarchica e contenere indicatori di stato
• Non deve essere scrollabile.
Per navigazione secondaria Theresa Neil intende quella che permette di accedere a voci collocate
all’interno di pagine successive alla prima. I pattern della navigazione secondaria coincidono con quelli della
navigazione primaria, ma è necessario comunicare chiaramente all’utente l’esistenza di pagine seguenti (es.
3. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
3
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
con scrolling tab da sfogliare orizzontalmente oppure con accordion da espandere/comprimere
verticalmente).
Form
Login / Sign-in
Nel modulo di login Theresa Neil consiglia di:
• Includere solo i campi per l’inserimento delle credenziali, il bottone Login, un help (es. funzione di
recupero delle credenziali) e, se previsto, il link al modulo di registrazione
• Visualizzare la password in chiaro (per facilitarne la verifica da parte dell’utente), offrendo l’opzione
per mascherarla
• Valutare l’opportunità di includere funzioni di social login
• Nel caso di app meno sensibili (es. non quelle in ambito bancario, finanziario, sanitario, ecc.),
valutare l’opportunità di salvare nelle impostazioni il nome utente alla prima apertura della app,
chiedendo per gli accessi successivi il solo inserimento della password.
Il modulo di login va posizionato nel punto in cui è richiesto il passaggio da funzioni/contenuti pubblici a
quelli destinati all’utente registrato.
Registrazione
Nel modulo di registrazione Theresa Neil consiglia di:
• Non richiedere la conferma dell’inserimento di e-mail e password
• Etichettare i campi in modo chiaro, collocando le etichette al di sopra dei campi cui si riferiscono
(anziché a sinistra, per motivi di spazio)
• Fornire all’utente feedback in-line in fase di compilazione, anziché al momento della richiesta di
invio del modulo
• Visualizzare la password in chiaro (per facilitarne la verifica da parte dell’utente), offrendo l’opzione
per mascherarla
• Se un utente già registrato, cioè con un indirizzo e-mail già in uso, tenta di registrarsi nuovamente,
reindirizzarlo alla pagina di login, con opzione di recupero delle credenziali.
I moduli multi-step, fra cui sono da annoverare anche i configuratori, possono presentare ogni passaggio in
una videata o in un DIV dedicati, indicando sia il numero complessivo di step previsti, sia il numero dello
step a cui si trova l’utente. Funzioni di avanti/indietro permettono all’utente di percorrere i passaggi in
modo non lineare. Va prevista una lista delle opzioni selezionate.
Check-out (del Carrello)
Per il check-out Theresa Neil consiglia di:
• Prevedere, oltre al login, anche un profilo Guest (Ospite) per gli utenti che non intendono
registrarsi, con l’opzione di convertire i dati guest in registrazione a check-out avvenuto
4. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
4
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
• Realizzare una sola pagina di check-out con DIV espandibili per completare le informazioni richieste
al completamento dell’acquisto
• Offrire shortcut, es.: riprendere automaticamente dall’account dell’utente informazioni note;
proporre vari metodi di pagamento; supportare la funzione di scansione della carta di credito (per
rendere l’input più rapido)
• Supportare il check-out rapido per utenti già registrati, che abbiano salvato tutte le informazioni
necessarie a completare l’acquisto (es. l’acquisto 1-click proposto da Amazon)
• Innovare, es.: all’interno dei punti vendita Walmart permette al cliente di scansionare i prodotti che
desidera acquistare, pagare con carta di credito e saltare quindi la fila alla cassa; all’atto della
scansione del prodotto, fornire informazioni su promozioni anche personalizzate per l’utente; nelle
vetrine dei negozi (in particolare nei giorni/orari di chiusura) e nelle pubblicità fisiche, inserire QR
code che permettano all’utente di scansionare il prodotto e acquistarlo online.
Tabelle
A causa degli spazi ridotti, le tabelle sono un punto dolente delle app. Ecco alcuni consigli per migliorarne la
fruibilità:
• Le tabelle di base dovrebbero essere caratterizzate da separatori solo orizzontali, intestazioni fisse,
righe a lettura facilitatati, allineamento dei dati a sinistra per i testi e a destra per i numeri
• In caso di tabelle senza intestazioni, ogni riga visualizza tutte le informazioni relative a un singolo
record, con il dato primario (es. il codice articolo) in evidenza
• In presenza di tabelle composte da numerose colonne, valutare l’opportunità di fissare la prima
colonna di sinistra, rendendo le altre scrollabili orizzontalmente. La sfida sta nel comunicare
chiaramente all’utente la possibilità di scorrere per accedere ai contenuti delle colonne “nascoste”
• Se la tabella espone dati raggruppabili per sottoinsiemi omogenei (es. anno, categoria
merceologica), evidenziare il raggruppamento con un titoletto interno
• Se la tabella espone dati sintetizzabili o visualizzabili sotto forma di diagramma, inserire il
sommario/diagramma di sintesi al di sopra della tabella di dettaglio
• Fare attenzione alla leggibilità e a non creare un sovraccarico di informazioni se la tabella include
indicatori visuali (es. pittogrammi, diagrammi, ecc.).
Ricerca
La ricerca può essere implicita o esplicita.
La ricerca implicita è la proposta proattiva di contenuti in base al profilo dell’utente e al suo contesto
operativo (tempo, luogo, azione). Theresa Neil sottolinea che si tratta del trend emergente e che va
considerata la prima opzione da valutare. Fra le ricerche implicite può rientrare anche il suggerimento delle
ricerche popolari all’interno di una determinata community.
Per realizzare uno strumento di ricerca esplicita efficace, ecco i consigli di Theresa Neil:
• Nelle opzioni di default, includere solo il/i campo/i necessari o più utilizzati
5. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
5
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
• Inserire moduli di ricerca lunghi all’interno di una pagina scrollabile, anziché paginarli
• Posizionare i bottoni invia/annulla secondo le specifiche dei diversi SO
• Supportare varie modalità di input, oltre a quello testuale, es.: scansione di QR code, bar code o
foto; voce; manipolazione diretta di un oggetto (in particolare di mappe geografiche)
• Salvare le ricerche in modo esplicito o consentirne il salvataggio esplicito (salva con nome…) da
parte dell’utente
• In fase di input, visualizzare la lista di ricerche rilevanti già effettuate (salvate in modo implicito
dalla app o esplicito dall’utente)
• Supportare l’auto-completamento, che gli utenti si aspettano di trovare e che Theresa Neil invita a
considerare ormai uno standard
• Assieme all’auto-completamento, supportare anche il filtraggio dinamico, visualizzando via via solo
i risultati rilevanti rispetto all’input dell’utente. Il loading indicator va previsto solo se è vi è il rischio
che i risultati siano in ritardo sull’input
• Se la app si articola in sezioni fortemente caratterizzare, valutare l’opzione di supportare la ricerca
verticale (scoped search), suggerendo all’utente di selezionare la categoria (es. libri, musica, ecc.) in
cui cercare l’espressione inserita. Il numero di categorie proposte dovrebbe essere compreso fra 3
e 5
• I risultati non vanno paginati e, se molto numerosi, visualizzati solo in parte, mentre l’app procede
a caricare i restanti (lazy loading)
• Supportare notifiche in-app sulle ricerche esplicite salvate (es. se l’utente ha salvato la ricerca
relativa a un prodotto, riceve una notifica in caso di variazione del prezzo o di errata corrige).
Ordinamento
Le opzioni di ordinamento possono essere proposte in fase di input dell’espressione da cercare oppure a
posteriori, sui risultati. Un’apposita icona permette all’utente di accedere alla lista dei criteri contestuali.
Filtri
I filtri sono utili per grandi set di dati per ottenere un numero di risultati inferiore, ma maggiormente
rilevanti. Un’apposita icona permette all’utente di accedere alle opzioni.
È opportuno prevedere il filtraggio dinamico, visualizzando via via solo i risultati rilevanti rispetto all’input
dell’utente. Il loading indicator va previsto solo se è vi è il rischio che i risultati siano in ritardo sull’input. Va
invece sempre prevista una lista dei criteri applicati, con la possibilità di modificarli e resettarli.
In alcuni contesti (es. mappe geografiche), l’input del filtro può essere dato anche dalla manipolazione
diretta dell’oggetto.
Strumenti (tool)
La tool bar (e l’eventuale tool box che raccoglie sotto-categorie di strumenti) è simile alla tab bar, ma
contiene gli strumenti con cui agire sui contenuti della videata corrente.
6. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
6
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
La posizione della tool bar dipende dal SO: in iOS è in basso, in Android in alto (tenendo conto che la action
bar contiene però anche gli elementi di navigazione, e che voci del menu e strumenti meno utilizzati vanno
inseriti nell’overflow menu a scomparsa, accessibile tramite l’apposito bottone).
Per ragioni di chiarezza, è opportuno che le icone siano provviste di etichetta, eventualmente a scomparsa.
Se, all’interno della videata, l’utente può compiere solo una azione (oppure due azioni di cui una primaria e
l’altra secondaria), è opportuno prevedere – anziché la tool bar – uno o due bottoni con call-to-action (CTA)
esplicita. I bottoni possono essere contestuali oppure persistenti (collocati tendenzialmente in basso, al
centro), se la app è dedicata integralmente al compimento di una sola operazione.
Se lo strumento agisce non a livello di videata, ma di singolo contenuto, il bottone diventa di una “in-line
action”. Tendenzialmente si tratta di bottoni a 2 o più stati (es. lo stesso bottone cambia stato passando da
“Scarica PDF” ad “Apri PDF” oppure a “Cancella” a “Sei sicuro di voler cancellare?” a “Cancellato”). Studi
dimostrano che gli utenti preferiscono interagire con i bottoni multi-stato, anziché con le finestre di dialogo
(poiché l’interazione è più immediata e veloce).
Dipendentemente dal tipo di contenuti e operazioni, valutare l’opportunità di supportare azioni bulk, es.:
riordinare, cancellare, ecc. tutti gli elementi selezionati.
Diagrammi
Ogni diagramma deve raccontare una storia, evidenziando relazioni importanti fra i dati esposti. Se più
diagrammi contribuiscono alla narrazione di una storia unica, possono essere collocati all’interno di una
dashboard. In questo contesto possono risultare utili le “spark-line”, mini-diagrammi che visualizzano solo
le informazioni di base, permettendo di accedere alla versione completa.
Titolo, etichetta degli assi e dati sono gli ingredienti di base di ogni diagramma.
Il tap va supportato per ottenere dettagli su uno specifico data-point, procedendo eventualmente anche
per approfondimenti successivi.
Nel caso di diagrammi a estensione orizzontale, è opportuno supportare la rotazione dello schermo per
vederne meglio i contenuti, nonché le consuete funzioni di pinch e pan per zoomare e navigare il
diagramma.
Feedback
Theresa Neil suggerisce che:
• I messaggi di errore siano ben visibili, chiari all’utente tipico della app e proporre una soluzione.
Nella compilazione dei moduli è preferibile prevenire gli errori, fornendo all’utente feedback in-
line, mentre sta compilando il modulo
7. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
7
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
• I messaggi di conferma siano limitati per azioni critiche e visualizzati in modo tale da interrompere il
meno possibile il flusso di lavoro (es. mediante messaggi “toast”, che scompaiono
automaticamente dopo 5 secondi o meno)
• I messaggi di stato del sistema siano incentrati sulla comunicazione del progresso verso l’obiettivo,
non sull’attesa in sé. Valutare l’uso di “skeleton screen”, i cui contenuti si caricano via via, a partire
da quelli più leggeri (l’utente non deve attendere il caricamento di tutti i contenuti per iniziarne la
fruizione).
Affordance
Si tratta degli stilemi grafici convenzionali, anche specifici per ogni SO, che indicano all’utente che è
possibile fare tap su un elemento, sfogliare una pagina, scrollare una videata, trascinare o zoomare un
oggetto, ecc.
Le invitation, particolari tipi di help contestuali, possono aiutare l’utente a scoprire funzioni nuove e/o
avanzate presenti sulla videata o sul contenuto. Le invitation possono essere persistenti (visualizzate finché
l’utente non compie l’operazione suggerita) oppure a scomparsa. Per essere percepita positivamente dagli
utenti, ogni invitation deve essere contestuale e specifica, concentrandosi su un solo topic.
Help
Theresa Neil passa in rassegna i vari tipi di help:
• How-to per illustrare step-by-step i passaggi delle procedure operative
• Manuale/help online: più approfondito e da organizzare per topic. Dovrebbe essere contestuale al
compito che l’utente sta cercando di portare a termine
• FAQ: raccolta di coppie domanda/risposta basate sui quesiti reali degli utenti e organizzate in base
alle reali priorità
• Tutorial: studi dimostrano che, di tutti quelli sopra elencati, è quello meno sgradito agli utenti,
poiché possono imparare facendo e, se possibile, divertendosi
• Valutare l’opportunità di integrare User Feedback Tools, come User Voice o Get Satisfaction, che
rendono facile catturare il feedback degli utenti, basilare per il miglioramento continuo della app.
Theresa Neil sottolinea che le guide non sono generalmente bene accette, ma fornisce alcuni consigli per
realizzarle al meglio in caso di necessità. Esse:
• Non devono caricarsi automaticamente alla prima apertura della app
• Devono privilegiare interazione e multimedialità all’esposizione testuale, ed essere quindi
improntate al learning by doing e, se applicabile, alla gamification
• Devono essere contestuali
• Vanno integrate nella progettazione della app e sottoposte a miglioramento continuo, basato sul
feedback degli utenti.
8. Kea s.r.l. | Via Strà, 102 | 37042 Caldiero (VR)
Tel. / Fax: +39 045 6152381
Web: www.keanet.it | E-mail: info@keanet.it
8
Mobile Design Pattern
Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it) | Dicembre 2016
Anti-pattern
Fra gli esempi negativi da non seguire spiccano:
• Elementi dell’interfaccia grafica non standard per il tipo di applicazione (app, web, desktop) e per il
SO, esposti nelle linee guida ufficiali
• Introdurre elementi di complessità a discapito dell’efficienza con cui l’utente può portare a termine
il suo compito
• Scegliere la metafora errata a livello di applicazione (non corrispondente allo schema mentale
dell’utente tipico) e/o di interfaccia
• Inserire finestre di dialogo inutili, che interrompono il flusso di lavoro dell’utente (es. richieste di
conferma su azioni non critiche)
• Introdurre nei diagrammi ornamenti grafici non funzionali alla comprensione dei dati
• Portare la app dalla piattaforma originaria a un’altra piattaforma, senza “localizzarne” l’interfaccia.
Autore: Petra Dal Santo – KEA S.r.l. (dalsanto@keanet.it)