Archivi categoria: Information Architecture

Interfacce che si adattano

Pubblicato il da

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

Pubblicato il da

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.