Design Pattern: Navigazione a Faccette

Navigazione a Faccette#section1

Anche chiamata navigazione guidata e ricerca a faccette, il modello di navigazione a faccette influenza i campi metadata ed i loro valori per fornire agli utenti delle opzioni visibili per chiarire e rifinire le query. La navigazione a faccette è probabilmente l’innovazione nella ricerca più significativa della decade appena passata.^[2] È caratterizzata da una ricerca integrata ed incrementale e da una esperienza di browsing che permettono agli utenti di iniziare la ricerca con la classica parola chiave, per poi fornirgli una lista di risultati tra cui scorrere. Fornisce inoltre una mappa personalizzata (solitamente a sinistra dei risultati) che fornisce delle idee riguardanti il contenuto e la sua organizzazione, offrendo una varietà di utili passi successivi. La navigazione a faccette dà prova della sua potenza in questo: mantenendo fede ai principi di progressive disclosure e di costruzione incrementale, gli utenti possono formulare l’equivalente di una sofisticata query booleana attraverso una serie di piccoli, semplici step. La navigazione a faccette affronta il bisogno universale di circoscrivere, limitare la quantità di informazione. Di conseguenza, questo schema è diventato pressoché onnipresente nell’e-commerce, data la disponibilità di metadati strutturati ed il chiaro valore per il business di una migliore trovabilità dei prodotti. L’utilizzo della navigazione a faccette si sta espandendo rapidamente attraverso una grande ed impressionante varietà di contesti e piattaforme. Nel mondo della ricerca, la navigazione a faccette è ovunque.

La Figura 4-19 illustra un’implementazione ben riuscita della navigazione a faccette come modello per l’interazione con i cataloghi di molte biblioteche accademiche. Questo è un buon esempio di federated search [ricerca federata, ndr] nella quale alla sorgente (più o meno equivalente alla locazione) viene ridotta l’enfasi relativa al soggetto e al formato. L’obiettivo del consorzio è quello di mettere in connessione gli studenti e gli accademici con i migliori materiali, senza stare a guardare a che università appartengono. Questo esempio suggerisce anche delle sfide progettuali. La navigazione a faccette non è semplicemente una caratteristica che permette di spuntare gli elementi di una lista. Il successo richiede un’attenzione accurata per i dettagli e la comprensione del vasto array di possibilità offerto dall’interaction design [progettazione dell’interazione, ndr]. Ad esempio, le biblioteche pubblicano una serie di faccette a scomparsa sulla sinistra. Solo le faccette più rilevanti (soggetto, formato, locazione) sono aperte. La maggior parte è chiusa per default. Ciascuna faccetta aperta rivela solo i primi quattro o cinque valori più popolati. Questo permette un piccolo ingombro per le faccette che lascia libero molto spazio nello parte principale per i risultati stessi. Il numero di risultati che coincidono con ogni valore (mostrati all’interno di parentesi) è un elemento chiave della mappa, così come lo è la riformulazione dei termini di ricerca e dei valori selezionati come pile di breadcrumb, che permettono agli utenti di vedere o modificare i loro parametri di ricerca correnti. Questa interfaccia è il risultato della ricerca sull’utente, dei test di usabilità e dell’iterative design [progettazione iterativa, ndr]. Ma non è l’unico modo.

