Introduzione All'usabilità 18641f

INTRODUZIONE ALL’USABILITA’

Progettare applicazioni usabili per dispositivi mobili

Gioele Stefano Luca Fierro

© 2008 Gioele Stefano Luca Fierro.

Tutti i diritti sono riservati.

ISBN 978-1-291-53250-0

2

INDICE

1 - INTRODUZIONE

1.1 Obiettivi del testo ............................................................... 7

1.2 Veduta d'insieme ................................................................ 9

1.3 Com'è scritto ...................................................................... 11

2 - USABILITA'

2.1 Principi fondamentali ....................................................... 13

2.2 L'esperienza utente ............................................................ 17

2.3 Come si misura .................................................................. 18

2.4 Riconoscibilità grafica ....................................................... 23

2.5 Qualità del contenuto ........................................................ 25

2.6 Semplicità non è omologazione ....................................... 26

3 - PROGETTAZIONE

3.1 Contenuti e usabilità .......................................................... 28

3.2 COSA ................................................................................... 28

3.3 CHI ..................................................................................... 30

3.4 COME ................................................................................. 32

4 - NAVIGAZIONE

4.1 Navigazione ed usabilità ................................................... 38

4.2 Alberi di navigazione ......................................................... 38

4.3 Menu ..................................................................................... 42

4.4 Barra di navigazione ........................................................... 47

4.5 Cicli infiniti .......................................................................... 48

5 - LE RISORSE

5.1 L’usabilità .............................................................................. 52

5.2 Principi chiave ...................................................................... 53

5.3 Tabella di controllo dell’usabilità ....................................... 55

3

Per qualsiasi idea o suggerimento che riguardi i contenuti del libro o la

sua forma è possibile contattare l’autore

www.promezio.com

[email protected]

4

a Grazia, che riempie ogni giorno della mia vita con una dose di amore

di cui non posso fare a meno

ai miei genitori, che hanno sempre creduto nelle mie scelte anche

quando in fondo non ci credevo nemmeno io

6

1 – INTRODUZIONE

1.1 Obiettivi del testo

Quando sorgeva la necessità di comunicare con un cliente, venti anni

fa, mio padre non doveva far altro che dettare la missiva alla segretaria

e chiederle di spedirla.

Oggi manda una mail. Un’email è più veloce, incredibilmente più

veloce. Più comoda, permette di allegare un’intera collezione di

cataloghi senza utilizzare nessuno scatolone. Una mail è più versatile,

più efficiente, meno costosa, più rispettosa dell'ambiente e molto altro

ancora ma … è più semplice? Per mio padre no.

Il “programma” di scrittura manuale di una lettera, è quanto di più

semplice si possa immaginare. I i da fare sono elementari, logici,

congruenti. L'unica skill richiesta è l'abilità alla scrittura, cosa che

acquisiamo sin da bambini. Il resto viene da se.

Tutto questo preambolo non è stato scritto come inno contro la

tecnologia, anzi! Oggi i dispositivi tecnologici mobili connessi alla rete

permettono l'impossibile, permettono di fare molto e di farlo più

velocemente. L'abilità dello sviluppatore risiede proprio nel rendere

questo processo intuitivo, semplice, lineare; rendere le operazioni

necessarie all'uso dell'applicazione logiche e intuibili. Permettere

all'utente di eseguire l'operazione per la quale ha aperto l'applicazione

senza stare lì a riflettere su “quale pulsante premere” o magari a leggere

qualche noiosissimo manuale d'istruzioni.

Tutto questo, per brevità, lo definiremo come usabilità.

Nel corso di questo testo, parleremo di applicazioni pensate per

dispositivi mobili, riferendoci sia ad applicazioni native per

smartphone/tablet che ad applicazioni web.

La stragrande maggioranza delle applicazioni oggi sono interface-centric, la presentazione del contenuto, ed il contenuto stesso, devono essere

7

stilisticamente curati per poter emergere tra tanta concorrenza

mediocre.

Facciamo un esempio pratico. Esistono centinaia di applicazioni, che

permettono di leggere libri digitali ma “iBook”, l'app creata

direttamente da Apple e disponibile gratuitamente su AppStore, ha

rappresentato una piccola rivoluzione del settore, non tanto per l'idea

(nulla di davvero innovativo) ma per la grandiosa esperienza d'uso che

la sua interfaccia grafica e il suo ecosistema permette. Ora tutte le altre applicazioni la imitano. Questo ci insegna che un’idea da sola non

basta, in queste pagine ci proponiamo di analizzare i meccanismi dietro

la progettazione di GUI efficaci e usabili; insomma la progettazione di

applicazioni di successo. Cercheremo di analizzare le tecniche migliori

per garantire che il risultato finale della progettazione non sia solo

esteticamente gradevole ma anche semplice e funzionale.

In questo testo non vedremo righe di codice, il mondo dei dispositivi

mobili è in continua progressione, questo significa nuovi linguaggi,

nuove librerie, nuovi ambienti di sviluppo e nuove funzionalità. Per

rendere quanto imparato davvero utile, esamineremo tecniche che hanno valenza universale, indipendentemente dalla piattaforma o dal

linguaggio utilizzato per lo sviluppo.

Mi sono sforzato per rendere i capitoli quanto più generalisti fosse

possibile. Le differenziazioni tra applicazioni native e applicazioni web

sono minime dal punto di vista dell'usabilità, eviteremo

approfondimenti al codice specifico della piattaforma o alle specifiche

metodologie di implementazione per concentrarci su cosa rende un app

usabile e su cosa deve fare il progettista quando ne deve organizzare i

contenuti.

8

1.2 Veduta d'insieme

Vediamo ora in anteprima le singole parti che andranno a comporre

questo testo. In questo modo il lettore potrà avere un’idea generale del

contenuto dei capitoli che si appresta a scegliere.

CAPITOLO 2: USABILITÀ

In questa prima parte scopriremo cos'è l'usabilità e a cosa serve.

Impareremo a capire quando una GUI è usabile e quando invece non

lo è, cercando metodi empirici per misurare con esattezza questa

caratteristica. Si darà poi risalto agli scenari di utilizzo che influenzano pesantemente le valutazioni sull'usabilità delle interfacce grafiche

mobili.

CAPITOLO 3: PROGETTAZIONE

Un’applicazione priva di contenuto, con un contenuto scadente o

ancora con un contenuto disorganizzato non potrà mai essere usabile.

La prima tipologia di progettazione necessaria è quella del contenuto, il

resto potrà così contare su una solida base orientata all’usabilità.

CAPITOLO 4: NAVIGAZIONE

Muoversi all’interno dei contenuti è un'impresa delicata, è facile

compromettere l’usabilità proponendo all’utente percorsi intricati per

arrivare a ciò che cerca, o addirittura confonderlo contenuti non

pertinenti. Il secondo o di progettazione prevede la costruzione di

strutture di navigazione usabili, e su questo che è stato costruito il

quarto capitolo di questo libro.

9

CAPITOLO 5: LE RISORSE

Idee chiave e concetti principali riassunti in pochissime pagine per

fissare quanto detto e creare uno schema ben preciso dei contenuti.

Una tabella di verifica conclusiva aiuterà il lettore a capire (durante e

dopo la progettazione) se si sta seguendo la giusta strada in quanto ad

usabilità.

Ho cercato di rendere tutte le parti di questo libro quanto più

indipendenti mi fosse possibile, così da consentire una lettura

personalizzata, ogni capitolo è una sezione che può essere compresa a

se, naturalmente prevedendo un minimo di competenze propedeutiche

già in possesso del lettore. Se si legge per la prima volta di usabilità

comunque è consigliato leggere il testo in maniera progressiva,

seguendo l’ordine dei capitoli, così tutte le propedeuticità saranno

garantite.

10

1.3 Com'è scritto

Per ottimizzare la consultazione del testo sono stati adottati alcuni

accorgimenti, nulla di articolato, ma sarà utile conoscerli prima di

proseguire.

Ogni sottotitolo avrà una doppia numerazione del tipo x.y che

