+ All Categories

Diseño

Date post: 10-Feb-2016
Category:
Upload: caesar
View: 45 times
Download: 0 times
Share this document with a friend
Description:
Miguel Gea Universidad de Granada. Diseño. Objetivos. Conocer el proceso de diseño de sistemas interactivos ¿Realizar un diseño centrado en el usuario? Análisis de tareas Notaciones para el diálogo . Diseño centrado en el usuario . - PowerPoint PPT Presentation
67
Diseño Miguel Gea Universidad de Granada
Transcript
Page 1: Diseño

Diseño Miguel GeaUniversidad de Granada

Page 2: Diseño

Objetivos

Conocer el proceso de diseño de sistemas interactivos

¿Realizar un diseño centrado en el usuario?

Análisis de tareas Notaciones para el diálogo

Page 3: Diseño

Diseño centrado en el usuario

El proceso de diseño debe estar centrado en el usuario para recoger sus necesidades y mejorar su utilización.

El diseñador deberá satisfacer los requisitos humanos aplicando conocimientos de diferentes áreas: psicología cognitiva, dispositivos y técnicas de

interacción, guías, estándares, etc. El diseño se debe basar en criterios

consistentes basados en la experiencia y no en juicios intuitivos

Page 4: Diseño

Diseño centrado en el usuario

El objetivo del sistema interactivo es permitir al usuario conseguir un objetivo concreto en un dominio de aplicación

El diseño debe responder a las siguientes cuestiones: Cómo debe ser desarrollado el sistema

interactivo para asegurar la usabilidad Como puede la usabilidad de un sistema

interactivo ser demostrada o medida

Page 5: Diseño

Diseño centrado en el usuario

Diseño

Implementación

V&V

Análisis etnográfico

maqueta

simulación

Escenario

Requisitos

Evaluación

Page 6: Diseño

DiseñoAnálisis de tareas

Especificación diálogos

Evaluación

Estándares

Guías

Experiencia

Requisitos

Prototipado

Implementación

Internacionalización

accesibilidad

Page 7: Diseño

Prototipado

Page 8: Diseño

PrototipadoEscenario

Una historia de ficción con representación de personajes, sucesos, productos y entornos

Ayuda al diseñador a explorar ideas y las ramificaciones de decisiones de diseño en situaciones concretas.

Es difícil conseguir un escenario correcto la primera vez. Es interesante pensar en diferentes escenarios para reflejar las diferentes situaciones y puntos de vista diferentes.

Page 9: Diseño

PrototiposEscenarios

Es importante por otro lado ser consistente con la representación para ver que pasa en situaciones concretas.

Bruce Toganizzini nos comenta que el uso de los escenarios nos permite definir y desarrollar conocimientos sobre el entorno del usuario y su espacio de trabajo.

Page 10: Diseño

EscenariosEscenario de tareas

Es una descripción del mundo del usuario tal como existe ahora

Escenario de futuro Es una descripción del mundo del

usuario en un futuro

Page 11: Diseño

Tipo de escenario

NarrativaFlowchartTexto proceduralStoryboard

Page 12: Diseño

EscenarioFlowchart

Una representación gráfica de las series de acciones y decisiones extraídas de la narrativa

Page 13: Diseño

EscenarioNarrativa

Una historia completa de la interacción hecha con la existente o con un diseño nuevo

Page 14: Diseño

EscenarioTextos de los procedimientos

Una descripción paso a paso de las acciones del usuario y las respuestas del sistema

Page 15: Diseño

PrototipadoStoryboard

Un storyboard es una narración gráfica de una historia en cuadros consecutivos.

Podemos utilizar este concepto que se utiliza en el diseño cinematográfico, teatro, etc. para la realización de un escenario de interacción que puede ser evaluado con diferentes técnicas

Una de las opciones que tenemos en un storyboard para una aplicación es que podemos indicar los enlaces a diferentes páginas del storyboard a partir de los resultados de las interacciones del usuario.

Page 16: Diseño
Page 17: Diseño

Prototipo en papelEste tipo de prototipo se basa en la

utilización de papel, tijeras, lápiz o instrumentos que se puedan utilizar para describir un diseño en un papel.

Este sistema nos permite una gran velocidad y flexibilidad

Page 18: Diseño

Como se realiza un prototipo de papel

Para poder simular las diferentes interacciones que vamos a realizar con el sistema, realizaremos una hoja para cada uno de los diferentes escenarios que vamos a tener como resultado de las diferentes posibles interacciones que podemos realizar

Apilaremos estas hojas que nos permitirán simular la aplicación.

Page 19: Diseño

Prototipo en papelUso

Para utilizar el prototipo de papel nos situaremos en un escenario de uso de futuro en el que el diseñador actúa como coordinador

El prototipo será analizado por un posible usuario e intentará realizar algunas de las tareas que se pretende diseñar

