Cosa ho studiato usabilità a fare? Storia di un motore di ricerca interno.

L’usabilità è definita come l’efficacia, l’efficienza e la soddisfazione con le quali determinati utenti raggiungono determinati obiettivi in determinati contesti. Sul web l’usabilità cura la qualità dell’esperienza utente su di un sito: riesce a raggiungere i suoi scopi in modo facile e piacevole?

Per i suoi obiettivi l’usabilità non può essere la Cenerentola dello sviluppo web: per fare in modo che l’utente sia soddisfatto della sua esperienza bisogna in prima battuta chiedersi chi è l’utente?, cosa può fare sul nostro sito?, come possiamo agevolarlo?, come possiamo conciliare i suoi obiettivi con i fini del sito?
Se l’usabilità viene chiamata in causa a progetto finito, può soltanto valutare di quanto si è mancato l’obiettivo di un sito usabile e stimare i costi delle correzioni. Molto più sensato ed economico sarebbe invece tenerne conto dal principio della progettazione.

Nel mio lavoro di ogni giorno vedo che, mancando proprio una progettazione nella realizzazione dei prodotti per il web, il risultato è spesso lontano dall’essere usabile ma la cosa sembra proprio non turbare nessuno nella committenza. Quando un progetto parte da uno schema grafico con le sfumature e i bordi arrotondati ma senza pianificazione delle architetture informative, delle funzionalità, degli strumenti di orientamento e navigazione è persino difficile preoccuparsi dell’usabilità perché – dalla mia posizione attuale di sviluppatore forzato – la domanda più pressante è: “Sì, carino. Ma com’è che deve funzionare?”
In molti casi lo sviluppatore “inventa” il comportamento delle pagine con due risultati:

  • il committente si lamenta “ma non è così che lo volevo!”
  • l’utente si interroga “ma perché fa così? come lo devo usare?”

Immaginate da soli lo spreco di tempo, risorse economiche ed energie nervose.

Giusto per esemplificare ecco una storia tratta dal vero sulla realizzazione di un motore di ricerca interno al sito.

In principio era un campo di testo (ottobre)

Nella grafica del committente spicca in mezzo al menù un bel box etichettato “cerca” con accanto l’immagine di una lente di ingrandimento.
Lo sviluppatore prepara la query “Prendi tutti gli elementi che contengono la parola X” e traduce la grafica in codice con


< form method="post" action="***">
<label for="q">Cerca</label>
<input type="text" id="q"/>
<input type="image" src="***" />

e ritiene di aver finito.

Poi divenne la ricerca sul web (novembre)

La committenza si lamenta che con il campo così realizzato non è possibile cercare con Google.

S: Con Google?

C: Sì con Google

S: Ma con Google sul tuo sito?

C: No: con google su internet

S: Ah!

La nota di usabilità

Ma a che pro dato che esiste il sito “Google” in tutte le lingue ed esistono svariati modelli di toolbar integrati nel browser?
Questa funzionalità è superflua dal punto di vista dell’usabilità: esistono siti specializzati nella ricerca, sul tuo sito l’utente viene per l’informazione che offri tu, non per cercare con Google sul web.

Lo sviluppatore non può contestare le richieste della committenza per cui modifica il form aggiungendo dei radio button per distinguere tra ricerca interna e ricerca sul web ed aggiunge del javascript per dirigere la query sull’una e sull’altra.

Poi vennero i contenuti video e audio e i blog (gennaio)

Viene terminata la realizzazione della sezione multimedia.

C: Il motore di ricerca non trova i video e le photogallery!

S: Non le avevate richieste

C: Ma era ovvio che dovevate metterle!

Lo sviluppatore aggiunge alla query la ricerca sui due elementi nuovi e si inventa una resa “grafica” per la pagina dei risultati. Fortunatamente alla committenza piace ma….

C: Ma io voglio cercare solo per i video o solo per le photogallery e voglio cercare per data

S: Nella pagina delle ricerche?

C: No! nella pagina dei multimedia

S: Ah!

Lo sviluppatore Crea un nuovo box di ricerca dedicato ed una query apposita.

Poi tornò il grafico (febbraio)

La pagina dei risultati non piace più: viene inviato un nuovo pdf con la grafica desiderata.
Notare: PDF non file grafico così è necessario “indovinare” font e colori e ritagliare alla bell’e meglio gli elementi grafici. Passano oltre due settimane per avere le informazioni mancanti e i PSD.

C: La pagina dei risultati è brutta: cambiatela aggiungendo degli sfondi colorati alternati, il numero del risultato corrente, il numero del risultato totale e la stringa cercata eppoi…ah sì un link per l’ordinamento

S: Ordinamento?

C: Sì: data ascendente o discendente

S: ma non è solo grafica

C: massì massì che ci vuole per un link?

La nota di usabilità

L’ordinamento non è “grafica” ma una funzionalità! Quale comportamento ci si deve attendere da questo pulsante? Normalmente ci si aspetterebbe un ribaltamento del set dei risultati. In questo caso ci si trovava un set di risultati diverso poiché – per motivi di efficienza – la query restituisce solo 200 risultati e cambiandone la data si passava da uno set 2008 – 2009 a 2007-2008. Difficilmente gli utenti consultano tutti e 200 i risultati per accorgersene, in ogni caso è un comportamento anomalo. La problematica viene comunicata e snobbata.