permette di ricondurlo a un dato capitolo (x). Ad esempio il sottotitolo

2.3 sarà il terzo del secondo capitolo.

Per le immagini che correderanno i testi, sarà usata una numerazione

simile, del tipo x.y.z. Ogni immagine quindi sarà facilmente associabile

al capitolo (x) e al paragrafo (y) di appartenenza. Ad esempio

l'immagine 2.3.1 sarà la prima presentata nel terzo sottotitolo del

secondo capitolo.

Ricordo che le immagini utilizzate servono soltanto ad esplicare i

concetti, non sono immagini di reali interfacce grafiche. Sono spartane

rappresentazioni schematiche ma sono utili allo scopo di visualizzare

praticamente quanto spiegato.

All'interno dei paragrafi sono state introdotte delle differenziazioni

tipografiche.

Le frasi o le parole in questo formato (corsivo) sono importanti per la comprensione del periodo nel quale sono inserite e vanno quindi lette con maggiore attenzione.

Le frasi o le parole in quest'altro formato (grassetto) invece

andranno considerate come elementi chiave, ovvero concetti

fondamentali che devono essere ben compresi e assimilati per

dare un senso generale all'argomento in questione.

Utilizzando al meglio tutti questi strumenti il testo sarà profittevole,

piacevole e semplice da leggere.

O per lo meno … ho fatto del mio meglio per renderlo tale !

11

Per qualsiasi informazione o suggerimento potete scrivere all'autore

tramite email all'indirizzo [email protected]

Qualsiasi opinione è sempre gradita (anche se negativa) quindi sentitevi

liberi di scrivere senza remore alcuno.

Quanto c'era da conoscere prima di accingersi alla lettura del testo vero

e proprio termina qui. Buon proseguimento nel percorso che vi

introdurrà nel mondo dell'usabilità.

12

2. USABILITA'

2.1 Principi fondamentali

L'usabilità in informatica è uno STANDARD che riguarda

l'interfacciamento dei dispositivi computerizzati con l'uomo. Come

ogni standard è stato classificato da una norma ISO, cioè

dall’International Organization for Standardization.

Esistono 3 documenti principali che espongono le normative

riguardanti l'usabilità: ISO 9241, ISO/IEC 9126 e ISO 13407.

La definizione più elastica ed interessante è quella contenuta nella parte

11 del primo (e più importante) documento di quelli citati sopra:

“Il grado in cui un prodotto può essere usato da

specifici utenti per raggiungere specifici obiettivi

con efficacia, efficienza e soddisfazione.”

Questa definizione è il fondamento su cui si baserà tutto il testo, quindi

per comprenderla a pieno, in tutte le sue sfaccettature, esamineremo

tutte le parole chiave che ne specificano il significato.

Specifici Utenti/Specifici Obiettivi

L'usabilità non è una caratteristica intrinseca a una qualsiasi

applicazione ma è un insieme di fattori che permettono di valutare l'uso

del prodotto nel suo ambiente e per gli scopi esatti per il quale è stato

progettato.

13

Facciamo un esempio, se due astronauti portassero sulla luna uno

smartphone per usare un’applicazione che sfrutta l'accelerometro come

controller, sicuramente non riuscirebbero a controllarla in modo

adeguato e quindi non raggiungerebbero i loro scopi. Vuol dire questo

che l'applicazione non è usabile? O che i controlli sono stati progettati

male? Senza dubbio NO! E' il contesto a rendere inusabile

l'applicazione.

Anche se in modo meno palese rispetto all'esempio precedente, ogni

applicazione ha il suo campo di utilizzo, è progettata pensando a un

insieme di specifici utenti che vogliono raggiungere obiettivi

predeterminati. Per definire e misurare l'usabilità quindi dobbiamo

tenere conto di questi fattori fondamentali di specificità, fattori che

sono definiti come gli “scenari d'utilizzo” del prodotto software.

Efficacia

Un qualsiasi strumento è efficace quando raggiunge l'obiettivo

preposto, quando permette di ottenere l'effetto desiderato. Allo stesso

modo un software è efficace quando permette all'utente di raggiungere

lo scopo per il quale lo sta utilizzando.

L'efficacia perfetta non è ottenibile, cioè non si può garantire che

l'utente raggiunga SEMPRE lo scopo; possono insorgere errori e

problemi che esulano dai poteri dello sviluppatore. Ad esempio

malfunzionamenti o guasti hardware improvvisi. Anche involontarie

azioni errate dello stesso utente potrebbero portare all'interruzione

dell'esecuzione.

Lo scopo di ogni sviluppatore è quello di prevenire il maggior numero

di problemi e controllarli per permettere all'utente di raggiungere lo

scopo o per lo meno di salvare tutti i progressi e i dati che

l'applicazione contiene nel momento dell'interruzione.

14

Efficienza

Un prodotto software è efficiente quando sfrutta al meglio risorse del

dispositivo durante la sua esecuzione. Una volta stabilito lo scopo di

un’applicazione bisogna quindi capire qual'è il modo migliore per

raggiungerlo usando meno risorse possibili.

Le risorse principali di un dispositivo mobile sono la U e la RAM.

Ottimizzare l'uso della U significa semplificare al massimo le

operazioni da eseguire ed evitare ridondanze e cicli inutili che non sono

indispensabili alla meta preposta.

I dispositivi di ultima generazione sono dotati di U molto

performanti, sempre più spesso multicore, questo porta gli sviluppatori

a sottovalutare questo tipo di ottimizzazione in applicazioni non

particolarmente critiche.

Per ottimizzare l'utilizzo della memoria è invece importante gestire al

meglio gli elementi multimediali dell'applicazione e i dati contenuti nei

DataBase. Tutti i dati salvati che vanno deallocati non appena terminano il loro scopo. Android fornisce un sistema di gestione della memoria

automatico (il java integra un garbage collector) mentre in Objective-C,

il linguaggio usato per sviluppare applicativi per iOS, la gestione della

memoria è completamente affidata allo sviluppatore, che deve avere

maggiore attenzione nello scrivere il codice ma nel contempo ha più

controllo sulla memoria.

In applicazioni che sfruttano molto la GPU del dispositivo è essenziale

valutare l'efficienza d'utilizzo di questa risorsa e ottimizzarla come

avviene per le altre appena menzionate.

Questo è particolarmente importante per applicazioni che utilizzano

motori grafici in 3 dimensioni e che di conseguenza richiedono grandi

capacità di elaborazione.

15

Soddisfazione

Quest'ultimo principio è il più complesso, sia da acquisire che da

raggiungere.

Dopo aver garantito all'utente efficienza ed efficacia bisogna far si che

si trovi a suo agio nell'usare l'applicazione.

Rifinire un’interfaccia grafica per renderla soddisfacente è come

arredare una casa, bisogna tener conto dei gusti e delle idee del target a

cui si rivolge, bisogna tenere conto del contesto generale e soprattutto

del contesto utilizzativo delle varie parti che la compongono.

Nessun architetto inserirebbe un piano cucina in camera da letto, per

quanto bello e confortevole possa essere, perché non è il posto giusto,

sarebbe fuori luogo e non incontrerebbe le necessità dell'utilizzatore,

dell'inquilino in questo caso.

Così nell'inserire qualsiasi elemento dobbiamo tener conto di quanto

questo possa influenzare la soddisfazione dell'utente all'interno del

contesto utilizzativo previsto.

La soddisfazione trova la sua piena collocazione nell'esperienza d'uso.

Di questo tema si parlerà in modo approfondito nel prossimo

paragrafo (2.2).

Oltre questi fondamentali elementi discriminanti, l'usabilità è frutto di

molti altri principi, ma trattarli qui singolarmente sarebbe poco utile,

perché non è sempre facile ricordarli e applicarli nel modo corretto in

fase di progettazione. Nel resto del testo potrete scorgere questi nuovi

principi accessori che emergono da esempi e spiegazioni.

16

2.2 L'esperienza utente

E' dura definire esattamente cosa sia un’esperienza, perché il termine

stesso, ha mille sfaccettature e cambia il suo significato e la sua essenza in base al contesto.

