El diseño (página 2)

. . GOAL: SELECCIONAR-PIEZA-ADECUADA

. . . [select GOAL: IDENTIFICAR-PIEZA

. . . . SELECCIONAR-TECLADO

. . . . ESCRIBIR-IDENTIFICACION-PIEZA

. . . . CONFIRMAR

. . . GOAL: COGER-PIEZA

. . . . MOVER-CURSOR-A-PIEZA

. . . . PULSAR-BOTON-RATON]

. . GOAL: ELEGIR-DESTINO

. . . [select GOAL: IDENTIFICAR-DESTINO

. . . . MOVER-CURSO-ARRASTRANDO-PIEZA

. . . . ESCRIBIR-IDENTIFICACION-POSICION

. . . . CONFIRMAR

. . . GOAL: SOLTAR-PIEZA

. . . . MOVER-CURSOR-ARRASTRANDO-PIEZA

. . . . SOLTAR-BOTON-RATON]

. GOAL: CONFIRMAR-MOVIMIENTO

. . . [select GOAL: TECLA-CONFIRMACION

. . . . PULSAR-ENTER

. . . GOAL: PARAR-RELOJ

. . . . MOVER-CURSOR-RELOJ

. . . . PULSAR-BOTON-RATON]

Selection Rule for GOAL: DETERMINAR-TURNO

Si es una visualización gráfica, usar el método CONOCER-MOVIMIENTO-SIGUIENTE

en otro caso usar el CONOCER-ULTIMO-MOVIMIENTO

Selection Rule for GOAL: SELECCIONAR-PIEZA-APROPIADA

Si no tienes ratón usar el método IDENTIFICAR-PIEZA,

en otro caso usar el método COGER-PIEZA

Selection Rule for GOAL: ELGIR-DESTINO

Si no tienes ratón usar el método IDENTIFICAR-DESTINO,

en otro caso usar SOLTAR-PIEZA

Selection Rule for GOAL: CONFIRMAR-MOVIMIENTO

Si estas usando el teclado usar el método TECLA-CONFIRMACION,

en otro caso usar el método PARAR-RELOJ

El modelo GOMS fue uno de los primeros métodos utilizados para el diseño de interfaces de usuario, teniendo gran repercusión en investigaciones posteriores. Permite describir cómo un experto realiza tareas y las descompone en subtareas. Sin embargo, una de sus puntos débiles es que sólo considera comportamientos sin errores y tareas secuenciales.

KLM

Uno de los modelo GOMS más simple es el KLM (KeyStroke Level Mode), que simplifica el conjunto de operaciones disponibles a la pulsación de teclas y movimiento de ratón. Esta simplificación permite obtener predicciones del tiempo que una persona empleará para la realización de una tarea.

Estas mediciones parten de unos valores experimentales que determinan mediciones concretas para la realización de actividades elementales. A partir de estos resultados experimentales, se puede deducir que por término medio:

• El tiempo de planificación de una tarea se puede estimar que dura 2-3 seg. si ya está definida, y de 5 a 30 seg. si hay que pensarla.

• El tiempo de respuesta del usuario para una acción varía notablemente según el tipo de dispositivo y de la destreza del usuario. Podríamos crear una tabla donde aparecen las operaciones más usuales sobre los dispositivos (pulsar tecla, mover ratón, etc.) y su tiempo en función de las habilidades del usuario.

Por ejemplo, podemos comparar el tiempo de respuesta entre el diseño de dos menús con mucha profundidad o con mucha ramificación. En un menú basado en ordenes numeradas (16 opciones). Partiendo de las siguientes hipótesis:

• Opciones con igual probabilidad

• Usuario experto mecanógrafo

Podríamos concluir con la siguiente medición. Una selección de un menú por su posición (1-16) necesitaría de los siguientes operadores:

• Operador M para buscar y visualizar el menú

• Uno o dos operadores K para introducir el número de ítem + 1K (pulsación de tecla ENTER)

M + K (1er dígito) + 0.44K* (2º dígito) + K (Enter)

1.35 + 0.20 + 0.44(0.20) + 0.20 = 1.84 seg.

* Usado para las opciones de la 10-16. Probabilidad 7/16 = 0.44

Se puede comparar con la utilización del ratón para la elección del menú. Para ello bastarán los siguientes operadores:

M + P + K (click ratón)

1,35 + 1.10 + 0.20 = 2.65 seg.

Como vemos, KLM para este caso podría predecir que la selección por teclado sería más rápida (efectiva) que la selección por menú.

Se puede utilizar para analizar igualmente el balanceo de los menús (profundidad), selecciones de elementos por identificador o apuntando, etc. Otra utilidad que posee este método es la de hacer explícito el conocimiento implícito que debe poseer el usuario acerca del sistema.

TAG

Este es otro tipo de formalismo para representar el conocimiento del usuario. TAG (Task Action Grammar) describe el conocimiento del usuario para realizar una determinada tarea en base a una gramática con características [HAR90]. El conocimiento que posee el usuario del tipo "como puedo hacer…" se puede expresar mediante un esquema que engloba a un conjunto de reglas individuales. Un esquema estará formado por una estructura sintáctica definida a partir de un conjunto de características. Las características (features) son atributos que definen la semántica de la tarea. La tareas que tenga estructuras sintácticas diferentes tendrá un esquema diferente. A partir de esta aproximación, se podrá medir la complejidad del interfaz mediante la identificación de características en la acción de tareas y de su agrupamiento en esquemas. El número de esquemas puede dar una orientación de la consistencia del lenguaje de la interfaz; a menos esquemas, el usuario puede inferir el comportamiento esperado del sistema a partir de un conocimiento parcial. Se parte del hecho que la simplificación del esquema es comprensible por el usuario. De este modo, la consistencia ayuda al aprendizaje, ya que podemos inferir nuevas tareas a partir de las conocidas.

Para abordar la especificación de un interfaz mediante TAG se deben seguir los siguientes pasos:

• Identificar tareas simples que el usuario puede realizar sin resolución de problemas (sin incluir estructuras de control)

• Describir las tareas simples en un diccionario (como conjuntos de componentes semánticos), reflejando la categorización de las tareas.

• Definición de reglas de reescritura que trasladan tareas simples en una especificación de acciones, donde los tokens son etiquetados con características semánticas procedentes del diccionario de tareas simples. Las etiquetas permiten la generalización.

Por ejemplo, podemos utilizar TAG para estudiar la consistencia del conjunto de órdenes de un Sistema Operativo (copy, rename, delete). Para ello, partimos de las descripción gramatical de estas tareas, y analizaremos cómo se pueden agrupar en esquemas:

Tareas simples

Copiar fichero nombre_fichero nombre_fichero

Copiar disco nombre_disco nombre_disco

Renombrar fichero nombre_fichero nombre_fichero

Borrar fichero nombre_fichero

Primeramente, deberemos identificar las características que aparecen en estas tareas y sus posibles valores. En este caso, las características corresponden con el tipo de atributo y sus posibles valores. También deberemos tener en cuenta cuando el objeto fuente y destino es el mismo, ya que en tal caso, se produce un cambio en el objeto (y es una característica a tener en cuenta):

Objeto_antiguo [fichero disco, vacio]

Objeto_nuevo [fichero, disco, vacio]

Produce_cambio [si, no]

Una vez obtenidas las características y sus valores, se deberán reescribir las tareas simples mediante estas características, de modo que definan unívocamente su significado:

