Si è verificato un errore sconosciuto

Molti dei fortunati (o sfortunati, dipende dai punti di vista) che hanno acquistato un Iphone lo scorso Venerdì hanno riscontrato diversi problemi in fase di attivazione.

La causa è stata il carico dei server oppure qualcosa che non ha funzionato nel software di verifica del sito. Sarebbe bene che situazioni come questa non accadessero mai, ma sono convinto che per quanti test vengano compiuti, la realtà sia sempre più complessa.

Mi lascia però perplesso la superficialità con cui spesso vengono gestite le condizioni di errore. Il messaggio restituito a video era:

Non posso completare la richiesta ITunes Store. Si è verificato un errore sconosciuto (-9838).

Una risposta come questa è inaccettabile, perché

  • non permette all’utente di capire se il problema è nell’Iphone o nel processo di attivazione
  • non indica se si tratti di un problema momentaneo (il server è troppo carico) o permanente
  • è inutile sotto ogni punto di vista (sconosciuto? -9838 ?)
Una delle cattive abitudini nello sviluppo del software è che la gestione dei messaggi di errore viene spesso lasciata per ultima. Tanto andrà sempre tutto per il meglio, giusto?

Risparmiare sui messaggi di errore

L’intervento di Jared Spool su User Interface Engineering sottolinea, se ancora ce ne fosse bisogno, la necessità di progettare form che siano (realmente) usabili.

E’ frequente trovarsi di fronte a form, come quello riportato da Spool, in cui sia possibile evidenziare non uno, ma diversi errori di design.

Form con la scritta: !The ZIP that you entered doesn’t match the City/State you entered. Please verify the information.

Quello che mi ha colpito dell’intervento è stato però il titolo, “Being cheap with error messages”, cioè risparmiare sui messaggi di errore.

Sì, perché quello che molto spesso succede è che già dalla fase di wireframing, di creazione delle bozze, la gestione degli errori nell’interfaccia non venga considerata, perché “tanto al cliente non interessa vedere cosa succede quando l’utente sbaglia o c’è qualche problema”.

Questo atteggiamento prosegue nelle altre fasi di progetto, fino ad arrivare in produzione dove, a meno di trovare qualche programmatore con buone competenze sull’usabilità delle interfacce (e ce ne sono, per fortuna), alla gestione degli errori viene riservato l’ultimo quarto d’ora prima dei test.

Per quella che è la mia esperienza, solo se fin dalle prime bozze è stato previsto di gestire con qualità gli errori, c’è qualche probabilità che questa situazione venga mantenuta fino alla messa online del sito. Proprio meglio non risparmiare in questo caso.

Compatibilità plugin e WordPress 2.3

Visti i numerosi interventi che sto dedicando in questi giorni a WordPress 2.3, non è difficile capire che mi stia attrezzando per la migrazione di Fucinaweb.

Avevo addirittura pensato di uscire con il nuovo volto di Fucinaweb già usando una beta di WordPress 2.3, ma i tanti cambiamenti al cuore del prodotto, uniti a diversi errori riscontrati, mi hanno fatto presto desistere.

Uno degli argomenti caldi è, come sempre, la compatibilità con gli attuali plugin. Se anche voi siete curiosi di scoprire quali plugin, oggi, sono compatibili con WordPress 2.3, può senza dubbio tornare utile la pagina dedicata dal codex, che contiene un elenco puntuale in costante aggiornamento.

Stai leggendo uno di una serie di interventi dedicati a WordPress 2.3.