Per quanto riguarda quella che è comunemente chiamata “Esperienza

utente” potremmo dire che si tratta di una percezione interiore che

scaturisce dall'osservazione e dalla pratica utilizzativa dell'interfaccia

grafica.

Diciamo che un'interfaccia garantisce un’esperienza

utente gradevole se essa permette la miglior fruizione

possibile dei contenuti voluti.

Nei dispositivi mobili il concetto di experience va oltre la semplice

interazione tramite uno schermo sensibile al tocco. Grazie ad

accelerometri, giroscopi e fotocamere possiamo immergere l'utente in

un esperienza a 360° arrivando a creare quella che viene chiamata

“realtà aumentata” ovvero un o digitale alla realtà che ci

circonda.

Progettare un’applicazione che fornisca una buona experience va

quindi spesso oltre il progetto della GUI in se stessa. E' qualcosa che

parte dal progetto funzionale del prodotto software, e che cresce con

l'avanzare dello sviluppo.

Anche in questo caso tutto è strettamente dipendente dal contesto e

dal bacino d'utenza alla quale il nostro progetto si rivolgerà.

Inoltre non si può immaginare un’applicazione interamente centrata

sull'esperienza utente, perché questo potrebbe “legare” gli sviluppatori

a troppi standard e quindi il prodotto finale non sarebbe usabile sotto

17

altri aspetti. E’ necessario esercitare equilibrio così da mantenere il

controllo di questa caratteristica pur attenendosi strettamente alle

specifiche tecnico-funzionali.

2.3 Come misurarla

L'usabilità, come qualsiasi cosa che deve essere confrontata con uno

standard, va misurata. Ma come misurare l'usabilità?

Bisogna dire che la misura dell'usabilità è solo una misura orientativa, e

non esatta, proprio perché essa è frutto di moltissimi principi e quindi

ci sono così tante variabili in gioco che non possono essere prese in

considerazione nella loro totalità durante una misurazione.

Comunque esistono dei parametri generali che ci indicano se e quando

un'interfaccia risulti usabile in un dato contesto per un dato utente.

Esamineremo in questo paragrafo i quattro indicatori fondamentali e

per ogni uno di essi faremo un brevissimo esempio applicativo così da

sapere come utilizzarlo. L'interfaccia che utilizzeremo per questo

esempio è una singola vista che permette di inserire i dati anagrafici in

un database. Immaginiamo la vista composta di due campi di testo per

l’inserimento di nome e cognome e un selettore circolare per

l’inserimento della data.

18

2.3.1

Numero operazioni

Un primo parametro di interesse per la misura dell'usabilità è il numero

di operazioni richieste all'utente per poter arrivare allo scopo

dell'interfaccia in questione.

Nell'esempio di cui sopra, l'utente per completare l'azione deve

1. Selezionare il primo campo testo

2. Inserire il nome tramite tastiera

3. Selezionare il secondo campo testo

4. Inserire il cognome tramite tastiera

5. Scegliere il numero corrispondente con il giorno

6. Scegliere il numero corrispondente con il mese

19

7. Scegliere il numero corrispondente con l’anno

8. Selezionare “OK”

Le seguenti otto operazioni potrebbero essere ottimizzate, ad esempio

la data potrebbe essere inserita in un unico campo testo. Ma non per

forza questo porta ad una usabilità maggiore, come vedremo subito

sotto bisogna tenere conto anche degli altri parametri.

L’applicazione più usabile quindi non è sempre quella che consente di

fare l'azione per cui è stata creata con il minor numero di operazioni;

bensì l'applicazione che minimizza il numero di operazioni tenendo

conto degli altri parametri e degli altri principi fondamentali.

Numero errori

Il numero di operazioni, da solo, è davvero poco utile. Come abbiamo

già detto, sarebbe possibile ridurre le operazioni di inserimento

nell'applicazione di esempio, ma è davvero conveniente? Per capirlo

parliamo di un nuovo parametro di misurazione, il numero di errori.

Naturalmente non si può parlare del numero di errori che un utente

compie, essendo questo un dato completamente casuale che dipende

dall'utente stesso. Ma si possono stimare in modo accurato i

POSSIBILI errori che l'utente potrebbe fare.

Nel caso dell'esempio, se permettessimo all'utente di inserire la data in

un unico campo testo ci sarebbero molte possibilità che esso la

imputerebbe in modo errato, scambiando le posizioni dei valori o

inserendo valori non riconosciuti dal sistema che bloccherebbero

l'esecuzione dell'applicazione.

Ecco quindi come entra in gioco questo secondo parametro per la

misurazione dell'usabilità: essa è inversamente proporzionale al numero

di errori che l'utente potrebbe commettere.

Nell'applicazione d'esempio potremmo comunque abbassare

notevolmente questo parametro con una semplice finestra di dialogo

20

che permette, una volta premuto OK, di verificare visivamente la

correttezza dei dati inseriti, come nella figura.

2.3.2

Anche in questo caso tutti i parametri devono tendere all’equilibrio,

un’applicazione che per evitare possibili errori effettua 10 controlli

successivi non è usabile, perché aumenta inutilmente il numero di

operazioni che l'utente deve effettuare.

Tempo di operazione

Equilibrare il numero di operazioni con il numero di errori ci da già un

idea orientativa di come misurare l'usabilità delle interfacce che

progettiamo, ma ancora non è abbastanza.

21

Il numero di operazioni, ad esempio, potrebbe essere poco influente

sull'usabilità se si tratta di operazioni MOLTO LUNGHE. Una sola

operazione estremamente complessa invalida il valore del primo

parametro.

A questo scopo tra i parametri di misura è stato introdotto il tempo

della durata delle singole operazioni. Questo valore, serve anche per

individuare i “punti critici” delle nostre interfacce per cercare di

semplificare e ottimizzare i aggi più lunghi e complessi.

La semplicità dell'esempio scelto non ci permette di valutare operazioni

particolarmente lunghe e complesse, ciascuna delle otto operazioni

risulta già lineare e rapida.

Utilizzo risorse

L'ultimo parametro in questione è molto diverso dagli altri, in quanto è

strettamente correlato con la piattaforma sulla quale l'applicazione

funziona.

Si tratta di una stima percentuale dell'utilizzo di U, GPU e RAM di ogni operazione. Una stima complessa che diventa indispensabile per

dispositivi poco performanti o per applicazioni critiche che sfruttano al

massimo le risorse del sistema.

La risorsa che è più semplice da esaurire è la RAM, anche se gli ultimi

device possono contare su un buon quantitativo di memoria

disponibile c’è da dire che ogni applicazione ne può utilizzare solo una

parte (l’ampiezza di questo blocco varia da piattaforma a piattaforma).

Supponiamo ad esempio di progettare un applicazione che debba

lavorare su bitmap ad alta risoluzione, per rientrare nei limiti di

memoria è necessario monitorare in tutte le fasi il quantitativo

utilizzato. Bisogna tenere su RAM solo le informazioni che servono

per l’elaborazione corrente, e spostare sulla memoria di massa tutto il

resto. E’ vero che questo richiederà del tempo per la scrittura/lettura

22

dei dati su una memoria più lenta della RAM ma è indispensabile per

non saturare questa risorsa.

Per utilizzare tutti e quattro i parametri di misura in modo efficiente

possiamo stilare una semplicissima tabella che chiameremo indicatore

di usabilità, ad ogni riga corrisponderà un operazione per la quale

indicheremo il numero di errori possibili, il tempo necessario

all’esecuzione e la percentuale di utilizzo delle tre risorse principali; i valori inseriti in tabella permettono di tenere sempre sott'occhio una

stima numerica del livello di usabilità.

2.4 Riconoscibilità grafica

Fino a questo punto abbiamo trattato aspetti numerici e matematici

dell'usabilità ma non tutto è esprimibile con dei numeri. Alcuni concetti

complessi vanno discussi ed esplicati tramite esempi per poterne

comprendere l'ampiezza. Questo è il caso della riconoscibilità, un altro

fattore che concorre al rendere utilizzabile un’applicazione.

