La guerra tra sviluppatori e clienti

Incomprensioni, aspettative disattese, frustrazione.

A questo si può ridurre il rapporto tra chi realizza un sito e chi lo commissiona. La soluzione, almeno secondo la web agency Newfangled, sta nel coinvolgere gli utenti fin dall’inizio con un uso sapiente dei prototipi.

Quelli dell’agenzia sono talmente convinti di quello che dicono da aver realizzato un curioso manuale di 50 pagine da scaricare gratuitamente in formato Pdf, dal titolo “Client vs. Developer Wars“, ad indicare appunto la difficoltà di comunicazione tra le due realtà .

Consiglio di dare una sfogliata al testo e di leggerne soprattutto la prima parte: difficile non riconoscersi in alcune delle situazioni esposte.

L’unico aspetto sul quale non sono però completamente d’accordo è la scelta di realizzare i prototipi in Html, ma solo per via dei tempi: un prototipo Html richiede secondo me troppi sforzi. Meglio probabilmente ricorrere ad altri strumenti, ad esempio Visio con opportune estensioni. Ma in fondo è un dettaglio, è il principio di usare i prototipi che conta.

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.

Web design estremo

I motivi per cui la navigazione di un visitatore può inciampare in qualche condizione imprevista sono molti: problemi al server, moduli non compilati correttamente (campi obbligatori mancanti, tipi di dato non previsti), link errati provenienti da motori di ricerca, ecc.

Chi sviluppa il sito deve rendersi conto che per quanta cura è stata posta nel design e nello sviluppo di un sito, prima o poi una di queste condizioni si verificherà.

I ragazzi di 37signals hanno scritto un manuale che presenta 40 linee guida da seguire nello sviluppo di un sito perché sia possibile prevedere e gestire correttamente alcuni punti di crisi, come ad esempio:

E’ importante aiutare l’utente che si trova in queste situazioni anomale perché possa efficacemente uscirne, senza ambiguità e con un linguaggio comprensibile, ma anche presentando le sole informazioni necessarie allo scopo.

L’approccio degli autori è fortunatamente molto pratico: viene brevemente presentata la linea guida e seguono immediatamente alcuni esempi negativi e positivi tratti da siti reali. Non aspettatevi però suggerimenti su come intervenire direttamente sul codice, perché non è una guida di Html o di sviluppo web.

Defensive Design for the Web – How to improve Error Messages, Help, Forms and Other Crisis Point * 37 Signals * New Riders * $24.99

Traduzione italiana:
Defensive Design per il web – Come migliorare messaggi di errore, help, form e altri punti critici di un sito * 37 Signals * Tecniche Nuove * euro 19.90