Daniel Burka (Digg/Pownce) – Designing for web apps vs designing for the web

Daniel ha per prima cosa presentato le differenze tra due degli ultimi progetti che ha seguito, Digg e Pownce. Il primo ha 3 anni e 2 milioni di utenti, il secondo è una realtà più giovane ma in cui i gruppi sono molto affiatati.

Le persone si aspettano che Digg aumenti le funzionalità e rispetti le aspettative degli utenti, anche in termini di performance.

Ma come comportarsi al momento di introdurre delle modifiche che, potenzialmente, potrebbero essere accolte con critiche? Come, in particolare, il feedback degli utenti influenza lo sviluppo dei prodotti web?

Daniel presenta l’esempio del nuovo sistema di commenti di Digg. L’obiettivo è che potesse gestire dei thread di conversazione più complessi di quello attuale, che fosse più veloce, e che permettesse discussioni legate all’argomento di cui si parla.

Come introdurre modifiche al sistema:

  • tenere sotto controllo i precenti feedback sul sistema
  • conoscere la comunità per cui si sta lavorando
  • cercare di anticipare le aree di frizione
  • impiegare focus group e studi di usabilità
  • decidere quali parametri adottare per stabilire che la modifica ha generato successo nella direzione voluta

Come comportarsi quando gli utenti dicono che andava meglio prima? Gli utenti andrebbero preparati per tempo. Va tenuto conto che lamentarsi di cambiamenti è in ogni caso una reazione normale.

Anche il feedback da parti degli “esperti”è importante, soprattutto se volontariamente dedicano del tempo a motivare i problemi che hanno riscontrato.

Esiste poi del feedback implicito: osservare il comportamento degli utenti, usando delle metriche. Molti utenti sono infatti “muti”, non condividono le loro esperienze.

Come comportarsi in seguito al feedback degli utenti

  • passo 1: non reagire subito, prendere fiato, a parte correggere gli eventuali bug
  • passo 2: identificare temi di critica e idee da seguire
  • passo 3: coinvolgere la comunità
  • passo 4: iterare nuovamente dal primo passo

Ricordatevi anche che è impossibile accontentare tutti: non provateci neppure.

Questo intervento è stato scritto in live blogging dalla conferenza Future of Web Apps di Londra, il 3 e 4 Ottobre 2007. Leggi tutti gli interventi di Fucinaweb dal FOWA

Risparmiare sui messaggi di errore

L’intervento di Jared Spool su User Interface Engineering sottolinea, se ancora ce ne fosse bisogno, la necessità di progettare form che siano (realmente) usabili.

E’ frequente trovarsi di fronte a form, come quello riportato da Spool, in cui sia possibile evidenziare non uno, ma diversi errori di design.

Form con la scritta: !The ZIP that you entered doesn’t match the City/State you entered. Please verify the information.

Quello che mi ha colpito dell’intervento è stato però il titolo, “Being cheap with error messages”, cioè risparmiare sui messaggi di errore.

Sì, perché quello che molto spesso succede è che già dalla fase di wireframing, di creazione delle bozze, la gestione degli errori nell’interfaccia non venga considerata, perché “tanto al cliente non interessa vedere cosa succede quando l’utente sbaglia o c’è qualche problema”.

Questo atteggiamento prosegue nelle altre fasi di progetto, fino ad arrivare in produzione dove, a meno di trovare qualche programmatore con buone competenze sull’usabilità delle interfacce (e ce ne sono, per fortuna), alla gestione degli errori viene riservato l’ultimo quarto d’ora prima dei test.

Per quella che è la mia esperienza, solo se fin dalle prime bozze è stato previsto di gestire con qualità gli errori, c’è qualche probabilità che questa situazione venga mantenuta fino alla messa online del sito. Proprio meglio non risparmiare in questo caso.

L’usabilità preventiva nel web

Cosa intendo con usabilità preventiva nel web? Intendo la capacità, per un sito o servizio, di anticipare e guidare l’utente allo scopo di limitare lo sforzo richiesto per raggiungere i propri obiettivi.

Il visitatore, si sa, ha poco tempo da perdere, o almeno ci piace crederlo. Allora perché non agevolare la sua navigazione filtrando quello che potrebbe interessargli rispetto all’intero contenuto del sito?

Le strade per implementare questo tipo di soluzione sono diverse. La strada più percorsa, quella classica, è di chiedere esplicitamente al visitatore qualche informazione preventiva, come la nazione o la lingua, così da fornire subito quello che è più adatto alle sue esigenze. E’ il caso di un sito di e-commerce che calcola le spese di spedizione o di un sito multilingua che presenta le “bandiere” nazionali da qualche parte nella pagina.

Un’altra strada, usata soprattutto da siti che prevedono l’iscrizione del visitatore, è quella di permettere la personalizzazione, anche spinta, degli elementi dell’interfaccia grafica. Quello che fa, tanto per capirci, l’homepage personalizzata di Google.

C’è una terza possibilità. Il server web di cose sul navigatore ne sa infatti parecchie, dalla risoluzione del monitor al numero di colori, dalla nazione di provenienza alla lingua usata. Di solito queste informazioni sono usate, a posteriori, a fini statistici. E’ quello che si fa per esempio con Google Analytics. Nessuno vieta di usare alcune di queste informazioni nel corso della navigazione dell’utente, così da agevolare alcune operazioni. Anche di questo parla l’interessante presentazione di Stephen Anderson di cui ho parlato qualche mese fa, in cui l’autore immagina un form che presenti precompilata la nazione di provenienza basandosi sull’indirizzo di IP (con possibilità, ci mancherebbe, di modificare il dato).

Questo terzo approccio, se ben impiegato, senza per forza voler strafare, potrebbe ridurre l’attività svolta “inutilmente” del visitatore.

Vediamo come con un’esperienza – negativa – vissuta in prima persona.

Incuriosito dal rilascio da parte della BBC dell’iPlayer, un software che permette il download dei programmi dell’emittente britannica trasmessi nell’ultima settimana, l’ho voluto provare. Ecco la cronistoria delle faticose operazioni che ho compiuto un mese fa. Oggi le cose sono diverse, proprio perché la stessa BBC ha impiegato qualche semplice tecnica di usabilità preventiva.

In coda

Ho richiesto un invito per partecipare al programma e ho atteso pazientemente. E’ passata circa una settimana e ho ricevuto nella mia casella un accredito, cioè un login e una password

Login con sorpresa

Dal sito iPlayer ho cercato il login e mi è apparsa la relativa schermata.

image

Si tratta di una finestra modale. Un peccato, perché mi ha impedito di accedere a Gmail dove erano salvati login e password, che ho allora dovuto copiare e incollare da un documento di testo.

Selezione del programma

A questo punto mi è apparsa la pagina principale dedicata ai programmi, in perfetto stile web 2.0.

image

Da qui ho navigato verso un qualcosa che mi interessava, in particolare un documentario sulle montagna.

Download

Ho cliccato sulla scheda del programma e mi si è presentata la possibilità di procedere con il download, come del resto mi sarei aspettato.

image

Problema 1: il browser

image

Ma non avrei dovuto usare Firefox, perché il sito è per il momento rivolto solo a utenti Internet Explorer. Anche se avessi usato il Mac non avrei avuto fortuna migliore. Ho allora ripetuto tutta la procura e mi sono autenticato con Internet Explorer.

Problema 2: la versione di Windows Media Player

Questo problema è quasi divertente. Anche se il computer sembra soddisfare tutti i requisiti presenti in questa pagina, c’è ancora qualcosa che non va.

image

Si tratta in realtà – è bastato poco per scoprirlo – della versione di Windows Media Player, che va quindi aggiornato. Scarichiamo il player, installiamo e ricominciamo da capo. Login, ricerca, selezione, ecc.

Download e installazione di iPlayer

image

A questo punto mi è stato chiesto di procedere con il download di iPlayer, che è un programma Windows a tutti gli effetti. L’ho scaricato, installato e sono poi ritornato per l’ennesima volta sulla scheda del programma e ho – finalmente – potuto richiederne la visione. Ricevendo questa pagina in risposta:

image

In poche parole: non posso usare il servizio perché mi sto connettendo da fuori della Gran Bretagna. Non posso fare nulla, il servizio è disponibile solo a chi vive lì. Fine, stop, punto.

La colpa, diciamolo francamente, è mia. Se avessi letto con attenzione le pagina fitta fitta di requisiti avrei trovato il riferimento a questo limite fondamentale e avrei risparmiato mezz’ora di tentativi.

Qualcosa in più l’avrebbe potuta però fare anche lo stesso sito della BBC. E oggi è infatti così: non riuscirete più ad ottenere una login e una password per accedere alle schermate che ho riportato qui sopra, perché ancora prima della richiesta di un accredito per la versione beta troverete ad attendervi il messaggio che vi avvisa del requisito principale, ovvero di essere residenti in Gran Bretagna.

L’esempio di iPlayer è sicuramente al limite, in quanto l’IP è usato addirittura per impedire l’accesso a una sezione (limite che con un po’ di impegno è comunque possibile aggirare).

Eppure in casi più semplici, come la precompilazione di alcuni dati nelle maschere di inserimento, i dati lasciati dal browser dell’utente potrebbe essere usati, una volta tanto, per risparmiargli un po’ di tempo piuttosto che per spiarne il comportamento.