Principios de Diseño

1. Principios de Diseño

2. Algunos atributos de las buenas Interfaces • 1) Invisibles • 2) Fáciles de aprender • 3) Fáciles de recordar • 4) Predecibilidad • 5) Pocos errores • 6) Recuperación sencilla ante errores • 7) Uso eficiente • 8) Flexibles • 9) Inteligentes • 10) Satisfacción subjetiva • 11) ... y varios más

3. Algunos principios generales de diseño • Simplicidad • Consistencia • Metáforas apropiadas • Feedback informativo • Diseño gráfico • Prevención y tratamiento de errores • otros ..... • Cada estilo de interacción proporciona principios de diseño particulares

4. Simplicidad • Principio KISS (“Keep It Simple, Stupid”) • Presentar exactamente la información necesaria • ‘Less is More’ • Menos para aprender, para equivocarse, para distraerse, ... • Eliminar u ocultar la información irrelevante o innecesaria • Compite con la información importante en la presentación • La información debiera aparecer en un orden natural • La información relacionada debe estar agrupada graficamente • El orden de acceso a la información debe corresponder a aquel que espera el usuario • No utilizar muchas ventanas • No utilizar navegaciones o administración compleja entre ventanas • Si es dificil de explicar o documentar, rediseñarlo • Lenguaje conciso

5. Simplicidad

6. Simplicidad

7. Consistencia • Tipos de consistencia: • Efectos • Los mismas comandos y acciones deberán tener siempre el mismo efecto en situaciones equivalentes • Predecibilidad de la interfaz • Lenguaje y gráficos • La misma información/controles en la misma posición en todas las pantallas • La misma apariencia visual a lo largo del sistema • look & feel de un toolkit • Terminología idéntica en ayudas, manuales, etc. • inputs • Sintaxis consistente en el sistema completo

8. Consistencia • Facilita al operador la determinación de la forma correcta de interactuar • ej. el operador puede recordar la forma de manipular un objeto en pantalla, a partir de su similitud con otros objetos (ej. barras de desplazamiento, botones) • Algunas formas de potenciar la consistencia: • Definición de una metáfora de interacción • Utilización de las guías de estilo provistas por cada plataforma • Utilización de un ‘toolkit’ • Las excepciones debieran ser limitadas • ej. falta de eco en la entrada de claves (‘passwords’), confirmación del comando delete

9. Consistencia con toolkits • Algunos toolkits proveen consistencia, por medio de la implementación de un look&feel particular. • Proveen un conjunto de OI predefinidos, de propósitos generales • Las operaciones se aplican siempre de una misma forma particular • Facilidad para recordar y aprender para el operador • Pueden existir dificultades cuando la IU no puede ser implementada totalmente por un toolkit particular. • Rediseñar la interfaz para adecuarse a un toolkit particular, o • Extender el toolkit para lograr la funcionalidad o apariencia deseada

10. Consistencia con toolkits Reimplementación de controles (diferentes a los estandares) Posible desorientación en los usuarios

11. Guías de estilo • Guías publicadas por los proveedores de GUIs • Open Software Foundation OSF • Open Look • MS Windows • Apple • Describen el look&feel de la interfaz • ej. Open Look: agrupamiento de menúes en el mismo menú • “Utilizar un espacio en blanco entre grupos grandes de controles en menúes o en grupos pequeños cuando el espacio en pantalla no es un problema” • Características • son específicas de la GUI y para los widgets provistos • numero alto de guías • pueden no cubrir algunos principios de diseño fundamentales

12. Guías de Estilo: Apple

13. Guías de Estilo • Las aplicaciones Windows suelen colocar la función Find en el menú Edit • En el Notepad, la combinación Alt+E+F no funciona

14. Metáforas • Términos, imágenes y conceptos fundamentales que son fácilmente reconocidos, comprendidos y recordados [Marcus 93] • Propósito • Descripción de un modelo nuevo, en términos de un modelo conocido • Algunas metáforas actuales: • “Modelo del mundo” (‘model world’) • Reproducción electrónica de objetos del mundo real • ej. Metáfora de escritorio. • “Conversación” (‘conversation’): • Acciones representadas de una forma lingüística • ej. Lenguajes de comandos textuales (Unix)

