È un po’ che ho in mente di scrivere questo post: quante volte malediciamo i nostri utenti perché quando qualcosa va storto ti dicono: “non funziona” e quanto chiedi educatamente se si ricordano il messaggio di errore la risposta è quasi sempre negativa.
Ma è sempre colpa loro? Io credo che molte volte si trascuri l’aspetto di user experience nella gestione degli errori, si fa presto a scrivere un:
catch (Exception ex)
{
var md = new MessageDialog(ex.Message);
var result = md.ShowAsync();
}
Ma il risultato non è sempre alla portata di tutti:
Brutta bestia il MessageDialog o MessageBox usato in una catch, ma è quello si usa molto spesso: che fare quindi? Prima di tutto è bene sostituire i messaggi di sistema, che sono pensati per fornire informazioni di debug allo sviluppatore ma non per essere visualizzati all’utente. Gli errori devono essere semplici, di facile comprensione e memorizzazione, per esempio:
- Errore di rete;
- Accesso negato;
- Manca la carta nella stampante;
- Non riesco a salvare;
Evitare di usare parole come memoria (gli utenti non sanno mai se si tratta di RAM o di storage), database (questo misterioso) o altri tecnicismi che potrebbero confondere l’utente.
Salvare gli errori di sistema in un log al quale l’utente potrà accedere su richiesta del tecnico di help desk, con un comando apposito.
Evitare le dialog: è incredibile come le dialog vengano sistematicamente ignorate dagli utenti. In caso di errore visualizzare l’informazione in modo evidente nell’interfaccia utente e se necessario disabilitare comandi che potrebbero generare altri errori.
Questo è un esempio di come ho implementato la gestione degli errori:
Debbo dire che l’esperienza ha dimostrato che anche in caso di problemi l’utente è sempre in grado di comunicare correttamente l’errore riportato.