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

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.

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.

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.

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.

Problema 1: il browser

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.

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

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:

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.

Ogni form ha esigenze diverse dagli altri, ma se lo scopo è quello di inviare al visitatore del materiale acquistato, ma anche una semplice brochure, cercate di prevedere sempre un campo “azienda”.

Spesso visito siti che non prevedono la possibilità di specificare un riferimento aziendale. So che se inserissi semplicemente il mio nome e l’indirizzo dell’azienda il postino o il corriere non riuscirebbero mai a trovarmi. La soluzione per il visitatore è allora quella di sporcare il campo cognome con qualcosa del tipo “Cognome c/o Azienda”, ma così facendo viene compromesso il patrimonio di informazioni che lascia.

Certo, memorizzare il campo azienda è il primo passo, ma se questa informazione non è poi passata a chi si preoccupa della consegna, si è comunque fatta poca strada. E’ quello che succede per esempio con La Fonera: ho visto il corriere percorrere l’intero stabile in cerca del mio collega che l’ha ordinata perché nel documento di viaggio non compariva in alcun modo l’azienda per cui lavora.

E’ quello che ho fatto l’altra sera, intorno alle 21.30. Le mie intenzioni erano quelle di dichiarare il reddito per il 2006, operazione che da quest’anno è possibile svolgere anche online. Per posta ordinaria mi sono infatti arrivate due lettere, la prima contenente il codice, la seconda la password.

E infatti mi sono collegato senza problemi, ricevendo però questa risposta:

Insomma, anche il server web ha il diritto di fare orario da ufficio.

La prima, e sicuramente la migliore, è la presentazione di Luke Wroblewki, designer di Yahoo!, dal titolo Best Practices for Form Design, che è possibile scaricare in formato Pdf. Una presentazione piena zeppa di suggerimenti e consigli su come presentare e raggruppare i campi di un form. Ne segnalo solo alcuni:

• posizionare le etichette di campi in alto è utile per ridurre il tempo di completamento, ma richiede ovviamente più spazio verticale; allinearle a destra del campo lega con evidenza il campo e l’etichetta, ma può ridurre la leggibilità; allinearle a destra facilita la lettura delle etichette, ma ne riduce l’associazione con il campo
• vale la pena indicare i campi obbligatori solo se sono in minima parte, altrimenti meglio indicare quelli opzionali
• la lunghezza del campo fornisce preziose informazioni sulla compilazione
• è bene cercare di raggruppare campi che sono in qualche modo correlati, per velocizzare la compilazione del form
• le azioni primarie (salva, continua, invia) devono essere chiaramente separate ed evidenziate rispetto alle azioni secondarie (cancella, indietro, reset)
• meglio usare poche indicazioni su come compilare il form, da porre vicino ai campi che richiedono attenzione

Molti, molti altri consigli nella presentazione.

Un’alta interessante documento è la guida realizzata dal ministero del commercio norvegese: Simplified Forms for the Public Sector, progetto Elmer. Si tratta di una serie di linee guida rivolte principalmente al settore pubblico, suddivise in categorie e sezioni. Alcuni suggerimenti sono forse fin troppo specifici ed esagerati, ma darci un occhio matura sicuramente delle buone ideee per il futuro.

Vale la pena anche dare un’occhiata alla presentazione di Aaron Gustafson dal titolo Learning to Love Forms, decisamente più tecnica e che va diretta al codice Html. Anche qui interessanti suggerimenti, come quello di usare le liste al posto di “div” o paragrafi per ospitare i campi del form e qualche esempio su come utilizzare tag normalmente dimenticati, come legend e fieldset. Sono 100 slide con estratti di codice che vale davvero la pena di provare.

Nelle mie ricerche ho avuto la fortuna di imbattermi in alcuni risorse che mi sento senza dubbio di consigliare.

La prima è il manuale “Designing the Mobile User Experience“, pubblicato da Wiley, che è un’ottima introduzione a questi temi. Secondo l’autrice, Barbara Ballard, il termine “mobile” si riferisce, più che al dispositivo o al software, all’utente e alle situazioni in cui si trova a interagire con queste periferiche.

Questo testo contiene anche utili indicazioni delle differenze con cui i dispositivi mobili vengono usati in Europa, in America e in Asia. Non si tratta semplicemente di variazioni di standard o di protocollo, ma anche di impiego. In America, ad esempio, gli SMS hanno storicamente riscosso minore fortuna che in Europa, a causa di eccessivi prezzi fissati dagli operatori, ma anche per la capillare diffusione della posta elettronica.

La cosa bella di questo manuale è che il capitolo più interessante, il sesto, è in buona parte disponibile anche online sottoforma di wiki. Il capitolo prende in considerazione alcuni pattern di progettazione per i dispositivi mobile, suddivisi in macrocategorie:

• progettazione dello schermo
• navigazione all’interno delle applicazioni
• gestione delle applicazioni
• pubblicità

Avendo a che fare con dispositivi dalle funzionalità eterogenee, questi sono statti suddivisi in classi di appartenenza. Ciascun pattern fa quindi riferimento a una o più classi, così che sia immediato capire se un pattern è applicabile o meno a una determinata periferica.

Un’altra interessante risorsa, questa volta liberamente scaricabile in formato Pdf, è il documento “Mobile Web Developer’s Guide” scritto da Brian Fling, e si rivolge a chi si proccupi di realizzare siti web che siano accessibili anche ai telefoni cellulari, e in generale alle ultime generazione di dispositivi mobile. Questo testo integra in qualche modo quanto presentato dal manuale della Ballard, avvicinandosi più alle problematiche di sviluppo.

Un estratto condensato del primo:

