Ancora su Ajax e usabilità

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 design d’interfaccia nel web 2.0

Ho appena finito di leggere Designing Interfaces, pubblicato per i tipi di O’Reilly da Jenifer Tidwell.

Un must per chiunque si trovi a dover progettare un’applicazione, sia essa desktop, web, o web 2.0 e necessiti di qualche spunto o suggerimento. Si tratta in particolare di un insieme di pattern, ovvero soluzioni a semplici e comuni problematiche raggruppate per categoria:

  • Organizzazione del contenuto
  • Navigazione
  • Layout di pagina
  • Azioni e comandi
  • Tabelle e dati complessi
  • Form e controlli
  • Editors
  • Estetica

Non è quindi un testo dedicato esclusivamente a chi lavora con il web. Tutt’altro. Molti degli esempi riguardano infatti normali applicazioni desktop. Ma il probabile successo di Ajax è destinato a far avvicinare il design di interfaccia web a quello delle normali applicazioni; motivo in più per procurarsi questo testo.

Ma anche senza acquistarlo potete trarre beneficio da due risorse disponibili gratuitamente. Prima di tutto un capitolo gratuito, uno dei più interessanti, dedicato al layout di pagina.

E’ però soprattutto utile il sito del libro, perché vi troverete una buona selezione dei pattern presentati nel testo. Più di così…

Designing Interfaces – di Jenifer Tidwell – O’Reilly

Ha senso imparare Ajax?

Che in futuro la percentuale di applicazioni web di tipo Ajax (e Ria in generale) aumenti sempre più è un dato di fatto. Ma non è ancora chiaro chi, all’interno del team di sviluppo di un progetto web, debba imparare a masticare questa nuova architettura. Tutti? Solo chi si preoccupa della programmazione? Chi sviluppa i template? Il designer?

Chi progetta l’interfaccia

Uso qui impropriamente il termine “progettare l’interfaccia” intendendo in realtà molte specifiche professionalità, illustrate sapientemente da Jesse James Garrett nel diagramma “The Elements of User Experience“.

Chi rientra in questa categoria farebbe bene a capire come per l’utente cambia il modo di usare un sito che utilizzi Ajax. Perché le possibilità aumentano e l’interattività si avvicina a quella di un normale programma per computer. Per capire cosa intendo potete dare un’occhiata a quanto messo a disposizione da Yahoo!. Ma tutto questo pone anche dei problemi per quanto riguarda l’accessibilità e l’usabilità di Ajax.

Chi declina il template

La cosa più importante che deve fare chi si occupa del lavoro sporco, ovvero di convertire i template in codice Html e fogli di stile, è fare in modo che questi aderiscano il più possibile agli standard web. Non solo sulla carta, ma per davvero, come dico da due anni e passa.

Il fatto che Ajax impieghi massicciamente Javascript, realizzato solitamente da chi si occupa di produrre l’Html della pagina, potrebbe trarre in inganno. Si tratta infatti di un uso avanzato di Javascript, da lasciare a chi lavora lato server.

Chi scrive il codice lato server

Ecco, direte, quali sono i veri utilizzatori di Ajax, le persone che si infangano le mani tra codice Javascript e programmazione lato server…o no?

Certo, per capire come funziona Ajax suggerisco di creare da zero un piccolo esempio, ma è imprensabile sviluppare applicazioni complesse in questo modo.

Molto meglio votarsi a un framework che sollevi da questa responsabilità. Ma se possibile non un framework lato client, come ad esempio Prototype.

In futuro (neanche tanto lontano, basti pensare a quello che sta facendo, tra gli altri, Microsoft con Atlas), il supporto per Ajax sarà integrato direttamente all’interno dei framework di sviluppo lato server, tanto da renderne “invisibile” il funzionamento.

Attenzione però, perché trasparente fa rima con pericoloso. Dovrete prestare comunque attenzione a quello che fate; non dimenticatevi che siete sempre alle prese con un browser e – la maggior parte delle volte – con il protocollo Http.