En voz alta se irán realizando las interacciones y le iremos cambiando las hojas de papel en función de las interacciones que vaya realizando.

Page 20: Diseño

Prototipo de papelVentajas

El coste es muy reducido, necesitando únicamente los recursos humanos dedicados a la realización del prototipo.

Los cambios se pueden realizar muy rápidamente y sobre la marcha. Si el diseño no funciona se puede reescribir las hojas erróneas o rediseñarlas y volver a probar la tarea a realizar

Los usuarios o los actores se sienten más cómodos para poder realizar críticas al diseño debido a la sencillez del mismo por lo que no se sienten cohibidos a dar sus opiniones.

Page 21: Diseño

PrototipadoPrototipo en papel

Page 22: Diseño

Prototipo en vídeoUn prototipo por ordenador nos permite, de una

manera relativamente barata, visualizar sistemas futuros, pero puede fracasar a la hora de comunicar el sentimiento de un usuario en una nueva experiencia, simplemente porque el hardware que ha de utilizar el nuevo sistema no existe o por la dificultad de crear una maqueta interactiva de un gran sistema ([NIE93], [CAR00]).

Un video nos permite realizar la demo final fuera de las limitaciones del hardware. Todo funciona perfectamente, cada vez que el espectador mirar al vídeo. Un ejemplo interesante de prototipo en vídeo es el vídeo starfire, rodado por Sun [TOG94].

Page 23: Diseño

Análisis de tareas

Page 24: Diseño

Análisis de tareasTarea Unidad significativa de trabajo en la

actividad de una persona (sobre una aplicación)

Una de las premisas de cualquier aproximación con la que abordemos el diseño es la de conocer el usuario y cómo realiza las tareas.

El primer paso en el diseño de un sistema interactivo es el análisis de las tareas que el usuario debe realizar.

Page 25: Diseño

Análisis de tareasInformación que necesita el usuario

para realizar la tarea (qué hacer) Terminología y símbolos del dominio

del problema (elementos). Descripción de cómo esas tareas se

realizan actualmente (cómo).

Page 26: Diseño

Análisis de tareasEs el proceso de analizar la manera

en que las personas realizan sus trabajos Lo que hace Sobre que cosas actuan Que necesitan saber

Page 27: Diseño

Análisis de tareasUsos

DocumentaciónRecogida de requisitosPredecir prestaciones

Page 28: Diseño

Análisis de tareasObjetivos, tareas, acciones

Objetivo El estado que el usuario quiere alcanzarTarea externa

Tarea Una actividad necesaria para conseguir un objetivoTarea interna

Acción Una tarea que no implique una solución de un problema o

una estructura de controlTarea simple

Page 29: Diseño

Análisis de tareasMétodos

Descomposición de tareas Ver el modo en el cual una tarea se puede

descomponer en otras mas simples Análisis basado en conocimiento

Identifica el conocimiento del usuario para llevar a cabo dicha tarea, y cómo está organizado este conocimiento

Análisis de relaciones entre entidades Aproximación orientada a objetos donde enfatiza

los actores y objetos, las relaciones entre los mismos y las acciones que pueden realizar

Page 30: Diseño

Análisis de tareasJerarquicoGOMSEntidad relación

Page 31: Diseño

Análisis jerárquico de tareas

Page 32: Diseño

Análisis jerárquico de tareas

Page 33: Diseño

HTA en notación texto0. make tea 1. boil water 1.1 fill kettle 1.2 light stove 1.3 put kettle on stove 1.4 wait 1.5 turn off stove 2. empty pot 3. put leaves in pot 4. pour water 5. wait 6. pour tea Plan 0: do 1. if pot is full, then do 2 at the same time do 3-4-5 when tea is brewed, do 6 Plan 1: do 1.1-1.2-1.3-1.4 when water is boiling, do 1.5

Page 34: Diseño

Análisis de tareasCheck-in

Checkin

Datos personales

Tipo habitación

Identificación FormaPago

Asignaciónhabitación

Entrega llave

Huellasdactilares

Voz Clave

Page 35: Diseño

HTAMetodologíaEtapa inicial

Definir la tarea principal, que puede ser dividida entre cuatro y ocho subtareas

Etapa intermedia Decidir el nivel de detalle que se requiere y en que

punto acabar la descomposición Parte final

Revisión y evaluación del trabajo realizado para comprobar su consistencia

 

Page 36: Diseño

ProblemaAnálisis de tareas jerárquico

Planteamos el siguiente análisis de tareas

Realizar una llamada telefónica desde un teléfono móvil Conocemos el número de teléfono Se puede dar el nombre hablando Buscar en una lista

Page 37: Diseño

GOMS

Page 38: Diseño

GOMSFamilia de técnicas propuesta por Card,