Per introdurre il concetto di riconoscibilità possiamo utilizzare qualche

esempio pratico che incontriamo nella vita di tutti i giorni. Osservate la

seguente sequenza di simboli:

⏏ ✔ ✚ ♪

Vi risulta semplice associare ad ogni simbolo un significato?

Sono certo di si, quelli presentati sopra sono simboli molto

riconoscibili, che possiamo trovare su tanti oggetti di uso comune.

Sono riconoscibili nel senso che tutti gli utenti che utilizzano quel dato

sistema conoscono a priori il significato del simbolo. Tutti gli

utilizzatori di un DVD Player riconoscono nel primo simbolo il

pulsante che permette l’estrazione del o ottico.

23

Lo stesso concetto si può applicare nel campo delle applicazioni

mobili. Osservate le tre interfacce qui in basso:

2.4.2

Tutti gli utenti che hanno utilizzato un dispositivo dotato di Android,

iOS o Windows Phone sapranno riconoscere in una delle tre interfacce

degli elementi distintivi che caratterizzano le applicazioni di un dato

sistema operativo.

Questo è possibile grazie al fatto che gli sviluppatori hanno utilizzato

nella loro App degli elementi costruttivi riconoscibili e standard per il

sistema operativo in questione.

Questa pratica è utile e rende un applicazione più utilizzabile.

L'utente che ha a che fare con elementi riconoscibili, comuni alla

maggior parte delle applicazioni del sistema operativo che utilizza e

conosce, potrà utilizzare l'applicazione con meno fatica, impiegando

24

meno tempo a capire cosa serve a fare cosa. Troverà un ambiente a lui

familiare, e per questo più intuitivo e semplice da utilizzare.

2.5 Qualità del contenuto

L'usabilità comunque va oltre i tecnicismi esposti fino a questo punto,

durante lo sviluppo di un'applicazione bisogna tener conto di quali

sono i bisogni di chi la utilizza. Per questa ragione un fattore che

determina l'usabilità dell'applicazione è la qualità del contenuto.

Bisogna dare all'utente esattamente quello che cerca, questo significa

proporre in modo adeguato le informazioni utili.

I principi di usabilità esaminati fino a questo momento riguardano il

come esporre le informazioni, ora vedremo invece come poter

assicurarci della qualità del contenuto.

Il concetto di usabilità va considerato sin dalle prime fasi dell'ideazione.

Bisogna dare all'utente un’applicazione specifica, che assolva una

specifica funzione. Creare applicazioni generaliste che servono a tutto

così come a niente rende impossibile farle diventare usabili nelle fasi di

progettazione successive. La prima cosa da fare nell'ideare

un’applicazione è stabilire esattamente per cosa l'utente la utilizzerà e

quindi sceglierne i contenuti.

Avendo a disposizione i contenuti, è necessario organizzarli.

Bisogna organizzare la quantità dei contenuti e la modalità di

visualizzazione. E' fondamentale non subissare l'utente con contenuti

che non sono strettamente legati agli scopi prefissi nel o

precedente; ma naturalmente l'utente dovrà trovare tutto quello che

cerca.

25

“Che cosa vuole fare l'utente quando apre l'applicazione?”

Questa domanda è fondamentale per tradurre in pratica i principi visti

e per garantire qualità del contenuto, ma non è sempre facile trovare

una risposta soddisfacente se l'applicazione non è specifica.

Uno dei modi per rendere accessibili i contenuti è quello di organizzare

un sistema di ricerca per keyword o per categoria. Questo non significa

che tutte le applicazioni per essere usabili hanno bisogno di un sistema

di ricerca, ma questo va creato tutte le volte che l'utente deve

consultare una quantità di dati abbastanza consistente da non poter

essere esposte linearmente nelle view.

Oltre ai meccanismi di ricerca, è necessario fornire all'utente un

pannello di impostazioni adeguatamente dettagliato che permetta di

organizzare i contenuti secondo determinate esigenze. Non tutti gli

utenti avranno bisogno degli stessi contenuti nello stesso posto, quindi

l'organizzazione dei contenuti che abbiamo progettato dev'essere

flessibile e configurabile. Maggiore è il numero dei dati, maggior livello

di personalizzazione è necessario, e di conseguenza maggiori saranno le

opzioni di impostazione.

2.6 Semplicità, non omologazione

Un contenuto semplice, e ben strutturato non è sinonimo di

omologazione. Tutte le abitazioni sono formate fondamentalmente da

pilastri e fondamenta, ma dire che per questo motivo tutte le abitazioni

sono uguali è miope. Gli architetti possono dare grande sfogo alla

creatività, nonostante le “costrizioni” che impongono strutture di base

che seguono rigide norme di sicurezza.

Allo stesso modo, gli “architetti” delle applicazioni possono essere

molto creativi pur mantenendosi all'interno dei limiti imposti dai

principi d'usabilità. In fondo si tratta d’indicazioni, non di recinti o

restrizioni.

26

Il terzo capitolo sarà interamente dedicato alla progettazione, vedremo

che per progettare una GUI è necessario rispondere a tre domande

fondamentali:

- COSA ?

- CHI ?

- COME ?

27

3. Progettazione

3.1 Usabilità e progettazione

Il concetto di usabilità è davvero ampio e copre un insieme di fattori

che devono essere tenuti in considerazione sin dalle primissime fasi di

creazione di un app, in questo capitolo vedremo cosa è necessario

tenere in considerazione quando si progetta un'applicazione nativa o web per un dispositivo mobile.

Sia le funzionalità che il modo di presentarle dev'essere cucito intorno

alle ESIGENZE e alle ASPETTATIVE dell'utente che ne usufruirà.

Per raggiungere questo obiettivo è necessario, come primo step,

definire chiaramente il contenuto. Una volta stabilito COSA dire si puó

are alla profilazione di CHI utilizzerà l'app. Come ultimo o

infine bisogna stabilire COME presentare i contenuti stabiliti.

Esaminiamo questi tre i per arrivare ad avere un idea chiara di

come tener conto dell’usabilità in fase di progettazione.

3.2 COSA

E' il contenuto, a fare da fulcro alla nostra applicazione. Parte sempre

tutto da un idea, ed è l'idea iniziale che spesso fa la differenza tra un

applicazione di successo e un applicazione mediocre. Ma l’idea da sola

non basta, va ampliata e strutturata adeguatamente per far si che si

tramuti in contenuti.

La prima cosa da estrapolare dall'idea è lo scopo dell'applicazione: cosa

spingerà l'utente ad usarla? Quale sarà la funzionalità che verrà aggiunta

al suo dispositivo mobile grazie ad essa? Rispondendo a queste due

semplici domande abbiamo posto la base della struttura del contenuto.

E' importante essere in grado di dare una risposta univoca a queste

domande, un applicazione generica, multipurpose, che vuole

28

raggiungere dieci o cento obiettivi lontani tra loro, non potrà mai

essere usabile, l'utente verrebbe sballottato tra schermate e viste non

omogenee che porteranno solo confusione. A prima lettura questa

affermazione potrebbe suonare strana, in effetti possiamo citare molte

applicazioni che permettono di svolgere diverse funzioni, ma in realtà

se diamo un occhiata da vicino a queste app ci rendiamo conto che

tutte le funzionalità servono per raggiungere lo scopo finale, che è

unico, chiaro e ben definito.

Facciamo un esempio, l'applicazione ufficiale di Facebook è oramai

disponibile per quasi tutte le piattaforme mobili, e permette di

compiere un insieme di task anche molto differenti tra loro, ci si puó

scambiare messaggi con gli amici, si puó creare un evento, si possono

condividere idee foto e video, e tanto altro ancora. Ma qual'è lo scopo

di tutti questi singoli task e quindi dell'applicazione? Tenersi in contatto con i propri amici. Tutta l'applicazione ruota intorno a questo singolo

obiettivo.

Una volta chiarito lo scopo dell'applicazione c'è da capire quali sono le

singole funzionalità che permetteranno all'utente di raggiungerlo.

Queste funzionalità vanno specificate e organizzate gerarchicamente

