De hecho, esta pregunta trata sobre las precauciones que deben tomarse para mejorar la experiencia del usuario de calidad y reducir las llamadas de soporte evitables.
Respuestas:
La falta de una validación de entrada adecuada es una de esas cosas que tiende a llevar rápidamente a los usuarios a hacer cosas "malas" con su aplicación, cuando realmente debería ser manejada por el programador.
He visto aplicaciones heredadas donde los usuarios han sido capacitados para:
a-z0-9,emailcampo, de lo contrario, los correos posteriores a ese usuario usarán lo que esté en el campo y fallaránhttp://" se coloca antes de las direcciones webetcétera etcétera
Todos los problemas anteriores son los que deben ser manejados por un desarrollador de aplicaciones. Cuando su validación de entrada es esencialmente "asegúrese de que el usuario sepa en qué formato debe estar este campo y confíe en que lo que ha ingresado es correcto", entonces cosas inesperadas seguramente encontrarán su camino hacia la aplicación. Además de las obvias implicaciones de seguridad, los usuarios cometen errores. Como programadores, a menudo producimos nuestros mejores productos inclinándonos hacia atrás para asegurarnos de que el usuario no pueda equivocarse, ¡sin importar cuánto lo intenten!
http://punto de validación. Como ejemplo, ASDFhace esto de una manera ingenua, y el resultado es que no puede alojar paquetes en dominios que usan https://.
Una vez recibí una llamada de atención al cliente porque mi aplicación simplemente desapareció. Resultó que abrieron otra aplicación encima.
... Decidí no asegurarme de que no volviera a ocurrir, ya que fueron los analfabetos informáticos de los usuarios los que causaron el problema, no la aplicación. Cualquier cosa que podría haber hecho para solucionarlo habría llevado a una mala experiencia de usuario para los demás.
Casi todos los programas que escribo se invocan estrictamente desde la línea de comandos. También he escrito algunas cosas más sofisticadas que comenzaron como interfaces CLI y rápidamente se convirtieron en algo más parecido a un shell que a cualquier otra cosa.
Entonces, solo puedo hablar por lo que sé. Aquí hay algunos problemas comunes con los programas de línea de comandos:
Demasiadas opciones
A menos que esté escribiendo un compilador o un editor de línea, intente mantener las opciones limitadas a una pantalla llena en un búfer de cuadros de 80x25 cuando --helpo /?se pasa. Está perfectamente bien tener más opciones que eso, pero dividirlas en subcategorías. Por ejemplo
foo --help
foo --help option_name
No hay opciones largas
Es mucho más fácil recordar foo --attach_to [argument] --volatile --verboseque recordar foo -a [arg] -v +V. Esto no siempre es posible, pero en la mayoría de los casos, lo es.
Sin validación de entrada
Casi todas las plataformas tienen múltiples bibliotecas que se prueban, prueban y son verdaderas cuando se trata de analizar y validar argumentos. Casi todas las plataformas tienen un lexer probado, probado y verdadero que valida la entrada de una CLI. Use uno, el otro o ambos. Si su programa se divide por defecto o se divide por cero debido a algo que proporcionó un usuario, eso es vergonzoso.
Es posible que no necesite algo tan complejo como un lexer, tal vez solo pueda tokenizar la cadena si espera cosas en un cierto orden con ciertas cosas en ciertos lugares.
De hecho, recibí un informe de error una vez donde se esperaba un número entero y alguien escribía f*** my lifeentre comillas. No escribí ese programa, tuve la desgracia de heredarlo.
No hay perilla 'verbocity'
Permita que los usuarios experimentados descubran fácilmente cómo sacar mucho más ruido de su programa de lo que la mayoría de la gente toleraría, pero por defecto solo imprime cosas serias y críticas. No puedo decirte cuántas veces tuve que disparar stracesolo para darme cuenta de que algo falló porque funcionaba en una secuencia de archivos NULL.
También puede ajustar las aserciones para que desactivarlas a través de NDEBUG u otros medios aún resulte en algo impreso o registrado para que el usuario lo encuentre.
Hablando de archivos de registro, trate de asegurarse de que todo lo que coloque en ellos tenga sentido (al menos un poco) para alguien que no sea usted. Si el comienzo de cada entrada es una fecha de época UNIX, agravará la frustración de alguien que realmente quiera ayudarlo a reproducir el error.
Sin 'compañero de error' en modo de depuración
Muchos programas ofrecen algún tipo de interruptor de 'depuración' que ofrece una charla adicional sobre lo que está sucediendo con el programa, pero muy pocos ofrecen lo siguiente:
O tal vez le guste escuchar a las personas leer lo siguiente por teléfono:
Dice condición inesperada a cero ef oh cuatro cero oh ... OK, déjame leerte eso ...
Archivos de configuración demasiado complejos.
No justifique la necesidad de analizar una configuración como una excusa para obtener un montón de azúcar sintáctica. Intente utilizar un formato que la gente realmente conozca, incluso si eso significa trabajo adicional al analizar. Intento usar el formato de estilo INI siempre que sea posible. Te sorprendería lo que puedes lograr con un simple diccionario clave-> valor.
No hay archivos de configuración
No haga que las personas escriban scripts de shell o archivos por lotes solo para usar su programa, a menos que esté destinado a ser una herramienta para cualquiera de las tareas. Dame un medio para señalar un archivo que contenga mis opciones habituales y proporciona solo algunos argumentos adicionales.
No hay signos de 'piso mojado'
Si alguna característica podría causarle problemas al usuario (tal vez esté allí para usuarios avanzados), márquela claramente como tal. Además, si alguien ingresa u olvida algo, haga que el programa imprima un enlace muy amigable a la documentación en línea. Puede estar tratando con alguien que está usando su programa a través de KVM y no puede cortar y pegar.
Cuando sea posible, (esto coincide con la validación de entrada) use el apporach de Google:
¿Querías decir foo --bar FILENME, solo escribiste foo --bar
Ofrecer una salida de instrucciones destructivas
El objetivo es decirle al usuario por qué no funcionó y hacer que lo intente un par de veces más, mientras se asegura de que no haga nada potencialmente destructivo a menos que parezca que el usuario realmente quiere que lo haga. Permita un interruptor que apague "fastidiar", por ejemplo, -Yo de lo /Ycontrario permita una salida para alguien que simplemente tiene "dedos gordos".
Probablemente estoy olvidando algunos consejos. Trato esto con frecuencia, ya que es muy, muy difícil hacer que la interfaz de 'bajo nivel' sea algo lo suficientemente intuitiva para que la mayoría de las personas eviten cometer errores.
"¿Está seguro de que desea eliminar este archivo / registro? Sí / No". Hice clic en Sí y luego recibí una llamada que "por error" hizo clic en el botón rojo Eliminar y necesita esos datos de nuevo :)
No creo que obtener ejemplos específicos de descanso / arreglo sea tan importante como darse cuenta de esto:
Si a través de esa exploración rompen algo, como programador es su trabajo advertirles del peligro o evitar que ocurra en primer lugar. No recuerdo dónde lo vi ahora, pero en el fondo de mi mente siempre trato de " hacer que hacer lo correcto sea fácil " para el usuario de mi software.
Si insiste en ejemplos:
¿Ves a dónde va esto? :)
Aquí hay uno que escuché esta semana. Un usuario solicita una función "enviarme una notificación cuando ocurra un evento". Bastante simple y el desarrollador sigue adelante y lo implementa. Claro, la primera pregunta debería haber sido "¿qué están tratando de abordar con esta notificación?". No voy a entrar en eso. Pocos días después, el usuario pasa por el desarrollador y pregunta "Recibí esta notificación. ¿Qué se supone que debo hacer con ella?".
Recordé este cómic de Dilbert y le sugerí al desarrollador "escribir una aplicación para averiguar qué debe hacer el usuario con esa notificación".
Como dijo mpeterson, el usuario es muy competitivo en su área de especialización. Simplemente no piensan como un desarrollador o diseñador de software.
No creo que los usuarios sean estúpidos. No quieren usar tu o ningún programa en absoluto. Todo lo que quieren es hacer sus cosas. Ayúdelos y evite que les ocurra daño en el camino.
Tener una buena interfaz de usuario y proporcionar una experiencia de aprendizaje adecuada contribuye en gran medida a evitar que los usuarios hagan cosas malas.
Las buenas interfaces de usuario deben ser sin fricción.
En lugar de abrir un cuadro de diálogo (una operación costosa y que los usuarios ignoran después de un tiempo) para confirmar una eliminación, realizar la eliminación y ofrecer una forma de deshacer.
Las buenas interfaces de usuario deben ser reconocibles.
Aunque la cinta en Microsoft Office recibe muchas críticas porque obliga a los antiguos usuarios de Word a cambiar sus formas, la cinta es un ejemplo brillante de cómo puede hacer que una interfaz sea reconocible (es decir, fácil de descubrir).
Las buenas interfaces de usuario, como un buen código, deberían explicarse por sí mismas.
Nadie lee el manual. El único manual que hice que mis usuarios leyeran fue una presentación de PowerPoint que contenía tutoriales paso a paso del software. He visto esto hecho con herramientas de video como Camtasia, pero los PowerPoints son mejores porque puedes voltear fácilmente hacia adelante y hacia atrás a través de los pasos.
El usuario no comete errores. Los errores recaen en el programador que no pudo crear una interfaz utilizable.
¡Haz las pruebas de usabilidad con cada lanzamiento!