Kataweb Blog al momento è un servizio basato sulla piattaforma TypePad.
Kataweb ha deciso di non utilizzare più la piattaforma di TypePad a partire da mercoledì 25 luglio 2007.

Ricevuta la mail dovrai scegliere, entro e non oltre la mezzanotte del 22 luglio 2007, una tra le seguenti due opzioni:

1. Trasferire il tuo Blog sulla nuova piattaforma di Kataweb
2. Rimanere TypePad e abbonarti alla loro versione a pagamento

Se entro la mezzanotte del 22 luglio 2007, non avrai scelto alcuna delle due opzioni, il tuo Blog verrà disattivato e tutti i contenuti saranno cancellati definitivamente.

e della email di Yahoo!

Dear Yahoo! Photos user,

For some time now, we’ve supported two great photo sharing services: Yahoo! Photos and Flickr. But even good things come to an end, and we’ve decided to close Yahoo! Photos to focus all our efforts on Flickr — the award-winning photo sharing community that TIME Magazine has called “completely addictive.”

We will officially close Yahoo! Photos on Thursday, September 20, 2007, at 9 p.m. PDT.

Please give us your decision by Thursday, September 20, 2007, at 9 p.m. PDT. After that time, any photos remaining in Yahoo! Photos will be deleted.

Due messaggi apparentemente simili, anche se si riferiscono a servizi diversi. Apparentemente:

1. Kataweb, non è un po’ tardi avvisarmi i primi di Luglio per dirmi che mi cancelli il 22 di Luglio? Metti che abbia la fortuna di passarmi 3 settimane in vacanza. Al ritorno cosa faccio quando mi vedo il blog annientato? Yahoo! da’ un bel po’ di tempo in più, il giusto per poter fare qualcosa
2. Non mi piace quel “Kataweb ha deciso di non utilizzare più la piattaforma di TypePad”. Sa troppo di rimprovero verso un fornitore di servizi di cui non si è contenti
3. Perché, visto che se clicco un tasto mi porti sulla nuova piattaforma blog, non lo fai automaticamente se non dico nulla? Vuoi forse risparmiare qualche centesimo di spazio disco non migrando i blog abbandonati? Ma portali tutti di là! (La stessa cosa vale comunque anche per Yahoo!, anche se in questo caso potrebbero forse cambiare i termini di privacy con cui sono condivise le foto in Flickr).

Un nome un po’ infelice, difficile da ricordare e, per un italiano almeno, anche da scrivere.

Se ne devono essere accorti anche quelli di Wordpress, perché il sito è raggiungibile sia che scriviate Akismet.com sia, come è successo a me, Askimet.com. Ma anche Askismet.com porta da qualche parte, ovvero in casa di uno dei creatori di Wordpress.

Una bella idea, applicata da pochi che usano nomi di Url altrettanto - o più - complessi.

Potete quindi immaginare la mia reazione quando ho trovato, sul sito di La Repubblica, un banner che pubblicizza la mostra a lui dedicata ad Arezzo, Monterchi e Sansepolcro: ho cliccato.

E mi sono trovato davanti a un server in timeout. Pensate: qualcuno ha pagato un banner che approda a nulla.

Il fatto è poi che l’incidente, ovvero la scarsa qualità dell’infrastruttura che ospita il sito, ha involontarie ripercussioni psicologiche perfino sulla mostra.

“Se il sito è scarso, magari lo è anche la mostra”.

“Hanno risparmiato con il server, avranno fatto lo stesso anche con l’allestimento”.

“Non sono capaci di prevedere il carico web di una sponsorizzazione, chissà che coda ci sarà nelle sale”.

Volevano semplicemente farsi pubblicità, e si sono tirati il martello sui piedi.

L’unica cosa indiscutibile, per fortuna, è la qualità dell’opera di Piero.

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.

Ma la cosa interessante non è tanto il servizio, quanto la procedura di registrazione che è quasi inesistente. Dal momento in cui si è aggiunto l’utente Imified alla propria rubrica e si è inviato il primo messaggio siamo infatti già diventati utenti del sistema, senza username o password di sorta e quindi senza quasi accorgersene. E questo è sufficiente non solo per utilizzare il servizio via IM, ma anche per personalizzare e configurare il proprio account attraverso una opportuna pagina web.

Che sia una lezione per gran parte delle procedure di registrazione che si vedono in giro, oppure c’è qualche problema di sicurezza e privacy che gli inventori di Imified hanno forse sottovalutato?

Appena sotto la prima sponsorizzazione Adsense, compare una pubblicità made-in-google che conduce direttamente a Blogger, il loro servizio di creazione weblog.

Poiché anche la prima posizione è di Google, non sussiste nessun problema, ma provate a immaginare se al posto del primo spazio ci fosse una vostra inserzione: ne sareste contenti?

Anche se comparirebbe in prima posizione, esistono almeno due fattori che spingerebbe gli utenti a cliccare sul secondo link:

• è corredato da un’elegante immagine
• riporta la scritta “tip”, suggerimento, mentre invece sempre di pubblicità si tratta

Google ha poi rimosso questo tipo di sponsorizzazione, ma la domanda che mi pongo è: tutti questi esperimenti perché si rendono conto che il loro Adsense gli produce pochi risultati?

Con la messa online del sito sono stati pubblicati una serie di corsi tematici, uno riguardante Asp.net e un altro focalizzato sul web design, seguiti poco dopo da un corso di accessibilità web.

Questi cinque anni sono un modo per fare un consuntivo su quello che è stato fatto e scritto. Sono stati in particolare pubblicati fino ad oggi circa 250 tra articoli, recensioni e segnalazioni, di cui i 5 più visitati “di tutti i tempi” sono:

