Quali errori commettono i tuoi utenti e come puoi aggiornare la tua applicazione per gestirli? [chiuso]

In realtà questa domanda riguarda le precauzioni da prendere per migliorare l'esperienza dell'utente di qualità e ridurre le chiamate di supporto evitabili.

La mancanza di un'adeguata convalida dell'input è una di quelle cose che tende a condurre abbastanza rapidamente agli utenti che fanno cose "cattive" con la propria applicazione, quando dovrebbe essere realmente gestita dal programmatore.

Ho visto app legacy in cui gli utenti sono stati addestrati a:

• non inserire apostrofi nei nomi
• non inserire simboli diversi da a-z0-9,
• assicurarsi che non vi siano spazi prima o dopo il testo che hanno inserito
• verifica che nel emailcampo sia inserito un indirizzo e-mail correttamente formattato , altrimenti i successivi invii a quell'utente useranno qualunque cosa sia presente nel campo e falliranno
• assicurati che " http://" sia inserito prima degli indirizzi web

ecc ecc

Tutti i problemi di cui sopra sono quelli che dovrebbero essere gestiti da uno sviluppatore di applicazioni. Quando la convalida dell'input è essenzialmente "assicurati che l'utente sappia in quale formato deve essere questo campo e che si fidi che ciò che ha inserito sia giusto", allora le cose inaspettate sono destinate a trovare l'app. A parte le ovvie implicazioni sulla sicurezza, gli utenti commettono errori. Come programmatori produciamo spesso i nostri migliori prodotti piegandoci all'indietro per assicurarci che l'utente non possa sbagliare, non importa quanto ci provi!

Una volta ho ricevuto una chiamata all'assistenza clienti perché la mia app è appena scomparsa. Si è scoperto che hanno aperto un'altra app sopra di essa.

... Ho deciso di non assicurarmi che ciò non accadesse di nuovo, poiché era l'analfabetismo informatico degli utenti a causare il problema, non l'app. Tutto ciò che avrei potuto fare per risolverlo avrebbe portato ad una scarsa esperienza utente per gli altri.

Quasi tutti i programmi che scrivo sono invocati rigorosamente dalla riga di comando. Ho anche scritto alcune cose più fantasiose che sono iniziate come interfacce CLI e sono rapidamente cresciute in qualcosa di più simile a una shell.

Quindi, posso parlare solo per quello che so. Ecco alcuni problemi comuni con i programmi da riga di comando:

Troppe opzioni

A meno che non si stia scrivendo un compilatore o un editor di riga, provare a mantenere le opzioni limitate a una schermata piena su un frame buffer 80x25 quando --helpo /?viene passato. Va benissimo avere più opzioni di così, ma suddividerle in sottocategorie. Per esempio

foo --help

foo --help option_name

Nessuna opzione lunga

È molto più facile da ricordare foo --attach_to [argument] --volatile --verboseche da ricordare foo -a [arg] -v +V. Questo non è sempre possibile, ma nella maggior parte dei casi lo è.

Nessuna convalida dell'input

Quasi ogni piattaforma ha più librerie che sono provate, testate e vere quando si tratta di analizzare e validare argomenti. Quasi ogni piattaforma ha un lexer provato, testato e vero che convalida l'input da una CLI. Usa uno, l'altro o entrambi. Se il tuo programma segfault o si divide per zero a causa di qualcosa fornito da un utente, è solo imbarazzante.

Potresti non aver bisogno di qualcosa di complesso come un lexer, forse puoi semplicemente tokenizzare la stringa se ti aspetti cose in un certo ordine con determinate cose in determinati luoghi.

In realtà ho ricevuto una segnalazione di bug una volta in cui era previsto un numero intero e qualcuno digitava le f*** my lifevirgolette. Non ho scritto quel programma, ho avuto la sfortuna di ereditarlo.

Nessuna manopola "verbocity"

Consenti agli utenti esperti di scoprire facilmente come ottenere più rumore dal tuo programma di quanto la maggior parte delle persone tollererebbe, ma per impostazione predefinita stampa solo materiale serio e critico. Non posso dirti quante volte ho dovuto accendermi stracesolo per rendermi conto che qualcosa si è interrotto perché operava su un flusso di file NULL.

Puoi anche racchiudere le asserzioni in modo che disattivarle tramite NDEBUG o altri mezzi comporti comunque qualcosa stampato o registrato che l'utente possa trovare.