così da poter essere utilizzate nei i successivi

Ogni singola funzionalità dev'essere ben definita, e chiaramente

identificabile. Se ci sono varie funzionalità tra loro simili sarebbe bene

accorparle, aggiungendo opzioni ad una delle due ed eliminando l'altra.

In quest’ operazione è importante essere equilibrati, bisogna ridurre

dove possibile il numero delle funzionalità senza però incorrere nel

rischio di avere funzionalità troppo complesse ed articolate. Bisogna

trovare il giusto compromesso tra nuclearità e quantità delle funzioni e

delle viste, per questo tipo di scelte sarà l'esperienza del progettista a

fare la differenza.

Vedremo ora un esempio pratico per capire come ideare le funzionalità

di un applicazione. Naturalmente essendo solo un esempio a scopo

didattico la progettazione non sarà completa (bisognerebbe altrimenti

scrivere un altro volume solo per descriverla), ma servirà solo come

modello illustrativo.

29

Immaginiamo di progettare un applicazione mobile che consente di

comprare/vendere automobili tramite annunci. Lo scopo

dell'applicazione può essere sintetizzato come segue:

“Creare un punto d'incontro tra venditori e compratori per favorirne

le trattative”.

Lo scopo è generalista e tantissime funzionalità possono essere pensate

per raggiungerlo, ma per quanto detto sopra ci limiteremo a 3

funzionalità fondamentali:

- CERCARE UN AUTO

- METTERE IN VENDITA UN AUTO

- SISTEMA DI MESSAGISTICA PER I CONTATTI TRA UTENTI

Adesso sappiamo COSA farà la nostra applicazione, ogni funzionalità

corrisponderà ad una vista che andrà organizzata a livello grafico, ma

non basta questo per iniziare a creare una prima bozza del progetto,

abbiamo prima bisogno di conoscere CHI à l'applicazione.

3.3 CHI

Un applicazione usabile è disegnata attorno all’utente e alle sue

esigenze, quindi ora che le funzionalità sono chiare e ben classificate, è

necessario capire chi li utilizzerà. Con “CHI” non intendiamo le

caratteristiche anagrafiche degli utenti, ma le categorie di persone che

sfrutteranno le varie applicazioni.

Profilare gli utenti tipici che anno l'applicazione potrebbe essere un

lavoro molto lungo e complesso, a causa delle infinite combinazioni di

categorie. Il primo o per concentrare i nostri sforzi verso

l’obiettivo è quello di associare un verbo ad ogni funzionalità trovata

nel o precedente.

Utilizzando l’esempio che fa da guida al capitolo, possiamo individuare

i seguenti tre verbi:

30

- COMPRARE

- VENDERE

- COMUNICARE

A ogni verbo corrisponderà una o più categorie di utenti. L’obiettivo

del progettista è ottenere dei profili specifici, quindi evitiamo di essere troppo generalisti, così come di creare troppi profili simili tra loro.

Continuando con l’esempio precedente:

- COMPRARE

Utente che vuole comprare un’auto

Utente che vuole scorrere il catalogo per informazione

- VENDERE

Utente che intende vendere un’auto

- COMUNICARE

Utente che comunica con un possibile acquirente

Utente che comunica con un possibile venditore

Utente che comunica per completare una transazione

Utente che comunica a fine transazione

Sarebbe stato possibile aggiungere altri profili, come l’utente che vuole

semplicemente provare come si fa a vendere un’auto nella seconda

azione, o l’acquirente che comunica solo perché ha tempo da perdere e

non perché è interessato all’acquisto/vendita; è evidente comunque che

questi profili esulano dall’obiettivo di cui abbiamo appena parlato,

ricordiamo che noi cerchiamo solo le informazioni che ci saranno

indispensabili nel prossimo o, dove definiremo COME presentare

la nostra app, il resto è superfluo.

Come per qualsiasi cosa nella vita, anche nella creazione di un app non

è mai possibile accontentare tutti, e questo diventa particolarmente

vero quando si tratta di applicazioni molto complesse che generano

decine di differenti profili (diversamente da quanto vediamo nel

semplice esempio guida). Per capire allora dove concentrare le

attenzioni, il progettista deve stabilire una priorità che distingua i vari profili. Per

farlo basta assegnare un voto (1-5) ad ogni profilo creato, lo 31

schema relativo al nostro esempio diventa:

- COMPRARE

Utente che vuole comprare un auto (4)

Utente che vuole scorrere il catalogo per informazione (2)

- VENDERE

Utente che intende vendere un auto (5)

- COMUNICARE

Utente che comunica con un possibile acquirente (3)

Utente che comunica con un possibile venditore (3)

Utente che comunica per completare una transazione (5)

Utente che comunica a fine transazione (4)

Per decidere che priorità assegnare, ho immaginato che nel nostro caso

i proventi economici vengano dalla quota percentuale sul venduto, e

quindi la priorità è offrire la miglior esperienza di vendita possibile. E’

anche importante rendere semplice lo scorrimento delle varie offerte e

la gestione della trattativa , perché questi fattori contribuiranno

all’aumento delle vendite. L’utente che invece utilizza l’app solo per

informazione ha un ruolo marginale, lo si considera solo come

potenziale cliente, che potrà diventare in seguito un

compratore/venditore.

A questo punto abbiamo a disposizione i profili degli utenti che

utilizzeranno l'app con relativa priorità, le informazioni raccolte fino a

questo momento ci permettono di arrivare all'ultimo o della

progettazione, capire COME organizzare le funzionalità secondo le

aspettative degli utenti, ideando quindi un software usabile.

3.4 COME

Adesso abbiamo tutti gli elementi per iniziare a disegnare le viste vere e

proprie. Ad ogni vista dell'applicazione sarà assegnato il compito di

svolgere una specifica funzionalità. E' necessario decidere COME

questa funzionalità dev'essere svolta, sia a livello tecnico che a livello

32

grafico; per fare questo è necessario tenere in considerazione le

esigenze di tutte le categorie di utenti che la utilizzeranno.

Nelle prossime pagine vedremo teoricamente il percorso di questa fase

di progettazione per poi applicare la teoria all'esempio utilizzato anche

per i i precedenti.

Per organizzare le funzionalità si procede analizzandole singolarmente

e confrontandole con tutti i profili degli utenti che ne usufruiranno.

Vediamo 6 semplici regole che faranno da linee guida in questa fase.

TUTTO A VISTA

Tutte le opzioni che caratterizzano la funzionalità devono essere

esposte nella view e devono risultare facilmente accessibili. Le opzioni

più comuni devono essere fruibili con facilità anche nel caso in cui

l'utente utilizzi il dispositivo con una mano sola.

Nei casi in cui ci sono molte opzioni e di conseguenza non tutte

possono essere esposte nella vista principale della funzionalità,

l’accesso deve risultare ugualmente logico. Se è necessario inserire un

menu aggiuntivo, il pulsante d’accesso dev’essere posizionato in un

punto ben visibile e ben identificabile.

DISPOSIZIONI

Gli elementi della vista devono essere disposti in modo LOGICO e

PERTINENTE.

Le opzioni che modificano qualche elemento della vista vanno inserite

vicino l'elemento che sarà modificato. Ad esempio se visualizziamo una

mappa ed un tasto per lo zoom, è necessario che il tasto sia posto

direttamente sulla mappa o nelle immediate vicinanze.

Opzioni simili vanno raggruppate. Se per esempio nella vista è presente

un campo testo, alcuni tasti per l'editing (taglia – copia - incolla) e altri tasti per la formattazione (dimensioni – colore - stile), saranno presenti

due gruppi distinguibili di tasti. Mischiare le varie opzioni in un unico

gruppo rende più complesso il loro utilizzo; funzionalità raggruppate in

33

insiemi distinti permettono all'utente di ambientarsi in tempi brevi

nell'applicazione e utilizzare con maggiore rapidità tutte le opzioni.

PROPORZIONI

Ogni contenuto della funzionalità deve occupare uno spazio e una

posizione consoni al suo contributo per il raggiungimento dell'obiettivo