• 13 manuali per dominare Visual Basic .Net
• Ajax e l’usabilità
• Realizzare siti Flash più usabili dei siti Html
• Scegliere il CMS Open Source per le proprie esigenze
• Template Html Gratuiti

Ma se dovessi scegliere il mio preferito, non avrei dubbi, e suggerirei di leggere il (prolisso) “Gli standard web sono inutili (da soli)“, un articolo rivolto a chi considera gli standard web fini solo a sé stessi, senza considerare le complessità di un progetto web nel suo insieme. Un articolo a suo tempo criticato da molti, a mio parere senza troppe motivazioni convincenti.

Fucinaweb non è nato come weblog. Mi ricordo che all’inizio era gestito completamente “a mano”: la pubblicazione di un articolo prevedeva l’inserimento di tutto il codice Html, la compilazione di tutti i link in cui quell’articolo veniva citato, e la copia di tutto via Ftp, sempre manualmente. Dopo qualche esperimento con Wordpress sul mio sito personale ho poi deciso di procedere alla migrazione di tutta Fucinaweb a questa piattaforma, scelta che rifarei subito. Nel procedere con la migrazione ho cercato quanto più possibile di mantenere funzionanti i link della precedente versione, processo che ho documentato nell’intervento “Sito nuovo, Url vecchi“, per evitare che il traffico proveniente dai motori di ricerca venisse subito penalizzato.

Da qualche mese ho registrato il dominio fucinaweb.it, che a suo tempo non era disponibile. Questo banale particolare mi ha sempre infastidito, soprattutto perché il sito che rispondeva a quel dominio, realizzato da una sconosciuta web agency, tutto era fuorché accessibile, usabile, standard…una presa in giro.

Mi fermo qui, ma per chi volesse saperne di più vi consiglio di leggere l’intervista che il bravo Mirko di Blographik mi ha rivolto in questi giorni e che affronta anche altri temi a me cari, come il project management e il difficile rapporto con il cliente e l’usabilità.
Questi i primi cinque anni di questo sito: suggerimenti su come affrontare i prossimi cinque?

• Don’t make me think (seconda edizione) di Steve Krug. I concetti principali di usabilità web spiegati in meno di 200 pagine e con uno stile moderno, ironico, accattivante. Non dimenticherete facilmente i concetti appresi. Se già avete la prima versione del testo, però, i 3 capitoli aggiunti in questa edizione non valgono la nuova spesa
• Building Scalable Websites di Cal Henderson. Da uno dei capi progetto di Flickr, un manuale che non parla solo di come creare siti web che siano scalabili, cioè che siano in grado di rispondere efficacemente a carichi di utenti e di elaborazione. Quella che viene affrontata da Henderson è invece una metodologia di progetto che parte dalla scelta dell’ambiente di sviluppo e dei prodotti per la gestione dei sorgenti del codice fino ad affrontare i sistemi di statistica e di alerting, passando per l’analisi dei colli di bottiglia e delle tecniche di scalabilità per web server e database. Ed è proprio questa eterogeneità di argomenti a fornire al lettore buoni spunti per organizzare i propri progetti a 360 gradi.
• Naked Conversations di Robert Scoble e Shel Israel. In questo testo si parla di business e weblog, di come società come Microsoft, reticenti nel fornire questa possibilità ai propri dipendenti, abbiamo poi scelto di aprire le porte ai weblog aziendali. Un libro che parla dei big ma anche delle piccole aziende, di consulenti, di pubblicità e di come proporsi con il proprio weblog aziendale, ma anche dei passi falsi e le scorciatoie da evitare assolutamente.
• Blog! di David Kline e Dan Burstein. Un compagno ideale di Naked Conversations, questo testo ha un respirio più ampio del precedente, affrontando il tema dei weblog non solo nel mondo professionale/aziendale, ma nella politica e più in generale nell’ambito culturale. Mi sono trovato a sottolineare diversi spunti e idee.

Nel suo ultimo libro, Prioritizing Web Usability, Nielsen cerca di uscire da questa situazione e analizza, dopo 10 anni, le linee guida che lo hanno reso, nel bene e nel male, famoso.

In usa sezione del manuale vengono presentate le problematiche di usabilità che non sono cambiate in questi anni, tra cui:

• I link che non cambiano colore quando visitati
• Il pulsante back che non funziona (attenzione con Ajax)
• I popup
• Elementi della pagina che sembrano pubblicità

alcune che sono cambiate un poco, nel senso che sono meno urgenti o non confondo i visitatori del sito

• Pagine pesanti (grazie alla diffusione della banda larga)
• Flash (perché i designer hanno imparato a usarlo come si deve)
• Multimedia e video (grazie ai nuovi computer)

e altre problematiche che secondo Nielsen sono oggi trascurabili

• Pagine lunghe (gli utenti hanno imparato a scorrere la pagina…)
• Link che non sono blu (una volta una vero cavallo di battaglia di Nielsen)
• Registrazione (processo migliorato notevolmente)

In poche parole, secondo l’autore, da un lato i designer sono oggi più preparati nel progettare un sito, dall’altro gli utenti sono ormai in grado di usare senza grossi problemi anche interfacce complesse.

Lo studio di Nielsen e Hoa Loranger, coautrice del testo, si basa su dei test realizzati con una settantina di candidati, anche se loro stessi sottolineano come “le linee guida del libro sono valide nella maggior parte dei casi, ma non per tutti”.

Una concetto che ho trovato interessante riguarda il rapporto degli utenti con i motori di ricerca.

