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.

Un lustro di Fucinaweb

Fucinaweb nasceva l’1 Febbraio 2002 allo scopo di promuovere la progettazione di un sito web a 360 gradi, considerando i diversi elementi (sviluppo, information architecture, usabilità, accessibilità, web design) come realtà tra loro in comunicazione e non a compartimenti stagni.

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:

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?