Copiar fichero [Obj_antiguo=fichero, Obj_nuevo=fichero, cambio= no]

Copiar disco [Obj_antiguo=disco, Obj_nuevo=disco, cambio= no]

Renombrar fich [Obj_antiguo=fichero, Obj_nuevo=fichero, cambio= si]

Borrar fichero [Obj_antiguo=fichero, Obj_nuevo=vacio, cambio= no]

A partir de estas tareas podríamos obtener un único esquema a partir de tres características que lo definen.

Task [obj_ant, obj_nuevo, cambio] :=

Orden[obj_ant, obj_nuevo, cambio]+param1[Obj_ant]+param2[obj_nuevo]

Cada orden vendría dada por un nombre (de la tarea a realizar) y dos parámetros. Los valores para estos argumentos vendrían dados unívocamente por el valor de las características:

tarea[obj_ant=fichero, obj_nuevo=fichero, cambio=si] := "ren"

tarea[obj_ant=fichero, obj_nuevo=fichero, cambio=no] := "copy"

tarea[obj_ant=disco, obj_nuevo=disco, cambio=no] := "diskcopy"

tarea[obj_ant=fichero, obj_nuevo=vacio, cambio=no] := "delete"

param1[obj_ant=vacio] := NULL

param1[obj_ant =fichero] := drive-id + "nombre_fichero"

param1[obj_ant=disco] := drive-id

param2[obj_nuevo=vacio] := NULL

param2[obj_nuevo =fichero] := drive-id + "nombre_fichero"

param2[obj_nuevo=disco] := drive-id

drive-id := NULL | "A:" | " "B:" | "C:" | …

TAG no realiza predicciones absolutas de rendimiento. Mas bien, se puede utilizar para generar hipótesis que deben ser probadas experimentalmente.

TAG se ha utilizado para medir la consistencia de lenguajes de órdenes (UNIX, MSDOS), aunque también se puede generalizar para acciones de manipulación directa, ubicación de órdenes en menús, etc.

La evaluación de la consistencia del lenguaje del interfaz de usuario puede ser muy sencillo de estimar con TAG. Así por ejemplo, podríamos detectar rápidamente inconsistencias en el lenguaje de órdenes como en este ejemplo, donde las órdenes no poseen la misma estructura. El esquema tiende a ser menos consistente conforme aumenten los esquemas. Como consecuencia, el número total de reglas no es importante, sólo el numero de esquemas.

La consistencia está muy relacionada con la facilidad de aprendizaje. Podríamos estimar que existe una relación directa entre el tiempo de aprendizaje necesario y el número de esquemas que aparecen del lenguaje.

UAN

Las técnicas basadas en gramáticas no resultan adecuadas para la descripción de la interacción en interfaces gráficas de usuario basadas en el paradigma de manipulación directa ya que no permiten describir la realimentación visual (feedback) del sistema. A esto se une la dificultad de especificar tareas basadas en el arrastre de iconos ya que su semántica depende del lugar donde se suelte. En este sentido, UAN (User Action Notation) es una notación centrada en el usuario para descripción de tareas. Su principal característica es la descripción física de las acciones a realizar en el proceso de interacción [HAR95].

Una especificación en UAN se realiza mediante una tabla dividida en 3 columnas describiendo las acciones de usuario, la realimentación de la interfaz y el estado del sistema tras la acción. Las acciones de usuario y la realimentación poseen una notación donde explícitamente se designa la manipulación que se realiza sobre los objetos de la interfaz. Así por ejemplo, las acciones Mv y M^ denotan el efecto de pulsar y soltar el botón del ratón, ~[fichero] representa el movimiento del ratón en el contexto del objeto fichero mientras que fichero > ~ significa que el objeto fichero se está arrastrando. Del mismo modo podemos especificar la respuesta del sistema (feedback) para cada acción tales como la una selección en vídeo inverso de un icono (fichero!), vídeo normal (fichero-!), o un parpadeo (fichero!!). La siguiente descripción especifica la tarea de borrar un fichero mediante técnicas de arrastre.

Esta especificación nos permite especificar la tarea de arrastrar un fichero a la papelera mediante el proceso que se muestra gráficamente en la Figura 7.

Figura 7 Manipulación directa descrita mediante UAN

ConcurTaskTrees (CTT)

CTT es una notación desarrollada por Fabio Paternò [PAT00] cuyo principal finalidad es la de poder representar las relaciones temporales existentes entre las actividades y usuarios que son necesarios para llevar a cabo en las tareas. En concreto, esta notación es especialmente útil para aplicaciones CSCW (ver capítulo "Trabajo cooperativo con ordenador").

Una de las principales ventajas de esta notación es su facilidad de uso, lo que hace que sea aplicable a proyectos reales con aplicaciones de un tamaño medio–largo y que con llevan especificaciones de cierta complejidad. La notación genera una representación gráfica en forma de árbol de la descomposición jerárquica de las tareas existentes en el sistema. Se permite la utilización de un conjunto de operadores, sacados de la notación de LOTOS, para describir las relaciones temporales entre tareas (secuencialidad, concurrencia, recursión, iteración…)

Podemos reutilizar partes de especificación para la creación de "árboles de tareas concurrentes" e identificarlo como un patrón de tarea. Podemos identificar 4 categorías de tareas en función del actor que la llevará a cabo.

Para la descripción se utilizan además una serie de operadores temporales que facilitan la descripción de las relaciones temporales existentes entre tareas. Estos operadores se han obtenido como una extensión de los operadores existentes en LOTOS [EIJ89]. El uso de estos operadores facilita la descripción de comportamientos complejos. Los operadores temporales que podemos usar son:

T1 ||| T2. Entrelazado (Concurrencia independiente). Las acciones de las dos tareas pueden realizarse en cualquier orden.

T1 |[]| T2. Sincronización (Concurrencia con intercambio de Información). Las dos tareas tiene que sincronizarse en alguna de sus acciones para intercambiar información.

T1 >> T2. Activar (enabling). Cuando termina la T1 se activa la T2. Las dos tareas se realizan deforma secuencial.

T1 []>> T2. Activar con paso de información. Cuando termina T1 genera algún valor que se pasa a T2 antes de ser activada.

T1 [] T2. Elección. Selección alternativa entre dos tareas. Una vez que se esta realizando una de ellas la otra no esta disponible al menos hasta que termine la que esta activa.

