Archivi tag: User Experience

Usabilità per dispositivi mobile

Pubblicato il da

Per chi fosse interessato ad approfondire le tematiche di design e usabilità per dispositivi portatili, come i cellulari, consiglio di provare la versione mobile di Gmail.

Vi si può accedere con un dispositivo portatile all’indirizzo http://m.gmail.com, ma anche le ultime versioni di Firefox sono in grado di visualizzare l’interfaccia, se volete limitarvi a curiosare.

E’ interessante notare come i tipi di Google abbiano adattato l’applicazione ai limiti dei dispositivi portatili, cioè display piccoli e tastiera limitata.

Prendiamo ad esempio la schermata di creazione di un nuovo messaggio.

Scrivere un nuovo messaggio in Gmail Mobile

Come potete vedere, l’interfaccia va subito al dunque. Per prima cosa è richiesto il mittente: cliccando “Add Recipients” sono visualizzati per primi i destinatati contattati più di frequente, così da aumentare la probabilità di averli subito presenti nella lista. Se invece vogliamo inviare il messaggio a qualcun altro, in fondo alla stessa schermata è comunque possibile compiere una ricerca.

Lista dei destinatari più frequenti

Tornando alla schermata di spedizione notate anche che la copia carbone e la copia carbone nascosta sono state spostate in fondo alla pagina, visto che sono funzioni usate di rado.

Anche l’organizzazione e visualizzazione dei messaggi tiene conto dei limiti del mezzo. Nel mio cellulare, ad esempio, ogni messaggio è suddiviso in più pagine che è possibile scorrere avanti e indietro. Ogni voce di menù è poi accessibile tenendo premuto un numero del tastierino, evitando quindi di scorrere la pagina nel diplay.

E’ presente inoltre la possibilità di personalizzare l’interfaccia grafica, in modo da privilegiare le operazioni compiute più di frequente.

Personalizzare l'interfaccia

L’esempio di Gmail mobile fa anche riflettere chi sostiene (io non sono tra questi) che accontentare dispositivi eterogenei sia solo una questione di applicare fogli di stile diversi. In realtà ci vuole molto di più: si tratta di ristudiare completamente non solo l’interfaccia, ma anche l’interazione dell’utente con l’interfaccia, oltre a trovare altre soluzioni per la visualizzazione dei contenuti.

Se dovete cimentarvi in questo tipo di progetti, Gmail mobile rappresenta un buon caso di studio.

Ancora su Ajax e usabilità

Pubblicato il da

Anche le prime ore di vita di Google Calendar non sono state esaltanti. Ho perduto modifiche che ero convinto di aver salvato e soprattutto ero spaesato perché spesso non capivo se a una mia azione seguiva un riscontro del software.

L’ho già detto, e mi ripeto ancora una volta. La creazione di applicazioni basate su Ajax offre sicuramente delle nuove possibilità, ma pone anche delle nuove problematiche relative all’usabilità dei prodotti.

L’altro giorno nell’usare Google Calendar mi capitava di voler creare un nuovo evento, completarlo con alcuni dati, e solo dopo una trentina di secondi (quando oramai stavo facendo dell’altro) l’interfaccia mi informava che l’operazione non era andata a buon fine.

Mi chiedo poi se non stiamo utilizzando un po’ troppo pesantemente questo tipo di interfacce. Ci sono elementi in Google Calendar che effettivamente beneficiano di un’implementazione “ricca” (cioè usando Ajax), come ad esempio l’inserimento di un nuovo evento. Ma già quando si tratta di modificarlo successivamente, il fatto che il campo diventi editabile quando ci si muove sopra con il mouse è forse superfluo, oltre a trarre in inganno (ho passato 10 secondi a cercare un esplicito pulsante “edit”).

Speriamo sia solo l’esuberanza dei primi mesi, e che questo tipo di soluzioni maturi tanto da permettere di usarle solo dove hanno realmente senso.