Poi venne la performance (maggio)

L’utente si lamenta del fatto che per la parola chiave del sito la ricerca produce soltanto 200 risultati.

C: Ne voglio di più: almeno 1000!

S: Ma la query diventa pesante!

C: Ma non è vero

La nota di usabilità

La pagina della ricerca non è strutturata per dare feedback: nell’attesa dei risultati l’utente resta sulla pagina da cui ha lanciato la ricerca senza sapere se sta funzionando o se si è bloccato il pc. La query richiede nel migliore dei casi 50 secondi.

Ma lo sviluppatore cosa ne sa della pazienza dell’utente? Innalza la soglia della query a 1000 risultati

Poi venne la ricerca temporale (giugno)

Viene richiesta la realizzazione di un modulo di ricerca per data da apporsi nella pagina delle ricerche. La grafica segue di una settimana la richiesta e presenta un campo di testo, due campi data “da” e “a” e la solita icona a lente per la ricerca. Lo sviluppatore realizza in Ajax il form con i calendari.

C: non va bene: la ricerca deve essere al massimo di 12 mesi e se restituisce più di 1000 risultati deve avvertire con un messaggio che conviene restringere la ricerca

Lo sviluppatore adatta il modulo vincolando i valori dei campi in modo che automaticamente limitino sia la scelta da calendario sia l’inserimento manuale. Predispone i messaggi di errore (anche quello inutile poiché la query restituisce al massimo 1000 risultati mai di più).

C: non va bene: i campi data devono essere sempre pieni e valorizzati ad oggi

S: ad oggi ossia di base la ricerca viene fatta solo sul giorno di oggi?

C: si così

S: ma il campo nel menù va da oggi nel passato…

C: no no deve andare da oggi ad oggi!

S: e l’ordinamento…

C: da oggi ad oggi

S: e se l’utente mette delle date

C: massimo 12 mesi

S: ah!

La nota di usabilità

La media dei motori di ricerca interni ad un sito svolge le ricerche da oggi nel passato.Se porre un limite di 12 mesi è ancora comprensibile, porre il limite ad 1 solo giorno è anomalo. Ci si scosta dalle convenzioni e dalle abitudini acquisite dagli utenti ed -oltretutto- nel menù principale non si fornisce visibilità a questa limitazione. Gli esiti di questa scelta non progettata sono :

  • un comportamento difforme dalle convenzioni e non esplicitato;
  • una contraddizione: se 200 risultati su un lasso temporale ampio erano pochi, quanti pensano di ottenerne su un solo giorno? Dunque a cosa serve far girare una query da 1000 item? ;
  • l’impossibilità di cercare nel passato oltre 1 anno;
  • se si applica l’ordinamento ad una ricerca effettuata con uno span temporale fissato dall’utente, i risultati dell’ordinamento sono di meno dei precedenti poiché hanno lo span temporale di un giorno;

Nonostante le incoerenze viene apportata la modifica.
2 giorni dopo segue mail:

C: forse era meglio prima. Rimettiamo la ricerca di base su uno span temporale da oggi meno un anno”.

Conclusione della storia

Lo sviluppatore potrebbe ghignare e dire “te l’avevo detto” ma più che altro si arrabbia perché sta perdendo tempo e pazienza.
Se invece di inventare pezzi di interfaccia ed interazione secondo l’estro del momento, senza riflettere su come si inseriscono nel sistema complessivo, se servono all’utente e su come verranno usati, si fosse spesa mezza giornata ad inizio progetto per definire i requisiti del motore di ricerca interno la realizzazione avrebbe richiesto meno tempo e meno soldi.
Oltrettutto: tutte le modifiche sono avvenute a prodotto attivo ossia mentre gli utenti usavano il sito e il suo motore di ricerca.
Immaginate quanto possano avere apprezzato un servizio che nell’arco di pochi mesi ha cambiato molte volte il suo comportamento in modo pressoché invisibile. Immaginate come si siano trovati a loro agio.

Dunque mi chiedo: cosa ho studiato usabilità a fare? Se la norma della realizzazione di progetti web è questa conviene diventare tutti programmatori perché ne serviranno molti per poter continuare a mettere pezze al sistema.

2 commenti su “Cosa ho studiato usabilità a fare? Storia di un motore di ricerca interno.”

  1. Ziqu ha detto:

    Per quelli che non sono del lecchese: magut è dialetto per indicare il muratore “tuttofare”, quello che si trova a svolgere i compiti più ingrati.

    Effettivamente ogni tanto mi sembra proprio di essere il jolly della situazione e che ci provino gusto a menarmi per il naso…

  2. Xander ha detto:

    Concordo e aggiungo dal moderno vocabolario informatichese:

    programmatore: moderno magut tecnologico.

    Motto: fare e disfare è una cosa da imparare se vuoi saper programmare.

Commenti chiusi