principale.

Se immaginiamo una vista che mostra il percorso per arrivare ad una

data destinazione, la mappa occuperà la maggior parte della vista e sarà

presentata in posizione centrale, l'indirizzo e i tasti per le varie opzioni di navigazione avranno una posizione marginale.

PERCORSI BREVI

Qualsiasi funzione offerta dalla view va completata nel minor numero

possibile di step.

Alcune funzioni, come la compilazione di un form, o l'esecuzione di un

test richiedono una serie di step successivi. I problemi di usabilità

nascono quando queste serie sono troppo lunghe ed intricate, tanto da

disorientare l'utente. Per evitare questa evenienza si ottimizzano il

numero di step e la ramificazione di questi ultimi.

Nel caso in cui, ad esempio, l'utente deve compilare dei form per

portare a termine una registrazione, sarebbe poco saggio organizzare

uno step per ogni campo. L'ottimizzazione consisterà nell'organizzare i

vari campi per similarità o per argomento e inserire i gruppi di

compatibili in un unico step. Anche in questo caso rileviamo che

assembramenti troppo grandi di campi che richiedono lunghi scroll per

essere raggiunti, sono sconsigliati, quindi è necessario equilibrare il

numero di step con la lunghezza di ognuno di essi.

INSERIMENTO DATI

La tastiera virtuale, necessaria all'imputazione di dati, occupa circa la

metà dello spazio disponibile sul display del dispositivo, quindi va

gestita con la massima perizia, accertandosi che sia la comparsa sia

l'uscita della tastiera avvengano esattamente quando è necessario per

l'utente così da non impegnare spazio utile senza motivo. Inoltre

quando la tastiera è visibile, tutti gli elementi dell'interfaccia che

34

possono essere necessari all'utente non devono essere nascosti, in caso

contrario l'utente sarà costretto a chiudere la tastiera, utilizzare una

funzionalità necessaria e poi riaprirla.

Con questi principi fondamentali in mente completiamo l'esempio

iniziato qualche pagina fa. Stabiliamo quali sono le viste che

comporranno l’applicazione.

- INTERFACCIA DI RICERCA

- ELENCO AUTO

- INTERFACCIA INSERIMENTO ANNUNCIO

- INTERFACCIA PER LA MESSAGGISTICA

Adesso abbinieremo ad ogni vista le funzionalità ed i profili che

abbiamo trovato negli step precedenti. Ogni vista sarà caratterizzata da

una priorità che rappresenta la somma delle priorità dei profili che

contiene.

- INTERFACCIA DI RICERCA (6)

COMPRARE

Utente che vuole comprare un auto (4)

Utente che vuole scorrere il catalogo per informazione (2)

- ELENCO AUTO (6)

COMPRARE

Utente che vuole comprare un auto (4)

Utente che vuole scorrere il catalogo per informazione (2)

- INTERFACCIA INSERIMENTO ANNUNCIO (5)

VENDERE

Utente che intende vendere un auto (5)

- INTERFACCIA PER LA MESSAGGISTICA (11)

35

COMUNICARE

Utente che comunica con un possibile acquirente (3)

Utente che comunica con un possibile venditore (3)

Utente che comunica per completare una transazione (5)

Questo schema è il fine ultimo dei nostri sforzi, adesso abbiamo una

lista di viste che è davvero fondamentale per are al disegno vero e

proprio degli elementi grafici. Per ogni vista sappiamo tutto quello che

è necessario per tenere conto dell’usabilità nella nostra progettazione.

Grazie alle indicazioni di priorità sapremo cosa mettere in evidenza,

quali percorsi privilegiare, sarà più semplice canalizzare l’attenzione

dell’utente sul contenuto così da minimizzare i tempi di apprendimento

per l’uso del software e massimizzare l’esperienza d’uso.

Ogni elemento che disegneremo deve rispondere alle esigenze degli

utenti e deve essere incentrato sulla funzionalità che abbiamo stabilito

come fondamentali. Se utilizzeremo questo schema, tenendo a mente

le cinque linee guida, saremo sicuri che il risultato finale sarà un

progetto solido che diventerà un’applicazione usabile.

Questo elenco che abbiamo creato non contiene TUTTE le viste

dell’applicazione ma le viste che fanno da base portante al contenuto.

Lo sviluppatore deciderà in seguito se e come inserire nuove viste

accessorie che vanno a completare l’esperienza d’uso e le viste

principali.

A queste informazioni di natura “tecnica” è necessario aggiungere la

fantasia del progettista e l’abilità del grafico per ottenere un risultato di spessore.

Anche se abbiamo a disposizione tutte le nostre viste, il lavoro di

progettazione non è ancora finito, un’applicazione usabile deve avere

anche un efficiente sistema di navigazione, che permetta all’utente di

36

muoversi con agilità tra le varie viste. Di questo parleremo nel

prossimo capitolo.

37

4. NAVIGAZIONE

4.1 Navigazione e usabilità

Uno dei compiti più ardui per gli sviluppatori è la gestione di viste

multiple all'interno della stessa sezione dell'applicazione. Questo

compito diventa ancora più complesso quando si parla di gestire

schermi si dimensioni molto disomogenee, che vanno dai tre ai dieci

pollici. Lo spazio è molto ridotto in alcuni casi e molto ampio in altri;

le differenze tra dispositivi diversi che condividono lo stesso sistema

operativo e le stesse applicazioni rendono di cruciale importanza una

buona progettazione del sistema di navigazione tra le varie viste.

Abbiamo già stabilito nel precedente step quante viste sono realmente

necessarie, ora bisogna capire come mostrarle e soprattutto come

are da una vista alla conseguente con agilità.

Iniziamo con il prendere in considerazione gli alberi di navigazione.

4.2 Alberi di navigazione

Un albero di navigazione non è altro che un particolare tipo di

diagramma di flusso che presenta graficamente la successione logica

delle viste.

Per la stesura di un albero di navigazione funzionale bisogna tenere

conto del fatto che non si sta creando un percorso obbligato per

l'utente, ma semplicemente una successione teorica di i successivi

che l'utente può decidere di intraprendere. Questo significa che

qualsiasi o deve essere reversibile e che bisogna sempre mantenere

38

aperta la possibilità per l'utente di interrompere il percorso iniziato per tornare ad altre attività della stessa applicazione.

4.2.1

Ogni albero di navigazione presenta un nodo principale dal quale si

diramano tutte le possibili alternative . Ogni flusso deve essere descritto da uno e un solo albero di navigazione. Un’applicazione invece può essere descritta da un insieme di alberi di navigazione differenti, per applicazioni

medio-grandi diventa impossibile nella pratica gestire tutti i possibili

flussi con un unico albero di navigazione.

Creeremo ora l'albero di navigazione dell’applicazione esemplificativa

studiata nel precedente capitolo, per vedere in pratica quali sono i

meccanismi che regolano la stesura degli alberi di navigazione.

L’applicazione prevedeva quattro viste principali, sceglieremo una delle

quattro come vista principale dalla quale far partire l’applicazione e

quindi anche il flusso di navigazione.

39

4.2.2

Per comodità mostriamo i flussi di navigazione delle viste per

l’inserimento dell’annuncio e della messaggistica in altri due alberi

separati.

4.2.3

40

4.2.4

4.2.5

41

4.3 Menu

Il menù è il cuore del sistema di navigazione per qualsiasi app; contiene

uno o più collegamenti che permettono all’utente di spostarsi dalla vista

attuale alle altre viste necessarie e può essere composto da icone o da

collegamenti testuali. La quasi totalità delle viste contiene uno o più

menù.

Un menù di solito non può contenere collegamenti a TUTTE le viste

della nostra applicazione, è impossibile collegare direttamente tutti i

percorsi previsti dato che molte viste sono consequenziali ad altre.

Alcuni elementi di un menù possono essere accorpate in un unico

sotto-gruppo contrassegnato da una voce principale. Il sotto-menù sarà

quindi mostrato solo quando l’utente lo desidera e seleziona la voce

principale. Questa gerarchia è fondamentale per la gestione di menù