Il ciclo di vita dell’accessibilità web (seconda parte)

Pubblicato il da

Presentiamo una versione rivista e ampliata dell’articolo “The Lifecycle of Web Accessibility” pubblicata dall’autore su evolt.org in inglese nel dicembre 2002

Nella scorsa puntata di questa mini serie abbiamo parlato di analisi dei requisiti e di come anche in questa fase iniziale sia importante tenere conto degli aspetti legati all’accessibilità del sito che andremo a costruire.

Affrontiamo ora la parte di progettazione concettuale, la vera a propria definizione di struttura e contenuto.

Progettazione concettuale

Cosa troviamo in questa fase

In questa fase avete bisogno di definire i flussi di funzionamento e disabilità cognitive, ad esempio, potrebbe incontrare delle difficoltà ad afferrare completamente il significato delle voci che avete utilizzato per un menu, soprattutto se queste sono in gergo (o, magari per risparmiare spazio, avete fatto largo uso di acronimi). Per la stessa ragione, cercate di limitare il numero di elementi in una lista e di mantenere la lunghezza della pagina entro limiti accettabili, eventualmente dividendola in più pagine.

Un cieco, invece, potrebbe utilizzare uno screen reader per accedere alla pagina, e in questo modo non dispone subito una visione completa della pagina che si trova di fronte. Prediligete allora una visualizzazione dei contenti che preveda di inserire, all’inizio del testo, un sommario che condensi quello di cui tratterà l’articolo. In questo modo sarà molto semplice saltare l’articolo, se non è di interesse.

Anche una efficace funzionalità di ricerca, presente in ogni pagina, è molto importante in questo senso, perché un cieco (come tutti, del resto) potrebbe non aver tempo da perdere e voler arrivare subito al contentuo di interesse. Per saperne di più potete scaricare l’ottimo capitolo sulla ricerca messo a disposizione da O’Reilly a proposito della seconda edizione di “Information Architecture for the World Wide Web” di Peter Morville e Louis Rosenfeld. Maggiori dettagli li trovate in fondo alla recensione scritta a suo tempo su Fucinaweb.

Da quello che è stato detto finora vi accorgerete che tener conto di questi elementi non aiuta solo i disabili che fruiscono il nostro sito, ma in realtà qualunque utente. Una ragione in più per fare le cose come si deve.

Per finire questa seconda parte voglio spendere qualche parola per i pochi che pensano sia meglio progettare per i disabili una versione alternativa, solo testo, del sito. Non si fa: i disabili non sono cittadini di seconda classe; possono e hanno il diritto di usufruire della pagina allo stesso modo di tutti gli altri utenti. Non dimenticatevi che l’accessibilità è un processo additivo; dovete aggiungere elementi e caratteristiche (come tag, descrizioni e attributi) piuttosto che eliminarli. Potete approfondire questi concetti in un interessante articolo di Usability Infocentre.

E se proprio secondo voi non c’è alternativa alla creazione di diverse versioni del sito, cercate prima di tutto di capire se potete ottenere lo stesso beneficio semplicemente realizzando diversi fogli di stile da applicare alla pagina, che è una strada praticabile e solitamente poco costosa.

Potreste pensare che, disponendo di un Cms, la strada sia spianata per realizzare versioni parallele. Ma chiedetevi quanto vi costerà e se non sarebbe meglio investire questa cifra nel migliorare usabilità ed accessibilità dell’unico, vero sito.

L’unico caso in cui potete (anzi, dovete) realizzare una versione parallela di sito, si verifica quando a cambiare non è solo la rappresentazione del contenuto, ma il contenuto stesso. Pensate per esempio a un telefonino, dove è improponibile usare la stessa quantità di contenuto normalmente visualizzata in una pagina web. Nella prossima puntata, dedicata ai prototipi e alla messa in produzione, vedremo quali standard possono essere utilizzati in casi come questo. Anche qui c’entra l’accessibilità web.