T1 [> T2. Desactivación. Cuando se da la primera acción de T2, la tarea T1 se desactiva.

T1 [][> T2. Desactivación con paso de información. Igual que la anterior pero pasando información de una tarea a la otra.

T1*. Iteración. La tarea T1 se realiza de forma repetitiva. Se estará realizando hasta que otra tarea la desactive.

T1(n). Iteración finita. La tarea T1 puede darse n veces. Se utiliza cuando el diseñador conoce cuantas veces tiene que realizarse la tarea.

[T1]. Tarea opcional. No es obligatorio que se realice la tarea. Cuando describimos las subtareas existente en la tarea de rellenar un formulario algunas de las subtareas pueden ser opcionales (las de los campos que sean opcionales).

A la descripción jerárquica de las tareas se le añade la descripción de los objetos que son manipulados por las distintas tareas. Estos objetos pueden clasificarse en dos grupos:

• Objetos perceptibles. Son objetos gráficos que sirven para presentar información al usuario (ventanas, tablas, gráficos…) o elementos sobre los que el usuario puede interactuar (menús, iconos…).

• Objetos de aplicación. Elementos que pertenecen al dominio de la aplicación. La información que almacenan estos objetos tiene que ser mapeada a alguno de los otros para poder ser percibida por el usuario.

Cada objeto puede ser manipulado por mas de una tarea. Como ejemplo de especificación utilizando los ConcurTaskTrees podemos ver una parte de una aplicación para acceder a información sobre un museo. En la Figura 8 se muestra el modo de introducir la información por parte del usuario sobre el tipo de artista que está buscando y el sistema le presenta la información asociada a el.

Figura 8 Tarea de acceso a un museo mediante CTT

Se comienza con la tarea "Acceso_Museo_Virtual" que puede ser interrumpida en cualquier momento ([>) por la tarea "Cerrar". En un siguiente nivel podemos ver la tarea de interacción "Selecc_Tipo_Arte" con la que se describe la selección del tipo de arte sobre el que se requiere información, seguido (>>) por la selección del periodo histórico en el que esta encuadrada la obra del artista. La siguiente tarea a realizar es el acceso a la información del artista para ello se ha obtenido información de las tareas anteriores ( []>> operador activación con paso de información). Algunas de estas tareas se van a descomponer en nuevas tareas de manera jerárquica. Así la tarea "Selecc_adicional" permite seleccionar un artista mediante una lista alfabética o mediante una lista ordenada por periodos históricos.

La descripción de tareas cooperativas consiste en tareas que requieren de la participación de más de un usuario para poder llevarla a cabo. Esta descripción se puede realizar creando un árbol donde aparecerán las tareas cooperativas, que se denotarán con un identificador especial. Por ejemplo, una solicitud de información se podría modelar del siguiente modo:

Figura 9 Tarea cooperativa con CTT

Modelos arquitectónicos

Los modelos arquitectónicos son una alternativa (en algunos casos complementaria) para la representación de sistemas interactivos. En este caso, se pretende obtener un modelo del sistema a desarrollar, centrándose en los aspectos computacionales básicos en los que debe estar basado.

Los primeros modelos que se proponen en este sentido son para describir el sistema interactivo en su conjunto recogiendo sus características esenciales. Si bien los primeros modelos como Seeheim o ARCH se centraban en aspectos funcionales, las últimas propuestas definen una arquitectura modular basada en componentes como MVC o PAC. También podemos encontrar propuestas encaminadas hacia un diseño basado en modelos concretos del sistema con herramientas para su obtención automática como puede ser MOBI–D, HUMANOID, etc. (ver capítulo "Herramientas").

Los aspectos más relevantes de estas propuestas se centran en la modelización de los componentes interactivos (estructura) y mecanismo de interacción (diálogo).

Modelos de componentes interactivos

Los modelos basados en componentes realizan la descripción del sistema como una colección de interadores, elementos básicos que encapsulan interacciones elementales con las que se pueden construir interacciones más complejas.Estos modelos definen las características de los objetos con los que interactúa el usuario (como listas, deslizadores, ventanas, etc.). El modelo conceptual debe reflejar los aspectos relevantes del cualquier componente interactivo (apariencia, eventos, comunicación, etc.). Normalmente esta arquitectura es modular por lo que permite la composición de componentes para crear sistemas más complejos.

Uno de los modelos que más se ha utilizado para la especificación de sistemas interactivos es el denominado interador (de York) [DUK95]. Un interador (interactor) consiste en un estado y un conjunto de acciones que puede percibir e invocar el entorno a través de una interfaz bien definido. Esta definición recoge los elementos esenciales de cualquier elemento interactivo (su estado actual, visualización y eventos para su manipulación. Una parte importante de esta interfaz es la representación gráfica del componente (presentación), que es perceptible por el usuario del sistema. Bajo este modelo, podemos describir elementos interadores abstractos, que posteriormente se plasmará en los lenguajes de especificación.

El concepto de interador ha sido utilizado ampliamente para construir metodologías de diseño de sistema interactivos. La mayor diferencia entre ellas es el lenguaje de especificación utilizado, Z, Lotos, álgebra de procesos, etc.

Figura 10 Modelo de interador de York

Podemos realizar una descripción más detallada de un interador utilizando para ello conceptos que aparecen en los sistemas concurrentes. Así, un interador es un modelo abstracto basado en procesos, canales de comunicación y señales de control que definen un componente interactivo con capacidad de representación gráfica y modificación dinámica. Su estructura favorece la interconexión de interadores para realizar modelos de interacción complejos.

En el siguiente esquema se detallan los procesos que definen su funcionalidad, así como las comunicaciones entre los mismos. La idea que se recoge bajo el paradigma del interador es la de representar un componente activo que posee una apariencia gráfica y una medida que representa el valor actual del interador (o estado). Este valor puede modificar la apariencia del interador, así como externamente podemos variar la forma de obtención de la medida. Podemos sincronizar los distintos procesos mediante señales de control.

Un interador se puede describir mediante cuatro procesos. Collection proporciona una descripción de alto nivel de la apariencia gráfica del objeto. Feedback se encarga de producir la apariencia externa del objeto. Measure obtiene un dato de un nivel inferior, y Control, se encarga de generar una nueva medida para el nivel superior. Las entradas y salidas del interador se definen por medio de canales de comunicación: im, oc, od y eo. La sincronización se realiza mediante dos señales de control: it y ot.

Figura 11 Esquema de un interador

Podemos trasladar el concepto de interador a diferentes lenguajes de especificación. La definición formal de un interador mediante LOTOS [EIJ89, FAC92] es la siguiente:

En la especificación se describen las distintas sincronizaciones que se deben garantizar sobre los procesos que conforman la estructura del interador. Así, por ejemplo, el proceso feedback se encarga de producir su apariencia gráfica producto de una modificación de la medida (me) o bien de un cambio de apariencia (cf). Podemos asociar a cada canal de comunicación información acerca del tipo de dato que transporta. Por ejemplo el canal de comunicación eo definirá sus datos de tipo gráfico: eo?p : Picture, especificado en ACT ONE. Una de las ventajas que tiene LOTOS (y en general todos los métodos basados en álgebra de procesos) es que explicitan todas las sincronizaciones que aparecen en un sistema interactivo.

Se han desarrollado metodologías para diseñar sistemas interactivos utilizando los interadores en las que se describen las posibles formas de interconectarlos para describir interacciones complejas.

En la siguiente imagen podemos ver como se interconectarían tres interadores para describir parte de un sistema en el que se van a utilizan iconos para representar objetos como ficheros, directorios y unidades de disco. El usuario puede manipular los iconos por medio del ratón y puede modificar el estado de los iconos usando también entradas de un menú.

Se pueden utilizar otros formalismos para la descripción de interadores como por ejemplo la lógica temporal. En [DUK95] se realiza una combinación de un modelo de interador con lógica. Los axiomas se especifican en lógica modal de acciones (MAL), de forma que, junto a los predicados basados en lógica de primer orden, se extiende con un conjunto de operadores modales, que controlan las acciones que se pueden provocar en el sistema. MAL incluye el concepto de agentes (humanos y ordenador) y las responsabilidades mutuas entre ellos. Los operadores usuales son el permiso (per) y la obligación (obl) bajo un paradigma deontológico.

Figura 12 Red de interadores para controlar iconos

En la Figura 13 se observa cómo se pueden especificar mediante lógica modal el modelo de interador. El concepto de estado se recoge en la colección de atributos, mientras que la interacción se refleja en la sección de acciones disponibles en el entorno para su manipulación. Cada acción o componente del estado posee calificadores, indicando si posee apariencia gráfica (vis: visual), o limitación en cuanto a su utilización por el usuario (any: cualquier modalidad).

interactor button

attributes

vis

selected : B // botón seleccionado o no

vis

enabled : B // botón habilitado o no

actions

any

select

any

toggle

axioms

[1] enable ? selected = B ( [select] selected = ?B

[2] enabled = B ( [toggle] enabled = ?B

[3] per(select) ( enabled

Figura 13 Especificación de un botón

Podemos encontrarnos axiomas con predicados de la forma "P ( [A] Q" , de modo que si se satisface P, cuando se realice la acción A, Q será cierto. Otro operador, per(A) denota permiso para que la acción A pueda ocurrir, mientras que obl(A) indica que esa acción obligatoriamente debe ocurrir.

Modelos del diálogo

En el diseño de sistemas interactivos, existen muchos aspectos a considerar, el contexto organizacional, los tipos de usuarios, los dispositivos de comunicación, los estilos de interacción, la influencia de la aplicación subyacente, etc. Sin embargo, un aspecto fundamental en estos sistemas es la estructura del diálogo, la descripción de la comunicación de cada participante. Uno de los componentes cruciales en los sistemas interactivos es la descripción del diálogo. Su complejidad y naturaleza dinámica hace aconsejable la utilización de un modelo que permita su correcta especificación.

Gramáticas

Las gramáticas nos permiten describir secuencias, elección e iteracción como elementos básicos del proceso del diálogo. Se puede utilizar herramientas tales como lex&yacc para obtener un prototipo de la comunicación. Las gramáticas describen el diálogo como reglas de producción. BNF enfatiza la relación entre sintaxis y las acciones necesarias para realizar una orden. Una 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 reservadas del lenguaje). Representan acciones que el usuario tienen que aprender y recordar.

• Símbolos no terminales. Representan conjuntos de acciones agrupadas para realizar una actividad/tarea.

• Metasímbolos. ::= (definición), | alternancia, () agrupacion, [ ] opcional

Este método es muy adecuado para estilos de diálogo basados en órdenes. Una extensión de este modelo (las gramáticas multi–party) permite identificar al participante que actúa en la interacción (U: usuario, C: computadora):

::=

::= LOGIN

::= HELLO []

Sin embargo, uno de los mayores inconvenientes que posee es que no permite representar conceptos sensibles al contexto, junto a su dificultad para su comprensión con especificaciones largas.

Diagramas de transición de estados (STN)

Ha sido uno de los primeros métodos utilizado para la descripción del diálogo. Con diagramas STN podemos expresar los posibles estados del sistema así como las transiciones entre ellos. El diagrama de transiciones está formado por nodos y enlaces. Los nodos representan los posibles estados del sistema. Los enlaces representan las posibles transiciones entre estados. Podríamos incluso identificar el actor que ha provocado la acción. Las acciones del usuario será aquellas transiciones realizadas directamente por la participación directa del usuario.

U: Usuario

S: Sistema

T: transición temporal

Figura 14 STN de una lámpara

Este tipo de especificación muestra el flujo de acciones y determina el estado tras una acción. Con el mismo, podemos describir las posibles acciones de usuario, así como los estados críticos del sistema. Por ejemplo, la descripción del mecanismo de encendido de una lámpara se puede describir del siguiente modo.

Se puede utilizar para la descripción de mecanismos de interacción más complejos, como por ejemplo, para la especificación de un portapapeles.

Sin embargo, un problema asociado a este tipo de descripción es la explosión combinatoria de estados en cuanto existan diálogos concurrentes. Por ejemplo, las diferentes opciones para el estilo del texto (itálica, negrita, subrayado, etc.) provocan una explosión combinatoria de 2n estados, con n siendo el número de opciones.

Figura 15 Descripción de un portapapeles

Redes de Petri

Si consideramos los sistemas interactivos como un caso particular de sistemas reactivos, podríamos utilizar todas las técnicas y herramientas que se disponen para la especificación y diseño de sistemas concurrentes. Existen abundantes referencias de la utilización de Redes de Petri, CSP o LOTOS para la descripción de procesos, sincronizaciones, eventos y no determinismo. Dentro de todos estos formalismos uno de los mas usados a la hora de especificar la naturaleza concurrente de un sistema interactivo son las Redes de Petri.

Figura 16 Red de Petri para las opciones del texto

Es uno de los formalismos más antiguos en computación para una representación gráfica de actividades concurrentes. En un STN, el sistema se encuentra en un estado en cualquier instante y se puede simular el comportamiento siguiendo los arcos. La red de Petri es similar, pero con la diferencia que puede tener varios estados al mismo tiempo. Una red de Petri se compone de lugares (círculos) transiciones (rectángulos) y marcas (que pueden cambiar de lugar mediante una transición). Por ejemplo, para especificar la concurrencia de opciones (negrita, cursiva) para el texto se puede realizar de forma sencilla con redes. Las acciones del usuario están explícitamente recogidas así como el estado del sistema (mediante las Marcas).

Los lugares elípticos representan las acciones del usuario. La regla de las redes de Petri es que si todos los lugares de una transición poseen Marca (están Marcados), la transición se puede disparar. En este ejemplo, la acción del usuario "pulsar negrita" provocará la transición T1 que desactiva la negrita. La siguiente pulsación del usuario "pulsar negrita" provocaría que en este caso, se disparase la transición T2. Se puede describir arcos inhibitorios, como por ejemplo, no puede suceder T3 mientras que esté el contador en Negrita (on).

Diseño orientado a objetos

Los interfaces de usuario son muy adecuados para un desarrollo basado en el paradigma de objetos [COX93], ya que el sistema está formado por componentes de naturaleza manipuladora (interactiva) con representación gráfica y en la que existe una gran vinculación (mediante herencia) de unos componentes con otros.

Una estructura típica del modelo conceptual es un conjunto de objetos capaces de realizar una serie de acciones (modelo objeto–acción).

• Objetos: Un objeto es un elemento de información sobre el que el usuario tiene algún control. El conjunto de objetos posee usualmente alguna estructura. Dicho conjunto es una visión abstracta de la información gestionada por el sistema (modelo).

• Acciones: Una acción es una operación que el usuario puede realizar con un objeto. El conjunto de acciones define la capacidad funcional del sistema. El conjunto de acciones no tiene que ser necesariamente ortogonal al de los objetos. Estas acciones serán las tareas que debe realizar el usuario para manipular los objetos del dominio de la aplicación.

Ejemplo: Flexo. Un flexo dispone de una bombilla, un interruptor y una clavija de enchufe. El interruptor puede estar en una de dos posiciones (encendido o apagado), la clavija se puede conectar y desconectar a una base de enchufe. Cuando la clavija está conectada a una base en buen estado y el interruptor esta en la posición de encendido, la bombilla se ilumina.

Podemos identificar dos tipos de objetos: a) aquellos que aparecen en la comunicación entre el usuario y el sistema y que típicamente pertenecen a la interfaz (objetos de control), y b) los que son propios de la aplicación (objetos intrínsecos). Por ejemplo, una barra de iconos, una regla o una ventana son objetos intrínsecos con acciones propias (mover, ocultar, redimensionar, etc.) mientras que el registro de una persona es un objeto de control susceptible de aplicarle acciones del dominio de la aplicación (insertar, modificar, ver DNI, etc.). Para la descripción de los objetos y de las acciones podemos usar metáforas que ayuden a comprender su significado y utilización (ver capítulo "Metáforas, estilos y paradigmas").

Para la especificación del sistema deberemos identificar tanto a los objetos como a sus acciones asociadas. Los objetos se describen identificando sus atributos más relevantes. Uno de los más importantes es su representación gráfica. Para describir las acciones se puede utilizar una notación de diálogo basada en diagramas de estado y lenguaje de órdenes (secuencia). El lenguaje de órdenes nos daría información necesaria acerca del protocolo (qué acción se realiza), mientras que el diagrama de estado indicaría cómo cambia el estado de los objetos con las modificaciones (cómo implementarlo).

Lenguaje de órdenes

En un sistema interactivo basado en objetos, podemos identificar un conjunto de órdenes que deben aparecer en el modelo para poder representar y manipular los objetos del interfaz de modo gráfico e interactivo. Alguna de ellas son:

• Selección/deselección de un objeto

• Búsqueda/Identificación de un objeto

• Creación/eliminación de objetos

• Mover/copiar objetos

• Obtener/cambiar valores de los atributos del objeto

• Visualización del objeto

Además podemos encontrarnos con objetos complejos que poseen acciones específicas:

• Agrupación. Es un objeto formado por otros objetos. Se pueden ubicar y eliminar componentes así como conocer sus valores.

• Colección. Es un objeto que contiene un número variable de objetos. Se pueden añadir nuevos objetos, eliminar, ordenar/clasificar, etc.

Lenguaje modal

Un modo es un estado (o conjunto de estados) en cual se puede realizar un conjunto de posibles tareas de interacción por el usuario [FOL90]. Ejemplos de diálogos modales son:

• Estado en el cual se permite que un conjunto de órdenes se pueda aplicar únicamente al objeto/s seleccionado/s (modos sobre selecciones).

• Estado en el cual se debe completar un cuadro de diálogo antes de hacer otra operación (ventana modal).

• Estado en el cual se usa un programa externo para modificar un objeto (gráfico, diagrama, etc.).

Los modos pueden aparecer por la estructura que posea el lenguaje de órdenes. Las sintaxis del lenguaje puede tener las siguientes estructuras:

• Acción–Objeto. En primer lugar se identifica la acción a realizar y a continuación se aplica sobre el/los objeto/s. A nivel de sintaxis esto está asociado a la posibilidad de que existan producciones del tipo

O ::= ( c ( ( c

en las que el significado de ambas opciones sea diferente ((=copiar, (=borrar). En tal caso el lenguaje es modal, ya que la interpretación de una entrada depende del estado (previo) de la aplicación.

• Objeto–Acción. En este caso, primeramente se selecciona el objeto de interés al que se va a aplicar la acción. Se puede utilizar la selección múltiple. Esta sintaxis es especialmente adecuada para paradigmas basados en la manipulación directa, ya que primeramente se identifica el objeto sobre el que se quiere actuar.

Los modos pueden ser beneficiosos o perjudiciales según el uso que se haga de ellos. Los diálogos modales que no son perceptibles (visibles por el usuario) y que no tienen un significado coherente aumentan la probabilidad de error por parte del usuario y su dificultad de aprendizaje. Un dialogo modal bien diseñado deberá indicar claramente el modo actual (por ejemplo inserción/sobreescritura en un editor), suministrar información acerca de las órdenes disponibles y disponer de significados intuitivos para las acciones asociadas.

Modelos abstractos

El estudio de los sistemas interactivos como sistemas reactivos permite estudiar propiedades relacionadas con estos sistemas tales como la ausencia de interbloqueos o inanición. Sin embargo, desde el punto de vista de la interacción con el usuario, las propiedades deseables del sistema están relacionadas con la parte de interacción con el humano, tales como: las propiedad de comenzar nuevamente (Restartability), deshacer la última acción en cualquier momento (Undo), utilizar toda la funcionalidad de la aplicación (completitud), capacidad para cancelar en cualquier momento la ejecución de una tarea, observación en todo momento del estado del sistema (Observabilidad), etc.. Básicamente este tipo de propiedades de interés se pueden resumir en los siguientes casos:

• Predecibilidad. Se trata de reconocer y predecir cual será el efecto futuro del sistema ante una nueva interacción. Esta propiedad permite medir la consistencia del sistema.

• Alcanzabilidad. Esta propiedad permite razonar y determinar si el usuario tiene acceso en todo momento a la funcionalidad del sistema. Esta propiedad permite medir la completitud del sistema.

En este sentido, los métodos que se utilizan son meramente descriptivos. La notación y el fundamento matemático en el cual están basados permiten expresar propiedades y por tanto, se podrán utilizar para razonar y verificar ese tipo de propiedades.

El Modelo PIE

El modelo PIE [DIX91] ofrece una visión externa del sistema, donde se recoge el comportamiento visible por parte del usuario. Bajo este modelo de caja negra, PIE describe el sistema en base al efecto perceptible que produce la interacción (entradas de usuario) sobre el sistema. Las entradas son un conjunto de órdenes (P) que forman parte de un programa. El efecto (E) observado por el usuario es resultado de un proceso de interpretación (I), de modo que para cada entrada posible, podemos obtener su interpretación como una función de transformación del dominio de las entradas al dominio de los efectos:

Figura 17 Red–PIE

En este modelo abstracto, P representa las entradas de usuario, E representa el efecto producido, mientras que I es la función de interpretación.

Un problema de predecibilidad se podría expresar formalmente mediante la propiedad de monotonía, del siguiente modo:

( p1,p2 ( P: I(p1) = I(p2) ( ( p ( P : I(p1·p) = I(p2·p)

es decir, en el caso que dos tipos de entradas de usuario posean la misma interpretación, esto significa que el efecto será siempre equivalente, cualquiera que sea el estado del sistema (dado por acciones previas). En caso de no satisfacerse esta propiedad, tendríamos un sistema ambiguo en donde no podríamos predecir el resultado de las acciones a partir de la interacción del usuario, el sistema no es determinista.

Desde este punto de vista, el concepto de efecto es muy amplio, por lo que usualmente se utilizará el modelo red–PIE que extiende el modelo anterior para diferenciar el efecto que es percibido por el usuario (D) del resultado que es alcanzado por el sistema (R).

Figura 18 Red–PIE

Mediante esta aproximación, se podría establecer relaciones entre el estado del sistema (R) y la observación del usuario (D). El problema de los sistemas no predecibles puede estar ocasionado porque existan efectos que modifican el estado del sistema y que no sean percibidos por el usuario (no son observados). Por tanto, se deberá enunciar la predecibilidad desde el punto de vista de la percepción del usuario, es decir:

( p1,p2 ( P: d(I(p1)) = d(I(p2)) ( ( p ( P : I(p1·p) = I(p2·p)

La propiedad de alcanzabilidad garantiza que se puede realizar cualquier tarea sobre la interfaz de usuario, independientemente del estado actual del sistema, es decir:

( p,q ( P?(r( P : I(p·r) = I(q)

La opción de deshacer una orden (undo) será un caso particular de alcanzabilidad.

Este mecanismo es simple pero potente para hablar de propiedades. Sin embargo, el modelo es demasiado abstracto como para su utilización para el diseño y desarrollo de sistemas interactivos, y no permite la descripción de sistemas asíncronos debido a su carácter determinista.

Estrategia de diseño

Con los modelos que se disponen de las tareas y de la arquitectura del sistema, deberemos guiar el diseño para obtener una implementación correcta. Este proceso en algunos casos puede ser automático, pero en la mayoría de los casos, requerirá de un profundo reconocimiento de los aspectos más delicados del proceso de diseño y que está directamente relacionados con el diálogo con la máquina y la presentación de la información. Nos centraremos en los mecanismos básicos de interacción y el diálogo con la aplicación y la capa de presentación.

Tareas de interacción

Cuando el usuario realiza una interacción con el ordenador, introduce una unidad de información que posee significado en el contexto de la aplicación. EL tipo de interacciones que se pueden realizar en el sistema son [FOL90]:

• Posicionamiento. Obtención de una posición u orientación. La posición puede ser en cualquier dimensión (2D, 3D). Se puede usar para dibujo, situar ventanas, arrastrar elementos, etc.

• Valor. Obtención de un dato cuantificable, ya sea numérico (por ejemplo, el número de página, nº de copias, etc.) o porcentual (p.e. barra de progresión).

• Texto. Introducción de un texto o identificador (nombre de fichero, apellidos, etc.).

• Selección. Obtención de una alternativa (de entre varias posibles). Se puede distinguir entre la selección sobre un conjunto finito o bien de tamaño variable, en el cual la opciones pueden ser alternativas disyuntivas o no.

• Arrastre. Secuencia de posiciones entre una posición inicial y otra final (por ejemplo movimiento de una carpeta con el ratón).

A cada una de estas interacciones podemos aplicarles un conjunto de técnicas que nos permitan facilitar y flexibilizar el modo de obtención de la información.

Tarea de posicionamiento

Esta tarea consiste en la obtención de una coordenada 2D o 3D. La acción que se realiza es la de mover un cursor por pantalla para introducir un valor, o introducir la coordenada directamente. Algunos de los aspectos a tener en cuenta son:

• Sistema de coordenadas. El movimiento del objeto puede ser en función de un sistema de coordenadas del propio objeto, de la pantalla o del mundo. Este factor es muy importante en los sistemas de modelado de posicionamiento 3D (Realidad Virtual).

• Resolución: En caso de movimiento con un dispositivo (cursor) las posiciones pueden ser discretas o continuas. Habrá que tener en cuenta la relación Control/Display (C/D) para mecanismos de posicionamiento indirecto, es decir, la distancia que hay que mover el puntero (ratón) en la mesa para obtener una nueva posición diferente en pantalla.

• Restricciones. Se puede utilizar elementos que ayudan al posicionamiento como la rejilla (grid) que facilitan la introducción de los puntos ajustados a valores. Esta rejilla puede ser direccional (sobre una única dirección) modular (restringido a una retícula) o gravitacional (a unos puntos sensitivos).

• Realimentación. La realimentación puede ser espacial (visualización gráfica del cursor en pantalla), relacionada con otros elementos), o lingüística (representando el valor numérico en coordenadas cartesianas).

Figura 19 Diferentes técnicas de ayuda en el posicionamiento

Tarea de selección

Esta tarea básica consiste en la selección de un elemento de entre un conjunto (de órdenes, atributos, objetos..). El conjunto puede ser:

• Tamaño fijo: Elementos invariables (órdenes, etc.)

• Tamaño variable: Elementos de la aplicación (objetos)

La tarea de selección se puede realizar de los siguientes modos:

• Mediante identificador: La selección se realiza introduciendo el identificador del objeto (nombre)

• Apuntando: Búsqueda espacial del objeto mediante un dispositivo apuntador (ratón)

Figura 20 Selección en lista variable de objetos (gráficos)

La selección sobre conjunto de objetos de tamaño variable se organiza sobre listas dinámicas o bien en ventanas (que actúan como contenedores) donde se disponen los elementos con diferentes alternativas de presentación (gráfica, textual, icónica, etc.) y modo de ordenación.

La selección sobre conjuntos de tamaño fijo utiliza otros mecanismos de representación. Uno de los más utilizados es la presentación mediante menús y se usa para la selección de órdenes. Cada orden es un ítem dentro del menú, y se pueden utilizar diferentes técnicas para estructurar el conjunto de elementos (jerarquías, separaciones, atajos, etc.).

Figura 21 Organización de un menú

Otras posibles representaciones para la selección son los botones (o conjuntos de botones agrupados en barras de iconos). Los botones pueden tener una representación gráfica icónica o bien estar basado en el texto. Se pueden inhabilitar botones (representados en un tono claro) en caso que la orden no esté activa en ese momento.

Figura 22 Barra de botones (icónica)

Otras estructuras para la selección son la listas en sus diferentes representaciones (desplegables) o fijas.

Para el caso de selección sobre valores lógicos, se utilizan elementos que representen dos posibles estados (seleccionado o no). Generalmente se utiliza la casilla de verificación como elemento gráfico que representa un valor lógico (si no aparece pulsada equivale a falso/no). En caso de seleccionarse la casilla, aparece un símbolo (() que recuerda a una marca hecha con bolígrafo.

En caso de casillas de verificación, podemos encontrarnos conjuntos de cuestiones donde las opciones son mutuamente excluyentes (sólo se puede seleccionar una de las casillas). Para diferenciar estos dos tipos de casillas gráficamente, tradicionalmente se ha utilizado una representación circular para las selecciones excluyentes y cuadrada para las casillas de comprobación. Estas casillas pueden estar incluidas en los menús.

Figura 23 Casillas de verificación

En ambos casos de selección, ya sea de tamaño fijo o variable, un factor muy importante es la ubicación espacial de los ítems (órdenes, objetos) para su rápida selección, el texto del identificador (para su reconocimiento) y la organización semántica (para recordar su posición).

Tarea de introducción de texto

Esta tarea consiste en la introducción de información textual. Existen alternativas a la introducción de texto por teclado como son los reconocedores de caracteres (OCR) y de gestos. Un aspecto importante relacionado con el texto es su resolución (tamaño en pantalla), que se mide en puntos o píxels. Se deben utilizar tamaños y tipos de letra que sean legibles y proporcionales a la resolución de pantalla que posea en ese momento el usuario. El texto puede ser longitud variable y ocupar más de una línea, por lo que se consideran dos tipos de presentación, una entrada de tamaño fijo (con posible control del formato) o un área de texto (con uso de deslizadores).

Tarea de introducción de valor

Esta tarea consiste en la introducción de un dato cuantificable. En caso de identificar un número, la forma habitual es mediante el teclado numérico, aunque en determinados casos, se utilizan representaciones gráficas (diales, deslizadores, etc.) que ayudan a una introducción mediante ratón.

Figura 24 Deslizador

En caso de valores porcentuales (sobre un valor de tamaño variable o de tiempo para completar una acción) también se pueden utilizar representaciones, pero en este caso, no son directamente manipulables por el usuario (son informativas).

Figura 25 Barra de progresión y de posición

Tarea de arrastre

Esta tarea consiste en la introducción de una secuencia de posiciones que denotan un movimiento. Esta tarea típicamente se ha utilizado para describir explícitamente manipulaciones de objetos gráficos (mover, rotar, escalar), y que ha sido utilizada para dar significado a las operaciones de un sistema de escritorio (drag and drop) y en operaciones de diseño gráfico. Esta tarea requiere de una realimentación continua del objeto desplazado (puede ser una instancia, una línea/caja elástica, un punto de una curva, etc.).

Gestión de entradas del usuario

La gestión de entradas se puede hacer mediante distintas técnicas de interacción entre aplicación–dispositivo [OLS98]. Esta interacción se puede realizar en diferentes modos: pregunta–respuesta, ordenes, etc. Los eventos es el principal mecanismo para la comunicación entre el usuario y el sistema interactivo. Cuando el usuario interacciona con los dispositivos, estas acciones se trasladan a eventos software que se distribuyen a la ventana apropiada (en un sistema de ventanas). Todos los eventos están identificados (mediante un tipo de evento) que permite al software que los recibe distinguir la información que se pretende comunicar.

Se puede establecer tres mecanismos de comunicación entre usuario y aplicación:

• Petición (request). El programa espera hasta que se produzca una entrada. Los Dispositivos están en espera. Es un diálogo dirigido por la aplicación.

• Muestreo (sample). Ambos trabajan concurrentemente. Consulta del estado del dispositivo al realizar una petición. Los datos no son almacenados, por lo que se consulta el estado actual.

• Evento (event). Se provee de una cola de sucesos por parte del dispositivo. La aplicación está dirigida por los datos, y permite entradas asíncronas.

Los sistemas interactivos son programas dirigidos por eventos, y su estructura difiere de las aplicaciones tradicionales de procesamiento y de cálculo. El cuerpo principal del programa es simplemente un ciclo de obtención de eventos.

Inicialización

While(not salir) {

Obtener siguiente evento E

Gestionar evento E

}

Cola de eventos. Existen diferentes modelos para distribuir los eventos a los objetos. Al manipular el sistema interactivo, los eventos se ponen en una cola de eventos. Todos los sistemas de ventanas poseen rutinas para obtener el siguiente evento de la cola. A menudo, los eventos no poseen suficiente información como para ser procesados o son irrelevantes (movimiento continuado del ratón, pulsación de teclas no habilitadas), por lo que se deben proveer mecanismos de filtrado para eliminar aquellos eventos que no son significativos.

Algunos de los tipos de eventos que podemos encontrar son:

• Eventos de entrada. Son los generados por el usuario. Clasificación: eventos del ratón. El evento del ratón siempre posee la posición actual del ratón. Teclado: Se puede considerar un array de botones de ratón (uso de modificadores)

• Eventos de las ventanas. Se reciben de la propia ventana. La mayoría de los sistemas de ventanas envían un evento de creación/destrucción de la ventana, que permite al código de la aplicación gestionar la acción pertinente. Tipos de eventos: crear/destruir, abrir/cerrar, iconificar/deiconificar, redimensionar, mover, etc.

• Eventos definidos por el usuario. Eventos de alto nivel creados por software.

Comunicación entre objetos

Un punto importante de la gestión de eventos es la comunicación con otros objetos interactivos. Un ejemplo de ello es el movimiento de la barra de deslizamiento, que provoca el cambio del texto presentado (relación entre dos componentes interactivos). Esta comunicación se realiza mediante pseudo–eventos (eventos que han sido creados por la comunicación entre objetos, y no son realmente eventos de entrada).

En sistemas de ventanas no orientados a objetos, un evento consiste en un registro de un tipo (entero), información estándar y otra adicional suministrada por el objeto que origina el evento. Existen tres modelos básicos para este tipo de comunicación:

• Modelo de llamadas (callbacks). Permite asociar un procedimiento (código C) a un widget en tiempo de ejecución. Por ejemplo, se utiliza en sistemas de ventanas como Motif, y primeras versiones de Xwindows y lenguajes como Xtk, TK.

• Modelo de notificación. Cada componente interactivo notifica a su ventana padre (de la que depende jerárquicamente) la ocurrencia de un evento significativo. Este modelo se utiliza en las primeras versiones de MS Windows.

• Modelo de conexión o delegación. Permite a un objeto comunicarse con cualquier otro objeto (u objetos) mediante registro de los objetos receptores para un determinado evento. Modelo utilizado en NexTStep o Java.

• Modelo callbacks. Un callback es un procedimiento que se ejecuta inmediatamente después que se produce el evento. En Tcl/Tk, la conexión entre objetos (interactivos) evento y procedimiento se realiza mediante la siguiente orden

bind .boton1 { puts "Boton %b situado en %x,%y" }

Con esta orden se asocia al objeto interactivo ".boton1" cuando sucede el evento (pulsación del botón izquierdo del ratón) una secuencia de órdenes entre llaves.

• Modelo de notificación. Suministra un mecanismo interactivo más estructurado. Los componentes notifican a la ventana de nivel superior el evento sucedido. La ventana padre posee todo el código para decidir qué realizar con los eventos recibidos. Se puede prestar atención a eventos específicos (por ejemplo a eventos de aceptar–rechazar dentro de una ventana de opciones), que dirigen el modo de consulta y obtención del resto de eventos.

• Modelo de conexión de objetos. Permite a los objetos comunicarse directamente entre ellos. Por ejemplo: comunicación entre la barra de desplazamiento con el editor de textos, invocando un método del objeto editor de textos.

La organización de la información afecta a la impresión general del interfaz. Debe incluir los siguientes elementos:

• Diseño (formato de pantalla, organización general)

• Representación de la información (métodos de codificación)

• Realimentación (seguimiento)

• Comunicación con el usuario (errores, mensajes de estado, etc.)

En el nivel de presentación se debe mostrar la información de forma que sea comprensible y asimilable por el usuario. Se puede pecar de exceso de información (provocando fatiga y desbordamiento al usuario) o demasiado sobria (la falta de información puede causar incertidumbre). Hay que tener en cuenta que el espacio donde se presenta la información es escaso, por lo que deberemos hacer un uso racional de este recurso. La distribución (no oclusiva) de la información es un factor muy importante, y podemos jugar con diferentes tipos de diseño: uso de zonas fijas o que se puedan ocultar (de forma dinámica), disposición del área trabajo: menús, mensajes, información de estado, etc.

Para la representación de objetos deberemos utilizar una simbología y codificación para que sea fácilmente identificable, económica en recursos (tamaño en pantalla) y consistente (iconografía, colores, texto, etc.) (ver capítulo "El diseño gráfico").

Diseño de la presentación

El significado de una imagen puede ser más fácilmente percibido por el observador si posee claridad visual. Deberemos por tanto enfatizar la organización lógica de la información. Para conseguir una buena organización se puede utilizar las reglas de Gestalt, que permiten mejorar la claridad visual de la información. Estas reglas se basan en cómo organiza el observador los estímulos visuales (de forma global) y que se pueden resumir en los siguientes principios:

• Similitud. Objetos similares próximos se interpretan como una representación conjunta/agrupada

• Proximidad. Elementos visuales con propiedad común se interpretan como agrupados

• Cierre (clausura). Elementos visuales que tienden a cerrar un área se interpreta como cerrada

• Continuidad (determinación de formas). Discriminación de elementos diferentes según la continuidad natural

Figura 26 Reglas de claridad visual (Gestalt)

Estas reglas se aplican frecuentemente al diseño visual de los sistemas gráficos, como por ejemplo en la colocación de los botones, elementos de menú, organización general del interfaz, etc.

La claridad visual afecta a la impresión general de la interfaz. Al reforzar la claridad visual, promovemos las relaciones lógicas entre elementos (por ejemplo, minimizando el movimiento ocular para obtener información).

Figura 27 Aplicación de reglas a ventana de diálogo

Podemos organizar la pantalla de la interfaz siguiendo algunas reglas efectivas de diseño.

• Balanceado. Consiste en el ajuste de la visión con el área de visualización. El balanceado es la búsqueda de equilibrio entre los ejes horizontal y vertical en el diseño. Si se asigna un peso a cada elemento visual, se debe conseguir que la suma en cada eje sea similar. Se debe buscar un centro de gravedad en sentido horizontal y vertical, ya que de lo contrario, se crearía una inestabilidad.

Figura 28 Pantalla balanceada (izda.) e inestable (dcha.)

• Simetría. Consiste en duplicar la imagen visual a lo largo de un eje de simetría. Esta técnica automáticamente asegura el balance.

Figura 29 Pantallas con diferentes simetrías

• Regularidad. Técnica visual para establecer uniformidad ubicando los elementos de acuerdo con una distribución regular en filas–columnas.

• Alineamiento. Puntos de alineación que existen en el diseño. Se debería minimizar.

• Enrejillado. Separación y acentuación la organización entre áreas.

Figura 30 Pantalla con enrejillado y alineamiento (izda.)

Para obtener estas distribuciones de contenedores y componentes dentro de la pantalla, deberemos utilizar los controladores geométricos (layout manager) que nos facilitan las librerías de diseño de interfaces. Podemos utilizar desde los más simples (posiciones absolutas, ordenación de izda. a dcha.) a los más complejos, que asignas proporciones relativas para cada elemento, tamaño de expansión, offset, etc.

Figura 31 Controlador geométrico reticular con restricciones

Realimentación

La realimentación es de gran importancia en los sistemas interactivos, ya que el usuario debe estar informado en cada momento de las acciones que realiza. Cuando por ejemplo una tarea tarda más tiempo del razonable, se deberá informar mediante algún tipo de mensaje de ese proceso para no provocar incertidumbre. Sin embargo, un problema que deberemos tener en cuenta es que tenga una gestión rápida, ya que en tal caso puede no coincidir el estímulo con la respuesta del sistema. Algunos ejemplos de realimentación son:

• Sobre las órdenes. Mostrar efectos, errores, confirmación, indicadores

• Sobre la selección. Resaltar de forma no ambigua la orden activa

Esta realimentación debe ser fácil de leer y entender. Para ello se debe fomentar la consistencia, y en algunos casos puede condicionar la estructura de datos del modelo, ya que sea necesario almacenar información adicional para realizar el feedback.

Para su diseño, se debe estudiar las acciones de cada tarea y ver como es la interacción (realimentación del propio gesto), confirmación (selección, mensajes, iluminación) y posibles errores (pantalla de aviso) La realimentación informa al usuario acerca de su interacción con el sistema. Indica qué está haciendo y le ayuda a realizarlo correctamente. Se puede utilizar cualquier combinación de canales sensoriales (sonoro, visual, táctil, etc. ).

Se puede clasificar la realimentación por su dimensión temporal:

• Futura. Realimentación de una acción antes de llevarla a cabo. Indica qué sucederá si se realiza una acción (por ejemplo, etiqueta informativa de los botones).

• Presente. Realimentación durante la interacción. Indica qué esta sucediendo actualmente (p. e. borrado de ficheros, formateando, mover cursor..).

• Pasada. Información de lo que ha sucedido, y cómo ha cambiado el sistema (p. e. información de finalización de tareas).

Gestión de errores

Sobre un sistema, un factor crítico desde el punto de vista del usuario, es cómo se organizan los mensajes de error y su explicación. Normalmente ocurren por un desconocimiento por parte del usuario que puede ser motivado por diferentes causas:

• Errores por acciones del usuario. Error en la traslación entre la intención del usuario y su acción (intención correcta, pero realización incorrecta). La solución es mejorar el diseño ergonómico, mejorar los aspectos físicos del diseño (ubicación de menús, tamaño, posición, visibilidad, color, etc.)

• Errores por las intenciones del usuario. El usuario realiza una acción equivocada. El modelo de usuario no es correcto. La solución es mejorar el modelo mental. Es importante buscar posibles causas ya que el usuario está asumiendo un modelo mental incorrecto.

El usuario, ante un error, debe reconocer qué ha sucedido, para evitar confusión. Algunas técnicas que se deben evitar en los mensajes de error son:

• Tono imperativo. Aumenta la ansiedad del usuario. Dificulta la corrección del error ("Acción ilegal", "error fatal", "terminación anormal del programa").

• Mensajes genéricos o confusos. Ofrecen poca información ("error sintáctico", "run time error n. XXXX").

Un estudio de la distribución y frecuencia de errores puede ayudar al diseñador, al mantenimiento del producto y al posible usuario mediante una conveniente documentación.

Conclusiones

En este capítulo hemos visto las características más relevantes de los sistemas interactivos y las dificultades que se plantean a la hora de realizar un diseño efectivo. Si bien para el diseño de sistemas interactivos existe abundante bibliografía, la mayoría está basada en recomendaciones, consejos y guías de estilo para el diseño que están recogidas de la experiencia de los autores. Sin embargo, raramente aportan una metodología clara para llevar a cabo de forma sistemática el proceso de diseño. En este capítulo hemos incluido diferentes propuestas metodológicas basadas en teorías cognitivas para el diseño defectivo de aplicaciones interactivas.

Para ello, deberemos aplicar notaciones que permitan analizar las tareas que el usuario realiza en su entorno de trabajo, y utilizar técnicas para su traducción a conceptos de diseño. Posteriormente, hemos visto modelos arquitectónicos que proponen la arquitectura básica (sobre la base de componentes interactivos) que debe poseer el sistema, y por último, hemos aplicado una serie de técnicas que nos permitan trasladar de forma efectiva el modelo conceptual del sistema a un modelo computacional basado en eventos y componentes gráficos.

Referencias

Bibliografía

Baecker, R., Grudin, J., Buxton, W., Greenberg, S. (ed.) Readings in Human–Computer Interaction: towards the year 2000, 2ª ed. Morgan Kaufman Published. 1995.

Cox K. y Walker D. User interface design. Prentice Hall, 1993

Dix A., Finlay J., Abowd G. y Beale R. Human–Computer Interaction, 2ª edición. Prentice Hall, 1998

Foley J., van DAm A., Feirner S. y Hughes J. Computer graphics: principles and practice, 2ª edición. Addison and Wesley, 1990

Olsen, D. Developing user interfaces. Morgan Kaufman Publishers, 1998

Paternò F. Model–based design and evaluation of interactive application. Springer–Verlag, 2000

Shneiderman B. Designing the user interface. Strategies for effective human computer interaction, 3ª edición. Addison–Wesley, Reading, MA, 1992

Enlaces interesantes

http://giove.cnuce.cnr.it/ctte.html

ConcurTaskTrees.

Herramientas y documentación.

http://hcibib.org/tcuid/

Task–centered user interface design: a practical introduction.

Lewis C. (http://www.cs.colorado.edu/~clayton/) y Rieman J. (http://home.att. net/~jrieman/)

Autor:

Miguel Gea

Francisco Luís Gutiérrez

Enviado por:

Ing.+Lic. Yunior Andrés Castillo S.

"NO A LA CULTURA DEL SECRETO, SI A LA LIBERTAD DE INFORMACION"?

Santiago de los Caballeros,

República Dominicana,

2015.

"DIOS, JUAN PABLO DUARTE Y JUAN BOSCH – POR SIEMPRE"?