Rispetto a 10 anni fa gli utenti web si trovano ormai a proprio agio con i motori di ricerca. Piuttosto che digitare direttamente l’indirizzo del sito su cui vogliono entrare, preferiscono usare il motore di ricerca come strumento di aiuto. Questo ha fatto sì che il vero protagonista del web diventasse l’homepage del motore di ricerca piuttosto che quella dei tradizionali siti, con una conseguenza, secondo gli autori:

Grazie ai motori di ricerca agli utenti ora interessa trovare quello che cercano, e non si preoccupano del sito in cui trovano questa informazione. Gli utenti vedono cioè il web come un insieme di risorse e non si preoccupano del singolo sito web; sanno che tutto quello che vogliono è disponibile, su un sito o su un altro.

Ecco un buon motivo - che sa di web 2.0 - che sottolinea l’importanza di fare subito buona impressione.

Una delle pecche presenti nel testo è che gli autori parlano di molte cose, fin troppe. Sarebbe bene concentrarsi sull’usabilità dell’interfaccia e dell’interazione piuttosto che mettersi anche a discutere, mutuando i concetti da libri già scritti, di web writing. Poco approfondito anche il discorso sull’ottimizzazione per i motori di ricerca.

Belle invece, come sempre nei manuali di Nielsen, le decine di schermate prese dai siti web in esame. 

Peccato, infine, che il libro sia infarcito di box di approfondimento che invece di puntare a risorse gratuite rimandano - guarda caso - ai report a pagamento della società di cui Nielsen è socio. Sarebbe un atteggiamento perdonabile solo se il libro fosse distribuito gratuitamente.

Proritizing Web Usability (titolo italiano - web usability 2.0 l’usabilità che conta), di Jakob Nielsen e Hoa Loranger, edito da New Riders (editore italiano - Apogeo) - 2006

E’ sicuramente vero che questo ha sottratto tempo prezioso al già ambizioso programma della giornata, ma sono convinto che si sia trattato comunque di momenti da cui trarre qualcosa, e cioè che la politica europea, francese, ma sicuramente anche italiana:

• non sa cosa sia internet
• non è rappresentativa dei bloggers
• non si rende conto di partecipare a un evento che parla di comunità, condivisione, open source e usa invece un tono unidirezionale, scialbo
• si fa bel danno, molto meglio stare a casa
• non sa più comunicare
• parla di argomenti troppo semplici/semplicistici (come diceva con tempismo poco dopo dallo stesso palco David Weinberger)

E’ stata illuminante in questo senso l’entrata sul palco di Nicolas Sarkozy. Lo abbiamo dovuto aspettare, vedere salire precipitosamente sul palco, esibirsi in un soliloquio in francese, terminare, uscire di corsa dalla porta di servizio, faccia scura in volto.

Quanto strideva questo compartamento da quello che stava succedendo fino a pochi minuti prima in quella sala! Che differenza di comunicazione!

Siamo sicuri che non sia servito da lezione? Perché se non fosse successo e fossimo rimasti tra noi blogger, magari uscendo avremmo pensato, anche dopo aver letto Naked Conversations e Blog!, che non solo noi, ma anche il mondo della politica è pronto per il web 2.0. Beh, la strada è ancora lunga.

Ecco il breve resoconto di alcuni interventi, quelli che ho seguito con più interesse, nel corso della prima di due giornate di incontri. Alla fine di ogni intervento le mie osservazioni.

Opening remarks

Nell’introduzione all’evento Loïc Le Meur di Six Apart France e organizzatore dell’evento, ha manifestato il suo stupore nell’essere riuscito a organizzare una manifestazione senza marketing, ma solo con il passa-parola e con il supporto dei bloggers. L’evento è stato organizzato in solo 6 settimane e al primo piano, parallelamente alle sessioni, 15 startup presentano le proprie soluzioni di business sostenibile.

Commento: evento molto friendly, forse fin troppo colloquiale. Si capisce che l’impatto sarà rivolto molto al rapporto dei media con la rete.

A conversation on the future of the internet

Niklas Zennström, fondatore di Skype e Kazaa, sostiene che non è necessario essere dei grandi per riuscire ad avere un buon numero di utenti, ma che per farlo è importante non isolarsi ma collaborare con altre aziende.

Il software che ha successo in questo web 2.0 è quello che aiuta a risolvere le esigenze di base, senza complessità, ma che al tempo stesso rende disponibili tramite API un insieme globale di servizi, per permetterne l’estensione. L’importante è realizzare del software non troppo specifico, ma che tutto il mondo possa usare e trarne beneficio.

Niklas prende come esempio il suo Kazaa, che è nato tra Svezia, Danimarka e l’Inghilterra, ma che già dopo poche settimane dal lancio ha cominciato ad essere usato in tutto il mondo. Questo dimostra che internet non è completamente dominicato dagli Stati Uniti (Skyphe ha solo un ufficio in California, il resto è tutto in Europa).

Un vantaggio dalle startup europee potrebbe essere quello di sfruttare la diversità tra le diverse nazioni, che distingue l’Europa dall’approccio americano. Questo vuol dire per esempio realizzare partnership con paesi che non dispongono ancora di un’economia stabile e in buone condizioni, ma magari ottime risorse intellettuali.

Niklas esorta a dimenticare ben presto il mercato locale e guardare alla complessità della realtà europea, cominciando subito a ragionare in inglese. La mera traduzione è semplice quando si parla del sito, ma è molto più complessa quando si parla di web service.

Secondo Zennström il web 2.0 è solo un’etichetta, lo spirito di collaborazione c’è da prima che venisse coniato questo termine. Ma oggi disponiamo dell’infrastruttura che rende tutto questo possibile e che consente di costruire un business che sia sostenibile: una situazione completamente diversa da qualche anno fa.