Moran, and Newell (1983), para modelar y describir las prestaciones de las tareas desde el punto de vista humano

GOMS es un acrónimo que significa Objetivos (Goals), Operadores (Operators), Métodos (Methods), y Reglas de selección (Selection Rules),

Page 39: Diseño

GOMSFamilia de métodos

KLM Keystroke Level Model - Card, Moran, Newell 1983 Utiliza un sola secuencia de operadores

CMN-GOMS Añadido objetivos, sub-objetivos y métodos

NGOMSL Lenguaje GOMS natural Basado en teoría de la complejidad cognitiva

CPM-GOMS Cognitiva, perceptual, motores Añadido métodos paralelos, sujeto a restricciones

de procesamiento, los modelos utilizan gráficos PERT

Page 40: Diseño

Modelo GOMS...

] Objetivo (Goal): Son los objetivos del usuario, describen lo que

pretende conseguirOperadores

Nivel de análisis a más bajo nivel. Son las acciones básicas que se deben llevar a cabo para utilizar el sistema. Son dependientes del sistema (pulsar la tecla ‘X’) o del modelo mental del usuario (leer el área de mensajes).

Page 41: Diseño

...Modelo GOMSMétodos

Existen diferentes alternativas para la consecución de un objetivo. Por ejemplo en un gestor de ventanas, ésta se puede cerrar bien mediante combinación de teclas (Alt-F4), o ratón (Archivo-cerrar).

Reglas de selección Elección entre posibles alternativas para

alcanzar un objetivo. Se puede recoger el método más adecuado para cada usuario mediante una serie de reglas que aconsejan la estrategia más adecuada.

Page 42: Diseño

GOMSMétodos

externos Acciones de usuario observables

presionar una teclaEsperar un eventoMover el cursor

mentales acciones de usuario internas

Tomar una decisión básica Manipular un elemento de la memoria de trabajoEstablecer un objetivo

Page 43: Diseño

Method for goal: make tea Step 1. Accomplish goal: boil water Step 2. Decide: If Verify that pot is full Then empty pot Step 3. put leaves in pot Step 4. pour water Step 5. Wait for tea to brew Step 6. pour tea Selection rule set for goal: boil water If kettle is electric Then Accomplish goal: boil-water-in-kettle Else Accomplish goal: boil-water-on-stove Return with goal accomplished Method for goal: boil-water-in-kettle Step 1. fill kettle Step 2. turn kettle on Step 3. Wait for water to boil Step 4. Return with goal accomplished

Method for goal: boil-water-on-stove Step 1. fill kettle Step 2. light stove Step 3. put kettle on stove Step 4. Wait for water to boil Step 5. turn stove off Step 6. Return with goal accomplished

GOMSEjemplo NGOMSL

Page 44: Diseño

Entidad-relaciónEl modelado de entidad relación es una

técnica de análisis asociada normalmente con diseño de bases de datos y mas recientemente con programación orientada a objetos

En análisis de tareas estamos interesados en entidades no computacionales como los objetos físicos, las acciones realizadas con ellos y las personas que las realizan

Page 45: Diseño

Entidad relaciónSupongamos que queremos realizar un

análisis entidad relación de una empresa vendedora de flores, se empieza por enumerar todos los objetos de nuestro dominio de interés, herramientas de jardinería, un carro pequeño para el transporte de flores. Hay tres empleados, Carmen, Pedro y Juan. La empresa dispone de varios invernaderos. Tiene tambien un pequeño tractor para roturar los campos.

Page 46: Diseño

Entidad relaciónObjeto Pedro actor humano

Acciones:     P1: conduce tractor     P2: cultiva las flores  Objeto Carmen actor humano Propietaria Acciones:     V1: Planta semillas     V2: Programa el riego Acciones como propietaria:    V3: Organiza el trabajo de Pedro y Juan

Page 47: Diseño

Entidad-relaciónObjeto invernadero

Atributo:  Humedad: 0-100%

Objeto Controlador de riego actor no humano Acciones:   IC1: Abrir bomba1   IC2: Abrir bomba2  IC3: Abrir bomba3

Page 48: Diseño

Entidad-relaciónEventos:

  Ev1: La humedad cae por debajo del 25%   Ev2: Medianoche

Relaciones: objeto-objeto  posición(bomba3, invernadero)  posición(bomba1, campo1)

Page 49: Diseño

Entidad-relaciónRelaciones acción-objeto

  sujeto(V3,Pedro)     Carmen dice a Pedro que roture el campo   sujeto(P1, fresadora)     .. con la fresadora

Relación: acción-evento   disparo(EV1, IC3)     Cuando la humedad esté por debajo de

25%, el controlador pone en marcha la bomba1

Page 50: Diseño

DiálogoEl diálogo es el proceso de

comunicación entre dos o más participantes

