principios de diseño

62
Principios de Diseño

Upload: britanney-hall

Post on 03-Jan-2016

32 views

Category:

Documents


0 download

DESCRIPTION

Principios de Diseño. 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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Principios de Diseño

Principios de Diseño

Page 2: Principios de Diseño

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

Page 3: Principios de Diseño

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

Page 4: Principios de Diseño

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

Page 5: Principios de Diseño

Simplicidad

Page 6: Principios de Diseño

Simplicidad

Page 7: Principios de Diseño

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

Page 8: Principios de Diseño

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

Page 9: Principios de Diseño

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

Page 10: Principios de Diseño

Consistencia con toolkits

Reimplementación de controles (diferentes a los estandares)Posible desorientación en los usuarios

Page 11: Principios de Diseño

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

Page 12: Principios de Diseño

Guías de Estilo: Apple

Page 13: Principios de Diseño

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

Page 14: Principios de Diseño

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)

Page 15: Principios de Diseño

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

Page 16: Principios de Diseño

No abusar de las metáforas

La aplicación de una metáfora puede no proporcionar mayor usabilidad

Quick Time Player (todos los sonidos se ven iguales en el preview)

Macintosh

Page 17: Principios de Diseño

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

Page 18: Principios de Diseño

Feedback informativo

Selección actual

Modo actual

Interpreta-ción de las acciones

Page 19: Principios de Diseño

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

Page 20: Principios de Diseño

Feedback informativo La eliminación de los items deshabilitados puede

confundir

Indicar en todos los elementos las acciones deshabilitadas

Page 21: Principios de Diseño

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.

Page 22: Principios de Diseño

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

Page 23: Principios de Diseño

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

Page 24: Principios de Diseño

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

Page 25: Principios de Diseño

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

Page 26: Principios de Diseño

Principios Diseño Gráfico

Page 27: Principios de Diseño

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

Page 28: Principios de Diseño

Usar el lenguaje del usuario

CompuServe's WinCim

Page 29: Principios de Diseño

Usar el lenguaje del usuario

Numeración comenzando desde 0(Netscape Communicator)

Colores representados en hexa (y no el color mismo)

Page 30: Principios de Diseño

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"

Page 31: Principios de Diseño

Puntos de Salida

Deben indicarse claramente Los usuarios no desean sentirse “atrapados” por el SI

Page 32: Principios de Diseño

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

Page 33: Principios de Diseño

‘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

Page 34: Principios de Diseño

‘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)

Page 35: Principios de Diseño

‘Shortcuts’Aceleradores de teclado en menúes

Scrolling para incrementos de acuerdo al tamaño de la página

Doble-Click para activar las opciones visibles en la barra de tareas

Doble-Click para activar un menú específico del objeto seleccionado

Menú con opciones recientemente utili-zadas en el tope

Barras ‘customizables’ y paletas para acciones frecuentes

Page 36: Principios de Diseño

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

Page 37: Principios de Diseño

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, ...

Page 38: Principios de Diseño

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

Page 39: Principios de Diseño

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

Page 40: Principios de Diseño

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

Page 41: Principios de Diseño

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

Page 42: Principios de Diseño

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”....?

Page 43: Principios de Diseño

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

Page 44: Principios de Diseño

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

Page 45: Principios de Diseño

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

Page 46: Principios de Diseño

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)

Page 47: Principios de Diseño

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

Page 48: Principios de Diseño

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

Page 49: Principios de Diseño

Tratar los errores en forma positiva y significativa

Page 50: Principios de Diseño

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

Page 51: Principios de Diseño

Mensajes de error Constructivos

Indicar porque sucedió el error y cómo solucionarlo

Positivos no ‘FATAL ERROR’

Page 52: Principios de Diseño

Mensajes de error No confundir al usuario

Page 53: Principios de Diseño

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”

Page 54: Principios de Diseño

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

Page 55: Principios de Diseño

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,...

Page 56: Principios de Diseño

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

Page 57: Principios de Diseño

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

Page 58: Principios de Diseño

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’

Page 59: Principios de Diseño
Page 60: Principios de Diseño
Page 61: Principios de Diseño
Page 62: Principios de Diseño