Rendere navigabili i dati

Pensare all'architettura delle informazioni e disegnare il modello dati del sistema non basta. Che si tratti di un programma progettato per funzionare in rete locale, di un'applicazione web o di un sito, occorre definire anche i criteri di navigazione tra le informazioni gestite.

Troppo spesso si vedono applicazioni gestire migliaia di informazioni che poi si possono consultare solo a fatica e con percorsi rigidamente codificati a priori. Per esempio:

Necessità di specifiche

Alla fase di disegno del modello dati, deve seguire la descrizione di come l'utente potrà navigare tra le informazioni. In particolare occorre:

• descrivere le regole generali. Ad esempio, le tendine di selezione devono consentire l'apertura delle schede corrispondenti ad ogni voce?

• descrivere i percorsi agevolati più importanti. Ad esempio, la visualizzazione del numero telefonico del riferimento principale del cliente;

• descrivere i punti principali dai quali occorre poter arrivare ai dati;

• descrivere i collegamenti obbligatori;

• descrivere i simboli rappresentativi dei dati più importanti;

• principali report da estrarre;

• principali filtri già disponibili con l'avvio dell'applicazione.

Chi progetta l'interfaccia, infatti, deve conoscere i criteri di navigazione necessari all'utente e questi sono spesso ovvi nel momento in cui si defiscono i dati. Allo stesso modo, i simboli che rappresentano gli oggetti più importanti o i dati elementari (es: il numero di telefono) devono essere scelti da chi usa l'applicazione e non fissati dal progettista.

Per la rappresentazione dei criteri di navigazione tra i dati vi sono vari simbolismi. Tra questi:

• la notazione OO (Object Oriented) di Yourdon/Coad;

• le mappe mentali o, nei casi più complessi, quelle cognitive;

• i CFD (Control Flow Diagram);

• un albero strutturale delle parti attive della HIC (Human Interface Component).

Alcuni problemi di navigabilità

Tra i problemi che spesso si riscontrano nelle applicazioni, sia web sia client/server, si notano:

• spesso si può passare da un livello al successivo del menu, senza poter tornare indietro di uno;

• sulle tendine, in mancanza di una voce non è possibile inserire al volo un elemento, anche dove avrebbe senso;

• non è possibile aprire le schede di dettaglio delle descrizioni di decodifica;

• non è possibile usare alcuni campi nei filtri;

• i pulsanti hanno icone che non si accordano con l'oggetto richiamato, secondo gli utenti;

• i menu non sono raggiungibili in alcune fase o sono parziali.

In generale, le interfacce applicative sembrano non tenere conto delle reali necessità di navigazione che l'utente ha nel corso del proprio lavoro. Si considera l'estetica, il rigore formale degli alberi funzionali, i dettami tecnici e si dimentica che l'utente non ha necessità di capire perchè una certa cosa non si può fare o come lo si debba fare, ma semplicemente che sia possibile farla.

Non a caso, sempre più di frequente nei team di progettazione delle interfacce sono presenti psicologi e sociologi come garanti che i processi mentali degli utenti non siano violentati da applicazioni che tendono a modificare iter collaudati, solo perchè progettisti troppo tecnici che ignorano la base del modo operativo, realizzano sistemi che piacciono a loro, prima che agli utilizzatori. Non chiederti, insomma, se l'interfaccia che stai progettando è bella. Chiediti se piacerà e non per la sua estetica, ma per le possibilità di navigazione che consente tra i dati. Non pensare a ciò che è giusto, ma a ciò che secondo l'utente è giusto, anche se per te non lo è. L'applicazione non la progetti per te!

Il menu: per funzione o per oggetto?

In relazione alla navigazione tra i dati, tra i componenti più importanti troviamo il menu.

Con alcune piccole eccezioni, distinguiamo due categorie di menu: quelli organizzati in base alle funzioni disponibili; quelli organizzati sulla base degli oggetti disponibili.

Un menu funzionale consente all'operatore di entrare nella funzione di aggiornamento delle tabelle e chiede in seguito quale tabella si vuol aggiornare. Un secondo esempio è dato dalle funzioni di stampa, nel quale si accede al sotto-menu corrispondente, si seleziona il report desiderato e quindi si filtrano i dati.

Un menu per oggetti consente di scegliere su quale oggetto si vuol operare e da qui rende disponibile le azioni valide per quel tipo specifico di oggetto.

I menu strutturati per funzione sono quelli che più spesso si presentano rigidi e con scarse capacità di navigazione (che poi devono essere risolte mediante pulsanti aggiuntivi). Frequentemente, trovandosi sui clienti, per aggiornare le offerte occorre chiudere la scheda aperta, cambiare sezione del menu, scegliere l'offerta che ci serve, ecc.

Sulle applicazioni web, la maggiore difficoltà tecnica di realizzazione di menu dinamici o contestuali è la principale motivazione di rigidità. In tali situazioni è importante che la navigazione sia garantita da altre possibilità insite nell'interfaccia, come i pulsanti, il tasto destro le mouse, ecc.

Percorsi agevolati

Studi dimostrano che per ogni tipo di applicazione esistono dei percorsi abitualmente usati dagli utenti. Tali percorsi sono concettualmente poco importanti, ma quotidianamente usati. I progettisti tendono a considerarli di secondaria importanza, soprattutto perchè tramite il sistema di menu si riesce comunque a percorre l'iter che porta al dato interessato.

Per agevolare la navigazione tra i dati, invece, sarebbe preferibile che tali necessità operative quotiane fossero agevolati mediante percorsi veloci.

