Principi base di interaction design - Bruce Tognazzini

[Traduzione di First Principles of Interaction Design di Bruce Tognazzini a cura di Marco Catani]
[Sempre di Bruce Tognazzini: Ridurre il tempo soggettivo]

In questo articolo:

Introduzione

Il principi qui esposti sono fondamentali per il disegno e l'implementazione di interfacce efficaci, sia per le GUI tradizionali sia per il Web. Ultimamente si sono viste numerose applicazioni web che hanno mostrato, a loro discapito, una totale mancanza della comprensione di questi principi. Semmai l'applicazione di questi principi è ancora più importante proprio in luce del fatto che queste applicazioni vivono su Web.

Interfacce efficienti hanno elementi ben visibili e perdonano gli errori, instillando nei propri utenti un senso di padronanza. Gli utenti capiscono velocemente le opzioni messe a disposizione, afferrano al volo come ottenere i risultati attesi e portano a termine il proprio lavoro.

Interfacce efficienti non disturbano l'utente richiedendo la comprensione di meccanismi interni al sistema. L'avanzamento del lavoro è costantemente salvato e l'utente può in ogni momento tornare indietro e modificare quanto fatto.

Applicazioni e servizi efficienti fanno gran parte del lavoro, richiedendo all'utente il minimo numero di informazioni.

indice ↑

Anticipazione

Le applicazioni dovrebbero cercare di anticipare i bisogni e le aspettative dell'utente. Non ci si deve attendere che un utente vada a cercare, per ogni step del processo, le informazioni e gli strumenti necessari per proseguire; questi vanno invece forniti in prima istanza.

indice ↑

Autonomia

* Il computer e l'interfaccia "appartengono" all'utente, ma l'autonomia dell'utente non significa abbandono delle regole.

E' sì importante lasciare all'utente un po' di spazio. Gli utenti imparano più velocemente e raggiungono un livello di padronanza più rapidamente quando sentono di avere il controllo. Paradossalmente invece le persone non si sentono libere in totale assenza di ogni vincolo (Yallum, 1980). Un bambino piangerà sia che lo si stringa forte sia che lo si lasci abbandonato a se stesso. Gli adulti allo stesso modo si sentono più a proprio agio in un ambiente che non sia nè limitante nè infinito, esplorabile ma non pericoloso.

* Usare meccanismi di che forniscano informazioni sullo stato del sistema per mantenere gli utenti informati.

Non può esistere autonomia in assenza di controllo e non può esistere controllo in assenza di sufficienti informazioni. Riportare lo stato del sistema è di fondamentale importanza affichè chi ci lavora possa rispondere in modo appropriato al mutamento delle condizioni del sistema stesso. Volendo esemplificare, gli utenti, in assenza di informazioni, dovranno mantenere una concentrazione elevata anche in momenti in cui non sarebbe realmente necessario. Questo comporta uno stress e una fatica inutili, creando una carenza di risorse fisiche e mentali per affrontare le fasi successive del lavoro.

* Mantenere le informazioni sullo stato del sistema aggiornate e sempre visibili all'utente

Gli utenti non dovrebbero cercare le informazioni sullo stato del sistema. Piuttosto dovrebbero guardare la propria area di lavoro ed essere capaci di fornire una stima approssimata del carico di lavoro e dello stato in cui si trova il sistema. Le informazioni di sistema possono essere abbastanza sottili: l'icona della casella di posta in entrata può essere mostrata vuota, piena o stracolma. Ma attenzione a non eccedere in questo senso. Il macintosh per anni ha mostrato un'icona che rappresentava un serio pericolo di esplosione del cestino, anche se un solo documento vi era stato gettato. Questo comportamento dell'interfaccia ha creato la tendenza negli utenti a svuotare il cestino direttamente in seguito all'inserimento del primo documento, trasformando un processo di uno step solo in un processo a due step (getta nel cestino, svuota il cestino), e ha negato inoltre l'intero vantaggio dell'avere un cestino, ossia la possibilità di annullare l'operazione di cancellazione.

