I 15 princìpi web della BBC

Tom Loosemore della BBC ha pubblicato nel suo weblog un elenco di 15 punti che i dipendenti del network inglese sono tenuti a rispettare nel progettare e aggiornare i propri siti.

Li ho trovati degli ottimi comandamenti che andrebbero stampati e appesi vicino al monitor, e li traduco qui con qualche libertà:

  1. Realizza prodotti che incontrino le necessità del tuo pubblico
  2. I migliori siti web fanno una sola cosa, e la fanno molto bene
  3. Non cercare di fare tutto da solo, inserisci collegamenti ad altri siti di qualità
  4. Sperimenta e verifica velocemente, itera
  5. Tratta tutto il web come una tela creativa: non restringere la creatività al tuo solo sito
  6. Il web è una conversazione. Partecipa. Adotta un tono rilassato, ammetti i tuoi errori
  7. La qualità dell’intero sito è data dalla qualità della sua pagina peggiore. Verifica che le linee guida editoriali siano adottate e seguite
  8. Assicurati che sia possibile aggiungere collegamenti verso le tue pagine. Per sempre
  9. Ricordati che tua nonna non userà mai “Second Life”. Potrebbe utilizzare internet, ma con esigenze molto diverse da quelle dei precursori
  10. Crea diversi percorsi per raggiungere il contenuto: sviluppa aggregazioni per persone, luoghi, argomenti, canali, ecc. Ottimizza il sito per l’indicizzazione nei motori di ricerca
  11. Design e percorsi di navigazione consistenti coerenti non significa che una soluzione vada bene per tutti: gli utenti devono sempre sapere che si trovano su uno dei tuoi siti, ma questi possono essere anche molto diversi tra loro
  12. L’accessibilità non è un optional
  13. Fa’ in modo che i tuoi utenti possano copiare e incollare i tuo contenuti sulle pareti delle loro case virtuali: incoraggia gli utenti a prendere estratti di contenuto dalla tue pagine, e a inserire link verso il tuo sito
  14. Inserisci link alla discussioni che nascono nel web, non limitarti a ospitarle
  15. La personalizzazione dev’essere non intrusiva, elegante e trasparente. Dopo tutto si tratta dei dati dei tuoi utenti, che vanno rispettati

Del punto 12, relativo all’accessibilità, ho avuto modo di parlare molto. Anche l’ultimo, che parla di personalizzazione, è stato oggetto di qualche considerazione su Fucinaweb, a proposito delle interfacce che si adattano.

Interfacce che si adattano

Cominciano a comparire nei blog dei relatori alcune delle presentazioni al recente Information Architecture Summit di Las Vegas. E ce ne sono da leggere con attenzione.

Come per esempio quella di Stephen Anderson, “Creating the Adaptive Inferface” che affronta il problema della progettazione di interfacce che non si manifestino allo stesso modo a tutti gli utenti, ma siano in grado di adattarsi alle diverse esigenze, ai diversi usi, e anche al grado di padronanza che con l’uso l’utente è in grado di dimostrare.

L’idea – non nuova – di Anderson è quella di sfruttare le informazioni “involontariamente” lasciate dall’utente nel sito web, come per esempio l’indirizzo di ip (e quindi, con buona approssimazione, la località) e, nel caso di servizi sotto login o che sfruttino i cookie, le variazione nelle attività dell’utente e la frequenza di utilizzo.

Questo permette al software che produce l’interfaccia di evidenziare le sezioni più richieste a scapito di quelle meno utilizzate, di precompilare alcuni campi in base alle preferenze dell’utente e di personalizzare alcune etichette dell’interfaccia.

Il concetto è sicuramente interessante, come lo sono i diversi esempi presentati. Esistono comunque alcuni fattori da tenere in grande considerazione nel progettare questo tipo di interfacce. Il primo, riconosciuto dallo stesso autore, è che l’utente non va spaventato dandogli a vedere che sappiamo molto di lui: l’aiuto dell’interfaccia dev’essere discreto e non superare mai i limiti della cortesia.

A questo aggiungo che esiste un rischio nel modificare il comportamento dell’interfaccia verso un utente col il progredire della sua esperienza, ed è quello di generare dubbi e confusione perché eravamo convinti “che quel pulsante fosse lì” e che “quella funzionalità si attivasse in quel modo”. Anche queste variazioni vanno studiate con molta cautela.

