Con o senza filtro?

“Il talento sta nelle scelte.”
Robert De Niro

Esempio di form di ricerca

Quella visualizzata nell’immagine è la maschera di ricerca di un software personalizzato progettato alcuni anni fa. L’archivio in cui si voleva fare la ricerca era un tipico archivio contratti.

Con un po’ di analisi e un paio di versioni si ottenne un sistema con 10 filtri, inclusa la possibilità di cercare per intervalli di date.

Dopo qualche tempo si notò che le descrizioni dei contratti inserite dagli operatori avevano la seguente forma.

2014 - Rossi - Abbonamento al servizio XYZ

Consultando gli operatori, che inizialmente non erano stati coinvolti nella scelta dei criteri di ricerca, si scoprì che aggiungevano metodicamente alla descrizione del contratto l’anno d’inizio e il cognome del contraente. Lo facevano perché era “il modo più semplice per trovare un contratto”.

Cos’era successo?

  • Nella quasi totalità dei casi, i parametri di ricerca usati erano l’anno d’inizio contratto, il cognome del contraente e la descrizione.
  • Gli operatori avevano scoperto che la funzione di ricerca trovava anche le sottostringhe di testo presenti nella descrizione.

In sostanza ciò che serviva a soddisfare la maggior parte delle ricerche era cercare sottostringhe di testo nella descrizione del contratto e nel cognome del contraente e la corrispondenza esatta nell’anno di inizio contratto.

Un’idea semplice e funzionale:

RicercaGoogle

In realtà, quando si tratta di costruire strumenti software su misura, uno degli obiettivi è semplificare le attività quotidiane senza perdere flessibilità.

La soluzione istintiva è quella vista nel nostro esempio: aggiungere filtri su filtri. Così facendo si generano problemi derivanti dalla complessità della funzione di ricerca:

  • aumentano i costi di realizzazione e manutenzione del software;
  • un difetto nell’implementazione, oltre a essere difficile da individure, può produrre risultati errati;
  • un’interfaccia utente complessa induce nell’operatore il dubbio di commettere errori (“non ho trovato quello che cerco perché non è nell’archivio o perché ho sbagliato uno dei dieci parametri?”).

Una soluzione migliore consiste nello comporre la funzione di ricerca in due strumenti da utilizzare in contesti diversi.

Ricerca libera

Fornendo un’unica stringa di testo, gli elementi dell’archivio sono selezionati in base al contenuto di tutti i campi che si ritengono significativi; questi campi devono essere chiari all’utente.

Funziona molto bene in due casi tra loro opposti e molto frequenti:

  • si conosce una chiave di ricerca univoca, come il numero di contratto, che consente di trovare rapidamente quanto cercato (rapidità e precisione);
  • si conosce solo parte di un’informazione non univoca, come il cognome del contraente, che è associata a quanto cercato e consente di ottenere un ristretto numero di risultati da esplorare “a vista” (completezza della ricerca).

Viste utente

La vista utente è una finestra sui dati che ha una corrispondenza diretta col modo in cui gli operatori vedono il contenuto dell’archivio durante lo svolgimento delle loro mansioni. E’ importante considerare gli operatori come classe di utenza senza affidarsi al giudizio di un solo individuo.

Per essere tale, una vista utente deve avere caratteristiche precise:

  • rappresentare concetti che prescindono dall’esistenza di un sistema di gestione informatizzato come le “fatture pagate/non pagate” o i “contratti scaduti”;
  • non richiedere la definizione di parametri di ricerca granulari, come “il numero contratto” o “l’intervallo di date”, ma proporne di semplici quali “le fatture pagate nell’ultimo mese” o “i contratti scaduti” (ovviamente a oggi);
  • avere al massimo tre parametri definibili dall’utente; l’ideale sarebbe non averne affatto ma spesso un parametro è intrinseco nel modello di lavoro (es. “fatture pagate/non pagate”);
  • utilizzare ordinamenti predefiniti che siano evidenti osservando il risultato della ricerca quali “ordine alfabetico per contraente” o “prima le fatture scadute da più tempo”;
  • essere parte irrinunciabile della specifica funzionalità che si sta realizzando e non prevista per un possibile uso futuro.

Infine, dopo aver creato le viste utente, occorre resistere alla tentazione di unirle per ottenere funzioni di ricerca più “potenti”.