molto articolati in poco spazio.

Il problema sorge quando ci sono menù molto complessi che devono

essere visualizzati su display di dimensioni ridotte. Una lista molto

lunga di voci o d’icone tende a creare confusione: o le si nascondono

dalla vista dell’utente o le si mostrano a dimensioni microscopiche. In

questi casi il progettista deve minimizzare quanto più possibile il

numero di voci e se questo non basta, si a a individuare gruppi di

voci per la creazione dei sotto-menù.

La creazione di gerarchie è un compito arduo perché è facile rovinare

l’usabilità dell’intera applicazione con una scelta errata. Tutte le voci del sottomenù devono essere 1) logicamente collegate tra loro e 2)

logicamente collegate con la voce principale. All’utente deve risultare

ovvio trovare una voce all’interno di un gruppo, senza possibilità di

equivoci. A questo riguardo bisogna evitare gruppi simili che

potrebbero essere confusi e gruppi generalisti che contengono al loro

interno di tutto e di più.

I casi in cui utilizzare gerarchie multiple, e quindi annidare un sotto-

menù all’interno di un altro sotto-menù sono davvero rari, è meglio

42

evitare per quanto è possibile queste brutture. L’utente in un app

usabile arriva dove vuole in una o massimo due mosse.

Ci sono due tipi di voci in un menù: le voci obbligatorie e le voci opzionali. Nel primo caso si tratta di elementi che non possono essere estromessi dal menù, pena l’esclusione di alcune viste dalla navigazione.

Nel secondo caso invece si tratta di voci che vengono aggiunte per

rendere più accessibili alcune operazioni comuni che richiederebbero

una navigazione più lunga.

Adesso vediamo quali sono le voci da inserire in un menù; il parametro

per stabilire quali sono le voci obbligatorie è molto semplice: devono

risultare accessibili TUTTE le viste che sono direttamente collegate alla

vista della quale stiamo progettando il menù. A questo riguardo sono

molto utili i diagrammi che abbiamo costruito nel paragrafo

precedente, vanno inserite come voci tutte le viste collegate

direttamente da una linea alla vista in questione.

La cosa si fa un po’ più complessa nel caso delle voci opzionali,

l’usabilità dipende anche dall’equilibrio nella scelta di queste voci.

Vanno inserite come voci opzionali SOLO quegli elementi che l’utente

medio à abitualmente dalla vista che stiamo trattando. L’obiettivo è quello di rendere più semplici le operazioni comuni, ma se per

raggiungerlo inseriamo troppe voci e troppi menù rendiamo complesso

lo svolgimento di tutte le operazioni e quindi abbassiamo il livello di

usabilità dell’applicazione.

Per schematizzare la nostra progettazione emo delle liste, una per

ogni menù, che conterranno l’elenco delle voci con i relativi

collegamenti. In caso di sotto-menù la voce padre non sarà seguita da

un collegamento a una specifica vista, questo perché se l’utente la

seleziona non sarà riportato ad una nuova vista ma ad un elenco di voci

figlie. Il titolo della lista è composto dal nome che desideriamo dare al

menù seguito dal nome della vista che lo conterrà.

Se necessario è possibile corredare ciascuna lista da una breve

spiegazione che indica le generalità del menù ed eventuali specifiche

per la sua comparsa.

43

MENU1 (View 1)

NOTE EVENTUALI

- Voce1 => View2

- Voce2

+ Sotto-voce1 => View3

+ Sotto-voce2 => View4

+ Sotto-voce3 => View 5

- Voce 3 => View6

4.3.1

Tutto quello che abbiamo visto fino a questo momento riguardo i

menù ora lo trasporteremo nella pratica progettando i menù per l’app

di esempio che sta facendo da guida a questo capitolo.

Menù principale (Ricerca)

- Preferiti => Annunci preferiti

- I miei annunci => Annunci personali

- Aggiungi annuncio => Inserimento annunci

- Messaggi => Messaggistica

Menù di ricerca (Ricerca)

- Cerca => Elenco auto

- Ricerca acanzata => Popup

44

Menù messaggi (Messaggistica)

- Aggiungi nuovo => Popup

- Indietro => Ricerca

Menù selezione messaggi (Messaggistica)

Questo menù comparirà se uno o più messaggi sono selezionati.

- Cancella => Popup

- Archivia => Popup

- Inoltra => Popup

Menù gestione messaggio (Messaggio singolo)

- Cancella => Popup

- Archivia => Popup

- Inoltra => Popup

- Indietro => Messaggistica

Menù / ( - )

Questo menù compare identico in entrambe le viste.

- / => Revisione e conferma

- Indietro => Dati veicolo

45

Menù conferma policy (Inserimento Annunci)

- Accetto => Dati veicolo

- Indietro => Ricerca

Menù conferma dati (Revisione e conferma)

- Avanti => Annunci personali

- Indietro => Dati veicolo

Menù risultati (Elenco auto)

- Perfeziona la ricerca => Popup

- Indietro => Ricerca

Menù auto (Descrizione auto)

- Aggiungi a preferiti => Annunci preferiti

- Contatta

+ Chiama => App esterna

+ SMS => App esterna

+ E-mail => App esterna

Come potete notare dalle liste d’esempio molti elementi sono collegati

direttamente ad un popup invece che ad una vista. In questo caso si

tratta di operazioni che necessitano di conferma oppure operazioni che

aggiungono informazioni necessari alla vista di partenza.

46

4.4 Barra di navigazione

Per rendere facilmente accessibili gli strumenti di navigazione è

possibile aggregarli in una barra comune a tutte le viste. La barra di

navigazione permette di avere tutti gli strumenti per l’utilizzo dell’app a portata di mano e dà uniformità al sistema.

La barra di navigazione è generalmente disposta in alto, sia Android sia

iOS forniscono al progettista e allo sviluppatore gli strumenti nativi per

realizzare una barra di questo tipo. E’ sempre consigliato utilizzare gli

strumenti nativi piuttosto che un componente specifico, questo

permette all’utente di utilizzare qualcosa che già conosce e che ha già

utilizzato in altre app; apprendere come funziona il software sarà più

semplice e quindi l’applicazione sarà più usabile.

4.4.1 – iOS

4.4.2 - Android

47

Ricordiamo che la barra di navigazione non è una barra degli strumenti,

quest’ultima contiene gli elementi d’interazione con la view stessa e

non gli elementi che servono per navigare tra le viste. Una barra degli

strumenti può ad esempio contenere i controlli per la dimensione e il

font dei caratteri in un editor di testo. E’ buona norma mantenere le

due barre separate, se entrambi i controlli sono integrati in un unico

spazio si rischia di creare confusione.

Vediamo ora quali sono i membri di una barra di navigazione:

Titolo/descrizione. Il logo o il nome dell’app o in alternativa

il nome della vista specifica.

Tasto indietro. Permette di ritornare alla view precedente.

Tasto home. Permette di ritornare alla vista principale.

Tasti utilità. Accesso a menù o a funzionalità rapide.

Lo strumento che abbiamo analizzato è molto versatile, può essere

contenuto in tutte le viste (variando adeguatamente i componenti) o

solo nelle viste navigabili. L’unico vincolo è quello dell’uniformità, se

vogliamo rendere familiari all’utente i vari controlli non possiamo

spostarli continuamente ando da una vista all’altra, ad esempio se

decidiamo di inserire il pulsante “Indietro” in alto a sinistra bisogna

mantenere questa posizione in tutte le view. Oltre alle posizioni è bene

mantenere invariati colori e stili, il solito pulsante per tornare indietro di cui prima, non deve solo essere sempre nella stessa posizione ma

deve avere sempre la stessa forma, la stessa dimensione e lo stesso

colore.

4.5 Cicli infiniti

All'interno di un flusso di navigazione è spesso necessario organizzare

dei salti tra viste seguendo le decisioni dell'utente, senza quindi seguire un flusso statico. Nel corso di questi spostamenti possono venirsi a

48

creare dei cicli che se non gestiti correttamente rischiano di diventare

infiniti, di confondere l’utente e quindi di compromettere l’usabilità