Riprogettazione di applicazioni web

Riprogettare un’applicazione web nel nome di una migliore usabilità, oltre che per arricchirne le funzionalità, è un’operazione lodevole e che si verifica molto spesso in un ambito così concorrenziale come internet.

Ma attenzione a stravolgere un’applicazione, anche se con i propositi più meritevoli.

E’ vero che riprogettare un’applicazione web la può notevolmente migliorare, ma è anche vero che gli utenti affezionati al servizio, soprattutto quelli meno esperti, si trovano a dover reimparare l’uso di un’interfaccia che conoscevano alla perfezione (sia i suoi pregi, sia i suoi difetti). Rendetevi conto che state chiedendo a questi utenti, che vi hanno dato fiducia, di fare del lavoro non richiesto.

Non esistono delle regole da applicare a propri che spieghino come comportarsi. Vale la pena prima di tutto coinvolgere gli utenti, e questo si può fare ancora prima di riprogettare l’applicazione, chiedendo il loro parere sui limiti della versione attuale e sulle funzionalità di cui il prodotto manca.

Le statistiche, insieme ai dati delle registrazioni, sono un ottimo metodo per distinguere la percentuale di utenti consolidati rispetto a chi entra e fugge, e vi può aiutare a capire a quanti utenti state arrecando piccoli o grandi disagi. Quest’analisi, in realtà, andrebbe fatta indipendentemente dalla riprogettazione del servizio.

Nella maggioranza dei casi quello che emerge è che piuttosto di considerare l’applicazione come una tabula rasa su cui ripartire da zero, è meglio procedere con passi incrementali, ben documentati.

Introdurre una nuova funzionalità, sottolineare i cambiamenti nell’interfaccia, attendere un feedback, introdurre una nuova funzionalità, e così via.

E’ quello che succede con prodotti come Flickr e Gmail che vengono considerati in “beta perpetua”. Questo permette al team di sviluppo di rilasciare costantemente nuove funzionalità secondo i principi della programmazione agile, ma evita anche agli utenti di essere sommersi da nuove caratteristiche da digerire tutte in un colpo.

Capita a volte che questo procedimento non sia perseguibile, perché la riprogettazione dell’applicazione si discosta talmente tanto dalla versione precedente da rendere impossibile il rilascio incrementale.

Anche in questo caso si può, in alcuni casi, fare qualcosa. E’ quello che è successo ad esempio con Google Reader. In questo caso la vecchia versione del prodotto è stata completamente riscritta, senza stazioni intermedie.

Ogni utente ha però la possibilità di tornare, se non è soddisfatto della nuova versione, a quella precedente, dovesse mai preferirla, per un periodo limitato, e sottoporre anche un commento. Si tratta comunque di un processo altamente dispendioso, perché vi trovate a gestire contemporaneamente due prodotti diversi.

Creare tassonomie efficaci

Theresa Regli ha scritto per l’AIIM E-Doc Magazine un interessante articolo in cui indica alcuni suggerimenti per creare delle tassonomie efficaci per i contenuti.

Una tassonomia è lo schema e l’insieme di gerarchie che descrive un certo tipo di informazione. Questo intervento di Fucinaweb, per fare un esempio, è un contenuto che appartiene alla categoria Content Management e Information Architecture ed è anche descritto da alcuni tag supplementari in fondo all’articolo.

L’introduzione di una tassonomia per i contenuti deve essere motivata a chi poi la andrà a utilizzare tutti i giorni, evidenziando il modo migliore di impiegarla. Il rischio è altrimenti quello di introdurre una caratteristica di soggettività durante l’uso della classificazione, con persone diverse che applicano criteri diversi allo stesso contenuto (io stesso ho potuto verificare questa problematica in un progetto che prevedeva la catalogazione di migliaia di articoli tratti da riviste).

Secondo la Regli, e condivido, agli utilizzatori di questi metodi di catalogazione dovrebbe essere fornito un modo per verificare subito, con le stesse ricerche che impiegherà chi poi deve ricercare i contenuti, la bontà e i limiti della catalogazione. Avere un riscontro istantaneo del proprio operato è importante per raggiungere fin da subito un buon livello di qualità in questo tipo di operazioni solo a prima vista ripetitive.

I concetti di tassonomia e catalogazione per il web sono affrontati con un ottimo livello di dettaglio in Information Architecture for the World Wide Web, che ho recensito qui su Fucinaweb.