15. Metáforas • La aplicación de metáforas no siempre es beneficiosa • Algunas conceptos u operaciones no tienen una representación real en la metáfora • ej. no existe una operación ‘undo’ en un escritorio real • En estos casos, la metáfora puede producir confusiones

16. No abusar de las metáforas • La aplicación de una metáfora puede no proporcionar mayor usabilidad Macintosh Quick Time Player (todos los sonidos se ven iguales en el preview)

17. Feedback informativo • Información contínua al usuario acerca de: • Lo que está haciendo • La interpretación que se le está dando a las acciones del usuario • El usuario siempre debe estar consciente de lo que está haciendo

18. Feedback informativo Modo actual Selección actual Interpreta- ción de las acciones

19. Feedback informativo • Indicar las acciones inhabilitadas sobre los OI • El OI debe indicar dicha inhabilitación • Presentación opaca del OI, y suspensión de las reacciones al mouse • ‘do nothing approach’ • No hace nada, no hay posibilidad de error • Removiendo el OI actualmente inaccesible. • Producirá cambios en la localización de los otros items • Contradice el principio de consistencia en el layout espacial

20. Feedback informativo • La eliminación de los items deshabilitados puede confundir • Indicar en todos los elementos las acciones deshabilitadas

21. Feedback informativo • Mostrar el modo actual • Interacción con “modos”: los mismos inputs producen resultados diferentes, dependiendo del estado del sistema. • ej. Dragging o rubberbanding de un objeto en una manipulación directa • En general, los modos no pueden ser evitados, pero debe proveerse un feedback explícito acerca del modo actual.

22. Feedback informativo • Informar al operador ante tiempos de respuesta largos • Cuando una entrada no puede ser procesada en un tiempo razonable, debe indicarse mientras está siendo procesada. • Forma especial del cursor • Para transacciones cortas • Barra con la progresión del trabajo • Para transacciones más largas • Indica cuanto resta de la operación • Tiempo estimado • Que está haciendo • Aleatorio • Para tiempos de respuesta desconocidos

23. Feedback informativo • Representar los movimientos de los dispositivos de input en la pantalla. • Facilita el proceso de evaluación. • ejs. ‘rubberbanding’ y ‘shape tracking’. • Pueden requerir un esfuerzo de programación sustancial • Debe ser tan específico como sea posible • Es conveniente presentarlo dentro del contexto de la acción • ej. indicación del guardado de archivos en MS Word

24. Feedback informativo • Tiempos de respuesta • Como perciben los usuarios las demoras en las respuestas • 0,1 seg. (máximo): percibida como una acción “instantánea” • 1 seg. (máximo): el flujo de pensamiento del usuario no se interrumpe, pero la demora es percibida • 10 seg. : limite para mantener la atención del usuario focalizada en el diálogo • > 10 seg. : los usuarios prefieren realizar otra tarea mientras esperan los resultados

25. Principios Diseño Gráfico • Colores apropiados, atrayendo la atención del usuario • Agrupar objetos relacionados • Alineación, decoraciones similares • Balancear el espacio • Pocas fuentes y colores (5 a 7 colores) • Contraste apropiado

26. Principios Diseño Gráfico

27. Usar el lenguaje del usuario • Utilizar terminología basada en el lenguaje utilizado por el usuario en la tarea • Los mensajes de error y feedback deben referirse a objetos del dominio del usuario • Utilizar palabras comunes, no vocabulario o jerga tecnica • Permitir nombres con longitud arbitraria

28. Usar el lenguaje del usuario CompuServe's WinCim

29. Usar el lenguaje del usuario Numeración comenzando desde 0 (Netscape Communicator) Colores representados en hexa (y no el color mismo)

30. Usar el lenguaje del usuario • No confundir al usuario • Que significa “Continue”? • “continuar usando XFM” o “Continuar para salir”? • En que difieren “Cancel” y “Abort”? XFM, "X-windows File Manager"

