Ajax e l’usabilità, seconda parte

Torniamo a occuparci (dopo averne approfonditamente discusso in un precedente intervento) di sviluppo di applicazioni Ajax e di come questa architettura ponga il progettista di interfacce davanti a nuove sfide.

L’occasione per riparlarne è un consolatorio articolo Donna Maurer per Digital Web; consolatorio perché va nella stessa direzione del precedente articolo di Fucinaweb.

“La sfida chiave nel progettare questo tipo di applicazioni e che gli utenti si accorgano degli aggiornamenti di parti di pagine”.

E la mia lamentala a proposito di Google Reader parte proprio dal fatto che, sotto carico, è impossibile per un utente del servizio capire se e dove c’è un problema.

L’articolo di Donna Maurer prende in realtà in considerazione non solo le applicazioni ajax, ma in generale quelle che vengono definite RIA, comprendendo con questo anche Applet Java e applicazioni basate su Macromedia Flash (maggiori informazioni su RIA possono essere trovate su wikipedia).

Quali sono sfide da affrontare secondo Maurer?

Decidere quanta interattività aggiungere

Vero, il rischio è di tornare ai tempi immediatamente successivi all’avvento della gif in movimento, che tutti usavano come fosse la soluzione a tutti i mali.

Gestire gli elementi interattivi

Creare applicazioni internet complesse significa avere a disposizioni nuovi elementi e possibilità per facilitare l’uso l’interfaccia. Ma questi elementi devono essere familiari agli utenti del sito, e il loro uso non ambiguo. A questo scopo possono senz’altro aiutare i pattern definiti da Yahoo! (come ad esempio quelli relativi al drag&drop o agli slider, che i lettori di Fucinaweb hanno già avuto modo di apprezzare).

Ricaricare parti di una pagina

Poiché il fuoco d’attenzione di una persona può concentrarsi solo su una cosa alla volta, è molto importante che l’interfaccia segnali proprio nel punto in cui c’è attenzione eventuali cambiamenti o richieste di intervento. Questa pratica è in realtà comune a tutte le interfacce, ma la novità per gli utenti nel trovarsi di fronte a nuovi comportamenti del browser fa sì che sia ancora più importante comunicare con lui in modo preciso e non ambiguo.

Superare il modello tutto-in-una-pagina

Avere la possibilità di ricaricare parti di una pagina non vuol dire che questa sia sempre la strategia corretta o che questa debba perfino essere portata all’estremo, così da usare una sola pagina per l’intera applicazione.

Nell’articolo di Donna Maurer viene citato The Design of Everyday Things di Don Norman, ma a mio avviso è bene rispolverare un altro grande testo (se siete stati così scortesi dall’averlo messo in soffitta): The Human Interface di Jef Raskin.

Ajax e l’usabilità

Ho recentemente avuto modo di esprimere qualche pensiero a proposito di Ajax e accessibilità web.

Mi però anche chiesto quali siano i vantaggi e gli eventuali problemi legati all’usabilità di questo tipo di applicazioni.

Il nocciolo della questione è che varia il modo con cui l’applicazione interagisce con l’utente. Invece di essere legati all’ormai consolidato procedimento per cui ad ogni azione dell’utente corrisponde una richiesta al server, che provoca la spedizione di un’intera pagina Html verso il browser, con Ajax è possibile aggiornare parti della pagina senza che sia necessario ricaricarla completamente.

I benefici l’hanno davanti agli occhi chi utilizza un’applicazione basata su questa architettura. Gmail non solo consente di ricercare agevolmente i contatti o di inserire allegati come se stessimo usando un applicativo desktop, ma da qualche tempo è presente un’utilissima funzione di salvataggio automatico.

A livello di usabilità sono sicuramente dei passi da gigante. Quando ho avuto modo di provare in anteprima la nuova versione di Yahoo! Mail sono rimasto stupefatto. Si tratta di un vero e proprio client di posta elettronica all’interno di un browser, con funzionalità di drag & drop (sia dal desktop, sia dalle cartelle della posta), menù contestuali, finestre multiple, ecc.

Mi rendo però conto che questo tipo di applicazioni altamente interattive, se mal pensate, possono d’altro canto ridurre sensibilmente l’usabilità. E chi sbaglia non è lo sviluppatore casuale, ma anche chi normalmente è attento a queste problematiche, come i ragazzi di Google.

Ho utilizzato il loro reader Rss negli sfortunati giorni appena successivi al rilascio, quando l’applicazione era di una lentezza esasperante. Per carità, può succedere, e questa non è sicuramente colpa di Ajax. Il problema è che per tutto il tempo che ho utilizzato il Reader non ero sicuro se la mia richiesta fosse stata ricevuta dal server di Google, e se questo stesse lavorando per esaurire la mia richiesta. Non ero addirittura sicuro di aver premuto il link giusto nel posto giusto.

Il motivo? Il fatto è che, nel bene o nel male, siamo tutti abituati al comportamento di un’applicazione web standard.

Premo un pulsante o un link, il logo in alto a destra del browser comincia a girare e la barra di stato in basso a sinistra indica cosa sta succedendo alla comunicazione tra browser e server. In poco tempo posso capire se ci sono problemi a contattare il server, se sta impiegando troppo tempo a rispondere, o se tutto si è risolto per il meglio.

Ma non con il lettore Rss di Google, costruito completamente con architettura Ajax, dove cambiano le convenzioni a cui siamo abituati. In questo caso la pagina non si ricarica completamente, ed è quindi necessario che sia lo sviluppatore ad avvisare esplicitamente che sta accadendo qualche cosa, che è stata inoltrata una richiesta al server. Altrimenti io utente vedo solo un browser che rimane fermo, senza sapere se ha ricevuto il mio click o no, se il problema è nel server o se è successo qualcos’altro.

Ajax dà quindi la possibilità di migliorare l’usabilità di una pagina, ma se non si pone la dovuta attenzione, è molto più facile peggiorarla. Su questo ci sarà molto da lavorare in futuro.