[2] Marti Hearst ed i suoi collaboratori del progetto Flamenco presso UC Berkeley si meritano una menzione per la loro ricerca pionieristica sulla navigazione a faccette (http://flamenco.berkeley.edu/).

Fig. 4.19 Navigazione a faccette delle Triangle Research Libraries

Ad esempio, le applicazioni dipendono da un mix di scented widgets [“[…] graphical user interface controls enhanced with embedded visualizations that facilitate navigation in information spaces […] (Controlli grafici dell’interfaccia utente potenziati con visualizzazioni embedded che facilitano la navigazione in spazi di informazione), da: “Scented Widgets: Improving Navigation Cues With Embedded Visualizations”, Wesley Willett, Jeffrey Heer, and Maneesh Agrawala, ndr] per la visualizzazione e l’interazione con i valori delle faccette e da alcuni selettori di faccette spostati in alto o a destra piuttosto che a sinistra.

Fig. 4.20 Un insieme variegato di scented widgets

Presentare le faccette in alto attira più attenzione alle possibilità di circoscrizione. Data l’enormità degli insiemi di risultati, questo è un metodo efficace per sottolineare la struttura dati e attirare gli utenti verso i filtri. Talvolta, posizionare elementi in alto può oscurare i risultati e causare confusione, ma può funzionare bene con le collezioni di immagini come Artist Rising (Figura 4-21) o quando sono necessarie poche faccette. E’ spesso utile permettere una certa flessibilità nel numero di faccette visualizzate. Come mostrato nella Figura 4-22, le faccette adattive permettono ai controlli di uniformarsi al contenuto nel momento in cui gli utenti si spostano tra le categoria ed individuano un dato all’interno delle collezioni attraverso raffinamenti progressivi. Questo potrebbe essere un motivo per evitare di posizionare le faccette in alto. Sebbene siano meno visibili, le faccette possono funzionare anche quando sono piazzate sulla destra, ipotizzando che appaiano chiaramente come controlli piuttosto che come pubblicità e che non vengano tagliati fuori da browser più piccoli. Quando avete dubbi, fate affidamento sugli standard de facto (lato sinistro) e sottoponete i vari progetti alle ricerche sull’esperienza utente e ai test di usabilità.

Fig. 4.21 La navigazione a faccette mette i metadati sulla mappa

Fig. 4.22 Le faccette adattive di Amazon

In contrasto con la progettazione, relativamente matura, dello spazio per il desktop Web, il mobile è una piattaforma in cui gli standard per la navigazione a faccette devono ancora emergere. Pochi progetti di ricerca come FaThumb^[3] hanno esplorato le sfide e le possibilità delle interfacce basate sulle faccette per la ricerca su dispositivi mobili. Ovviamente, i piccoli schermi precludono l’utilizzo dei modelli prestabiliti: non c’è spazio sufficiente per presentare le faccette ed i valori insieme ai risultati. Sempre tra i pionieri, Amazon è tra le prime ad aver progettato un’applicazione mainstream che aggiunge la navigazione a faccette ad una ricerca su dispositivo mobile. Come mostra la Figura 4.23, è caratterizzata da un modello iterativo che richiede più step di quelli che sarebbero ideali, ma è un passo nella direzione giusta. Non appena la ricerca su mobile varcherà l’abisso, gli utenti si aspetteranno le caratteristiche e le funzionalità a cui sono abituati su desktop e per primissima cosa avranno un assoluto bisogno di circoscrivere i risultati di una ricerca.

[3] Un’interfaccia basata sulle faccette per la ricerca su dispositivi mobile. Disponibile su http://research.microsoft.com/apps/pubs/default.aspx?id=64303.

Fig. 4.23 Navigazione a faccette su Amazon mobile

Tra le varie piattaforme, ci sono alcune precisazioni ed alcune questioni che vale la pena rivedere. Innanzitutto, abbiamo usato il termine “navigazione a faccette” piuttosto liberamente. Le definizioni formali delle faccette possono escludere i campi ed i filtri semplici, ma la discriminazione non offre garanzie nella pratica, dal momento che i filtri operano in maniera indipendente e gli utenti possono aggiungerli o rimuoversli in ordine arbitrario in accordo con l’aggiornamento dei risultati.

D’altro canto, la distinzione tra la navigazione a faccette e la ricerca parametrica è rilevante. Nelle applicazioni di ricerca parametrica, gli utenti specificano i loro parametri di ricerca sin dall’inizio, utilizzando una varietà di controlli quali i checkbox, i menu a tendina, e gli slider per costruire quella che è a tutti gli effetti una query booleana avanzata. Sfortunatamente, è difficile per gli utenti settare diversi parametri tutti in una volta, specialmente dal momento che molte combinazioni produrranno zero risultati.

Oggi, è raro vedere ricerche puramente parametriche, ma molte applicazioni tendono più a quella parte dello spettro di quello che dovrebbero. Per esempio, Snooth non riesce ad indicare il numero di risultati che vanno bene con una ricerca fintanto che l’utente non ha eseguito una ricerca rifinita. Le widget sono decisamente non profumate e l’interfaccia incoraggia gli utenti a modificare più parametri prima dell’esecuzione della query. E’ una soluzione difficile per le persone ma facile per l’hardware. In altre parole, è un infelice compromesso che sacrifica la risposta immediata per ridurre il carico del server.

Fig. 4.24 Problemi parametrici su Snooth

All’estremo opposto, le applicazioni di ricerca in tempo reale come Volkswagen UK (Figura 4-25) aggiornano dinamicamente i risultati, senza aver un bottone submit o senza fare un refresh della pagina. Ci sono dei reali vantaggi con questo modello dinamico, che permettono un’immediata risposta, una minima interruzione e transizioni eleganti. Ma ci sono anche dei costi. L’applicazione di Volkswagen UK impiega del tempo prima di caricarsi e Kayak deve usare un overlay cospicuo (e in qualche modo problematico) per richiamare l’attenzione sui risultati aggiornati. Le applicazioni per ricerche in tempo reale sono come i veicoli ibridi pericolosamente silenziosi. Quando non c’è più il rumore, capiamo che aveva un suo senso. Le transizioni eleganti possono reintrodurre parte delle interruzioni utili, ma, nei casi in cui sia i risultati sia le faccette cambiano simultaneamente, questo diventa rischioso.

Fig. 4.25 Risposta immediata sul sito Volkswagen UK

Fig. 4.26 Ricerca in tempo reale su Kayak

Ovviamente, fintanto che la progettazione e la tecnologia si evolveranno di pari passo, risolveremo questi problemi nonostante le nuove sfide in cui ci imbatteremo. I processori diventano più veloci, le persone no. Quindi, dovremmo gestire in maniera molto attenta le transizioni. Nel frattempo, la navigazione a faccette si adatterà sicuramente a qualunque contesto e piattaforma, perché il bisogno di circoscrivere le informazioni esiste all’incrocio tra il comportamento e la funzionalità.

Navigazione a faccette#section2

Fig. 4.27 Il modello di progettazione a navigazione a faccette

La navigazione a faccette è un signor modello. Il suo sviluppo impatta su tutti gli altri modelli di ricerca e sull’architettura dell’informazione nel suo insieme. Per semplificare ulteriormente, c’è il modello Google ed il modello a navigazione a faccette. Scegliere tra questi due è una decisione strategica cruciale. Determinare se la navigazione a faccette sia ragionevole e fattibile è uno dei primissimi step nella progettazione. L’infrastruttura per la navigazione a faccette può rendere possibile una relazione più stretta tra la ricerca ed il browsing. Può dare forma alla struttura e alla navigazione dell’intero sito o dell’intera applicazione. Cambia anche il modo in cui pensiamo all’auto-completamento e all’algoritmo di visita ottimale. Offre un framework familiare per gestire le risorse della federated search. Inoltre, il suo potere discriminatorio nel chiarire gli intenti e rifinire i risultati può controbilanciare la necessità della personalizzazione e della ricerca avanzata. Detto ciò, la navigazione a faccette non funziona dovunque. Per i principianti, è un progetto costoso. Le richieste dei software di ricerca e dei server sono considerevoli. In aggiunta a ciò, l’infrastruttura dei metadati implica sia un investimento iniziale sia una spesa costante. Per queste ed altre ragioni, un semplice modello di ricerca spesso è meglio, ma deve spesso essere affiancato da un sistema di ricerca avanzata.

Fig. 4.28 Ricerca avanzata su Genentech

Ricerca Avanzata#section3

Concetto relativo, la ricerca avanzata include tutto ciò che non è incluso nella ricerca semplice. E’ un modello che molti di noi o amano o odiano. Spesso, la ricerca avanzata è un rozzo add-on che viene usato raramente e fornisce una scappatoia agli ingegneri e ai designer. Caratteristiche preziose che sono difficili da integrare nell’interfaccia principale possono essere relegate al ghetto e dimenticate. Inoltre, c’è molta confusione riguardo il suo scopo. E’ un assemblatore di query user-friendly per novizi o un potente tool per esperti? Molte interfacce cercano di essere (e falliscono) entrambe le cose. Per esempio, non è equo supporre che gli utenti che comprendono cosa significhi una “frase esatta” sappiano anche usare i punti di domanda per specificare tale ricerca? Il problema principale con Boolean non è la sintassi, è la logica. E anche il linguaggio semplice mostrato in Figura 4-28 è molto improbabile che aiuti i pochi novizi che osano avventurarsi nell’intimidatorio reame della ricerca avanzata.