I vecchi media sono morti? I blog sono fantastici e introducono un ottimo grado di diversità, ma c’è comunque ancora bisogno di giornalismo approfondito: i giornali non sono morti.

Commento: intervento interessante, dovrebbe essere di stimolo alle aziende europee

The future according to Google

Lorraine Twohill è Marketing Director EMEA di Google UK. Nella sua presentazione evidenzia come nel 2006 ci sia un miliardo di persone online, e si chiede il prossimo miliardo da dove potrebbe venire.

Per capirlo analizza l’evoluzione di Google dalla sua comparsa, dividendola in 3 fasi

• information
• distribution and communication (buy,trade,talk)
• networking (youtube,blogger,myspace)

Lorraine è convinta che il prossimo miliardo arriverà proprio da quest’ultima fase.

Passa poi ad elencare alcuni pregi che hanno accompagnato la crescita di Google

• innovazione, non perfezione da subito
• condividi tutto quello che puoi
• se sei brillante, ti assumiamo
• prendi dei rischi, premia i successi, impara dagli errori

La Twohill ricorda come il 20% del tempo dei dipendenti Google viene impiegato per progettare soluzioni ai problemi che ognuno può avere. Da una di queste esigenze è nato Gmail.

Il termine Googlette si riferisce a un particolare tipo di questi progetti, svolti normalmente da sole 2 persone.

Ci sono 3 fattori che spingono a un cambiamento:

• l’accesso all’informazione
• la diffusione della banda larga
• la facilità di accesso

Lorraine sottolinea come la banda larga stia diventando ormai una commodity, tanto che diventerà ben presto gratuita e che in futuro ci potrebbe essere un buon ruolo svolto dai diversi internet cafè. La facilità di accesso è evidenziata anche dai dispositivi disponibili, che sono sempre più piccoli e portabili.

Vengono analizzati alcuni casi concreti:

• Pizco, una community di ragazze tra i 12/20 anni, che ha un approccio con la sicurezza sempre in primo piano (”conosci quelli con cui comunichi? la risposta è no”)
• Uno spot su Itube della Ford Ka, molto credibile, rivolta a un pubblico giovane

Quali sono i temi che guideranno il mondo di domani?

• Commercio
• Accesso ubiquo
• Comunicazione e collaborazione
• La ricerca (search, find, obtain)

La twohill conclude parafrasando una frase di Andy Warhol: ognuno può essere famoso per 15MByte.

Commento: uno degli interventi peggiori; non ha partecipato alla sessione dei commenti

The real world and why it matters

Hans Rosling, professore di International Health, Karolinska Institutet, Stoccolma, ha invece toccato argomenti quali la globalizzazione e l’evoluzione delle nazioni.

“La glogalizzazione è qui, cerchiamo di sfruttarla”.

Rosling ha affermato che più di globalizzazione, ha senso parlare di modernizzazione delle nazioni. Ancora prima di entrare nei mercati ricchi, infatti, si notano fattori di crescita dei paesi più arretrati, come ad esempio le nascite, la riduzione della mortalità, l’aumento del reddito.

Un dato: il 60% della popolazione possiede il 24% della ricchezza.

Commento: intervento interessante e davvero simpatico, anche se non è chiara la relazione con gli altri interventi della giornata.

The giants outlook on web 2.0

Con Yahoo!, Orange, Nokia Multimedia, Microsoft Windows Live

Alla domanda “conta essere grandi?” Microsoft riconosce come questo gli stia creando dei problemi e stiano cercando di divetare più veloci nei rilasci e di focalizzarsi nella realizzazione di veri e propri servizi web.

Secondo Nokia conta assecondare le esigenze dei consumatori mentre Orange nota come sempre più applicazione di accesso alle informazioni, in futuro, non saranno basati su pc.

Yahoo! è convinto che le dimensioni contino.

Alla domanda “qual è la prossima mossa” nessuno si sbilancia più di tanto

• yahoo!: interazione, reinventarsi, contenuti di ottima qualità. Si veda come competitore delle media company
• Microsoft si muoverà sempre di più nella ricerca, intesa come una caratteristica insita in ogni prodotto; vogliono far evolvere la ricerca perché sia più dinamica
• Nokia vede nel futuro la convergenza di internet, ovvero la fruizione di internet con il mobile; sempre più i contenuti sono realizzati da dispositivi portatili e anche il loro consumo è sempre più diffuso da questo tipo di dispositivi
• Secondo Orange, per tradizione l’Europa è molto ben posizionata in questa convergenza tra mobile, contenuti e internet, più di quanto lo siano gli U.S.. Questi pregi andrebbero sfruttatiimportant of communities

Secondo Yahoo! realizzare contenuto che sia di buona qualità, che sia usabile è molto difficile, anche dopo aver superato la barriera di attrarre molti utenti verso questi servizi. Non si tratta quindi solo di una questioen di strumenti.

Un interessante intervento dalla sala chiede come creare business da piccole comunità, come quelle della moda. Nessuna risposta degna di noto, Yahoo! si limita a dire che loro mirano comunque sia alla grossa comunità, sia agli eccellenti contenuti.

Commento: l’impressione è che questi grandi attori si siano trovati immediatamente una gallina dalle uova d’oro tra le mani, ovvero i contenuti creati dagli utenti. Ma non hanno ancora trovato un valido modello di business, né per loro né per gli utenti. Neppure loro sanno quale possa essere il futuro di queste iniziative, e come aiutare a produrre contenuti di qualità e come far guadagnare i propri utenti.

Is open source turning commercial?

Con Gil Penchina, Wikia