31. Puntos de Salida • Deben indicarse claramente • Los usuarios no desean sentirse “atrapados” por el SI

32. Puntos de Salida • Estrategias: • Botones de cancelación • diálogos esperando una acción del usuario • ‘Undo’ universal • permite retornar al estado previo • Interrupciones • para operaciones largas • ‘Quit’ • para salir del SI en cualquier momento • Valores por omisión • para restaurar un formulario de ingreso de datos

33. ‘Shortcuts’ • Los usuarios expertos deberían ser capaces de realizar rápidamente las operaciones frecuentes • Estrategias: • Aceleradores de teclado y mouse • Abreviaciones • Completando comandos • ‘Shortcuts’ en los menús • Teclas función • ‘Type-ahead’ • Realizar un ingreso antes de que el SI esté listo para ello • Saltos en la navegación • ej. Dirigirse directamente a una ventana o posición, evitando nodos intermedios • Sistemas con historia • ej. WWW: aprox. El 60% de las páginas son revisitadas

34. ‘Shortcuts’ • utilizar abreviaciones, iconos y terminos nemotécnicos significativas • ej. “Guardar un archivo” • Ctrl + G (abreviación) • Alt AG (termino nemotécnico para acción de un menú) • Guardar archivo (ícono)

35. ‘Shortcuts’ Aceleradores de teclado en menúes Barras ‘customizables’ y paletas para acciones frecuentes Menú con opciones recientemente utili- zadas en el tope Doble-Click para activar un menú específico del objeto seleccionado Doble-Click para activar las opciones visibles en la barra de tareas Scrolling para incrementos de acuerdo al tamaño de la página

36. Reducción necesidad de memoria “inmediata” • ‘short-term memory’ • Limitaciones humanas para el procesamiento de información • 7 +/- 2 ítems, 30 seg. a 2 min, a menos que sea interrumpida • Esta memoria es extremadamente frágil • Las distracciones pueden producir la pérdida de su contenido • Requiere presentaciones simples • Provisión de ayuda en línea para la sintaxis de los comandos, abreviaciones, códigos, etc. • El usuario debiera reconocer, no recordar • Menús, iconos, cajas de diálogo vs. líneas comando • Basado en la visibilidad de los objetos por el usuario

37. Reducción necesidad de memoria “inmediata” • Describir el formato esperado de las entradas • ej. los ‘prompts’ debieran indicar el formato de lo que se debe ingresar • Numero pequeño de reglas aplicables universalmente • Comandos genéricos: el mismo comando puede ser aplicado a todos los objetos de la interfaz • ej. Cut, copy, paste, drag & drop, ...

38. Reducción necesidad de memoria “inmediata” • Facilitar la tarea al usuario, proveyendo información contextual • El usuario debe recordar el directorio exacto • El sistema podría agregar STARTUP automáticamente

39. Reversibilidad de las acciones • En lo posible, todas las acciones deben ser reversibles • Tranquilidad para el usuario • Los errores pueden ser reparados (‘ undo’) • Facilita la exploración de opciones no conocidas • Unidad de reversibilidad: • Acción simple • Tarea de entrada de datos • Grupo completo de acciones

40. Errores • Todos los operadores cometen errores • 31% de las tareas tienen algún tipo de errores o estrategias ineficientes [Card 80] • Los errores producen perdidas de productividad • Es conveniente prevenir los errores • ej. permitir el llenado de un campo de un formulario con un menú, y no por medio de un tipeo. • Los errores ocurridos deben ser detectados lo antes posible • Deben ofrecerse instrucciones para reparar el error • ej. no retipear un comando entero, sino solamente aquellas partes que están equivocadas • Las acciones erróneas no deberían cambiar el estado del sistema, o el sistema debería proveer instrucciones para restaurar el estado