En el diseño de interfaces de usuario, el diálogo representa la estructura de la conversación entre el usuario y la computadora

Page 51: Diseño

DiálogosTipos

Gramática Diagramas de transición UAN

Page 52: Diseño

DiálogosDiagramas de transición

Podemos expresar los posibles estados del sistema así como las transiciones entre ellos

Está formado por nodos y enlaces Nodos

Posibles estados del sistema Enlaces

Representan las posibles transiciones entre estados

Page 53: Diseño

Diagramas de transición

Page 54: Diseño

Diagrama de transiciónInterruptor y luz

S(on)L(encendida)

S(off)L(apagada)

U: S(off)

U: S(on)

S: switch (interruptor)L: Lampara

Page 55: Diseño

DiálogosDiagramas de transición

Page 56: Diseño

Diálogo - Diagrama de estadosCheckmate

Identificación

Contraseña

MensajeDe

error

ValidarDatos

personales

ModificarDatos

personales

error

error

Page 57: Diseño

Gramáticas

Este es uno de los primeros métodos que se utilizó para la representación del diálogo H-C. Las gramáticas se han usado con éxito para la descripción de lenguajes de programación. Las gramáticas expresadas mediante BNF permite especificar la sintaxis y la semántica BNF enfatiza la relación entre sintaxis y las acciones necesarias para realizar una orden.

Page 58: Diseño

GramáticasUna gramática basada en producciones describe un lenguaje como un conjunto

de reglas que especifican los literales correctos en el lenguaje La gramática consiste en:

Símbolos terminales (palabras del lenguaje) Representan acciones que el usuario tienen que aprender y recordarSímbolos no terminales

• Representan conjuntos de acciones similares que se deben agruparMetasímbolos

• ::=, | alternancia, () agrupacion, [ ] opcionalLa ventaja que posee es que se pueden usar herramientas para asegurar la

corrección y completitud. Adecuado para un lenguajes basados en órdenes. Las gramáticas multi-party posee símbolos no terminales que se etiquetan al

participante: usuario o computadora. <Sesión> ::= <U: Open> <C:Respuesta> <U:Open> ::= LOGIN <U: Name> <C: Respuesta> ::= HELLO [<U: Name>] Inconvenientes: No permite representar conceptos sensibles al contexto,

junto a su dificultad para comprensión.

Page 59: Diseño

Gramática BNF de una agenda

<agenda> ::= <Persona> <Telefono><Persona> := <Nombre> <Apellido> <Apellido><Nombre> ::= <string><Apellido> ::= <string><string> ::= <caracter> | <caracter> <string><telefono> ::= [ ‘(‘ Prefijo ‘)’ ] <Numero><Numero> ::= <digit> <digit> ‘-’ <digit> <digit>‘-’ <digit> <digit><caracter> ::= A | B | …| Z<digito> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

Page 60: Diseño

User Action NotationUAN es una especificación mediante

un lenguaje para la descripción de las tareas del usuario

Una especificación en UAN se realiza en una tabla dividida en 3 columnas: acciones de usuario realimentación de la interfaz estado de la interfaz

Page 61: Diseño

UANicon! Respuesta del sistema:

iluminar el icono icon-! Dejar de iluminar el objeto

icono icon > ~ Movimiento de arrastre del

objeto icono

Page 62: Diseño

User Action NotationEjemplo: Tarea.  borrar un fichero en el cubo de basura

UAN Feedback Estado Interface

1) ~[file] Mv File!, forall(file!): file-! Selected = file

2) ~[x,y]* Outline(file) > ~

3) ~[trash] Outline(file) > ~ Trash!

4) M^ Delete(file), thash!! Selected= null

 

Page 63: Diseño

Elementos a considerarPrincipiosReglasEstándaresGuias de estiloInternacionalizaciónAccesibilidad

Page 64: Diseño

Estrategia de diseñoModelo conceptual

describe mediante diagramas y descripciones el conocimiento que debe tener una persona acerca de un sistema

Modelo mental

Page 65: Diseño

DiseñoAnálisis de tareas

Especificación diálogos

Evaluación

Estándares

Guías

Experiencia

Requisitos

Prototipado

Implementación

Internacionalización

accesibilidad

Page 66: Diseño

ConclusionesEl análisis y diseño de la interfaz de

usuario es una parte fundamental en el proceso de desarrollo de cualquier aplicación

No se puede esperar al final para hacerlo

Page 67: Diseño

BibliografíaLores et al Introducción a la Interacción

Persona-Ordenador Gea, Miguel Capítulo de diseño

Pressman, Roger S 1997. Ingeniería del software. Un enfoque práctico.Cuarta Edición. Editorial Mc Graw Hill

Preece, Jenny (1994). Human-computer interaction. Addison and wesley.

Barbee, Teasley, Minatt (1990). Software Engineering with student software guidance. Prentice Hall


Recommended