diseñando para el error

1. diseñando para el error tomas laurenzo laboratorio de medios · inco · fing · udelar Interacción persona computadora. www.fing.edu.uy/inco/cursos/inpercom

2. diseñando para el error Basado en: Designing for error Clayton Lewis and Donald A. Norman Del libro: User Centered System Design Edited by Norman & Draper

3. longjmp botch: core dumped • Fatal error in pass zero • awk: syntax error near line 1 • cp: asd: No such file or directory • ¿Qué significan estos mensajes? • ¿El usuario hizo algo mal?, ¿exactamente qué? • ¿Cuán grave es la situación?

7. longjmp botch: core dumped • Fatal error in pass zero • awk: syntax error near line 1 • cp: asd: No such file of directory • manejar los errores es un problema difícil. • Estos mensajes son el resultado de que el • usuario hizo algo a lo que el sistema no sabe • responder.

8. Mensajes de error El formato y tono de los mismos puede (suele) ser ofensivo, especialmente para los novatos, a los que les parece que ellos, personalmente,cometieron alguna infracción por su incompetencia. A su vez, la información muchas veces no alcanza para corregir el problema. O sugiere falsas explicaciones…

9. The "longimp botch" message comes courtesy of the "more" program in 4.2BSD UNIX. Note that the error message does not even say which program has had the diffculty, so that If many procedures are being used at the same time (as is often the case), the user does not even have any idea of which routine has caused the problem, how to recover, or how to avoid the difficulty in the future. The "Fatal error in pass zero" message comes from a compiler heavily used by students. The "awk" errors are two of the more famous exit lines of the UNIX program "awk" You might think that "awl: was being helpful by identifying itself and then indicating roughly where in the file the difficulty occurred. You would be wrong. The two errors both resulted from specifying a nonexistent file (the command used was "awk asd." "Awk" is perfectly capable of determining that its difficulty came from the fact that the f le "asd" did not exist. Instead, it gives the erroneous and misleading error messages appropriate had the file existed with a non-intelligible first line. Other UNIX programs, such as "cp" (the copy command) do better: The command sequence "cp asd" yields the last error message in the list: meaningful and useful. Even it could have done better, however, by aiding the user to make the correction rather than simply quitting, forcing the user to retype the sometimes lengthy command line for what might have been an error in a single character.

10. Mensajes de error ¿Por qué se llaman errores (lo cual implica que el error es del usuario), cuando es en realidad el sistema el que no interpreta lo que le decimos?

11. Mensajes de error: de la ofensa a la disculpa Un tono apropiado para los mensajes debería ser: Perdón, pero estoy confundido. ¿Podría usted ayudarme? si se toma el diseño centrado en el usuario seriamente, entonces hay que pensarlo como una tarea cooperativa: la tarea no es encontrar fallas y culpables sino resolver el problema

12. Mensajes de error: de la ofensa a la disculpa En una conversación entre dos personas se cometen muchos errores (sentencias incompletas, palabras erróneas) y muchas veces hay problemas para comprender, pero nunca nos responden tu frase no fue gramaticalmente correcta, decilo de nuevo, pero esta vez correctamente. además, en general el error se arregla automáticamente y el que habla no se da cuenta deque lo cometió. aunque a veces se pide aclaración sobre una palabra o frase conflictiva.

13. Mensajes de error: de la ofensa a la disculpa En una conversación, ambos participantes asumen igual responsabilidad en la comprensión, y ambos toman la responsabilidad de reparar la dificultad. No puedo encontrar el archivo que Ud. menciona www.fing.edu.yu/inco/cursos/inpercom/Clases/clase_9.zip ¿Quiere Ud. decir?: 1: www.fing.edu.uy/... /clase_09.zip 2: www.fing.edu.uy/... /clase_9.ppt Elija algún número o especifique un nuevo nombre.

14. ¿eh? ¿se puede diseñar sistemas complejos en los que el usuario no cometa errores nunca?

15. Tratando con los errores • Se puede diseñar sistemas que minimicen los errores. • También, se puede hacer más fácil el trato de los errores cuando estos ocurren. Proveyendo indicaciones claras del problema, sus causas posibles y las soluciones, también, herramientas que faciliten la corrección. • Si hay muchos errores o pocos pero graves, el sistema debería proveer información útil que ayude a comprender lo que implica cada acción.

16. Tratando con los errores La situación ideal es aquella en la cual la recuperación frente a un error fue tan grácil que pasó desapercibida.

17. Tratando con los errores • Encontramos dos tipos de errores: • Si la intención no es apropiada, equivocación. (mistake) • Si la acción elegida no es la que se tenía intención de elegir, traspié (slip) • Muchos tipos de traspié no ocurren con los novatos, pero sí con los expertos. (!) • Respecto a las equivocaciones, la mayoría resulta de un error en la interpretación o el diagnóstico de la situación, o un modelo mental erróneo.

18. Minimizando errores • Norman: no es posible eliminar los errores, pero sí se los puede minimizar a través de: • Un buen diseño, que incluya el esquema físico de los componentes y las pantallas de la interfaz, elección inteligente de nombres de comandos, etc. • Buenos modelos conceptuales, una imagen del sistema que se corresponda con el modelo. • Cuanto más distancia haya en los abismos de ejecución y evaluación, más errores habrá.