41. Errores • ‘Mistakes’ • Errores semánticos: ejecución correcta de las acciones, pero en una forma equivocada • ej. colocación de un rectángulo como un marco para un texto, en lugar de un marco propiamente dicho • ‘Slips’ • Comportamiento inconsciente que conduce a un camino erróneo en la ejecución de la tarea • Suelen suceder frecuentemente en usuarios experimentados • Generalmente por falta de atención • También suelen producirse por similaridades entre distintas acciones

42. Tipos de ‘slips’ • Errores de “captura” • Se ejecuta la actividad más frecuente en lugar de la actividad deseada • ej. confirmar el grabado de un archivo cuando no se desea sobreescribirlo • Generalmente ocurren cuando las acciones comunes y las infrecuentes tienen la misma secuencia inicial Porqué presioné “Si”....?

43. Tipos de ‘slips’ • Error de descripción • La acción deseada tiene mucho en común con otras posibles • ej. mover un archivo a la papelera de reciclaje, en lugar de a un directorio o unidad de disco • Generalmente ocurren cuando los objetos correctos y erróneos están fisicamente cercanos

44. Tipos de ‘slips’ • Pérdida de la activación • Olvido del objetivo de la tarea en el medio de la secuencia de acciones • ej. navegación de menúes o diálogos, y no recordar lo que se está buscando • “Desorientación” • Errores de modo • El usuario realiza acciones en un modo creyendo que está operando en otro modo • ej. referirse a un archivo que está en un directorio diferente • ej. búsqueda de comandos u opciones de menúes que no son relevantes

45. Diseño para evitar ‘slips’ • Reglas generales • Prevenir los ‘slips’ antes de que ocurran • Detectar y corregir los ‘slips’ cuando ocurren • Permitir la corrección del usuario con feedback y ‘undo’ • Ejemplos • Errores modales • Tener la menor cantidad de modos posibles • Explicitar los modos de la mejor forma posible • Errores de “captura” • En lugar de confirmación, permitir que las operaciones sean reversibles • Permitir la reconsideración de las acciones por el usuario • ej. los items de la papelera de reciclaje pueden ser recupeados • Pérdida de la activación • Si el SI conoce el objetivo de la tarea, explicitarlo • Si el SI no lo conoce, mostrar el camino seguido hasta el punto actual • Errores de descripción • En interfaces con iconos, evitar la similitud entre los iconos

46. Prevención y tratamiento de errores • Idea general • Prevenir o mitigar la continuación de una acción errónea • Estrategias • Tratar los errores, no permitiendo la continuidad de las acciones del usuario • ej. no pasar la ventana de login hasta que no se ingrese el password correcto • ‘Warnings’ • Avisar al usuario cuando ocurre una situacion no usual • ej. sonidos (campanas, timbres) • No abusar de su uso • ‘Do nothing’ • Una acción ilegal no tendrá ningún efecto • El usuario debe inferir lo que ha sucedido • ej. ingreso de una letra en un campo numérico (se ignora la tecla presionada)

47. Prevención y tratamiento de errores • Estrategias • Autocorrección • El sistema autocorrige el error, de acuerdo a determinadas acciones válidas • ej. autocorrector ortográfico • Se transforma en un problema de confianza • Negociación • El SI inicia un diálogo con el usuario para encontrar una solución al problema • ej. compiladores indicando la línea donde ha ocurrido el error, y posibilitando su reparación • Demostración • El SI pregunta al usuario cuál es la acción que desea ejecutar realmente

48. Prevención y tratamiento de errores • Estrategias • Chequeos • El SI chequea la razonabilidad de los datos ingresados por el usuario • ej. “Ud. ha solicitado la compra de 5000 lápices. Es realmente la cantidad que desea comprar?” • Ingreso de datos válidos • El SI solamente acepta los datos ingresados con un formato dado • ej. Los widgets actuales sólo permiten el ingreso de datos con un determinado formato

49. Tratar los errores en forma positiva y significativa

50. Mensajes de error • Expresados en el lenguaje del usuario • Preferiblemente en el lenguaje de la tarea • No utilizar códigos • no ‘ERROR 25’ • Precisos • ej. UNMATCHED LEFT PARENTHESIS en lugar de SYNTAX ERROR