Parlando di file di registro, cerca di assicurarti che qualsiasi cosa tu inserisca in essi (almeno un po ') abbia senso per qualcuno diverso da te. Se l'inizio di ogni voce è una data di epoca UNIX, aumenterai la frustrazione in qualcuno che vuole davvero aiutarti a riprodurre il bug.

Nessun "bug buddy" in modalità debug

Molti programmi offrono una sorta di 'debug' switch che offre chiacchiere extra riguardo a ciò che sta succedendo con il programma, ma pochissimi offrono quanto segue:

• Un modo per inviare automaticamente un rapporto tramite HTTP / HTTPS e ottenere un numero di riferimento del servizio
• Un modo per scaricare informazioni utili su un file che potrebbe essere inviato come allegato a una richiesta di supporto

O forse ti piace sentire le persone leggere al telefono quanto segue:

Dice condizioni inattese a zero eff oh quattro zero oh .... OK, lasciami leggere ...

File di configurazione troppo complessi

Non giustificare la necessità di analizzare una configurazione come scusa per ottenere un ronzio su un sacco di zucchero sintattico. Prova a utilizzare un formato che le persone conoscono effettivamente, anche se ciò significa un lavoro extra durante l'analisi. Cerco di utilizzare il formato di stile INI quando possibile. Saresti sorpreso di ciò che puoi realizzare con un semplice dizionario chiave-> valore.

Nessun file di configurazione

Non fare in modo che le persone scrivano script di shell o file batch solo per usare il tuo programma, a meno che non fosse inteso come uno strumento per entrambe le attività. Dammi un mezzo per indicare un file contenente le mie solite opzioni e fornire solo alcuni argomenti aggiuntivi.

Nessun segno di "pavimento bagnato"

Se alcune funzionalità potrebbero mettere nei guai l'utente (forse è lì per utenti esperti), contrassegnalo chiaramente come tale. Inoltre, se qualcuno inserisce o dimentica qualcosa, è necessario programmare un collegamento molto amichevole con la documentazione online. Potresti avere a che fare con qualcuno che sta usando il tuo programma tramite KVM e non può tagliare e incollare.

Quando possibile, (questo coincide con la convalida dell'input) utilizzare l'apporach di Google:

Intendevi foo - bar FILENME, hai digitato solo foo - bar

Offrire una via d'uscita da istruzioni distruttive

L'obiettivo è quello di dire all'utente perché non ha funzionato e di fargli provare altre volte, assicurando al contempo di non fare nulla di potenzialmente distruttivo a meno che non sembri che l'utente lo desideri davvero. Consentire un interruttore che disattiva il "fastidio", ad esempio -Yo /Yma altrimenti consentire una via d'uscita per qualcuno che ha semplicemente "dita grasse".

Probabilmente sto dimenticando alcuni suggerimenti. Mi occupo spesso di questo dato che è molto, molto difficile rendere l'interfaccia di "basso livello" per qualcosa di abbastanza intuitivo da evitare che la maggior parte delle persone commetta errori.

"Sei sicuro di voler eliminare questo file / record? Sì / No". Facendo clic su Sì, quindi ho ricevuto la chiamata che "erroneamente" ha fatto clic sul pulsante rosso di eliminazione e ha bisogno di quei dati indietro :)

Non mi sembra che ottenere esempi specifici di interruzioni / correzioni sia importante quanto realizzare questo:

• Gli utenti non leggono il tuo manuale o guardano i tuoi tutorial. Imparano il tuo software attraverso l'esplorazione.

Se attraverso quell'esplorazione rompono qualcosa, come programmatore è il tuo compito o avvertirli del pericolo o impedire che ciò accada in primo luogo. Non ricordo dove l'ho visto ora, ma nella parte posteriore della mia mente cerco sempre di " rendere facile fare la cosa giusta " per l'utente del mio software.

Se insisti su esempi:

• L'utente è stato in grado di inserire un nome minuscolo che ha interrotto il codice di integrazione / corretto eseguendo la convalida dell'input
• L'utente è stato in grado di fare clic sul pulsante sbagliato dopo aver eseguito un'azione / risolto mostrando solo i pulsanti corretti.
• L'utente è stato in grado di eseguire X per errore / risolto avvertendoli che stanno per eseguire X.

Vedi dove sta andando? :)

Eccone uno che ho sentito questa settimana. Un utente chiede una funzione "inviami una notifica quando si verifica un evento". Abbastanza semplice e lo sviluppatore va avanti e lo implementa. Certo, la prima domanda avrebbe dovuto essere "cosa stanno cercando di affrontare con questa notifica?". Non entrerò in quello. Pochi giorni dopo l'utente si ferma dallo sviluppatore e chiede "Ho ricevuto questa notifica. Che cosa dovrei farne?".

Ho ricordato questo fumetto di Dilbert e ho suggerito allo sviluppatore "scrivere un'app per capire cosa dovrebbe fare l'utente con quella notifica".

Come ha detto mpeterson, l'utente è molto competitivo nella sua area di competenza. Semplicemente non pensano come uno sviluppatore o designer di software.

Non penso che gli utenti siano stupidi. Non vogliono affatto usare il tuo o nessun programma. Tutto quello che vogliono è fare le loro cose. Aiutali e previeni che si verifichino danni lungo il percorso.

Avere una buona interfaccia utente e fornire un'esperienza di apprendimento adeguata aiuta molto a impedire agli utenti di fare cose cattive.

• Le buone interfacce utente dovrebbero essere prive di attrito.

  Invece di aprire una finestra di dialogo (un'operazione costosa e che gli utenti ignorano dopo un po ') per confermare l'eliminazione, eseguire l'eliminazione e offrire un modo per annullare.

• Le buone interfacce utente dovrebbero essere rilevabili.

  Anche se la barra multifunzione di Microsoft Office ha molti difetti poiché costringe i vecchi utenti di Word a cambiare strada, la barra multifunzione è un brillante esempio di come è possibile rendere un'interfaccia rilevabile (ovvero facile da scoprire).

• Le buone interfacce utente, come il buon codice, dovrebbero essere autoesplicative.

  Nessuno legge il manuale. L'unico manuale che ho mai potuto far leggere ai miei utenti era una presentazione di PowerPoint contenente procedure dettagliate del software. Ho visto questi fatti con strumenti video come Camtasia, ma i punti di forza sono migliori perché puoi facilmente scorrere avanti e indietro attraverso i passaggi.

L'utente non commette errori. Gli errori risiedono nel programmatore che non è riuscito a creare un'interfaccia utilizzabile.

Quindi fai test di usabilità con ogni versione!