In realtà questa domanda riguarda le precauzioni da adottare per migliorare l'esperienza utente di qualità e ridurre le chiamate di supporto evitabili.
La mancanza di una corretta convalida dell'input è una di quelle cose che tende a portare abbastanza rapidamente gli utenti a fare cose "cattive" con l'applicazione, quando dovrebbe essere gestita dal programmatore.
Ho visto app legacy in cui gli utenti sono stati addestrati a:
a-z0-9,
email , altrimenti i successivi messaggi di posta elettronica a quell'utente utilizzeranno tutto ciò che è presente nel campo e falliranno http:// " sia messo prima degli indirizzi web etc etc
Tutti i problemi precedenti sono quelli che dovrebbero essere gestiti da uno sviluppatore di applicazioni. Quando la convalida dell'input è essenzialmente "assicurati che l'utente sappia in che formato deve essere inserito questo campo e credi che ciò che hanno inserito sia giusto", allora le cose inaspettate sono destinate a trovare la loro strada verso l'app. A parte le ovvie implicazioni sulla sicurezza, gli utenti commettono errori. Come programmatori spesso produciamo i nostri migliori prodotti piegandoci all'indietro per assicurarci che l'utente non possa sbagliarlo, non importa quanto duramente provino!
Una volta ho ricevuto una chiamata di assistenza clienti perché la mia app è scomparsa. Alla fine hanno aperto un'altra app su di essa.
... Ho deciso di non garantire che non si ripetesse, dal momento che era l'analfabetismo degli utenti a causare il problema, non l'app. Qualsiasi cosa avrei potuto fare per risolverlo avrebbe portato a 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 nate come interfacce CLI e sono rapidamente diventate qualcosa di più shell di qualsiasi altra cosa.
Quindi, posso parlare solo per quello che so. Ecco alcuni problemi comuni con i programmi della 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 uno schermo completo su un buffer di frame 80x25 quando viene passato --help o /? . È perfettamente bene avere più opzioni di quelle, ma dividerle in sottocategorie. Ad esempio
foo --help
foo --help option_name
Nessuna opzione lunga
È molto più facile ricordare foo --attach_to [argument] --volatile --verbose che 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 veritiere 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 segfaults o divide per zero a causa di qualcosa fornito da un utente, è semplicemente imbarazzante.
Potresti non aver bisogno di qualcosa di complesso come un lexer, forse puoi semplicemente sincronizzare la stringa se ti aspetti qualcosa in un certo ordine con certe cose in certi punti.
In realtà ho ricevuto una segnalazione di bug una volta in cui era previsto un numero intero e qualcuno ha digitato f*** my life tra virgolette. Non ho scritto quel programma, ho avuto la sfortuna di ereditarlo.
Nessuna manopola 'verbocity'
Permetti agli utenti esperti di scoprire facilmente come ottenere più rumore dal tuo programma rispetto a quanto la maggior parte delle persone tollererebbe, ma di default stamperà solo cose serie e critiche. Non posso dirti quante volte ho dovuto aumentare strace solo per rendermi conto che qualcosa era segfault perché funzionava su un flusso di file NULL.
Puoi anche racchiudere le asserzioni in modo che spegnerle tramite NDEBUG o altri mezzi continui a produrre qualcosa di stampato o registrato che l'utente possa trovare.
Parlando di file di log, cerca di assicurarti che qualsiasi cosa tu inserisca in loro (almeno un po ') senso a 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à di debug
Molti programmi offrono una sorta di interruttore di 'debug' che offre ulteriori chatter riguardo a cosa sta succedendo con il programma, ma pochissimi offrono quanto segue:
Oppure, forse ti piace sentire le persone leggere quanto segue al telefono:
It says unexpected condition at zero eff oh four zero oh .... OK lemme read that back to you ...
File di configurazione eccessivamente complessi
Non giustifica la necessità di analizzare una configurazione come una scusa per ottenere un ronzio su un sacco di zucchero sintattico. Cerca di utilizzare un formato che le persone conoscono realmente, anche se ciò comporta un lavoro extra durante l'analisi. Cerco di utilizzare il formato di stile INI quando possibile. Saresti stupito di ciò che puoi ottenere con un semplice dizionario di chiavi e valori.
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 sia stato concepito 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 "pavimento bagnato"
Se alcune funzionalità potrebbero mettere l'utente nei guai (forse è lì per gli utenti avanzati), contrassegnarlo chiaramente come tale. Inoltre, se qualcuno ingrassa le dita o dimentica qualcosa, chiedi al programma di stampare un link molto amichevole alla documentazione online. Potresti avere a che fare con qualcuno che sta usando il tuo programma tramite KVM e non puoi tagliare e incollare.
Se possibile, (questo coincide con la convalida dell'input) usa il Google apporach:
Did you mean foo --bar FILENME, you typed only foo --bar
Offri una via d'uscita da istruzioni distruttive
L'obiettivo è dire all'utente perché non ha funzionato e farli provare qualche altra volta, assicurandosi di non fare nulla di potenzialmente distruttivo a meno che non sembri che l'utente voglia davvero che tu lo faccia. Consenti a un interruttore di disattivare "fastidioso", ad esempio -Y o /Y , ma in caso contrario consentire una via d'uscita per qualcuno che ha semplicemente "dita grasse".
Probabilmente sto dimenticando alcune indicazioni. Mi occupo di questo spesso perché è molto, molto difficile rendere l'interfaccia di "basso livello" per qualcosa di abbastanza intuitivo da impedire alla maggior parte delle persone di commettere errori.
"Sei sicuro di voler cancellare questo file / record? Sì / No". Ha fatto clic su Sì e poi ha ricevuto una chiamata per cui "erroneamente" ha fatto clic sul pulsante di eliminazione rosso e ha bisogno di tali dati:)
Non ho voglia di ottenere esempi specifici di interruzioni / correzioni tanto importanti quanto la realizzazione di questo:
Se attraverso quell'esplorazione rompono qualcosa, come programmatore è il tuo compito o avvertirli del pericolo o impedire che accada in primo luogo. Non riesco a ricordare dove l'ho visto ora, ma nella parte posteriore della mia mente cerco sempre di " fare la cosa giusta facile " per l'utente del mio software .
Se insisti sugli esempi:
Vedi dove sta andando? :)
Ecco uno che ho sentito questa settimana. Un utente richiede una funzionalità "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 stai 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. Cosa dovrei fare con esso?".
Mi sono ricordato di questo fumetto di Dilbert e ho suggerito allo sviluppatore di "scrivere un'app per capire cosa l'utente dovrebbe fare con quella notifica".
Come ha detto mpeterson, l'utente è molto competitivo nella sua area di competenza. Semplicemente non pensano come uno sviluppatore di software o un designer.
Non penso che gli utenti siano stupidi. Non vogliono affatto usare il tuo o qualsiasi programma. Tutto ciò che vogliono è ottenere le loro cose. Aiutali e previeni che si verifichino dei danni lungo il percorso.
Avere una buona interfaccia utente e fornire un'esperienza di apprendimento adeguata è molto importante per impedire agli utenti di fare cose cattive.
Buone interfacce utente dovrebbero essere attrito.
Invece di aprire una finestra di dialogo (un'operazione costosa e ignorata dopo un po 'dagli utenti) per confermare l'eliminazione, eseguire l'eliminazione e offrire un modo per annullare.
Buone interfacce utente dovrebbero essere rilevabile.
Sebbene la barra multifunzione di Microsoft Office ottenga un sacco di critiche perché costringe i vecchi utenti di Word a cambiare i loro modi, la barra multifunzione è un brillante esempio di come è possibile rendere l'interfaccia rilevabile (ovvero facile da scoprire).
Buone interfacce utente, come un buon codice, dovrebbe essere auto-esplicativo.
Nessuno legge il manuale. L'unico manuale che abbia mai letto per i miei utenti era una presentazione di PowerPoint contenente procedure dettagliate del software. Ho visto questi fatti con strumenti video come Camtasia, ma i PowerPoint sono migliori perché puoi facilmente capovolgere avanti e indietro attraverso i passaggi.
L'utente non commette errori. Gli errori riguardano il programmatore che non è riuscito a creare un'interfaccia utilizzabile.
Quindi fai test di usabilità con ogni versione!
Leggi altre domande sui tag bug maintenance user-experience