19. Evitando errores a través de una representación adecuada • Supongamos que queremos operar sobre un archivo. • Representación 1: cadena de caracteres digitados (TUI) • Si digitamos el nombre del archivo puede ocurrir que: • El archivo no exista. • El archivo exista pero se haya escrito mal. • El archivo exista, pero el directorio puede ser erróneo. • Se pueden hacer programas que ayuden a corregir el error. • Muchos errores surgen porque los archivos se representan por strings digitados. • ¿Esto sigue siendo así? (!)

21. Evitando errores a través de una representación adecuada • Representación 2: íconos en la pantalla (o menús de opciones) • Ventajas: • Sólo se selecciona entre archivos existentes. • Sólo se trabaja con los directorios existentes. • Pero puede haber otros problemas: • No puedo seleccionar aquellos archivos cuyo nombre cumplan determinadas propiedades. • Puedo elegir el archivo equivocado. (igual problema en nueva forma) • Cada elección en la representación (y en general en el diseño) implica considerar el balance.

22. Evitando falsas deducciones. El usuario puede generalizar demasiado El lado bueno es que se aprende más de una simple experiencia. El lado malo es que se realizan falsas inferencias. Permanentemente. Aprendizaje por inducción. Hay que proveerle al usuario la secuencia correcta de ejemplos, de lo contrario puede ser llevado a falsas generalizaciones.

23. Minimizando errores causados por traspiés (slips) Uso incorrecto de modos: Es necesaria una mejor respuesta (feedback) sobre en qué modo está el sistema. ¿Ejemplos de modos? Errores de descripción: Problemas de consistencia. Errores de captura: Surgen cuando un usuario, al hacer una acción infrecuente, realiza otra parecida que es más frecuente. Puede solucionarse minimizando la superposición, quizás avisar cuando puede ocurrir un error de este tipo, comparar con la intención original...

24. Detectando errores • Detectar un error es el primer paso hacia la recuperación. • La detección temprana es sumamente importante: • Elimina el esfuerzo innecesario del usuario. • La detección tardía hace más complejo el problema (esto es aún más importante para el usuario inexperto). • Los traspiés suelen ser más fáciles de detectar que las equivocaciones • Traspié: La detección ocurre al comparar el resultado con la intención. • Equivocación: al estar mal la intención, la persona compara la salida con la intención, y ve que está bien.

25. Detectando errores Un problema importante en los traspiés es el nivel: El nivel donde ocurre la acción suele diferir del nivel donde las intenciones se han formado. Tenemos la tendencia a mantener una decisión aún después de que se muestra que es errónea. Esto es porque se tiene la tendencia de buscar sólo evidencia confirmatoria. Desarrollar un sistema que nos brinde información suficiente para ayudarnos a un diagnóstico efectivo es un tema importante de diseño.

26. ¿Cómo debería responder el sistema? Detectamos seis maneras posibles: 1.- Gag (Mordaza): El automóvil no se va a mover hasta que se encienda el motor. Este tipo de función previene que usuario continúe. FLOW (Jef Raskin): lenguaje de programación elemental, que solo permite escribir sentencias correctas del lenguaje. Esto puede ser pedagógicamente contraproducente, porque complica el aprendizaje experimental, al no dejar terminar de expresar las ideas, aunque estén incorrectas.

29. ¿Cómo debería responder el sistema? 2.- Warning (advertencia): Hace notar de la ocurrencia de algo potencialmente peligroso, pero es el usuario el que debe decidir cómo responder.

30. ¿Cómo debería responder el sistema? 3.- Do nothing (no hacer nada): Si se intenta una acción ilegal, esta simplemente no ocurre. Nada especial ocurre, y se deja inferir al usuario que ha intentado algo prohibido. Para que esta estrategia funcione se deben ver los efectos de todas las acciones, para poder medir la distancia entre intenciones y resultados. Por tanto, es muy usado en Manipulación Directa. No debe costar evaluar si algo efectivamente ocurrió ni si lo ocurrido corresponde con las intenciones.

32. ¿Cómo debería responder el sistema? 4.- Self Correct (Autocorrección): Suponer alguna acción legal que el usuario intentó realizar. Una versión es el sistema DWIM (Do What IMean) de Interlisp. Esto es útil si hay una opción “undo”, dado que el sistema se puede equivocar. Hace notar de la ocurrencia de algo potencialmente peligroso, pero es el usuario el que debe decidir cómo responder. DWIM puede funcionar muy bien, por ejemplo, es utilizado a propósito para acelerar la escritura (se escribe algo corto y se lo hace corresponder con algo largo).

35. ¿Cómo debería responder el sistema? 5.- Let’s talk about it (hablemos de esto): Cuando hay un problema, Lisp debugger le muestra los posibles candidatos. Hay una responsabilidad compartida entre el sistema y el usuario.

