Ormai siamo abituati già da diverse decine di anni ad usare i computer sia per lavoro che per divertimento: siamo talmente abituati che riusciamo tranquillamente a districarci anche in nuove applicazioni perché magari somigliano ad altre. Le interfacce di applicazioni desktop per esempio hanno di solito un menù in alto che contiene almeno le voci “File”, “Modifica” o “Aiuto”.
Anche nelle interfacce web (i siti in particolare) l’utente è abituato a ritrovare elementi ricorrenti come il tasto “Home” (che di solito coincide con il logo del sito) o altre voci di menù posizionate orizzontalmente in alto o come lista sulla sinistra.
Questi elementi ricorrenti sono appunto Pattern, delle configurazioni di elementi grafici che richiamano gli schemi mentali degli utenti che hanno avuto modo di usare in precedenza applicazioni simili: questi schemi fanno sentire a suo agio l’utente che non avvertirà il sistema come “estraneo”.
Per le interfacce mobile dovrebbe valere lo stesso principio: affinché l’utente usi una applicazione questa deve essere effettivamente usabile nel senso accademico del termine. Soprattutto in un campo nuovo come quello mobile, lo studio delle interfacce è fondamentale principalmente perché:
- l’utente non ha pattern grafici mentali da richiamare e può sentirsi spaventato;
- in fin dei conti le applicazioni mobile non hanno molta logica… l’interfaccia è praticamente tutto!
Per riuscire quindi a far sentire l’utente a casa non abbiamo bisogno di approfondite nozioni sullo User-Centered Design o il Task-Centered Design ma c’è solo una importante considerazione da fare rispetto alle classiche applicazioni desktop e cioè il contesto d’uso: nel caso del mobile infatti l’uso di una app non sarà il task principale di un utente (cioè l’utente non sarà comodamente seduto sul divano mentre la usa) per cui eliminare disturbi cognitivi e semplificare l’interazione deve guidare la nostra progettazione. Basta quindi guardarsi in giro con un po’ di buon senso: ci sono soluzioni di interazioni utente che funzionano meglio di altre… per cui lasciamoci ispirare!
Il primo impatto è importante
Avere una schermata principale con le funzionalità (o categorie) principali può essere un ottimo punto di partenza. All’apertura, un nuovo utente capisce immediatamente cosa può fare l’applicazione, mentre l’utente usuale accede in pochi tap alla funzionalità desiderata. La dashboard dell’applicazione di Facebook ne è un esempio:
Nelle ultime versioni è stata anche aggiunta una barra che contiene le ultime immagini aggiunte dai nostri amici che, giustamente, compare solo negli schermi superiori a certe dimensioni.
Quando le funzionalità sono più articolate, la suddivisione dell’interazione grafica in tab è d’obbligo: l’utente si sposta tra “pagine” che contengono eventualmente delle dashboard raggruppate per funzionalità, riducendo il disturbo congnitivo che troppe informazioni portano all’utente. Non scordiamoci infatti che si tratta di applicazioni mobili i cui contenuti verranno fruiti nelle condizioni più inaspettate: semplificare l’interazione significa non far sforzare l’utente mentre usa la nostra applicazione mentre svolge altri compiti in contemporanea.
Barra delle azioni
Solitamente la parte alta dello schermo contiene il logo/nome dell’applicazione e non ha grandi funzionalità. Possiamo dare vita a questa barra informativa aggiungendo qualche azione ricorrente (quando applicabile) come il refresh della vista o una barra/pulsante di ricerca, come per esempio fa twitter:
Interagire con i dati
Quando abbiamo a che fare con la presentazione di diversi dati, la classica visualizzazione che ri ritrova nel mondo mobile è quella delle “list view“, ovvero dati presentati in elenco dove, alla pressione di un elemento, è possibile accedere al dettaglio. Nella stragrande maggioranza dei casi questo tipo di visualizzazione funziona. Se proprio siamo esigenti, forniamo la possibilità di visualizzare i contenuti in una “map view” o in una “icon view“: nascondiamo però questa impostazione nel tasto Option perché sarebbe di disturbo. Se invece le visualizzazioni sono alternative e hanno la stessa importanza, inserirle in tab è una buona idea, come in questo caso:
Azioni contestuali ai dati
Ci sono situazioni in cui all’utente fa comodo sapere che azioni può eseguire su un certo dato, un po’ come il click destro del mouse su Windows su un’icona. L’evento corrispettivo nel mondo mobile può essere il longpress o lo swipe (scorrere col dito lungo una riga). L’inconveniente di quesi eventi è che non sono così evidenti, quindi richiedono una certa esperienza dell’utente nelle interfacce mobile. Queste azioni possono essere racchiuse in un pannello modale (che disabilita l’interazione con i dati sottostanti) o tramite in modo meno intrusivo con dei piccoli popup come in figura:
Ricordiamoci comunque che Android non è un sistema esclusivamente touch: forniamo quindi un accesso alternativo non-touch agli eventi longpress o swipe.
Notifiche
L’utente vuole sempre sapere cosa sta facendo una applicazione mentre la usa: notificare quindi tutti gli eventi in corso. Il minimo sospetto di freeze ci fanno guadagnare inesorabilmente commenti negativi (che non vogliamo!).
Gli eventi da notificare possono essere feedback su certe azioni (per esempio: “File salvato!”) oppure messaggi di attesa durante i caricamenti. Se si prevede di effettuare operazioni che hanno tempi di caricamento considerevoli, è consigliabile inserire una progress bar (eventualmente anche con un tasto “Annulla”) per dare la percezione che il task richiesto è in esecuzione e fugare ogni dubbio di blocco dell’applicazione.
L’idea che ci deve guidare è che l’utente non deve mai pensare: “ma l’applicazione che sta facendo??!”.
Cose da non fare: gli antipattern
Istruzioni
Capita che alcune applicazioni visualizzino un breve tutorial su come si usa l’interfaccia grafica al primo avvio. Questo comportamento denota forse che:
- lo studio dell’interfaccia, se ha bisogno di spiegazioni, forse non è riuscito così bene;
- non tutti gli utenti hanno pazienza/voglia di leggere un tutorial appena aperta una applicazione.
Alcune applicazioni, come Winamp, aggirano il problema spiegando l’interfaccia grafica nelle preferenze. Il miglior approccio sembra comunque quello di spiegare le caratteristiche più avanzate “on the go“, ovvero nel momento in cui vengono visualizzate per la prima volta.
Nascondere le selezioni
L’evento swipe è spesso usato all’interno di view list per sostituire la riga selezionata con le azioni che possono essere fatte su di essa. Anche se è un effetto molto bello, di fatto se nasconde completamente l’elemento selezionato è sconsigliato perché può confondere l’utente in quanto copre il soggetto su cui si va ad operare.
Conclusioni
Gli esempi di questo post sono stati tratti da Android Patterns: tra i vari pattern mostrati, abbiamo pensato di dare evidenza a quelli che abbiamo ritenuto più comuni e più usati. Se vi interessa l’argomento, consigliamo di leggere attentamente i suggerimenti del sito prima di cominciare a sviluppare una nuova applicazione.
