Storico revisioni

1. Introduzione

Durante l’analisi/sviluppo di quella che sarà l’interfaccia con l’utente finale, bisognerà tener conto di tutte quelle problematiche che riguardano le incomprensioni, che si possono verificare, durante l’interazione programma – utente. In tale ambito, è necessario impedire che le informazioni mostrate siano ambigue, o che comunque possano indurre l’utente a compiere azioni non coerenti.

Durante questa fase sarà sponteneo porsi domande come:

• l’utente comprenderà “sempre” le informazioni mostrate?
• l’utente comprenderà cosa può o non può fare ?

Tali domande ci permettono di intuire una problematica piuttosto complessa, data l’elevata varietà di casistiche.

Un buon approccio alla risoluzione del problema può essere dato dall’uso di un’auto-regolamentazione abbastanza generica da adattarsi alle varie casistiche.

2. Analisi

L’iterazione programma – utente può essere semplificata in:

1) Il programma mostra delle informazioni all’utente.

2) In base ai dati mostrati, l’utente può compiere delle azioni, queste azioni vengono interpretate dal programma, il quale fornisce nuove informazioni, ritornando al punto 1.

2.1 Tipologie d’azione

Le azioni possono essere, essenzialmente, di questo tipo:

• Coerenti nel contesto.Ricadono in questa casistica tutte quelle azioni più o meno previste dal programma stesso: Es.: Azioni come salva, annulla, chiudi. Pur essendo operazioni coerenti, possono essere dannose per il nostro sistema. Es.: Una semplice operazioni di salvataggio di dati potrebbe inavertitamente sovrascrivere dati pre-esistenti. Oppure annullare la modifica, comporterà l’inevitabile perdità di dati inseriti.
• Non coerenti nel contesto.Talvolta ostiche da trattare, ma se seguiamo le leggi di murphy, tutto rientra nella norma. Ricadono in questa tipologia tutte quelle azioni che “non dovrebbero accadere” ma normalmente accadono. Ne elenco alcune:
  • Inserire una data non corretta.
  • Annullare dei dati appena modificati. Sebbene questa potrebbe essere un’azione coerente, è allo stesso tempo incoerente quando l’utente annulla “per sbaglio” le modifiche. E credetemi, succede spesso.
  • ecc.

In entrambi i casi bisognerà prendere delle precauzioni.

3. Un possibile approccio

Supponiamo di avere una semplice form per il data entry ,ed analizziamo i possibili scenari.

3.1 Azioni coerenti

A seconda dell’azione, “guideremo” l’utente verso l’operazione meno “dannosa”.

3.1.1 Salva

Salva, in questo caso si hanno due scenari. L’operatore sta inserendo dei nuovi dati. L’operatore sta modificando dei dati esistenti.

3.1.2 Annulla

3.1.3 Chiudi

Tale azione si comporterà analogamente al tasto annulla.

3.2 Azioni non coerenti

3.2.1 Validazione dei dati

Parte delle azioni non coerenti vengono controllate durante la validazione dei dati. Che consiste nel informare l’utente che i dati inseriti non sono corretti. Tale informazione deve risultare quanta più esplicita possibile. Bloccare il focus su un campo risulta al tempo stesso irritante quanto inutile. L’utente sarà più predisposto ad “irritarsi” perché il “programma si è bloccato” (il cursore non si sposta dal campo) piuttosto che cercare di capire cosa è successo e cosa ha sbagliato. Una buona strategia potrebbe essere quella di evidenziare con visivamente il campo contenente dati errati (ad esempio utilizzando un colore diverso) e riepilogare l’elenco degli errori presenti al momento dell’operazione di salvataggio dei dati.

3.3 Alcune norme

Per guidare in modo agevole l’utente verso “la giusta” strada. Sarà buona norma cercare di aderire – per quanto possibile – ai seguenti concetti:

• Azione di default.
• Possibilità di annullare.
• Regolamentazione del frasario.

3.3.1 Azione di Default

Per default, si intende, quell’azione associata al tasto di conferma – di solito il tasto invio -. Al quale sarà sempre associata l’azione meno “rischiosa”. Es.: Se l’azione guida verso un’alterazione o una perdita di dati, ad esempio un aggiornamento o un cancellazione, sarà buona norma avere come default l’annullamento dell’operazione, cfr. figura 2.

3.3.2 Annullamento

Per quanto possibile bisognerà fornire l’utente della possibilità di annullare l’operazione. Ad esempio, durante un operazione di chiusura di una schermata, ci accorgiamo che i dati sono stati variati, ma l’utente non li ha salvati. Quindi diamo all’utente la possibilità di salvare i dati prima di uscire (come in figura 2). Tuttavia, se l’utente ha avviato l’operazione di chiusura per sbaglio? Oppure non ha modificato tutti i dati ? Quindi, sarà buona norma aggiungere l’opzione “Annulla”, che permetterà di annullare l’operazione (come in figura 2).

3.3.3 Frasario

E’ consigliabile usare durante l’interazione con l’utente: lo stesso frasario, la stessa nomenclatura, etc. Ad esempio: Se utilizziamo, in una popup, una frase del tipo: “Si desidera sovrascrivere i dati ?” (con predefinito “no”). Non è corretto utilizzare, in altre popup, frasi come: “Annullare la sovrascrittura dei dati?” (con predefinito su “si”). Questo non farà altro che portare in confusione l’utente, ed aumentare la possibilità di errori. E’ bene prevedere che l’utente non sempre leggerà attentamente il messaggio, e sarà portato a premere instintivamente il tasto che preme di più.

4. Conclusioni

Come abbiamo visto, la casistica è molto vasta e il nostro “utente generico” è veramente bravo a combinare guai. Utilizzare approcci troppo restrittivi non aiutano a risolvere la problematica, quindi l’utilizzo di un approccio – omogeneo nell’intera applicazione – semplice che riduca il rischio di perdita di dati e adotti una comunicazione semplice con l’utente.