Gil parla di free culture e free software, illustrando concetti noti.

Qualità del codice:

• più coinvolgimento porta a miglioramenti del prodotto
• il codice aperto fa scoprire gli errori
• ognuno può partecipare e migliorare

Economicamente

• pubblicità (advertising)
• donazioni
• t-shirt, tazze, promozioni…

Non va molto oltre Tristan Nitot di Mozilla Europe, che sottolinea come la democrazie all’interno di un progetto open source assicura che la qualità sia elevata e che i contibuti contino.

Commento: tutto trito e ritrito

Will there be a Web 2.0 bubble?

Con TechCrunch, Index Ventures (UK), August Capital (USA)

Secondo TechCrunch non c’è rischio di cataclismo economico. August Capital pensa che un problema sia quello della frammentazione dei talenti. All’oggi molte startup invece si collocano con prodotti molto simili nelle stesse nicchie di mercato. Anche per Index Ventures questo è vero: sembra che ognuno voglia partire con la propria indee di business, invece che cercare risorse disposte a lavorare nello stesso progetto.

Si ribadisce come l’ecommerce vivrà momenti d’oro.

Commento: condivido la paura che molte realtà stanno realizzando prodotti copiandoli gli uni agli altri. Questo peggiora la situazione già complessa di questo settore.

Un esempio interessante è quello proposto dalla australiana Monash University. La loro guida di stile, che integra suggerimenti per la grafica e i contenuti, è davvero molto approfondita e ben strutturata.

Si comincia con un’introduzione rivolta all’audience della guida: web designer, sviluppatori e autori di contenuti dei siti dell’università. Non si tratta quindi di regole generiche che si possono trovare in qualunque buon libro sulla scrittura e design per il web (se interessati potete leggere su Fucinaweb le recensioni degli ottimi Web Word Wizardry, Hot Text - Web Writing That Works e Web Style Guide - Second Edition), bensì di indicazioni specifiche a un sito o a un network di siti.

Altro aspetto affrontato con intelligenza dalla guida è una breve descrizione degli utilizzatori del sito, cioè il pubblico a cui si rivolge. Notate come non vengano sprecate parole inutili: frasi brevi, buon uso degli elenchi puntati, link a risorse. La stessa guida è un ottimo esempio di come scrivere per il web.

Si passa poi ad affrontare il concetto di qualità dei contenuti e del design del sito, cioè cosa non può mancare ai contenuti e come funziona il processo editoriale e di revisione. Visto che alla Monash University offrono corsi che riguardano questi concetti hanno pensato bene di rimandarvi come approfondimento. Da notare anche la bella idea di separare, dedicandoci in una sezione dedicata, tutto quello che riguarda il loro sistema di Content Management (qui troverete informazioni sul software su cui si basa e sui motivi che li hanno portati ad estenderne le funzionalità).

Dopo questi contenuti introduttivi, ma fondamentali, si passa nel vivo della guida. La sezione branding and visual identity prende in rassegna le diverse sezioni del sito, e per ognuna illustra le scelte che sono state compiute per quanto riguarda i colori delle diverse componenti, le modalità con cui riferirsi a altre realtà presenti nell’universo dell’università, il tipo di immagini da usare (con esempi) e regole sul loro impiego.

In navigation e site structure si parla un po’ di information architecture, indicando le diverse tipologie di scheme con cui organizzare le informazioni, che nel caso dell’università sono:

• alfabetico
• cronologico
• geografico
• per argomento
• per compito
• per audience
• guidato da metafora

Forse questa è l’unica sezione che si sarebbe potuto affrontare con un po’ più di profondità, magari illustrandola con esempi e includendo suggerimento su come organizzare le voci di menù e come etichettarle. Bene invece che alla ricerca e ai metadati sia dedicata un’opportuna voce di menù, vista la sua importanza.

Ai contenuti sono dedicate diverse sezioni e sottosezioni, di cui la principale è content, text and images.

Un’ultima sezione che vale la pena soffermarsi a commentare è quella che riguarda i template web, a cui accennavo in uno scorso intervento. In questa sezione sono presentati i diversi template disponibili per il sito e ne viene suggerito l’uso per le diverse esigenze, con esempi di casi già online. Un’opportuna tabella, davvero un’ottima idea, evidenzia inoltre l’impiego dei fogli di stile sui diversi elementi della pagina. 

Quella dell’università di Monash è una guida di stile davvero completa. Probabilmente per i progetti “di tutti i giorni” è uno sforzo considerevole da affrontare, ma se vi date uno standard di progettazione vedrete che riuscirete a creare un documento di questo tipo, personalizzandolo per il cliente, senza necessariamente passare notti insonni.

Un altro interessante esempio di guida di stile, anche in questo caso di un’università, è la Penn Web Style Guide.

La FAO, grazie al progetto Imark, ha messo online un intero corso gratuito chiamato Building Electronic Communities and Networks in aiuto di quanti desiderano approfondire i concetti di comunità online, le professionalità richieste, i passi da seguire. L’occhio di riguardo è rivolto al mondo dell’agricultura, essendo FAO impegnata da anni in questi contesti, ma il ricchissimo materiale del corso aiuta chiunque sia alle prese con un progetto che necessiti dell’integrazione di una comunità, sia esso un weblog, una mailing list, un forum e quant’altro.

Il corso è strutturato e pensato davvero bene, e impiega al giusto modo la tecnologia web, Javascript e Flash per facilitare l’apprendimento. Ogni lezione è poi scaricabili e stampabile in formato PDF, così da formare un vero e proprio manuale di riferimento per chi si vuole interessare di questo mondo. E non vengono lesinati neppure link a risorse in rete di approfondimento.

Una risorsa davvero preziosa.

Se dovessi giudicare le newsletter che ricevo, però, mi verrebbe da dire che poco è stato fatto per migliorarne l’usabilità.

Una delle newsletter che aspetto con impazienza è per esempio quella della biblioteca civica di Belluno, che come spesso succede fa bene alcune cose, male molte altre.

Male

• E’ rigosoramente aperiodica: qualche mese ne vengono spedite 5, altri mesi un paio. Questo non sarebbe un problema [dello stesso problema, a dire il vero, soffre pure la newsletter di Fucinaweb]
• Il subject dell’email non dice nulla sul contenuto: “Messaggio n. 27/2006″
• La newsletter è composta solo da un elenco un po’ troppo sterile di avvenimenti, che riguardano eventi futuri anche di 2/3 mesi
• A poco serve l’alternanza di colori tra i diversi eventi, se non a sottilineare il carattere artigianale della newsletter

Bene

• Riporta correttamente gli estremi per contattare la biblioteca
• Indica esplicitamente come annullare la propria iscrizione
• Contiene, dove possibile, dei link di approfondimento verso il sito o altre risorse
• Contiene testo, non immagini o inutili abbellimenti. Si potrebbe fare ancora di più: spedirla in formato esclusivamente testuale

Vi si può accedere con un dispositivo portatile all’indirizzo http://m.gmail.com, ma anche le ultime versioni di Firefox sono in grado di visualizzare l’interfaccia, se volete limitarvi a curiosare.

E’ interessante notare come i tipi di Google abbiano adattato l’applicazione ai limiti dei dispositivi portatili, cioè display piccoli e tastiera limitata.

Prendiamo ad esempio la schermata di creazione di un nuovo messaggio.

Come potete vedere, l’interfaccia va subito al dunque. Per prima cosa è richiesto il mittente: cliccando “Add Recipients” sono visualizzati per primi i destinatati contattati più di frequente, così da aumentare la probabilità di averli subito presenti nella lista. Se invece vogliamo inviare il messaggio a qualcun altro, in fondo alla stessa schermata è comunque possibile compiere una ricerca.

Tornando alla schermata di spedizione notate anche che la copia carbone e la copia carbone nascosta sono state spostate in fondo alla pagina, visto che sono funzioni usate di rado.

Anche l’organizzazione e visualizzazione dei messaggi tiene conto dei limiti del mezzo. Nel mio cellulare, ad esempio, ogni messaggio è suddiviso in più pagine che è possibile scorrere avanti e indietro. Ogni voce di menù è poi accessibile tenendo premuto un numero del tastierino, evitando quindi di scorrere la pagina nel diplay.

E’ presente inoltre la possibilità di personalizzare l’interfaccia grafica, in modo da privilegiare le operazioni compiute più di frequente.

L’esempio di Gmail mobile fa anche riflettere chi sostiene (io non sono tra questi) che accontentare dispositivi eterogenei sia solo una questione di applicare fogli di stile diversi. In realtà ci vuole molto di più: si tratta di ristudiare completamente non solo l’interfaccia, ma anche l’interazione dell’utente con l’interfaccia, oltre a trovare altre soluzioni per la visualizzazione dei contenuti.

Se dovete cimentarvi in questo tipo di progetti, Gmail mobile rappresenta un buon caso di studio.

Prima di partire mi ricordo di aver cercato informazioni sul museo e sulla mostra con Google, aspettandomi di trovare come prima cosa i siti ufficiali di riferimento.

Ma se cerco, anche oggi (23 Maggio 2006), termini quali ‘Museo ara pacis’, ‘Ara pacis’, oppure ‘Mostra Antonello da Messina’, i siti ufficiali del museo e della mostra non solo non compaiono al primo posto, ma neppure nella prima, seconda, terza… pagina dei risultati.

Per capire come questo sia possibile ho analizzato più da vicino pagina e codice sorgente. A vedere il sito del Museo dell’Ara Pacis non sembra che ci possano esserci problemi di indicizzazione: la pagina è semplice, ad alto contenuto di testo, nessuna animazione. Sembra quasi un sito search-engine-friendly. Ma se guardiamo con un po’ più di attenzione pagine e codice sorgente ci accorgiamo che:

• La scritta “Museo dell’Ara Pacis” che fa da titolo non solo è un’immagine (quando avrebbe potuto benissimo essere del testo) ma, cosa ancora più grave, è priva dell’attributo per il testo alternativo
• Gli autori del codice sorgente hanno cercato di usare il markup separando aspetto grafico da contenuto. Una ottima idea (la pagina è leggera), ma applicata molto male. Le intestazioni dell’Html (h1,h2…) che servono a distinguere titoli da normali sezioni di testo, per esempio, sono assolutamente prive di significato. Ad h1 è stato associato il testo “Musei in Comune”, mentre con h2 “Menu di accesso facilitato”.

Sembrano sciocchezze, ma partecipano a far sì che il motore di ricerca non riconosca il testo “Museo Ara Pacis” come qualcosa di veramente significativo nella pagina.

Per il sito della ho già detto, non comportano nessuno sforzo aggiuntivo per chi sviluppa la pagina.

E’ cioè possibile aggiungere un evento al calendario senza doversi necessariamente posizionare sul giorno desiderato e inserire tutti i campi.

Google Calendar cerca infatti di analizzare il testo inserito in modalità Quick Add in modo da evincere se è presente un’indicazione di data e di luogo (o, come dice la pagina di aiuto di Google, “who, what, when and where”)

E’ stato portato all’estremo il concetto del pattern chiamato Forgiving Format, che suggerisce a chi progetta le interfacce di non realizzare form complicati con decine di campi, combo e check box con l’errata convinzione che imprigionare l’utente gli eviterà di commettere errori. Dei maestri (in negativo) in questo senso sono alcuni sviluppatori (tra cui, in passato, io stesso), che per evitare del lavoro in fase di validazione dell’input, giungono perfino a usare 3 combobox diverse per richedere una data.

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.

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

Più volte ho pensato di scrivere qualcosa sull’argomento, ma ho sempre abbandonato l’intento per un dubbio relativo al punto da cui cominciare.

Mi ha fatto allora piacere che John Grohol si sia fatto invece avanti, pubblicando per Alistapart “Anonymity and Online Community: Identity Matters“, una buona introduzione.

Vi lascio al suo articolo per i dettagli, riportando qui alcuni dei tratti essenziali:

• se dedicete di far partecipare gli utenti in forma completamente anomima, valutate almeno se sia il caso di far votare i diversi contenuti, così da dare visibilità ai migliori (e scremare il resto)
• chiedere uno username in fase di registrazione partecipa a creare un senso di reputazione e credibilità
• chiarite subito quali sono i benefici che si hanno nel registrarsi
• la registrazione deve essere semplice, poche domande, le indispensabili
• la registrazione è una piccola barriera utile per filtrare chi non porterebbe valore al dialogo
• non sempre ha senso verificare l’email dell’utente

L’ultima volta è successo quando mi sono collegato, dopo qualche mese, al mio account su Flickr, il bellissimo servizio di confivisione foto recentemente acquisito da Yahoo!.

E ho subito capito che Flickr fa parte della famiglia Yahoo!, visto da chi sono stato accolto, ovvero da una schermata che mi ha informato come il mio indirizzo di posta elettronica fosse presente sia nel database di Flickr, sia in quello di Yahoo!.

Yahoo! mi presenta questa schermata fondamentalmente a mio vantaggio: mi dà la possibilità di legare le mie informazioni su Flickr con l’account di Yahoo!. E lo dice.

A me la cosa sta tutto sommato bene, per decido di preseguire. Click.

La schermata informa su quello che sta per succedere, con eventuali limitazioni e un dettaglio delle utenze coinvolte. Notate la pulizia della schermata e i punti elenco alla fine, impossibili da tralasciare. L’utente dispone ora di ogni informazione riguardo a quello che succederà. Poiché infatti non è (almeno ancora) così frequente che due sistemi con registrazioni diversi si integrino in questo modo, è importante spiegare bene al visitatore cosa sta succedendo.

Vi accorgerete anche che tutto sommato di vantaggi in questa operazione ne ha anche Yahoo!, poiché per tutti i dati che avete lasciato a Flickr da questo momento in poi varranno le regole decise da Yahoo!

Ecco infine una conferma che tutto si è svolto nel migliore dei modi, con un riepilogo di quello che è successo e come comportarsi d’ora in avanti.

Dal punto di vista di interazione con l’utente questo esempio non è in realtà nulla di stratosferico, e proprio per questo mi colpisce la semplicità con cui è stato affrontato a livello di intefaccia utente un argomento non banale, come la “migrazione” o - meglio - la condivisione di utenti tra due sistemi che sono nati in realtà distinte. Non oso immaginare come altri (io tra questi) avrebbero progettato la stessa procedura

Il tutto si chiude con un’email che ho ricevuto, e che spiritosamente ringrazia in questo modo:

Thanks, and we hope you enjoy the
sign-on-to-everything-in-one-place goodness!

Volevo semplicemente leggere un articolo. La schermata che mi ha atteso richiedeva però per prima cosa l’inserimento di un Ibm Id e una password per l’autenticazione.

Ricordavo di essermi registrato in passato, ma il termine “Id” non mi suonava per nulla familiare. Dopo diversi tentativi a vuoto ho tentato allora di compiere una nuova registrazione, dove ho trovato l’etichetta “Please provide an email address as your IBM ID“.

E mettere questa stessa nota nella schemata di login no?

Ma non è finita: inseriti email e password (anche su questa avevo qualche dubbio), altro stop. Non ti posso autenticare perché

• o la password non è corretta
• o l’id non esiste
• o la tua Ibm Id non è riconosciuta da questo sito (e allora cosa ci potrei fare?)
• o sei residente in Italia, e la tua password potrebbe essere scaduta

Era l’ultima possibilità (grazie per l’aiuto, poteva essere qualunque cosa), e ovviamente non mi è stato proposto di cambiare password, ma ho dovuto mentire, cioè scegliere “ho dimenticato la password”, per farmene mandare un’altra.

Un vero inferno, per leggere un articolo…

In quest’ottica anche la gestione degli inevitabili errori applicativi dovrebbe essere migliorata, soprattutto perché con le nuove architetture (leggi Ajax), cambia anche il modo di utilizzare l’interfaccia del browser.

Chi fa le cose per bene, in questa fase tutto sommato ancora embrionale per questo tipo di soluzioni, viene subito notato. E lo nota ad esempio Cesare Lamanna in un suo intervento su html.it. Cesare apprezza la cortesia di Backpack di 37Signals che non lo incolpa dei propri errori quando, per un problema al sistema, una email non viene recapitata come ci si aspetterebbe.

Anche Federico Oliveira di WeBreakStuff nota come al posto del preoccupante e onnipresente “server error”, Flick adotti una strategia decisamente più rilassante (Flickr is having a massage). Magari chissà che disastro sta succedendo dietro le quinte, ma l’importante è tranquillizzare gli autori sullo stato della loro produzione fotografica.

Esempi come questi si contano sulle dita di una mano. Speriamo sia solo questione di tempo.

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.