37. ¿Cómo debería responder el sistema? 6.- Teach me (enséñame): El sistema le pregunta al usuario el significado de alguna frase o palabra. Un ejemplo es CLOUT (lenguaje natural), en el que el sistema pregunta por palabras desconocidas. Si hay palabras en la definición que no son comprendidas, también se pregunta por ellas. Esto continúa hasta que todos los términos son definidos.

39. El problema del nivel A veces se ejecuta un programa, motivado por alguna intención, pero dentro alguna instrucción no puede ser ejecutada, y se emite un mensaje que no tiene sentido para el usuario. Hay muchas posibilidades de error. A veces es posible depurar el código para encontrar el problema. Otras veces no. A veces “tiene sentido” el mensaje y otras veces no. Una solución podría ser conocer la intención. Pero no siempre funciona.

40. El problema del nivel • Ejemplo: • X sale del trabajo. Va a buscar su auto en el estacionam. • X inserta la llave en la puerta del auto, pero esta no abre. • (Dado el mensaje, la interpretación es que puso mal la llave) • X prueba nuevamente, y tampoco abre. • (Dado el mensaje, la interpretación es que puso la llave errónea) • X comprueba que tomó la llave correcta del llavero. (Dado el mensaje, interpreta que el problema es la cerradura del auto) • X prueba en otra puerta del auto, y tampoco abre. • (Dado el mensaje, X se siente confundido) • X presta atención al auto y se da cuenta que no es suyo. • X va a su verdadero auto y abre la puerta sin dificultad.

41. El problema del nivel A pesar que la gente conoce sus propias intenciones, suele pensar que el problema ocurre en el nivel más bajo. Luego va subiendo hasta que con dificultades llega al nivel correcto. Quizás la culpa también es compartida con el sistema, dado que brinda mensajes incompletos. Por ej: la llave podría avisar que la puerta es del auto incorrecto.

42. Fallas en la detección de problemas Algunos problemas no son detectados por el usuario, aún cuando exista acceso a la evidencia, y tampoco son errores detectables por el sistema. No es posible confiar en la detección por parte de los usuarios.

43. Fallas en la detección de problemas Sesgo en la relevancia: La gente suele sesgar su acción buscando evidencia confirmatoria (positiva) cuando se evalúa una hipótesis. Esto surge cuando hay que seleccionar evidencia en un conjunto demasiado grande como para hacer un examen completo. No se puede gastar tiempo en procesar información irrelevante, pero el juicio acerca de lo que es relevante se basa en lo que uno piensa que está ocurriendo. No se tiene el “mapa” de toda la información, y por tanto, solo se ve aquello que confirme algún “mapa tentativo”.

44. Ignacio se viste de negro, tiene pelo largo, negro, y escucha death metal. ¿Qué es más probable que sea cristiano o satánico?

45. Fallas en la detección de problemas Explicación parcial: Algunos errores no se detectan porque la gente acepta una correspondencia total entre lo que se espera y lo que se ve. Si se busca algo, y lo que se ve se corresponde con lo que se espera ver, entonces no se sigue viendo ese algo para confirmar la primera impresión. Si se está buscando el número de página, y se encuentra un número, debe ser el número de página. En realidad puede ser el número de renglón, o el carácter en el renglón, etc.

46. Fallas en la detección de problemas Superposición del modelo y el mundo: El modelo que uno tiene, se corresponde en gran medida con la realidad. Pero es difícil de detectar donde están las diferencias.

47. Corrigiendo los errores • DESHACER • Permitir volver a un estado anterior. • Tiene sus complicaciones. Una acción se puede componer de un conjunto importante de comandos. • Nievergelt expresa que para recuperarse de un error, hay que tener en claro los siguientes aspectos: • site (cuál es el estado actual del sistema). • trails (por donde he venido). • modes(cuáles son las alternativas). • Debería hacerse mayor uso de las estrategias “Hablemos de esto”, “enseñame” y “Autocorrección”.

48. Corrigiendo los errores • Parece importante, entonces: • Comprender las causas de error y diseñar para minimizar esas causas. • Hacer posible el deshacer. • Facilitar el descubrimiento de errores cuando éstos ocurren, y hacer que sean fáciles de corregir. • Cambiar la actitud hacia los errores. Pensar que el usuario está tratando de hacer una tarea a través de aproximaciones imperfectas. No pensar que el usuario está cometiendo errores; pensar en las acciones como aproximaciones de lo que se desea hacer.

49. Evitando errores • Generar funciones que fuercen acciones • (forcing functions): • Antes de borrar algo, preguntar si realmente se quiere borrar eso. • El auto no funciona si no tiene el abrochado el cinturón de seguridad. • Antes de cerrar un software, preguntar si se quiere salvar lo ya generado. • No abrir el horno de microondas sin que este se apague automáticamente. • Trancar algo para prevenir la entrada a lugares peligrosos.

50. Diseño para evitar errores • Poner el conocimiento en el mundo. No hacer que todo el conocimiento esté en nuestra cabeza. Permitir que el usuario realice operaciones más eficientes cuando tiene el conocimiento en la cabeza. • Utilizar la potencia de las restricciones naturales y artificiales. Utilizar funciones que fuercen acciones y mapeo naturales.