antirez weblog

Amo questo grafico, cosi' come ho amato gran parte di quello che e' stato prodotto da Kathy Sierra nel suo blog Creating Passionate Users.



C'e' un punto di complessita' delle interfacce utente good enough, che sembra essere ottimale. Ingegneristicamente parlando cio' puo' sembrare contro intuitivo: la tentazione e' quella di pensare che ci sia un modo di esporre le funzionalita' in maniera incrementale, a cipolla, che permette di avere tutte le funzionalita' e una interfaccia utente semplice da usare, allo stesso tempo.

Nella pratica cio' puo' rivelarsi molto complesso: alla fine le funzionalita' devono essere disponibili da qualche parte. Se non si da evidenza grafica immediata si finisce per creare una interfaccia simile a quella di Flickr in cui toccando alcuni oggetti spuntano menu' a tendina, il che in realta' non diminuisce la complessita' dell'interfaccia, ma e' un modo per offuscarla visto che alcune funzioni a cui si accede in tal modo sono assolutamente indispensabili.

La mia fede in quel grafico spiega facilmente la mia assoluta riluttanza ad aggiungere funzionalita a tudulist.com se prima non ho seriamente considerato tutte le implicazioni che avranno in termini di complessita' e la loro interazione con le altre funzioni gia' disponibili.

Il dualismo delle funzionalita'

C'e' un trucco tramite il quale e' possibile aggiungere funzionalita' ad una applicazione senza farsi alcuno scrupolo, a patto che le funzionalita' aggiunte siano di un certo tipo.

Le funzionalita' non sono tutte uguali, ne esistono di due tipi: alcune di esse sono opache, l'utente deve scontrarsi con esse, deve capirle, sapere dove si trovano per poterle usare. Altre invece sono trasparenti, e non sono un peso per l'utente, ma solo uno sgravo. Migliorano la nostra applicazione senza aggiungere complessita', e assieme ad essa l'esperienza utente.

Trasparenza

L'esempio piu' lampante di funzionalita' trasparente e' quella presente nei motori di ricerca. Quando cerchiamo qualcosa su Google scriviamo semplicemente cio' che cerchiamo e premiamo il tasto Cerca: i risultati proposti, e il loro ordine, fanno la differenza tra un buon motore di ricerca e uno cattivo. Eppure l'utente non deve interagire in alcun modo col sistema per avere dei buoni risultati, non deve immettere alcun parametro in piu' su Google per avere dei risultati migliori di quelli di Yahoo.

E' innegabile che generare un buon set di risultati sia una funzionalita' di Google, ma l'utente ne ricava solo beneficio.

Un altro esempio e' il filtro utilizzato da Flickr sulle foto immesse dagli utenti: Fickr ne equalizza automaticamente i colori e ne aumenta la nitidezza. E ancora la capacita' di Google Calendar di far apparire automaticamente delle entry nel calendario se trova delle email su Gmail che sembrano essere in un formato riconoscibile di richiesta di meeting, conference call, o qualcosa di simile.

Il principio della equivalenza

A volte una funzionalita' opaca puo' essere trasformata in una trasparente: in tal caso e' sempre una buona idea operare la trasformazione! Esempio:

Su tudulist non c'e' alcun modo per specificare nel calendar l'ora di uno specifico evento.

Posso mettere "andare dal dentista" per il giorno 12 Settembre ma non c'e' alcun modo di specificare che e' alle 5, perche' secondo me cio' complicherebbe inutilmente l'applicazione.

Infatti c'e' un modo piu' semplice, dopo un po' gli utenti scoprono che se proprio vogliono ricordarsi l'orario scrivono

"andare dal dentista alle 11:15"

o

"11:15 Dentista"

Il problema con questo approccio e' che gli eventi non vengono ordinati per ora attualmente, infatti l'ora e' solo implicitamente descritta nel testo della item, ma non ha un corrispettivo nel database.

Tudulist potrebbe pero' fare il parsing delle ore quando una nuova item viene immessa, estrarre l'ora e memorizzarla nel DB, usandola per ordinare gli eventi di un dato giorno in ordine cronologico.

Di fatto cio' e' esattamente equivalente ad una funzione opaca che si traduce nei seguenti oggetti nella interfaccia utente:

• Una select per selezionare ora e minuti durante l'inserimento di una item.
• Una select per la modifica di questo dato in fase di edit.
• Possibilita' di non specificare alcun orario in qualche modo semplice, facendo in modo che l'utente non si senta forzato dall'interfaccia ad immetterlo anche quando non lo conosce con precisione.

Tutto questo puo' essere eliminato dall'interfaccia senza alcuna significativa perdita di funzionalita', ma con una semplificazione tangibile della interfaccia utente.