Un esempio. La maggior parte delle volte che un commerciale seleziona un'azienda cliente è per selezionare subito dopo un riferimento interno, aprirne la scheda e leggerne il numero di telefono. Sarebbe senz'altro utile a questo tipo di utente, l'avere il numero di telefono dei riferimenti già sulla prima scheda, una volta che si è fatto click sul cliente interessato. Si eviterebbe in tal modo un percorso fatto di molti click, di aperture di schede e query inviate al server e di attese di dati tramite Internet.

Un secondo esempio. Sulla home di un sito che presenta ricette, dovrebbe esserci sempre il link all'ultima pubblicata. Probabilmente, infatti, vedere le nuove ricette è il motivo principale per cui i visitatori ritornano la seconda volta al sito, ed agevolarli non può che contribuire alla loro fidelizzazione.

Rimando all'oggetto citato

I rimandi attivi sono uno dei principali metodi per aumentare la navigabilità di un sistema.

Ogni scheda contenente un riferimento ad un' altra scheda o ad un oggetto diverso, dovrebbe consentirne l'apertura al volo, senza uscire dal contesto nel quale ci si trova.

Un esempio. Se si è nella fase d'aggiornamento del cliente e tra le informazioni si trova il riferimento alla banca, è opportuno che l'operatore possa aprire la relativa scheda per verificarne i dati.

Un secondo esempio. Se su una pagina di un sito si cita un'altra pagina o un elemento presente su un'altro sito, il riferimento dovrebbe sempre essere fatto con un link attivo. È scritto ovunque, ma rispettato pochissimo.

Pulsanti programmabili o Preferiti

Ogni applicazione, web o no, dovrebbe avere dei pulsanti programmabili riservati all'utente, con la possibilità di impostare semplici azioni o riferimenti a dati di interesse.

Le tecniche possono essere: una serie di pulsanti che l'utente ha la possibilità di associare ad azioni o indirizzi; un elenco di preferiti con la possibilità di associare dei rimandi ai contesti scelti.

La scelta tra pulsanti ed elenco di preferiti è data dalle possibilità d'implementazione che si hanno. Per i pulsanti serve una gestione maggiore (le icone associate, l'azione, il numero ed il posto ove mettere i pulsanti), l'elenco di preferiti normalmente è di più semplice realizzazione tecnica.

I pulsanti sono più indicati per attivare parti importanti dell'interfaccia in modo diretto, superando tutti i livelli di menu. L'elenco dei preferiti si presta meglio a memorizzare pagine o record di database (documenti, anagrafiche, ecc. in funzione del tipo di applicazione).

I pulsanti e preferiti devono ovviamente essere specifici per l'operatore, in modo da consentire ad ognuno di essi di impostare i propri.

Ultima informazione in esame

L'interruzione di un'operazione di aggiornamento di un certo documento, un'anagrafica o un altro oggetto, spesso implica la chiusura e la necessità di selezionare nuovamente l'elemento al momento della riapertura della sessione di lavoro.

Un sistema con buona capacità di navigazione, memorizza l'identificativo dell'informazione sulla quale si sta lavorando, per riproporla al nuovo avvio dell'applicazione. Tale meccanismo può essere automatico o a richiesta dell'operatore.

Come nel caso precedente, l'informazione registrata deve essere specifica per l'operatore, in modo da consentire ad operatori diversi di avere ognuno la propria ultima scheda aperta.

Sistemi più avanzati, consentono di memorizzare un numero più alto di ultimi documenti (record) cui s'è fatto accesso, per dare all'operatore ulteriore flessibilità.

Questa caratteristica, apparentemente meno importante per i siti, si rivela fondamentale, invece, per siti complessi che sicuramente non saranno letti dal visitatore in una sola sessione.

Filtri

Se nell'applicazione esiste la possibilità di avere elenchi, è importante che l'operatore possa impostare dei propri filtri sui dati presentati. Raramente, infatti, è possibile prevedere a tavolino la necessità di tutti gli operatori.

Un componente standardizzato per la gestione dei filtri, sicuramente di complessa realizzazione, è ampiamente ripagato dal valore che aggiunge a tutto il sistema.

Un sistema di filtro, basato su criteri di QBE (Query By Example), dovrebbe dare la possibilità di legare con operatori logici più condizioni, di accedere a tutte le tabelle e tutti i campi, di fare filtri anche sulle tabelle legate a quella su cui si sta operando. I filtri devono essere memorizzabili per usi
successivi.

Maschere personalizzabili

Progettando un'interfaccia, solitamente si scelgono i campi da posizionare
sulle schede.

Per rendere più semplice la consultazione tra i dati, è opportuno che in fase di configurazione del sistema si possa stabilire quali campi devono essere realmente visibili e quali invece resi nascosti.

L'ideale sarebbe che l'interfaccia prevedesse la possibilità d'avere maschere diverse in funzione dei profili o dell'operatore, in modo da mostrare solo i campi di reale necessità per ogni utilizzatore.

La possibilità di porre sulle schede dei pulsanti programmati dall'utente consente di aumentare ulteriormente la navigabilità dei dati.

Generazione di report

Difficilmente riscontrabili nelle applicazioni web, grazie ai nuovi generatori di report pensati per Internet, è più semplice dotare gli utenti di designer che consente agli utenti, se hanno sufficienti conoscenze informatiche, di disegnare i propri prospetti.

La storica lamentela degli operatori, infatti, è il dover inserire dati in applicazioni che poi non ne consentono la relativa estrazione.

Un buon generatore di report può supplire a molte deficenze dell'interfaccia, in relazione alla visualizzazione dei dati.

Conclusione

La navigabilità dei dati è uno dei principali fattori di successo dei sistemi che la contemplano tra le specifiche di progettazione.

Considerare il profilo dell'utilizzatore e pensare a come quest'ultimo lavora è fondamentale per comprendere perchè una splendida applicazione che consente l'inserimento velocissimo, ma la difficile estrazione, non sia poi amata dagli utenti.