Un esempio, questa volta positivo, riguarda un campo di ricerca che cambia colore e aspetto per indicare che la ricerca è in corso, piuttosto che è stata completata ma sono presenti troppi, o troppo pochi risultati. (come ogni elemento di interfaccia, l'utilizzo del solo colore non è sufficiente. Circa il 10% dei maschi mostrano sintomi di daltonismo. Una percentuale ancora maggiore potrebbe avere alterazioni della percezione del blu in condizioni particolari)

indice ↑

Daltonismo

Ogni volta che si usa il colore per veicolare l'informazione, si dovrebbe usare anche indicazioni secondarie ma chiare per trasferire l'informazione a coloro che i colori non li vedono.

Molte persone ormai hanno schermi a colori (ndt. praticamente tutti), ma esistono differenze di colore tra ognuno. In aggiunta a ciò il 10% della popolazione maschile, e una minima percentuale di quella femminile, soffrono di daltonismo.

Negli occhi i coni sono la sorgente della visione a colori. Abbiamo coni separati per rosso, verde e blu. Se a non funzionare sono i coni preposti al rosso allora si dice essere affetti da protanopia. Nel caso del verde abbiamo la deuteranopia e per il blu, fenomeno estremamente raro, la tritanopia.

La protanopia e deuteranopia sono le forme più comuni di daltonismo (ci sono significative differenze tra queste due forme e nei loro effetti, ma non hanno un vero impatto sull'interaction design). Sebbene la tritanopia sia molto più rara, impone di fatto di non legare informazioni alla differenza giallo/blu, senza quantomeno usare indicazioni secondarie.

Indicazioni secondarie possono consistere nell'avere differenziazioni basate sulla scala del grigio oppure che etichette associate ad ogni colore utilizzato.

indice ↑

Coerenza

I principi di seguito esposti offrono all'interaction designer un ampio orizzonte dell'evoluzione del prodotto, senza però intaccare le aree di coerenza importanti per l'utente.

* Livelli di coerenza: l'importanza di mantenere un severo livello di coerenza varia. La lista che segue è ordinata mettendo in cima gli elementi di interfaccia che richiedono una maggiore coerenza e in fondo quelli che ne richiedono meno. Paradossalmente molte persone ritengono che l'ordine in cui appaiono i punti dall'uno al cinque dovrebbero essere invertiti. Questa filosofia di design porterebbe ad applicazioni che si assomigliano tra loro, ma che si comportano in maniera diversa in modo imprevedibile:

  1. interpretazione del comportamento dell'utente, es. gli shortcut mantengono il loro significato
  2. strutture invisibili
  3. piccole strutture visibili
  4. il "look" d'insieme di una singola applicazione o servizio - splash screen, elementi di design
  5. una suite di prodotti
  6. coerenza in-house
  7. coerenza della piattaforma

"Strutture invisibili" si riferisce a quegli oggetti invisibili come il piccolo bordino destro in MS Word, che possiede virtù magiche e un infinità di proprietà, se mai scopri che si trova li. Potrebbe o potrebbe non apparire nella tua versione di Word. E se non compare in effetti non potrai mai sapere se è proprio li o altrove, proprio a causa della sua invisibilità. Il che è esattamente ciò che è sbagliato degli oggetti invisibili e perchè è così importante essere consistenti. Altri oggetti sono visibili, ma non sembrano essere dei controlli. Quindi gli utenti potrebbero non scoprirne mai il loro significato e utilizzarli. Il segreto, se proprio si vuole insistere su questa strada, è di essere chiari, per esempio: "puoi cliccare e trascinare i bordi della finestra del macintosh per ridimensionarla" e non "puoi cliccare e trascinare alcune cose a volte, ma non altre, altre volte".

"Piccole strutture visibili" si riferisce invece a icone, frecce della scrollbar, boxettini, ecc. L'aspetto di questi oggetti deve essere controllato con cura, se si vuole evitare che le persone passino metà del loro tempo a cercare di capire come di scrolla una pagina o come si fa una stampa. Il posizionamento è solo leggermente meno importante dell'aspetto. Quando è opportuno occorre uniformare anche quello.

* Incoerenza: è altrettanto importante essere inconsistenti visivamente, creando differenze quando le cose devono comportarsi in maniera diversa; allo stesso modo è importante essere consistenti quando le cose devono agire allo stesso modo.

Evitare l'uniformità. Creare oggetti consistenti per il loro comportamento. Oggetti che agiscono in modo diverso devono avere un aspetto diverso.

* La coerenza più importante è quella verso le aspettative dell'utente.

L'unico modo per scoprire veramente quali siano le aspettative dell'utente è fare user testing. Studio e discussioni non rappresentano un'alternativa.

indice ↑

Valori di Default

* Dovrebbe essere semplice "sbarazzarsi" dei valori di default: i campi che contengono valori di default dovrebbero essere presentati con il valore già selezionato, in modo tale che gli utenti possano rimpiazzare tele valore in modo semplice e veloce.

* I valori di default offerti dal sistema dovrebbero essere "intelligenti" e reattivi.

* Un'applicazione non dovrebbe utilizzare la parola "default" al proprio interno. Al suo posto è meglio usare "standard", "valori preimpostati", "valori di esempio" o altri termini specifici che illustrino meglio la situazione.

indice ↑

Efficienza dell'Utente

* Concentrarsi sull'efficienza dell'utente, non quella del computer.

Le persone costano di solito molto di più dei computer e mentre spesso si crede che aumentare l'efficienza delle macchine aumenti quella degli esseri umani, nella realtà spesso è vero il contrario. Quando giudicate l'efficienza di un sistema, non soffermatevi, ma guardate oltre, l'efficienza delle macchine.

Per esempio, quale di queste due azioni è più dispendiosa in termini di tempo: scaldare dell'acqua in un forno a microonde per un minuto e dieci secondi o farlo per un minuto e undici secondi?

Dal punto di vista del forno a microonde un minuto e dieci secondi è ovviamente la risposta corretta. Dal punto di vista dell'utente invece un minuto e undici secondi è più veloce. Perchè? Perchè nel primo caso l'utente deve premere il tasto Uno per due volte, localizzare lo Zero e premerlo. Nel secondo caso invece l'utente deve pigiare semplicemente il tasto Uno per tre volte. Ipotizzando che l'operazione di ricerca dello Zero richieda più di un secondo vediamo come l'acqua ci metta meno a diventare calda quando è "cotta" di più.

Altri fattori oltre quello della velocità ci portano a scegliere come più efficiente la soluzione 1-1-1. Cercare un altro tasto, non solo richiede tempo, ma richiede una certa quantità di processo cognitivo. Mentre questo processo viene svolto, il processo principale dell'utente - cucinare il proprio pasto - deve essere messo da parte. Maggiore è il tempo per cui lo si mette da parte, maggiore sarà il tempo che ci vuole per riprendelo.

In aggiunta, l'utente che adotta l'espediente di utilizzare cifre ripetute per il forno a microonde deve affrontare meno decisioni. Questo utente abbandona velocemente l'idea di stare a pensare se la pancetta debba cuocere per 2 minuti e dieci secondi puttosto che due minuti e ventitre secondi. Fa un rapido calcolo e, dato che la quantità di acqua e lo spessore della pancetta variano di volta in volta, finise per ottenere pressochè lo stesso risultato con molta meno fatica, migliorando la propria efficienza.

* Mantenere l'utente occupato.

Questo perchè tipicamente il costo più alto è quello del personale. Ogni volta che l'utente si trova ad aspettare la risposta della macchina per poter andare avanti si perdono dei soldi.

* Per massimizzare l'efficienza di un'organizzazione si deve massimizzare l'efficienza di ognuno, non solo di un particolare gruppo di lavoro.

Le grosse organizzazioni tendono ad essere a scompartimenti stagni, ad avere gruppi che si occupano del proprio interesse, a volte a discapito dell'intera organizzazione. I dipartimenti di information resource spesso cadono nell'errore di creare o adottare sistemi che migliorino la propria efficienza e i propri costi, ma a danno dell'intera azienda.

Per esempio, una grossa società in California usava floppy disk per raccogliere informazioni relative ai benefit (ndr. dati riguardanti le scelte di pensione integrativa e copertura sanitaria). All'inizio della procedura di raccolta dei dati, ogni impiegato riceveva un dischetto con dei moduli elettronici da compilare. Dopo aver inserito nome, cognome, numero di telefono, nome del dipartimento, ecc., l'impiegato poteva scegliere i vari benefit e restituire il dischetto contenente tutte le proprie risposte e decisioni. Il dipartimento di information resources estraeva quindi le informazioni dal disco in maniera automatica. In questo modo il dipartimento salvava un sacco di soldi rispetto al vecchio sistema, che consisteva nel reinserire a mano le informazioni scritte su un modulo cartaceo dall'impiegato.

Qual era il problema? Il carico dell'inserimento delle scelte degli impiegati nel sistema non gravava più sul diparitmento di information resources, ma su ogni singolo impiegato che doveva inserire il proprio nome, cognome, numero di telefono, nome del dipartimento, ecc. Il sistema era altrettanto inefficiente quanto quello vecchio, ma il costo in questo caso era ridistribuito su tutti i dipartimenti, inece che gravare unicamente sul dipartimento di information resources.

* Le grandi innovazioni in termini di efficienza nel software vanno trovate nell'architettura fondamentale del sistema, non nel disegno di massima dell'interfaccia.

Questa semplice verità è il motivo per cui è così importante che tutte le persone coinvolte nella progettazione del software si pongano come obiettivo primario la produttività dell'utente, e che capiscano la fondamentale differenza tra il costruire un sistema efficiente e potenziare l'efficienza dell'utente. Questa è inoltre un'attivià chiave nella serrata e costante cooperazione e comunicazione tra ingegneri e human interface designer, se si desidera raggiungere questo obiettivo.

* Scrivere messaggi d'errore concisi e inerenti al problema: un buon copywiriting è ripagato ampiamente in termini di comprensione ed efficienza

* I menu e le etichette dovrebbero riportare la parola / le parole chiave per prime

Per esempio in un word processor
è sbagliato:

  • inserire interruzione di pagina
  • aggiungere una nota a piè di pagina
  • aggiornare l'indice dei contenuti
ed è corretto:
  • interruzione di pagina
  • nota a piè di pagina
  • indice dei contenuti

Nel primo esempio, che speciffica le azione, è in effetti più ricco di informazioni e più accurato: una persona non "inserisce" una nota a piè di pagina se deve essere "aggiunta" di seguito a tutte le altre note. Allo stesso modo una persona non inserisce l'indice dei contenuti se ne esiste già uno nel documento, piuttosto lo "aggiorna". Eppure il secondo esempio si dimostrerà più efficiente nelle prove a tempo. Perchè? Perchè le informazioni aggiuntive che il primo esempio offre non controbilanciano il vantaggio di poter leggere scansendo solamente la prima parola in ogni voce di menu.

indice ↑

Interfacce esplorabili

* Fornire agli utenti strade ben definite e con una chiara segnaletica, poi lasciare che possano inserire la trazione integrale.

Imitate il senso di confidenza, sicurezza e la coerenza che offre il paesaggio naturale. Non intrappolate gli utenti in un singolo tracciato disegnato per un servizio, lasciate piuttosto un confine facile da oltrepassare. Questo approccio consente all'utente di portare a termine un lavoro nel più breve tempo possibile e seguendo un percorso "a sforzo zero", mentre lascia a coloro che vogliano esplorare e i "se e i ma" la possibilità di farlo.

* A volte, tuttavia, bisogna disegnare dei binari.

Più vi avvicinate alla parte meno pragmatica della curva di esperienza, più dovrete frenare i vostri utenti. Un'applicazione monouso per uno specifico compito richiede un'interfaccia molto più direttiva che l'abituale interfaccia che utilizza un esperto.

* Offrite agli utenti indicazioni che li aiutino a costruire una percezione dell'applicazione stabile e familiare.

Elementi visivi stabili non solo permettono agli utenti di navigare velocemente, ma agiscono anche come una segnaletica riconoscibile, dando alle persone un senso di familiarità.

* Pensare ad azioni reversibili

Le persone esplorano in diversi modi, oltre che alla consueta navigazione. A volte vogliono sperimentare cosa accade se provano a compiere un'operazione potenzialmente pericolosa. A volte non stanno nemmeno provando a sperimentare situazioni, ci capitano semplicemente per caso.

Rendendo ogni azione reversibile gli utenti possono esplorare e diventare "incauti" con il proprio lavoro.

* Consentire sempre l' "annulla".

Uno dei risultati inevitabili che si ottengono non supportando l' "annulla" è che al suo posto bisogna supportare tutta una serie di dialog box che dicano l'equivalente di: "Sei sicuro? Proprio sicuro?". Non c'è bisogno di dire che queste operazioni rallentano le persone.

Non solo, in assenza di questi dialog box le persone sono addirittura più lente. Uno studio condotto qualche anno fa dimostra che le persone che operano in un ambiente pericoloso non fanno più errori di quelle che lavorano in un ambiente più tutelato e visivamente più ovvio; lavorano però più lentamente e molto più attentamente per evitare di commettere errori.

* Consentite sempre una via d'uscita

Gli utenti non dovrebbero mai sentirsi in trappola. Dovrebbero invece avere una chiara via di uscita.

* In ogni caso, rendete più facile lo star dentro (l'applicazione) che l'uscirne.

I primi software erano difficili da chiudere. Con l'avvento del Web, abbiamo iniziato a vedere software che rendono difficile la "permanenza". I browser sono addobbati ancora a festa con oggetti e opzioni che non hanno nulla a che fare con la nostra applicazione e i servizi che ci girano. Il nostro compito può diventare analogo al disegnare un word processor che, per esempio, debba usare la barra di menu di Photoshop. Avere 49 opzioni sullo schermo che portino direttamente alla distruzione del lavoro dell'utente, assieme a una o due che possano effettivamente essere d'aiuto non è sinonimo di interfaccia esporabile, piuttosto di interfaccia infernale. Se state lavorando con interazioni e processi complessi usando un browser standard, spegnete la barra dei menu e tutte le altre opzioni irrilevanti; fornite voi le vostre limitazioni e opzioni.

indice ↑

Legge di Fitts

* Il tempo per raggiungere un oggetto è una funzione della distanza e della dimensione dell'oggetto.

Sebbene questa legge possa sembrare banalmente ovvia a prima vista, rappresenta uno dei principi di design più ignorati. La legge di Fitts - propriamente, di rado, scritta Legge di Fitts - dice che i menu a tendina su Mac dovrebbero essere approssimativamente cinque volte più veloci da utilizzare che i menu di Windows.

La legge di Fitts dice che la barra dei task delle finestre disturba, costantemente e senza necessità, il lavoro delle persone. La legge di Fitts indica che i punti ad accesso più rapido su qualsiasi monitor sono i quattro angoli dello schermo, a causa della loro posizione limite, e nonostante questo, per anni, sembra siano stati evitati ad ogni costo dai designer.

Usate oggetti grandi per funzioni importanti (i Bottoni grandi sono più veloci).

Usate le proprietà limite dei bordi, del fondo, del top e degli angoli dello schermo: una toolbar su una sola riga che si "immerge" nei bordi del monitor è molto più veloce di una doppia fila di icone con un bordino di un pixel, minuziosamente applicato, che le separa dal bordo dello schermo.

indice ↑

Oggetti dell'interfaccia utente

Gli oggetti dell'interfaccia utente non sono necessariamente gli stessi oggetti che si incontrano nei sistemi orientati agli oggetti. Questi oggetti includono di solito cartelle, documenti e cestini della spazzatura. Compaiono nell'ambiente d'uso dell'utente e possono o meno essere associati direttamente a oggetti object-oriented. Di fatto, molte delle prime GUI furono costruite interamente in ambienti non ad oggetti.

* Gli oggetti dell'Interfaccia utente possono essere visti, sentiti, toccati o altrimenti percepiti

* Gli oggetti di interfaccia utente che possono essere visti sono abbastanza familiari nelle interfacce grafiche. Oggetti che si rivolgono a un altro senso, come all'udito o al tatto, sono meno familiari. Un buon lavoro è stato svolto nello sviluppo di icone uditive (Gaver)

* Gli oggetti di interfaccia utente hanno modalità standard di interagire

* Gli oggetti di interfaccia utente hanno di conseguenza comportamenti standard

* Gli oggetti di interfaccia utente dovrebbero essere comprensibili, consistenti e stabili.

indice ↑

Riduzione del tempo di Latenza

*Quando possibile utilizzate il multi-thread per confinare i tempi di latenza in background.

I tempi di latenza possono essere spesso nascosti agli utenti usando tecniche di multitask, lasciando che loro continuino al lavorare mentre trasmissioni e processi si svolgono in background.

* Riducete il tempo di attesa dell'utente:

  • Date un riscontro visivo o uditivo di tutti i click sui bottoni entro 50 millisecondi.
  • Mostrate una clessidra ogni volta che un'azione impiega da mezzo secondo a due secondi.
  • Mostrate un messaggio che indichi la lunghezza dell'attesa per qualisasi azione che impieghi più di due secondi a finire.
  • Comunicate l'effettiva lunghezza attraverso una progress bar.
  • Offrite messaggi di interesse per gli utenti, per informarli e intrettenerli intanto che attendono affinchè una lunga procedura lunga termini
  • Producete un beep e offrite un'indicazione visiva chiara e rilevante al termine di procedure lunghe (> 10 secondi), così che gli utenti sappiano quando possono tornare a usare il sistema.
  • Impedite il click multiplo dello stesso bottone o dello stesso oggetti. Siccome Internet è lenta, le persone tendono a premere lo stesso bottone più volte, causando un ulteriore rallentamento

* Rendete tutto più veloce

Eliminate ogni elemento di interfaccia che non sia di aiuto. Siate spietati.

indice ↑

Apprendimento

Idealmente i prodotti non dovrebbero avere una curva di apprendimento: gli utenti dovrebbero sin dalla prima volta mostrare una padronanza immediata. Nella pratica, tutti i prodotti e i servizi, non importa quanto semplici, mostrano una curva di apprendimento.

* Limitate i compromessi

Usabilità e apprendimento non sono mutuamente esclusivi. Prima decidete quale sia dei due il più importante, poi cercate di fare il meglio su entrambi. Semplicità di apprendimento come conseguenza della semplicità di utilizzo è un mito.

indice ↑

Uso delle Metafore

* Scegliete le metafore bene. Le metafore aiutano gli utenti a cogliere immediatamente anche i dettagli più minuti del modello concettuale.

Le metafore buone sono storie che lasciano immagini nella mente

* Fate vivere le metafore rivolgendovi alla vista, all'udito, al tatto, ad aspetti cinestetici che possano innescare ricordi negli utenti

Le metafore invocano elementi familiari, ma spesso aggiungono distorsioni. Per esempio, Windows 95 ha un oggetto chiamato briefcase (cartelletta). Come le cartellette nel mondo vero, il suo scopo è di rendere i documenti elettronici più portabili. Il briefcase di Windows 95 non agisce però come un meccanismo di trasporto, ma come uno di sincronizzazione. I documenti nel briefcase sulla scrivania e quello sul device rimovibile sono aggiornati automaticamente quando il device rimovibile è collegato nel computer.

indice ↑

Proteggere il lavoro dell'utente

* Assicuratevi che gli utenti non perdano mai il proprio lavoro a causa di un errore da parte loro, dalle bizze della connessione ad Internet, o altre ragioni che non siano completamente inevitabili, come l'improvvisa mancanza di corrente al computer.

(Anche in questo caso comunque, non ci sono scusanti per il fatto che i moderni computer e sistemi operativi non supportino ed incoraggino l'uso di sistemi di continuità. Unito a una piccola parte di memoria protetta potrebbe eliminare l'imbarazzo di offrire macchine da 5000 dollari che offrono la stessa affidabilità di giocattoli da 10 centesimi).

indice ↑

Leggibilità

* Il testo che deve essere letto dovrebbe avere un alto contrasto. Scegliete di preferenza testi in nero su sfondi bianchi o giallini. Evitate sfondi grigi.

* Usate una dimensione dei font che sia sufficientemente grande da rendere semplice la lettura su monitor standard. In particolare usate font grandi per i dati che volete mostrare, più che per etichette o istruzioni. Per esempio l'etichetta "cognome" può anche essere abbastanza piccola. Gli utenti abituali impareranno a riconoscere che un ammasso grigio di una parola con quella forma dice "cognome" . Anche gli utenti ai primi utilizzi, dato il contesto della forma in cui il testo compare, indovineranno facilmente che si tratta di "cognome". Il cognome inserito dall'utente invece dovrebbe essere molto leggibile. Questo concetto diventa ancora più importante se si parla di numeri. Le parole hanno un certo grado di ridondanza, il che consente alle persone di correggere messaggi non perfettamente intelleggibili. I numeri, a meno che non seguano un protocollo ben definito, non hanno ridondanza; gli utenti devono quindi poterne leggere ogni singola cifra.

* Siate particolarmente propensi a capire i bisogni delle altre persone. Presbitismo - condizione in cui si trova un occhio con una lente indurita e poco flessibile, unita alla diminuita trasmissione della luce all'occhio - colpisce molte persone oltre i 45 anni. Non fidatevi dei vostri giovani occhi per prendere decisioni sulle dimensioni dei caratteri e sul contrasto.

indice ↑

Tracciamento dell'avanzamento

* Siccome molte delle nostre applicazioni browser-based esistono in un ambiente senza stati, abbiamo la responsabilità di tracciare lo stato quando c'è bisogno.

Potremmo aver bisogno di sapere:

  • Se è la prima volta che l'utente si trova sul sistema
  • dove si trova l'utente
  • dove vuole andare l'utente
  • dove è stato l'utente durante la sessione
  • dove si trovava l'utente quando ha abbandonato la precedente sessione

e migliaia di altri dettagli.

In aggiunta a sapere semplicemente dove sono stati potremmo anche fare buon uso di quello che hanno fatto.

* Le informazioni di stato dovrebbero essere conservate in un cookie sulla macchina dell'utente durante una transazione/sessione, e successivamente immagazzinate sul server quando l'utente abbandona la sessione.

Gli utenti dovrebbero essere in grado di abbandonare la sessione in ufficio, andare a casa, e continuare esattamente dal punto in cui avevano lasciato.

Un servizio privato per dottori, Physicians On Line, fa un lavoro eccellente da questo punto di vista. I dottori possono svolgere il 95% del lavoro su una transazione completa, uscire dal sistema, rientrarvi sei settimane più tardi da un'altra parte del mondo e il servizio chiede loro immediatamente se vogliono proseguire da dove avevano lasciato.

indice ↑

Interfacce visibili

* Evitate navigazioni invisibili

La maggior parte degli utenti non svilupperà eleborate mappe mentali e si sentirà perso e stanco se il sistema si aspetta che lo faccia.

Il World Wide Web, a causa di tutti i suoi schermi e bottoncini è in effetti uno spazio di navigazione invisibile. E' vero, tutto ciò che c'e' su una pagina si può vedere, ma non si può vedere nulla del vasto spazio che c'è tra le pagine. Una volta che un utente ha raggiunto la nostra applicazione, dovremmo ridurre la navigazione al minimo indispensabile e far si che quella che rimane sia chiara e naturale. Offrite l'illusione che gli utenti siano sempre nello stesso posto e che il lavoro sia portato a loro. Questo non solo elimina il bisogno di mappe o altri aiuti alla navigazione, offre anche un grande senso di padronanza e autonomia.

Così come per l'inerente natura stateless del Web (vedi la sezione precedente: tracciamento dell'avanzamento), il nostro lavoro non si limita ad accettare acriticamente il sistema, ma implica offrire quello strato di protezione e potenzialità di cui gli utenti hanno bisgono. Il fatto che la navigazione su Web sia invisibile è una sfida, non un fatto inevitabile da accettare.

indice ↑

Altre traduzioni:

indice ↑

Segnalazioni

Se hai cercato questo articolo probabilmente sei anche interessato a: corso di information design



indice ↑

Ringraziamenti

L'articolo è stato da poco tradotto. Se trovate qualche errore scrivete per cortesia a 10people

Ringraziamo per le correzioni: