Principios de Dise

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 lookfeel 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 lookfeel 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 AltEF 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
• gt 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

51
Mensajes de error

• Constructivos
• Indicar porque sucedió el error y cómo
  solucionarlo
• Positivos
• no FATAL ERROR

52
Mensajes de error

• No confundir al usuario

53
Mensajes de error

• No culpar al usuario de la ocurrencia del error
• ej. Cannot open chapter 5 because the
  application MS Word is not on your system

54
Provisión de ayudas

• Las ayudas no son un reemplazo para un mal diseño
• Sistemas simples
• Instrucciones mínimas
• Mayoría de los sistemas
• Ricos en características
• Muchos usuarios desean convertirse en
• usuarios expertos, no usuarios casuales
• Los usuarios no frecuentes necesitan recordar

55
Uso de la documentación

• La mayoría de los usuarios no leen los manuales
• Prefieren utilizar su tiempo continuando con su
  tarea
• Generalmente, utilizados cuando los usuarios
  necesitan una ayuda inmediata (en pánico)
• Indica la necesidad para la documentación en
  línea y herramientas de búsqueda
• La ayuda en línea puede ser específica al
  contexto actual
• Los manuales en papel generalmente no están
  disponibles en el lugar correcto
• Muchas veces utilizados como referencia rápida
• Sintaxis de acciones, posibilidades,...

56
Algunos tipos de ayuda

• Tutoriales y/o manuales getting started
• Guías cortas que los usuarios pueden leer cuando
  comienzan el uso de los SI
• Estimula la exploración y el conocimiento general
  del sistema
• Intenta proveer el material conceptual y la
  sintaxis esencial del SI
• Tours en línea, ejercicios y demostraciones
• Demuestra los principios más básicos a través de
  varios ejemplos de trabajo

57
Algunos tipos de ayuda

• Manuales de referencia
• Mayormente utilizados para búsquedas detalladas
  (por expertos)
• Organizados por tema
• Hipertexto en línea
• Search / find
• Tabla de contenidos
• Indices
• Indices cruzados

58
Algunos tipos de ayuda

• Reminders
• Significado sintáctico/semántico de las teclas
• Textos sobre los iconos indicando su
• significado o propósito
• Ayuda sensible al contexto
• El sistema provee ayuda acerca de lo
• que el usuario está realizando
• Macintosh ballon help

59
(No Transcript)
60
(No Transcript)
61
(No Transcript)
62
(No Transcript)