dell’app.

Si ha un ciclo quando l'utente ha la possibilità di are dalla view C

alla view A che a sua volta lo porterà attraverso la view B al punto C ,

dove sarà nuovamente possibile saltare alla view A iniziale. Molto più

semplice a vedersi che a dirsi.

4.5.1

Un ciclo diventa “infinito” se lo sviluppatore non gestisce in modo

adeguato l’uscita, se per l’utente non è chiaro COME e QUANDO

terminare l’iterazione.

Un ciclo all'interno del flusso di navigazione è spesso utile e addirittura in alcuni casi indispensabile, quindi è necessario capire come

intervenire per evitare di farlo diventare infinito. La soluzione generale

è quella di indicare all’utente l’esatto punto nel quale si trova fornendo

nello stesso tempo gli strumenti per terminare il ciclo.

Facciamo un esempio teorico per capire quali sono i rischi connessi ai

cicli infiniti e come informare adeguatamente l'utente. Nella figura 4.5.2

si può vedere l'albero di navigazione di un’applicazione che permette di

gestire un magazzino di oggetti. In particolare esaminiamo le viste per

l’aggiunta in serie di nuovi elementi al database.

49

4.5.2

È facile notare che il flusso presenta la possibilità di un ciclo infinito.

Vediamo tutte le opzioni che abbiamo a disposizione per gestire il ciclo

così da individuare la più usabile.

SOLUZIONE 1

Inserire un tasto “INDIETRO” per tornare al magazzino in entrambe

le viste. La soluzione funziona ma non è usabile, per interrompere il

ciclo si è costretti ad iniziare una nuova immissione assolutamente

inutile per l’utente. Inoltre il tasto nella vista di conferma non sarebbe

univoco, porterà alla vista precedente per la revisione dei dati o alla

vista principale?

50

SOLUZIONE 2

Aggiunta di un tasto “HOME” a entrambe le viste. Anche in questo

caso è una soluzione confusionaria, perché il tasto HOME e il tasto

INDIETRO porteranno allo stesso punto se ci si trova nella view per

l’aggiunta del nuovo prodotto. Inserire il tasto HOME solo della vista

di conferma dei dati crea discontinuità tra le viste, inoltre sorge un'altra domanda: alla pressione del tasto home nella view di conferma i dati

vengono salvati o meno?

SOLUZIONE 3

Inserire nella vista di conferma due pulsanti, uno per salvare il prodotto

corrente ed inserirne uno nuovo e un altro per salvare il prodotto

corrente e tornare al magazzino. Nella barra degli strumenti di

entrambe le viste sarà anche aggiunto un tasto “INDIETRO” che

porterà alla vista precedente, e quindi se ci si trova nella prima vista il ciclo viene interrotto e si torna al magazzino mentre dalla seconda vista

si tornerà indietro per modificare i dati. Questa terza soluzione è

intuitiva per l’utilizzatore, che sarà certo di utilizzare l’applicazione in modo corretto e di non perdere i dati inseriti fino a quel momento.

In questo capitolo abbiamo concluso con le spiegazioni, ora sappiamo

valutare l’usabilità di un applicazione mobile e siamo in grado di

progettare una soluzione software pratica e funzionale.

51

5. LE RISORSE

5.1 Usabilità

Essere esaustivi nell’esporre un argomento tanto delicato senza essere

prolissi è una sfida, che spero di aver superato con successo.

Il concetto di usabilità è un concetto universale, vale per un app mobile

così come per un oggetto fisico. I principi in gioco sono sempre i

medesimi ma l’applicazione degli stessi è molto specifica da campo a

campo. Il progettista deve considerare la facilità d’uso e l’ergonomia

dell’applicazione in tutte le fasi di progettazione. Ho cercato di

trasmettere come applicare questi principi chiave nelle varie fasi,

fornendo gli strumenti adatti a ottenere buoni risultati.

Le soluzioni presentate sono valide per la progettazione di app (native

o web-based) per smartphone e tablet, e sono indipendenti dai metodi

e dai linguaggi di sviluppo.

Durante la progettazione bisogna stabilire alcuni punti cardine.

Dev’essere chiaro COSA farà l’applicazione, quindi qual è lo scopo

della stessa. E’ giusto capire CHI utilizzerà il software così da fornire soluzioni usabili per il target corretto. La terza cosa indispensabile al

progettista è definire chiaramente COME il target di utenti raggiungerà gli obiettivi dell’applicativo.

Una corretta navigazione all’interno dell’app è la chiave di volta di un

app usabile quindi va progettata con la massima attenzione. Per capire

quali sono le criticità di navigazione e superarle è bene creare alberi di navigazione tra tutte le viste e tabelle riassuntive dei menù.

Un corretto uso della barra di navigazione garantisce una buona

navigabilità e una buona uniformità tra le viste, se l’utente trova i

comandi sempre nello stesso punto l’applicazione ne guadagnerà in

usabilità.

52

Nel prosieguo di questo capitolo conclusivo avrete a disposizione delle

risorse che ritornano utili durante la progettazione e lo sviluppo. Nel

prossimo sottotema (5.2) racchiudiamo i princìpi chiave mentre il

successivo (5.3) conterrà una tabella che permette di fare un controllo

rapido sull’usabilità di un progetto o di un’applicazione. Potete

copiarla, distribuirla, modificarla o farne qualsiasi altra cosa.

5.2 Principi chiave

L’usabilità è il grado in cui un prodotto può essere usato da specifici

utenti per raggiungere specifici obiettivi con efficacia, efficienza e

soddisfazione.

Diciamo che un'interfaccia garantisce un’esperienza utente gradevole se

essa permette la miglior fruizione possibile dei contenuti voluti.

Esistono dei parametri generali che ci indicano se e quando

un'interfaccia risulti usabile in un dato contesto per un dato utente. Tali parametri sono: il numero di operazioni, il numero di errori possibili, il

tempo di operazione e l’utilizzo delle risorse.

Sia le funzionalità che il modo di presentarle dev'essere cucito intorno

alle ESIGENZE e alle ASPETTATIVE dell'utente che ne usufruirà.

Per raggiungere questo obiettivo è necessario, come primo step,

definire chiaramente il contenuto. Una volta stabilito COSA dire si puó

are alla profilazione di CHI utilizzerà l'app. Come ultimo o

infine bisogna stabilire COME presentare i contenuti stabiliti.

Per progettare i percorsi che legano le viste si utilizzano gli alberi di

navigazione, ovvero un particolare tipo di diagrammi di flusso che

presentano graficamente la successione logica delle viste.

53

Un menù di solito non può contenere collegamenti a TUTTE le viste

della nostra applicazione, diventerebbe solo confusionario giacché

molte viste sono consequenziali ad altre.

Per rendere facilmente accessibili gli strumenti di navigazione è

possibile aggregarli in una barra comune a tutte le viste. La barra di

navigazione permette di avere tutti gli strumenti per l’utilizzo dell’app a portata di mano e dà uniformità al sistema.

Un ciclo diventa “infinito” se lo sviluppatore non gestisce in modo

adeguato l’uscita, se per l’utente non è chiaro COME e QUANDO

terminare l’iterazione.

54

5.3 Tabella di controllo

Tabella di controllo dell’usabilità

Contenuti

E’ chiaro lo scopo dell’app ☐

I comandi sono reperibili intuitivamente ☐

L’obiettivo è raggiungibile con poche azioni ☐

Non ci sono operazioni ordinarie più lunghe di 5 secondi ☐

Le singole funzionalità sono ben identificate ☐

Le funzionalità sono raggruppate logicamente ☐

Gli spazi sono ben sfruttati ☐

Navigazione

I comandi di navigazione sono facilmente identificabili ☐

Il numero di voci e di menù è ragionevole ☐

I comandi non sono equivocabili ☐

E’ sempre possibile tornare nella viste principale ☐

Consistenza

Comandi uguali in viste diverse hanno la stessa posizione ☐

Comandi uguali hanno uguali icone ed etichette ☐

I colori sono uniformi ☐

I font sono uniformi ☐

55

56