SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  1  

Unidad 1. Generalidades de Diseño y Pruebas Centradas en el Usuario

En esta unidad se introducen los principios básicos del diseño de la interfaz del usuario. Se expondrán dos facetas del diseño de interfaz de usuario (UI): la construcción de programas interactivos y el diseño de su comportamiento. La segunda faceta está basada en los principios de la psicología humana y se lleva a cabo con las técnicas de evaluación heurística y pruebas de pensamiento en voz alta del usuario.

Al concluir esta unidad, debes realizar el examen de opción múltiple. Además, debes hacer y entregar el ejercicio que se encuentra al final de esta unidad.

1.1 Fundamentos del Diseño y Pruebas Centradas en el Usuario 1.2 Una Herramienta para Crear Interfaces de Usuario: Visual Basic 1.3 Herramientas para Evaluar la Usabilidad de un Sistema: Pruebas Heurísticas

y de Pensamiento en Voz Alta

1.1 F undamentos del Diseño y Pruebas Centradas en el Usuario

1.1.1 Diseño Iterativo 1.1.2 Conceptos Básicos de la Programación Interactiva 1.1.3 Cómo Influye la Psicología Básica en el Diseño de Interfaces

1.1.1 Diseño I terativo

¿Porqué Diseño Iterativo? Visual Basic Evaluación Heurística Estudios en Voz Alta

¿Porqué Diseño Iterativo?

El objetivo de este curso es el de aprender a diseñar y construir software que sea útil: programas que se puedan usar fácilmente, de manera correcta y eficiente. Tu propia experiencia con programas computacionales comerciales y con elementos tal como la video casetera y el horno microondas es suficiente para demostrar que la construcción de software útil no es una tarea fácil. Existen muchos sistemas diseñados por personas muy talentosas que aunque son funcionales están lejos de ser elementos útiles.

El razonamiento fundamental tras este curso es que un diseñador de sistemas no puede anticipar que tan útil va a ser su diseño. En términos más sencillos: tú no eres el usuario. Este limitante proviene de diversas fuentes:

Tú eres solo una persona, los usuarios son muchos y con ideas diversas. Tú eres un experto en materia técnica, los usuarios por lo general no lo son. Mientras tu sabes exactamente lo que estabas pensando al diseñar el sistema, los

usuarios no.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  2  

Para manejar esta situación, el diseño del sistema debe basarse en un método iterativo. En vez de utilizar un método de consulta previa feed-forward (o cí rculo abierto) como se muestra en el siguiente diagrama,

Figura 1: Enfoque de diseño de consulta previa (Feed-forward), o círculo abierto.

el diseño debe incluir algunos pasos que incorporan factores adicionales a nuestra opinión personal. Como se muestra en la figura 2, por lo general esto implica agregar un paso en el cual se analiza el diseño preliminar de acuerdo a algunas reglas de dedo, y se hace una evaluación que toma en cuenta la retroalimentación de los usuarios con respecto a lo que se ha diseñado hasta el momento:

Figura 2: Diseño iterativo con retroalimentación

Las reglas de dedo que se utilizan en el ciclo de retroalimentación pequeño por lo general incluyen el conocimiento que se acumula con los años de experiencia y que se obtienen de los errores que se presentan en evaluaciones previas. La retroalimentación que se obtiene en el paso de la evaluación se incorpora a los siguientes pasos de análisis, diseño y construcción.

Dos dudas que provoca este método son:

1. Es muy costoso construir un sistema una vez, ¿cómo puede ser rentable que se construya lo mismo más de una vez?

2. ¿Cómo se puede lograr acumular la experiencia y obtener retroalimentación de los usuarios de manera útil que sirva como guía para futuros proyectos?

La clave para responder a la primera pregunta se encuentra en una metodología de prototipo rápido. La idea es implementar el suficiente diseño que permita llevar a cabo una evaluación sin necesidad de crear un producto completo. Por ejemplo, se puede hacer la imitación de varias pantallas que el usuario verá sin hacer toda la codificación necesaria para crearlas y navegar entre ellas. O se puede escribir el código para una operación, limitándole las opciones al usuario. Una vez que se obtuvo retroalimentación del prototipo, las opciones de diseño se reducen y se pueden hacer y evaluar los prototipos de otros aspectos del sistema.

Para contestar la segunda pregunta, se requiere mucho conocimiento y técnica. Para hacer una buena evaluación se requiere de un amplio conocimiento de la psicología

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  3  

humana, así como también buenas técnicas para solicitar, registrar y analizar la retroalimentación de los usuarios.

Este curso te ofrece tres herramientas importantes para el diseño iterativo centrado en el usuario: programación de interfaz de usuario en Visual Basic, evaluación heurística para las interfaces basada en la experiencia de diseño acumulada y la evaluación empírica de pruebas en voz alta.

Visual Basic

Uno de los lenguajes de programación más populares en la actualidad es Visual Basic, especialmente en el área de interfaz de usuario. Como verás, es muy útil para hacer prototipos rápidos de interface, haciendo posible la evaluación de muchos aspectos de utilidad del sistema antes de ser implementado. Una vez que hayas aprendido Visual Basic, podrás aplicar el mismo método para otros lenguajes de programación y otros sistemas.

Evaluación H eurística

La evaluación heurística es un proceso que utilizan los diseñadores para estimar la utilidad de su diseño antes de ser evaluado por el usuario. En este contexto, la palabra heurística significa el principio general o regla de dedo que conduce a una buena respuesta. En el curso, aprenderás un conjunto pequeño de heurísticas que te ayudarán a tomar decisiones de diseño de interfaz apropiadas, y aprenderás a aplicarlas a tu trabajo.

Estudios en Voz A lta

El método de pensamiento en voz alta es un método empírico poderoso para la evaluación de la utilidad de un sistema. Este método le presenta al usuario un sistema o un prototipo y se le pide que enumere en voz alta los pasos y las decisiones necesarias para desempeñar cierta tarea. Se requiere de un método muy disciplinado para recaudar y analizar los datos, el cual aprenderás en este curso.

El uso conjunto de las tres herramientas te ayudará a diseñar sistemas exitosos y útiles.

1.1.2 Conceptos Básicos de la Programación Interactiva

Manipulación Directa La Funcionalidad y la Retroalimentación Tareas Básicas y el Ciclo de Eventos/Redibujar Controles,Objetos Modelo, y la Interpretación de Eventos Encapsulación y Patrones de Acceso

Manipulación Directa

Las interfaces de usuarios gráficas modernas usan un estilo de interacción llamado manipulación directa. Las interfaces de manipulación directa están diseñadas para crear la ilusión de que el usuario está manipulando directamente los objetos que le interesan. Las imágenes le indican al usuario el estado y la naturaleza de los objetos y

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  4  

los programas están estructurados de manera que las interacciones se realizan en términos de esas imágenes representativas. Por ejemplo, en una computadora personal típica, los archivos de disco y los directorios administrados por el sistema operativo se le presentan al usuario en forma de manipulación directa usando la metáfora del desktop (escritorio). En la interfaz desktop, los archivos y folders se representan por medio de iconos (imágenes pequeñas representativas) ubicadas en ventanas (regiones sobrepuestas que aparentan ser hojas de papel sobre el escritorio). La forma del icono que representa un folder le recuerda al usuario un folder físico, y el usuario puede manipular los objetos del sistema de archivos moviéndolos, archivándolos, etc.

La interfaz de manipulación directa ha sido muy exitosa porque da la ilusión de ser clara - opera para que los usuarios sientan que están actuando directamente sobre los objetos, y no por medio de la computadora. La propiedad de ser directo no es una propiedad en sí de la interfaz. Las interfaces pueden ser más directas o menos directas dependiendo del sentimiento que le induzcan al usuario. Además, el sentimiento de que tan directo es, varía dependiendo del individuo, de la interfaz y en ocasiones varía entre partes de la interfase. Por ejemplo, probablemente el usuario encuentra más directo arrastrar un archivo hacia el icono de la basura para borrarlo que llevar a cabo alguna acción sobre un archivo al seleccionar un comando de un menu. Por lo general los usuarios prefieren las interfases que muestran ser más directas, ya que son más fáciles de aprender y de utilizar.(Sin embargo, es importante tomar en cuenta que el ser demasiado directos puede requerir que el usuario sea muy directo en algunas operaciones donde sería mucho más eficiente ser indirecto o automatizado).

La Funcionalidad y la Retroalimentación

Para presentar una interfaz clara, los diseñadores de interfaz comúnmente se concentran, entre otras cosas, a cumplir dos características importantes: funcionalidad y retroalimentación. La funcionalidad se refiere a las oportunidades de actuar que son obvias para el usuario. Por ejemplo, la manija de un martillo provee la oportunidad de tomarlo con la mano (de una manera particular que es útil para el propósito específico del martillo). Otro ejemplo típico son los nudillos - las ondulaciones que frecuentemente se encuentran en las perillas que hacen que la superficie sea más aspera, como se muestra en la Figura 1. Debido a que los nudillos aumentan la fricción, proveen una buena funcionalidad para tomar el objeto con los dedos.

.

Figura 1: Los nudillos dan funcionalidad para que pueda

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  5  

Debido a que la mayoría de los objetos en una interfaz de usuario gráfico aparecen como fotografías en una pantalla, las funcionalidades

físicas que se pueden ofrecer son limitadas. Sin embargo, al

manipular la apariencia visual de los objetos, podemos hacer que su proposito, estado y oportunidades de acción sean muy obvias para el usuario. Se puede pensar que esto es una funcionalidad visual. De tal manera que aunque no podemos sentir ni tocar los objetos de la pantalla, se puede simular el sentido como se muestra en la figura 2.

Aquí se muestra el botón de cambio de tamaño en la esquina de la ventana de la interfaz estándar de Microsoft Windows. Parece tener ondulaciones en su superficie. Como resultado, nos recuerda la funcionalidad que se encuentra en el mundo físico para sujetar un objeto, y por lo tanto nos invita a usar la interfaz gráfica de usuario (oprimiendo y sosteniendo el botón del mouse sobre el área para luego arrastrarlo). Como los nudillos están en diagonal, estos nos invitan a sujetarlo y arrastrarlo hacia el sureste - lo cual permite modificar el tamaño de una ventana. Cabe notar que para que la apariencia sea efectiva como funcionalidad de sujetar no es necesario que sepamos lo que es un nudillo, ni que ofrece la funcionalidad para sujetarlo. Es efectivo porque nos recuerda experiencias pasadas con objetos del mundo real.

Al manipular la apariencia visual de los objetos para que tengan funcionalidad propia (recordarle al usuario la funcionalidad presentada en experiencias pasadas, que por lo general tiene el mismo efecto práctico) hacemos que la operación de la interfaz sea más aparente y reducimos el esfuerzo para aprender y percibir las propiedades importantes. Como regla general (que veremos posteriormente en la forma de una heurística de utilidad) un buen diseño de interfaz de usuario provee una indicación visual (funcionalidad) de las acciones que el usuario puede llevar a cabo con dicha interfase.

El concepto de retroalimentación tiene un propósito similar. La Retroalimentación es la repuesta que el sistema le regresa al usuario según sus acciones. La retroalimentación puede consistir en una actualización visual, o en ocasiones de manera auditiva. Es mucho más fácil para los usuarios evaluar si sus acciones han tenido el efecto deseado si el sistema provee una retroalimentación inmediata que indica claramente la naturaleza y la consecuencia de sus acciones. En el mundo físico, al manipular un objeto normalmente recibimos retroalimentación inmediata en forma visual, táctil o auditiva. Sin embargo, en el mundo virtual las acciones computacionales son normalmente invisibles y silenciosas y falta la retroalimentación inmediata . Una de las mejores maneras de aumentar lo directo aparente de una interfaz es por medio de una retroalimentación fuerte e inmediata para cada acción del usuario.

Tareas Básicas y el C iclo de Eventos/Redibujar

sostenerse con la mano.

Figura 2: El nudillo simulado nos invita a"manejarlo" con el mouse.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  6  

El diseño de interfaces de usuario moderno tiene como objetivo proveer la apariencia de ser muy directo, es obvio que el usuario nunca será capaz de manipular físicamente un objeto computacional. Las acciones forzosamente se tienen que expresar por medio de los dispositivos de entrada de la computadora como intermediario.

Para que el usuario sienta que esta manipulando los objetos de interés de manera directa, un programa interactivo debe cumplir con varias cosas. Deben:

Proveer imágenes visuales que representan los objetos de interés para el usuario ( e indicar las acciones que se pueden realizar con ellos, en otras palabras, proveen una buena funcionalidad).

Aceptar entradas desde todos los dispositivos de entrada disponibles. Interpretar las entradas en el contexto de los objetos en la pantalla (y otras partes

del sistema). Modificar las estructuras internas que son modelos de los objetos de interés (y

deben invocar rutinas de aplicación) Actualizar la pantalla visual para reflejar las consecuencias de las acciones de

los usuarios (proveer buena retroalimentación).

Todas las interfaces de usuario gráficas cuentan esencialmente con este mismo conjunto de tareas. El diagrama de flujo de control general de un programa interactivo normalmente se puede resumir en un ciclo sencillo, como el que se muestra a continuación. Esto es debido a que la primera y la última tarea están estrechamente vinculadas, ambas proveen objetos visuales que percibe el usuario.

La estructura anterior es tan común que se encuentra en uso en la mayoría de los sistemas interactivos (incluyendo Visual Basic, que se utiliza aquí), y por lo tanto, deberás usarla en los diagramas de flujo de control para tu programa.

La salidas a la pantalla se producen por medio de una serie de llamadas a una librería gráfica, la cual por lo general es parte de un sistema de ventanas, o administrador de ventanas. En las secciones siguientes se considerará que un sistema de ventanas soporta una serie de superficies de dibujo independientes. Aunque para el programador dichas superficies aparentemente son espacios independientes, al usuario se le presentan una sobre la otra, en una forma ya conocida, ventanas. El control de las relaciones entre

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  7  

las diversas ventanas y la modificación de la salida a pantalla es tarea del sistema de ventanas. En algunos casos el sistema de ventanas puede mantener copias de las áreas de trabajo que se encuentran bajo otras ventanas, y después desplegar el material oculto. Debido a que esto se puede hacer de manera transparente, cada programa (o diferentes partes del mismo programa que utilizan ventanas diferentes) puede crear la ilusión de que se está dibujando en su propio dispositivo de despliegue. Lo anterior facilita la creación de código de dibujo y permite que muchos programas independientes (o partes del mismo programa) compartan eficientemente los recursos limitados tal como el dispositivo único de despliegue.

Generalmente las entradas de los sistemas interactivos modernos están diseñadas como registros de eventos de entrada (o simplemente eventos). Dicho registro de evento consiste en el registro de alguna acción relevante. Los eventos más comunes registran modificaciones en el estado de los dispositivos de entrada (como resultado de la manipulación de los dispositivos) - por ejemplo, al oprimir una tecla o al mover el mouse. Sin embargo, también pueden registrarse otro tipo de eventos, tal como la entrada de datos en una conexión de red. Los eventos pueden registrar información en referencia a qué sucedió, cuando sucedió, el contexto en el que se encontraban los otros dispositivos de entrada al momento en que sucedió el evento (por ejemplo, hacia dónde estaba apuntando el mouse cuando sucedió el evento, y el estatus de las teclas modificadoras, tales como SHIFT y CTRL). Finalmente, los eventos registran todos los datos asociados con la entrada (tal como el valor del caracter asociado al evento de oprimir una tecla).

Los registros de eventos se ponen en cola para asegurarse que no se pierdan, ya que es posible que el usuario genere eventos más rápido de lo que un programa puede responder. La operación de los programas es la siguiente: piden el siguiente evento de la cola de entrada, interpretan y procesan el evento, generan la nueva salida para el resultado (por ejemplo, cambiar el dibujo de la pantalla), y luego continúa con el siguiente evento. Si no hay eventos esperando en cola, el programa simplemente espera que llegue el siguiente evento. Es posible soportar varias formas de entradas asincrónicas usando el diagrama de flujo de control descrito arriba al asignar como evento todas las acciones de interés para el programa interactivo (hasta las comunicaciones entre procesos y el archivo de entrada y salida asincrónico).

Controles,Objetos Modelo, y la Interpretación de Eventos

Dado el ciclo básico de evento/redibujo descrito anteriormente, la duda central radica en cómo interpretar y responder a los eventos de entrada y como estructurar el proceso de creación de salida. La mayoría de los programas interactivos que se desarrollan hoy en día (incluyendo lo que harás en Visual Basic) utilizan toolkits (herramientas) que soportan las operaciones escritas en código de programación que responden directamente a los eventos y como resultado, se re-dibujan directamente. Las herramientas tienen un nivel mucho más alto de abstracción del ciclo de evento/re-dibujo y automatizan algunos pasos importantes. Específicamente, las herramientas tienen una librería de objetos que suelen aparecen en la pantalla y/o las utilizan los usuarios para ingresar datos de entrada. Tales objetos incluyen los objetos button, textarea, checkbox, y menu muy conocidos por los usuarios. Estos objetos regularmente se conocen como widgets (símbolos gráficos de interfase), interactores, o componentes interactivos. En Visual Basic y en algunos otros sistemas, estos objetos

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  8  

se conocen con el nombre de controles. Una de las mayores ventajas que ofrecen estas herramientas es de que proveen un gran conjunto de controles y permiten la creación de nuevos tipos de controles si es necesario. Esto significa que el programador no necesita crear un control button y todos los controles button que el usuario tiene a disposición trabajan igual.

En términos de manipulación directa, los controles proveen una presentación de los objetos de interés para los usuarios. Sin embargo, debido a que los controles provienen de una librería genérica, generalmente no tienen una semántica detallada. Por ejemplo, en la interfaz para ajustar la hora, un control de texto representa los minutos. Sin embargo, tal control de texto no reconoce que el valor del minuto debe ser un numero entero entre el 0 y el 59. Además, un objeto de interés puede ser representado por varios controles diferentes. Por ejemplo, en la interfaz de los minutos, puede ser conveniente que exista tanto una entrada de texto así como unas flechas (posteriormente veremos un control "arriba - abajo") para incrementar o decrementar el valor, como se muestra en la Figura 3.

Para modelar los detalles específicos de los objetos de interés y poder interpretar el objeto conceptual con los diversos controles que se requieran para implementarlo, por lo general necesitaremos enriquecer el control básico de la librería. Esto se puede hacer creando un objeto separado, interno a tu programa, que sirva como modelo del objeto conceptual de interés. Dicho objeto modelo contiene la información relacionada con el objeto de interés (así como el valor de número entero para los minutos) y es responsable de coordinar la acción de los controles que presenta el objeto al usuario. En el ejemplo de los minutos, el objeto modelo (el valor de número entero) necesita responder a los eventos que ocurren al oprimir el control button arriba/abajo. La respuesta debe incluir tanto la modificación del valor entero y la actualización del control de texto para presentarle el nuevo valor al usuario. Aparte de manejar las entradas del usuario, el objeto modelo necesita proveer una interfaz para cualquier código de aplicación que requiera manipular el objeto. Por ejemplo, un programa de reloj que no "sepa" nada de las interfases de usuario o de los controles puede necesitar actualizar el valor entero de los minutos. Si tal código de aplicación modifica la información almacenada en el modelo, el modelo necesita asegurarse que se actualice la información de los controles que despliegan la información y se la presentan al usuario. En el ejemplo de los minutos, si el reloj cambia el valor interno del minuto (no visto directamente por el usuario), el control de texto que despliega el valor debe ser modificado.

Cabe notar que las herramientas por lo general se encargan de los detalles internos relacionados con el re-dibujo de la pantalla para reflejar los cambios, pero a las herramientas se les deben notificar los cambios. El objeto modelo notifica a las

Figura 3: Dos formas para cambiar el valor modelo.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  9  

herramientas de los cambios al modificar las propiedades de los controles que necesitan ser modificadas. Las herramientas arreglan la apariencia actual de los controles en la pantalla para que se actualicen apropiadamente.

Resumiendo, en la siguiente figura se muestra la relación general entre las partes de un sistema interactivo.

Es importante notar que en este arreglo, los objetos modelo tienen un papel central en la organización. Aceptan las modificaciones en la información modelo (ya sea por medio de controles o código de aplicación), validan las modificaciones y responden a ellas actualizando las propiedades de los controles relacionados a esa información. En ciertas ocasiones es conveniente que los controles invoquen a las rutinas de aplicación y se brinquen al modelo. Esto es cierto particularmente en el caso de los menús y botones que representan comandos en la aplicación. Sin embargo, normalmente, la aplicación debe evitar la manipulación de los controles directamente sin pasar por el modelo.

Encapsulación y Patrones de A cceso

Es muy importante si no crítico, que los objetos modelo mantengan la encapsulación de la información, debido a que los objetos modelo deben estar informados cuando hay modificaciones en la información que manejan y porque necesitan responder de manera adecuada a esos cambios con acciones particulares (eso es, actualizando las propiedades de los controles). Esto quiere decir que es crítico que mantengan control del acceso a sus datos internos. Normalmente, para asegurar la encapsulación, estos objeto esconden información (por ejemplo, se puede declarar como privado el campo o la variable para que no se pueda accesar directamente) - para luego permitir el acceso a la información a través de métodos de acceso especiales. En Java, se puede hacer esto con un código similar al siguiente:

public class myModelClass { private myDataType myDataValue; public myDataType getMyDataValue() {return myDataValue;} public void setMyDataValue(myDataType val) {myDataValue = val;} }

Aquí se han especificado las implementaciones de métodos de acceso más básicos. Los métodos de acceso de los objetos modelo de las interfases de usuario contienen código adicional - tal como el que se describe a continuación. Este patrón general que utiliza un

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  10  

campo privado para los datos y los métodos de get y set para leer y escribir los valores de los campos constituye lo que se conoce como los patrones de acceso.

A diferencia de sus predecesores, Visual Basic .Net es un lenguaje orientado a objetos.Una parte del código en Visual Basic que se muestra a continuación es equivalente al patrón de acceso descrito anteriormente. En este momento no esperamos que entiendas completamente el código de Visual Basic, pero es importante que trates de entender la esencia del código presentado en esta sección.

Private myDataValue As myDataType Public Function getMyDataValue() As myDataType return myDataValue End Function Public Sub setMyDataValue(ByVal value As myDataType) myDataValue = value End Sub

El patrón de acceso descrito anteriormente provee la encapsulación básica necesaria para implementar los objetos modelo típicos. Sin embargo, los objetos modelo deben desempeñar acciones de actualización cuando los valores se modifican. Particularmente, cuando se llama a los métodos, necesitan actualizar las propiedades de todos los controles que reflejan esos valores. El patrón general del código sería el siguiente:

Public Sub setMyDataValue(ByVal value as myDataType) Dim newPropVal as someType

< Check validity of value, and possibly force into valid range >

If <value is a valid value > Then If value <> myDataValue Then myDataValue = value <Inform any parts of the application that care about the new value > End If

< For each control property that depends on myDataValue do the following> newPropVal = <prepare new value for the control property based on myDataValue > If < control> .someProperty <> newPropVal Then <control> .someProperty = newPropVal End If ...

Else <Ignore new value or perform error handling / feedback action> End If End Sub

Observa las líneas "If value <> myDataValue Then" y "If <control>.someproperty <> newPropVal Then". ¿Sabes porqué se encuentran en el código estas dos líneas? Se puede decir que esas líneas existen para que la interfaz sea más rápida: cuando no hay necesidad, el código dentro del IF-THEN no se ejecuta. El código, el cual informa del nuevo valor a otras partes de la aplicación puede llevarse más tiempo; por ejemplo, si se necesita notificar a muchos objetos o si se requiere de una serie de actualizaciones a la pantalla muy complicadas.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  11  

A decir verdad, los estatutos IF-THEN por lo general son necesarios para que el código sea correcto y tenga un buen desempeño. Si se permitieran propagar las actualizaciones a las variables libremente entre el objeto y la aplicación, aún cuando no haya un cambio en el valor, la interfaz se puede congelar y parecer que no se hace nada (Lo que puede estar sucediendo es realidad es que está ejecutando "actualizaciones" constantemente). Los estatutos IF-THEN que se muestran el código anterior proveen una buena solución para asegurar que no se permita una regresión infinita cuando no se modifique el valor de la variable. Se puede lograr el mismo efecto de maneras más complicadas que serían más especificas a tu aplicación pero la solución anterior es eficiente, fácil de implementar y fácil de corregir. Al usar una estrategia de programación sencilla y defensiva se evita el tener que considerar casos especiales. Este mismo código siempre funciona - sin importar si el cambio tiene origen en la aplicación o en las acciones del usuario. Además, el código no se "quiebra" si en un futuro se modifica la manera en que la aplicación o los controles responden al cambio.

A continuación se presenta un ejemplo específico que aplica el modelo de patrón de acceso, una función set para el ejemplo del minuto:

Public Sub setMinuteValue(ByVal min As Integer) Dim minStr As String

'Force into valid range If min < 0 Then min = 0 If min > 59 Then min = 59

'Update internal value If min <> minuteValue Then minuteValue = min ' Nothing in the application to inform in this case End If

'Prepare a two digit string (zero filled) to display minStr = CStr(min) If min < 10 Then minStr = "0" & minStr

' Update the text display if this is a change If MinutesText.Text <> minStr Then MinutesText.Text = minStr End Sub

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  12  

1.1.3 Cómo Influye la Psicología Básica en el Diseño de Interfaces

Motivación Generalidades Percepción Memoria Proceso Cognitivo Capacidad Motríz Errores Referencias

Motivación

La mayoría de los programas computacionales se diseñan para que la gente los use para desempeñar cierta tarea. Por lo tanto, para diseñar sistemas computacionales buenos, los desarrolladores deben conocer no nada más cómo trabajan las computadoras, sino también la tarea que van a realizar y la manera en la que las personas la realizan. Cuando los diseños requieren de un alto desempeño por parte del usuario, es fácil que éste cometa errores (los cuales pueden ser caros o fatales en los sistemas de seguridad crítica), le saque la vuelta a la tarea (lo cual es ineficiente), que abandone el sistema (si acaso tienen la opción) o se resista a adaptarse a sistemas nuevos (si acaso se ven forzados a usarlos). Al contrario, los diseños que aumentan la capacidad humana y ayudan a las personas a sobresalir de sus limitantes pueden ser verdaderamente útiles, efectivos en costos, y agradables para usar.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  13  

La tríada de un buen diseño de sistema consiste en comprender la tarea, la tecnología computacional y a las personas.

El objetivo de este módulo es ayudarte a diseñar mejores sistemas proporcionando un entendimiento básico acerca de la forma en que la gente trabaja, sus capacidades y sus limitantes. Obviamente, el tema es mucho más extenso de lo que se puede exponer en un módulo, pero esta breve presentación es útil por dos motivos.

En primer lugar, este curso comprende los principios de la psicología (nos referiremos a ellos más adelante en el material), de tal manera que al dominar y utilizar los métodos del curso, estarás aplicando los principios básicos de la psicología de manera implícita. En segundo lugar, contínuamente estarás trabajando en equipos interdisciplinarios en donde por lo menos un miembro del equipo puede tener especialización en alguna ciencia de comportamiento (tal como psicología, sociología, antropología, o comportamiento organizacional). Los temas que aprenderás en este módulo te ayudarán a trabajar con personas entrenadas en áreas diferentes para diseñar sistemas efectivos.

G eneralidades

Cuando alguien usa un sistema computacional, lleva a cabo diferentes actividades (Figura 1). Por lo general, obtienen información de la pantalla de la computadora (o de algún manual, o papeles que trajeron para trabajar, o de alguna otra persona), luego procesa la información formulando un plan de acción nuevo o usando uno utilizado anteriormente, ejecuta las acciones planeadas y procesa las respuestas de la computadora. En todas estas actividades, las personas están aprendiendo (ya sea nuevos conocimientos o practicando conocimientos adquiridos anteriormente), y también están cometiendo y detectando errores. Muchos años de investigación psicológica han resultado en datos y teorías que ayudan a los diseñadores de sistemas computacionales a evitar que el usuario se cicle en este proceso ayudándolo a aprender y minimizar errores.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  14  

Figura 1. Actividades humanas que se realizan al utilizar un sistema computacional.

El modelo de procesamiento de información (Figura 2) nos ayudará a entender algunos conceptos del diseño de interfaz computacional al estudiar la manera en la que las personas llevan a cabo sus actividades. El modelo asume que la persona se compone de tres procesadores computacionales diferentes: el procesador de percepción, el procesador cognitivo, y el procesador motríz. El procesador de percepción recibe la información del mundo externo, procesa alguna información relacionada a la Figura 1 (leyendo, escuchando, búsqueda visual, etc.), y deposita los símbolos en la memoria de trabajo (WM) que representa dicha información. Una vez que la información está en la memoria de trabajo, el procesador cognitivo hace el procesamiento necesario (solución de problemas, planeación, determinación de plan de acción, etc.). El procesador cognitivo puede recordar (recall) información adicional de la memoria de largo plazo (LTM) para ayudar en el proceso, y la información de la memoria de trabajo se puede almacenar en la memoria de largo plazo LTM (learning - aprendizaje). Cuando el procesador cognitivo determina que se necesita llevar a cabo cierta acción en el mundo

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  15  

exterior (por ejemplo, teclear un comando, usar el mouse para seleccionar un artículo, desplegar una pantalla, etc.), se deposita un símbolo en la memoria de trabajo reconocido por el procesador motríz para llevar a cabo cierta acción. El procesador motríz lleva a cabo la acción y el ciclo empieza de nuevo. Estos procesadores pueden trabajar en paralelo, lo cual refleja la realidad de que una persona puede pensar y llevar a cabo acciones motrices. Por ejemplo, al conducir un auto, el conductor observa el camino, va pensando en donde tiene que dar la siguiente vuelta y conduce el volante - todo al mismo tiempo. Sin embargo, el procesador cognitivo sólo puede hacer una cosa a la vez, y por lo tanto hay un cuello de botella que es muy importante para el diseño de interfaz.

Figura 2. El modelo de proceso de información de personas desempeñando actividades en el mundo.

Percepción

Las computadoras modernas se comunican con los usuarios primordialmente por medio del sentido de la vista del (aunque con el desarrollo de la interfaz de lenguaje, se hace más importante el sentido del oído). Algunos sistemas computacionales se comunican con el usuario por medio del sentido del tacto, como en los juegos juveniles de carreras de carros en donde el asiento del juego se mueve más violentamente cuando el coche corre por un camino de terrecería y menos cuando corre por un camino recto y liso. A la fecha, no se han incorporado los sentidos del olfato y gusto a los sistemas computacionales comerciales. El lenguaje de programación Visual Basic hace muy fácil la programación de la comunicación visual y por lo tanto nosotros nos concentraremos en las señales de la percepción visual.

Los humanos vemos los detalles con una pequeña parte del ojo llamada fóvea. El campo de vista de la fóvea es de 2 ángulos solamente. Para que una persona lea un texto o distinga un icono detallado tiene que apuntar la fóvea directamente al área específica de la pantalla. Para ver más de dos grados de ángulo el ojo debe moverse. El resto del ojo

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  16  

es mucho más sensible al los cambios en el campo visual que la fóvea. Esto quiere decir que en el resto de la pantalla, a donde la persona no esta viendo directamente, los cambios serán muy visibles (por ejemplo, la animación o cambios de color). Al ojo del usuario naturalmente le atrae la actividad en la periferia, haciendo muy difícil que el usuario se mantenga enfocado en un objeto que esta tratando de leer o decifrar. Además, la percepción visual toma tiempo. Para que el ojo detecte una señal visual sencilla (tal como el encendido de una luz) y la deposite en la memoria de trabajo, se tarda aproximadamente 100 mseg. Se toman unos 30 mseg para que el ojo se mueva a otra posición en la pantalla. Existen varios principios de diseño que se derivan de estas características del ojo y las expondremos en el resto del curso.

Figura 1. La fóvea puede percibir el detalle en un ángulo visual de 2 grados. Para leer toda la pantalla el ojo tiene que mover la fóvea alrededor de la pantalla. El ojo es muy sensible a los cambios en la pantalla fuera de la región foveal.

Digamos que una persona está buscando un objeto, el cual llamaremos objeto meta o target. El proceso en el cual una persona busca al objeto meta, ya sea una palabra o un icono, en la pantalla se denomina búsqueda visual. La búsqueda visual es muy fácil y sencilla si el objeto meta o target es diferente al resto de la pantalla. Por ejemplo, el color del objeto meta, su orientación, tamaño, o curvatura puede ser diferente al resto de los objetos de la pantalla. En este caso, el objeto "salta" a la vista y no importa si el resto de la pantalla está saturada o muy sencilla. Si el objeto meta primordial requiere que una persona discrimine entre muchos objetos, la búsqueda visual va a ser mucho más lenta debido a que la persona tiene que ver un objeto a la vez para decidir si es en realidad lo que esta buscando. Por lo tanto, los aspectos de diseño tal como la localización, la densidad de despliegue, el agrupamiento y el amontonamiento de la pantalla son factores determinantes para la rapidez de la búsqueda. Una vez más, los principios de diseño de la búsqueda visual los estudiaremos posteriormente en esta clase.

Memoria

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  17  

Existen muchas teorías sofisticadas con relación a la memoria humana que son tema de intenso debate teórico y empírico en la comunidad psicológica académica. Sin embargo, para efectos del diseño de interfaz de usuario, solo necesitamos conocer algunas generalidades de la memoria y pasaremos por alto los detalles sutiles que preocupan a los académicos.

Como aprendimos anteriormente, hay dos memorias importantes: la memoria de trabajo (WM) y la memoria de largo plazo (LTM). Se puede pensar que la memoria de trabajo es la parte activa de la memoria de largo plazo. La memoria de trabajo es la memoria donde el procesador de percepción deposita los símbolos que percibe y donde el sistema cognitivo guarda los resultados intermedios al procesar la información. La memoria de largo plazo almacena todos los conocimientos de la persona: las verdades, los procedimientos, y la historia (lo que le ha pasado a la persona). Lo anterior incluye el vocabulario, los procedimientos necesarios para llevar a cabo el trabajo, las relaciones entre conceptos, etc.

La memoria de trabajo almacena la información de manera visual o acústica mientras que la memoria de largo plazo, almacena lo importante de la información en vez de su forma visual o acústica. Esto es muy importante porque ayuda a predecir el tipo de errores que la gente comete. Por ejemplo, una persona que acaba de leer una novela cuyo protagonista se llama Jane puede confundir el nombre con Jean ya que los nombres son muy similares (todas las mismas letras) y los sonidos son similares (los sonidos "j" y "n"). Pero, para la siguiente semana puede ser que la persona ya no se acuerde ni del nombre de la protagonista y solo se acuerda que se trataba de una mujer (lo importante).

La memoria de trabajo puede tener sólo una cantidad limitada de información a la vez, aproximadamente 3 trozos ("chunks"). Chunk simboliza una pedazo de información. Los chunks se pueden organizar jerárquicamente. La mejor manera de explicar esto es por medio de un ejemplo. Haz clic en la siguiente liga para ver ejemplo:

E jemplo Auditivo: Chunks en la Memoria de T rabajo

La memoria de largo plazo es esencialmente infinita, pero frecuentemente es difícil extraer su información. Es mucho más fácil acordarte de algo haciéndolo en el contexto en el cual se aprendió. Supongamos que quieres aprenderte la siguiente lista:

Perro Gato Ratón Rata Caballo Ardilla Cerdo Vaca Borrego

Si en un futuro te piden que te acuerdes de los artículos computacionales que aprendiste de esa lista, sería muy difícil recordar "ratón" ' simplemente porque aprendiste esa lista

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  18  

en el contexto de "animales" y ahora te piden que lo recuerdes en el contexto de "equipo de cómputo".

Otra propiedad de la memoria de largo plazo es que es fácil que las piezas de información similares interfieran entre sí. Supongamos que se te pide que recuerdes el nombre del navegador de Web que utilizas generalmente. Enseguida se te pide que recuerdes el URL de la página de Web que visitaste el martes pasado. Debido a que seguramente solo utilizas un navegador de Internet, es probable que sea muy fácil para ti recordarlo. Sin embargo, ya que probablemente has visitado muchas páginas de Internet desde el martes pasado y casi todas comienzan con "http://" - es difícil que recuerdes el URL de la página que visitaste el martes.

Una tercera propiedad muy importante de la memoria es que es más fácil reconocer que recordar. Por ejemplo, es mucho más fácil que alguien te pueda decir si ha visto cierto artículo anteriormente si tu le muestras el artículo que si tu le pides que te especifique todos los artículos que has visto antes sin mostrarle ejemplos. Dicho de otra manera, es mucho más fácil que la persona reconozca si ha visto un artículo anteriormente a que retraiga el artículo de su memoria de largo plazo. Las diversas teorías psicológicas difieren en sus explicaciones de dicho fenómeno, pero la ocurrencia del fenómeno es confiable. A manera de explicación, se puede decir que una vez que la percepción ingresa la información de un artículo a la memoria de trabajo, esta información hace que la memoria de largo plazo busque la codificación del artículo.

Finalmente, aquí se encuentra una vez mas la figura de la sección "Generalidades":

El modelo de proceso de información de las personas desempeñando actividades en el mundo.

Cabe notar que la memoria de trabajo se puede alimentar tanto de la percepción como de la memoria de largo plazo, pero la información solo se puede almacenar el la

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  19  

memoria de largo plazo a través de la memoria de trabajo. Esto tiene implicaciones en el diseño y los métodos de diseño que estudiaremos a los largo de el curso.

Proceso Cognitivo

En este modelo, el procesador cognitivo es el que "piensa". Esto quiere decir que toma los símbolos que se encuentran en la memoria de trabajo (depositados por la percepción o por la memoria de largo plazo) para luego manipular los símbolos para resolver un problema, planear una serie de acciones para resolver el problema y decirle al procesador motríz la manera de ejecutar las acciones. Para el diseño de UI, hay dos tipos de actividades del procesador cognitivo: conocimientos de rutina y resolución de problemas.

Las personas que conocen bien un sistema desempeñan comportamientos conocidos como conocimientos de rutina. Conocen todas las opciones del menú, los comandos, las ventanas de diálogo, etc. Una vez que reconocen el tipo de situación (contexto) en el que se encuentran, saben exactamente que hacer. Por ejemplo, cuando usas un procesador de palabras y deseas borrar un párrafo, probablemente sepas exactamente como hacerlo (pones el párrafo en negrita y oprimes la tecla delete). Cuando una persona llega a este nivel de conocimiento es muy posible que se pueda determinar o predecir cuanto tiempo le va a tomar a la persona ejecutar ciertas tareas del sistema computacional. Aunque no vamos a hablar de predicciones, hay un método de diseño de UI llamado GOMS que ha mostrado hacer unas predicciones muy confiables del comportamiento, y es una manera importante de evaluar muchos sistemas computacionales. (John, 1995 John y Kieras, 1996).

Por otro lado, cuando el sistema computacional es nuevo para un usuario, o cuando sólo lo utiliza de vez en cuando, para llevar a cabo una tarea ocasionalmente se encuentran con que tienen que resolver ciertos problemas. (Nota: aún cuando una persona conoce bien un sistema, si el sistema es complejo, puede ser que sea muy buenos para ciertos aspectos del sistema y novatos para otros aspectos del sistema. Un ejemplo sería que puedes ser muy bueno para manejar el procesador de palabras para escribir documentos pero puedes no saber como usar la base de datos para hacer etiquetas de correo y escribir cartas personalizadas.) El resolver los problemas, es como buscar en un laberinto. Adivinan que hacer y luego siguen en ese camino una distancia corta. Si no se ve que estén progresando hacia su objetivo, se regresan y buscan otro camino. Lo anterior es el comportamiento de resolución de problemas típico - y nosotros podemos diseñar interfases de usuario que les apoyan este comportamiento deliberadamente o podemos producir interfases de usuario que no ayudan.

Capacidad Motríz

Los comportamientos motrices utilizados en los sistemas computacionales hoy en día son teclear, apuntar y hacer click. Estas son las técnicas de interacción que más soporta Visual Basic, y por lo tanto nos concentraremos en la psicología de dichas acciones.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  20  

Figura 3. Una vez más, el modelo de procesamiento de información.

En la figura 3 vemos que el procesador motriz toma la información de la memoria de trabajo y la usa para actuar en el mundo. Por ejemplo, el procesador cognitivo puede determinar que se debe seleccionar una opción del menú y lo deposita en la memoria de trabajo. El procesador motriz ve el menú en la memoria de trabajo y mueve el mouse a dicho menú en la pantalla y luego le hace clic. Como alternativa, si existe un "shortcut" o atajo para ese menú en la memoria de largo plazo, el procesador cognitivo puede pasar esa información a la memoria de trabajo para que luego el procesador motriz teclee el atajo.

La forma de teclear ha sido estudiada a detalle por más de cien años, y existen fenómenos importantes relacionados con teclear (por ejemplo, que tipo de errores comete la gente, cuales de estos los detectan por sí solos, cuánto tiempo se lleva transcribir un documento [Salthouse, 984]). Sin embargo, para la mayor parte de los objetivos de diseño, la velocidad con la que una persona teclea es el único parámetro que se requiere. Con esto se puede pronosticar con cierta exactitud el tiempo que le tomará a la persona ingresar información o utilizar un atajo del teclado.

El apuntar es otra acción motríz que se ha estudiado intensamente desde antes de que las computadoras se utilizaran comúnmente. La Ley de Fitt's (Welford, 1968) es una ley psicológica robusta que hace relación entre el tamaño y la distancia de una meta con el tiempo que le toma en apuntar a ella.

Tpoint = IM log2 (Distancia/Tamaño + 0.5)

IM es una constante determinada empíricamente. No es importante que entiendas como calcular la formula, solo comprendas que:

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  21  

El tiempo requerido para mover el ratón se incrementa conforme la distancia a la meta incrementa o el tamaño de la meta disminuye.

La relación de la distancia-a-la-meta con el-tamaño-de-la-meta es importante - de tal manera que las metas pequeñas o muy cercanas pueden ser tan difíciles de apuntar como las lejanas.

El clic al final del movimiento de apuntar es una acción sencilla que toma aproximadamente 200 mseg en ejecutarse.

Finalmente, el movimiento de la mano, del teclado hacia el mouse o vice versa (llamado homing) se ha medido en 400 mseg.

Con los cuatro parámetros - rapidez de tecleo, la Ley de Fitt's para apuntar, hacer el clic al botón del mouse y homing - los analistas pueden hacer una predicciones precisas de los tiempos de ejecución motrices (Card, Morgan y Newell, 1983). Veremos como estos parámetros también contribuyen a la heurística de diseño que estudiaremos más adelante.

E rrores

Los humanos cometemos errores - en todas las etapas del procesamiento de información. Podemos percibir la información de manera incompleta ( al no verla) o de manera incorrecta (al interpretar lo que vemos de manera incorrecta). Recordaremos información de manera imperfecta, confundiendo unas palabras por otras que suenan similares (si se presenta la información de manera oral), o que parecen similares (si se presenta la información de manera visual), o que son similares en significado (si se obtuvo la información de la memoria de largo plazo). Tenemos conocimientos incompletos y por lo tanto se podrán hacer planes incompletos. Al querer resolver problemas, la mejor solución podrá ser equivocada. Finalmente, al ejecutar las acciones motrices, podremos utilizar teclas equivocadas o equivocarnos al elegir la opción del menú. Los errores son inevitables y la mayoría de las veces los errores específicos son imprevisibles (aunque se pueden identificar una serie de situaciones que producen errores) .

Con esto concluimos el módulo de la psicología básica necesaria para el diseño de interfases de usuario.

En resumen, el modelo de procesamiento de información presentado en este módulo, en el cual se describe la manera en que las personas interactúan con el mundo es la base de muchas guías para el diseño de UI, los métodos, y las técnicas analíticas de predicción - incluyendo muchos que encontraremos posteriormente en este curso. Por lo tanto, como se mencionó anteriormente, cuando comprendas y apliques los métodos del curso, implícitamente estarás aplicando teorías psicológicas.

Referencias

Welford, A.T. Fundamentals of Skill. London: Methuen, 1968.

Card, S.K, T.P. Moran, and A. Newell. The Psychology of Human-Computer Interaction. Hillsdale, N.J: Lawrence Erlbaum, 1983.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  22  

John, B. E. "Why GOMS?" Interactions 2, no. 4 (1995): 80 9.

John, B. E., y D.E. Kieras. "Using GOMS for User Interface Design and Evaluation: Which Technique?" ACM Transactions on Computer-Human Interaction 3, no. 4 (1996): 287 319.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  23  

1.2 Una H erramienta para Crear Interfaces de Usuario: Visual Basic

El objetivo de este módulo es para prepararte para comprender las páginas de Visual Basic que se presentan en los siguientes módulos del curso. En esta sección aprenderás a usar el ambiente de programación de Visual Basic y adquirirás el conocimiento básico de los controles más comunes de Visual Basic. Asegúrate de leer el resumen del módulo antes de continuar con las páginas de los módulos individuales.

1.2.1 El Ambiente de Programación de Visual Basic 1.2.2 Cómo Escribir Código en Visual Basic 1.2.3 Cómo Depurar el Código en Visual Basic

Evaluaciones

Exercicio 2 Quiz de Opción Múltiple 2

Resumen del Módulo

Este módulo tiene el propósito de preparate para los módulos de VB que aparecen a continuación mediante la introducción de los principios básicos de Visual Basic. Como sabes, Visual Basic representa una de las formas más rápidas para crear aplicaciones para la plataforma Windows. Permite que los programadores creen aplicaciones visualmente-permite "dibujar" objetos (llamados controles) sobre objetos cuadriculados (llamados ventanas de formulario o formulario). (Para, "dibujar" se llevan a cabo operaciones tales como arrastrar objetos hacia un formulario desde la caja de herramientas (toolbox) de Visual Basic, arrastrar sus esquinas para cambiar su tamaño, y arrastrarlas de un lugar dentro de la forma a otro.) Talvéz también sepas que el lenguaje Visual Basic se utiliza como lenguaje de programación en otras aplicaciones de Windows-Microsoft Excel, Microsoft Access, entre otras. En este módulo "trabajarás directamente con Visual Basic"-preparándote así para los siguientes módulos en donde trabajarás con Visual Basic de forma más profunda. Aquí, conocerás los componentes del ambiente de programación interactivo de Visual Basic. Aprenderás también acerca del funcionamiento de formularios, controles y de como escribir código Visual Basic. También adquirirás la habilidad para depurar código Visual Basic y conocerás la forma en que el ambiente de Visual Basic soporta esta importante tarea .

Talvez puedas notar que algunas de estas lecciones son iguales a las que ya se presentaron en otro contexto-por ejemplo en el curso de Java. La programación moderna tiene la ventaja de que se pueden transferir rápidamente las habilidades ya aprendidas a otro contexto. Sin embargo, las diferencias en los lenguajes a veces son tan sutiles que lo que se usa en un lenguaje puede causarte problemas al querer aprender otro. Por lo cual es importante que cuando comiences a aprender un lenguaje nuevo prestes atención a las diferencias que tiene este lenguaje en relación a los otros que ya conoces.

E l L ibro

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  24  

En este módulo usaremos el libro Programming with Microsoft Visual Basic .Net de Diane Zak. Todas las lecturas para este módulo se encuentran en este libro, además, el módulo se apega mucho al formato de tutorial y lecciones del libro. Debido a que el libro contiene muchas características útiles que no se utilizan de manera explícita en este curso, vale la pena que antes de empezar, le des una hojeada al libro para observar estas características. Por ejemplo, a travéz de los párrafos H elp? podrás anticipar algunos problemas que pueden ocurrir mientras lees el libro. Observa también que el libro tiene márgenes anchos-la intensión es que puedas tomar notas en ese espacio- además, algunos comentarios llamados T IP y T IPs para el diseño de G UI se encuentran ya en este espacio. Los comentarios de T IP te presentan información complementaria de los párrafos adjuntos. Los T IPs de Diseño G UI presentan directrices para la creación de aplicaciones según los estándares publicados por Microsoft.

Otro consejo: Una ventaja del formato tutorial es que presenta información en el contexto de problemas que ocurren en la programación del mundo real, facilitando que recuerdes esta información y que veas la importancia que tiene. Sin embargo, una desventaja que tiene el formato tutorial es que la información contenida no se presenta en una forma de referencia rápida. Por ejemplo, los estándares de diseño se encuentran dispersos en muchos párrafos de T ips de Diseño G UI , y como estos párrafos no se encuentran indexados por tema, se dificulta hacer una búsqueda particular. Así que te recomendamos, al igual que en el curso de Java, que trates de hacer tu libro de texto más útil-marcando las secciones importantes de alguna manera en forma de que te sirva a tí como índice de alguna característica, por decir de T ip de Diseño G UI . (Por cierto, en la página 750 de tu libro de texto encontrarás una lista parcial de diseño GUI y una guía de programa.)

Las Lecturas

Como este módulo aprovecha el formato tutorial de Programming with Microsoft Visual Basic .Net, no lo leerás en forma de libro de texto, más bien trabajarás con el de en forma parcial seleccionada paso a paso. Sin embargo, Puedes ir viendo el material aún antes de que se toque el tema en clase para que conozcas de manera anticipada el material que vas a ver, podrás utilizar la siguiente estrategia:

Puedes comenzar con la primera lección y avanzar o comenzar en la última lección y avanzar para atrás.

Lee rápidamente las introducciones y resúmenes. Lee los títulos de las secciones. Revisa de manera rápida los diagramas, las tablas y las ilustraciones. Repasa el texto y trata de agarrar un par de ideas, puedes leer un T IP - o algún

párrafo que te llame la atención.

1.2.1 E l Ambiente de Programación de Visual Basic

Instalación y Configuración Cómo Crear y Modificar Proyectos en el Ambiente Interactivo de Visual Basic Cómo Obtener Ayuda

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  25  

Al estudiar las siguientes secciones, completarás parte del primer capítulo de Programming with Microsoft Visual Basic .Net, la lección A, parte de la lección B y dos ejercicios Discovery. Con esto, se te presentarán muchos de los principios básicos desde como ejecutar y terminar visual basic hasta como accesar su facilidad de ayuda on-line. Probablemente, la mejor forma de avanzar es manejar cada sección como unidad: leerla y realizar una parte relevante del tutorial antes de avanzar a la siguiente sección.

Readings:

Zak, Capítulo 1, Lección A, páginas 13-38, incluyendo el resumen y las preguntas. Observación: Completa esta parte de la lectura después de leer la sección de "Cómo crear y modificar proyectos en el ambiente interactivo de Visual Basic" que se encuentra a continuación.

Zak, Capítulo 1, Lección B, páginas 40-62, incluyendo el resumen y las preguntas; Ejercicios Discovery, páginas 64-5. Observación: Completa esta parte de la lectura después de leer la sección de "Como obtener ayuda" que se encuentra a continuación.

Instalación y Configuración

Antes de comenzar, necesitas contar con una copia de Visual Basic Express instalada en tu computadora y un conjunto de discos de alumno del libro de texto. En la mayoría de los casos, contarás ya con una copia de Visual Basic Express instalada en el area de computadoras, y tu instructor te proporcionará los archivos necesarios para que crees tu propio juego de discos de alumno. (También los puedes conseguir del Web Site del editor del libro de texto: Student Downloads.- busca las ligas bajo "Data Files for Students") Siendo así el caso, ya estás listo para comenzar a trabajar en este módulouna vez que hayas creado tu propio juego de discos.

Además, talvez requieras en alguna ocasión trabajar en otra computadora que no se encuentre en el area de computadoras por decir, tu computadora portátil. Puedes bajar una copia de Visual Basic Express del sitio de Web de Microsoft. Si no puedes bajar la versión Express, tu libro de texto tiene un CD que contiene una edición Standard de Visual basic. Aunque la versión en el CD está limitada, tiene la capacidad para trabajar con los ejericcios de los tutoriales. Podrás hallar la información de los requerimientos del sistema en la sección "Read This Before You Begin" de tu libro de texto.

Cómo C rear y Modificar Proyectos en el Ambiente Interactivo de V isual Basic

En esta sección aprenderás como iniciar y terminar Visual Basic, también aprenderás acerca de los componentes de despliegue de Visual Basic. También aprenderás como fijar propiedades de objetos; cómo crear, guardar, correr y parar aplicaciones; y como abrir proyectos ya existentes y proyectos nuevos. Asegúrate de prestar atención

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  26  

particular a la breve introducción de formularios y controles. Los formularios y los controles proveen las bases para "1.2.2 Cómo Escribir Código en Visual Basic".

Ahora, usando los discos de alumno, comienza a trabajar con la sección A. Usa el resumen de la lección y las preguntas para repasar lo que has aprendido. Además, si tienes tiempo y quieres, puedes realizar los ejercicios de la lección. Sin embargo, estos ejercicios son opcionales.

Cómo Obtener Ayuda

Esta sección hace una introducción al sistema de ayuda en línea de Visual Basic y a la biblioteca de Microsoft Development Network (MSDN). La primera parte de la lección B (la única parte que se te pide hacer) describe las características principales de estos dos recursos. En los ejercicios Discovery obtendrás experiencia práctica de como usarlos y como resolver problemas de programación del mundo real.

Ahora, realiza la primera sección de la lección B. Cuando termines, ve al ejercicio Discovery 4 y 5 Por supuesto, puedes hacer los otros ejercicios, pero de nuevo, estos son opcionales.

1.2.2 Cómo Escribir Código en Visual Basic

Formularios, Controles, Cómo Escribir y Editar Código en Visual Basic El Lenguaje de Programación Visual Basic Estructuras de Control, Etc. Manipulación de Strings

En las siguientes cuatro secciones, vamos a cubrir mucho material, completando en total siete lecciones. En la primera sección "Formularios, Controles y como Escribir y Editar Código en Visual Basic", repasaremos brevemente lo que son los formularios y los controles- desde el punto de vista de como estos se relacionan con el código de Visual Basic- después aprenderás algunos procedimientos básicos de como escribir código. En la sección dos, "El lenguaje de programación Visual Basic", veremos los detalles. En esta sección cubriremos desde los temas de sintáxis y estatutos de Visual Basic útiles hasta los temas de planeación, pruebas y documentación. En la sección tres, "Estructura de control, Etc." estudiaremos tanto los estatutos y Select Case como estatutos que inicializan y terminan los ciclos. Con estos estatutos juntos podrás controlar el flujo de de ejecución de las aplicaciones de Visual Basic. Por último, en la cuarta sección "Manipulación de strings", trabajaremos, no solo con la asignación y concatenación de strings, sino con funciones que permiten manipular datos string de manera sofisticada. Avanza en estas secciones, tratando a cada una como unidad: lee cada una de ellas y lleva a cabo las lecciones relevantes antes de avanzar a la siguiente.

L ecturas:

Zak, Capítulo 1, Lección C, páginas 66-74, incluyendo el resumen y las preguntas pero no los ejercicios. Observación: Lleva a cabo esta lectura después de leer la sección siguiente llamada "Formas, Controles, Cómo

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  27  

Escribir y Editar Código en Visual Basic". Zak, Capítulo 2, Lecciones A, B, y C, páginas 77-137, 94-

96, 116-137, incluyendo el resumen y las preguntas pero no los ejercicios; Capítulo 3, Lecciones A y B, páginas 148-166 y 170-191, incluyendo el resumen y las preguntas pero no los ejercicios. Observación: Lleva a cabo esta lectura después de leer la sección siguiente llamada "El Lenguaje de Programación Visual Basic".

Zak, Capítulo 4, Lección A, páginas 212-242, incluyendo el resumen y las preguntas pero no los ejercicios; Capítulo 5, Lecciones A, B, y C, páginas 361-380, 384-391 y 393-403, incluyendo el resumen y las preguntas pero no los ejercicios. Observación: Lleva a cabo esta lectura después de leer la sección siguiente llamada "Estructuras de Control, Etc.".

Zak, Capítulo 8, Lección C, páginas 461-484, incluyendo el resumen y las preguntas pero no los ejercicios. Observación: Lleva a cabo esta lectura después de leer la sección siguiente llamada "Manipulación de Strings".

Formularios, Controles, Cómo Escr ibir y Editar Código en V isual Basic

Comenzaremos con un repaso. Recuerda que en la lección anterior, se presentó la funcionalidad de la ventana de formulario del ambiente de desarrollo de Visual Basic que permite crear interfases de usuario llamados formularios (forms). Estos formularios se crean de manera "visual" en Visual Basic- esto es, por un proceso en donde los objetos, llamados controles se seleccionan de una caja de herramientas de windows y se "dibujan" en la ventana Forms. El pgramador podrá entonces actuar sobre estos controles (botones radio, cajas de selección, listas, entre otros) de varias maneras-así como arrastrarlos, eliminarlos, establecer propiedades, etc.

Así que, ¿dónde va el código? El código de Visual Basic es el medio por el cual los desarrolladores le instruyen al control lo que debe hacer (o como se debe comportar) cuando los usuarios llevan a cabo una acción en particular (llamada evento)- tal como hacer click,doble click o scroll.

En esta sección, conocerás la forma en la que puedes agregarle controles a un formulario y como determinar sus propiedades. También conocerás como abrir la ventana de código de Visual Basic, como agregar código y como crear archivos ejecutables. Asegúrate de poner atención en la opción que existe para imprimir las propiedades de un formulario y el código. Esta facilidad permite llevar a cabo la técnica de depuración- un tema de estudio que se profundizará en la sección del siguiente módulo.

Ahora, realiza la lección C del Capítulo 1 y utiliza el resumen de la lección y las preguntas para probar lo que has aprendido. Si tienes tiempo y quieres realizar algún ejercicio de la lección, igual que las anteriores, lo puedes hacer.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  28  

E l Lenguaje de Programación V isual Basic

Las siguientes tres lecciones, te presentarán a fondo las características del lenguaje de programación de Visual Basic. Se te presentará, por ejemplo, la sintaxis y los elementos de varios estatutos útiles: como crear variables locales, a nivel de forma y globales, como determinar sus tipos de datos, y como asignarles datos a estas variables. También aprenderás a concatenar datos string y a escribir ecuaciones de Visual Basic. Además, aprenderás algunos métodos de como planear código-usando tablas TOE y pseudocódigo-hasta ahondar en los temas de pruebas, depuración y documentación.

En este momento, realiza las lecciones A, B y C del Capítulo 2 y las lecciones A y B del Capítulo 3. Asegúrate de revisar los resúmenes de la lección y las preguntas para checar el avance de tu aprendizaje.

Estructuras de Control, E tc.

El crear aplicaciones de cualquier nivel de complejidad depende de establecer condiciones-funciones sensibles que permiten que la ejecución tome diferentes rutas-o una serie de instrucciones repetitivas. Como se mencionó anteriormente, en esta sección, aprenderás acerca del funcionamiento de los estatutos y Select Case, y acerca de los estatutos que inicializan y terminan los ciclos - las estructuras repetitivas For Next, Do While, y Do Until. Además se presentarán los operadores relacionales y lógicos y la forma en que estos estatutos inicializan e incrementan los contadores y actualizan los acumuladores. También presentaremos en esta sección los eventos de Change y Unload y la función MsgBox.

Ahora, realiza la lección A del Capítulo 4 y las lecciones A y C del Capítulo 5. Asegúrate de revisar los resúmenes de la lección y las preguntas para revisar el avance de tu aprendizaje.

Manipulación de Strings

En esta sección aprenderás acerca de diversas formas de manipulación de strings, además de las ya conocidas como asignación de datos y concatenación. Las funciones Right, L eft y Mid de Visual Basic regresan de un string, un rango específico de caracteres, y la función Instr (como "in string") busca dentro de un string determinado la existencia o no existencia de un conjunto de caracteres especificado.

Realiza la lección C del Capítulo 6, revisa los resúmenes de la lección y las preguntas para checar el avance de tu aprendizaje.

1.2.3 Cómo Depurar el Código en Visual Basic

Cómo Listar, Verificar, Encontrar y Reemplazar Código de Aplicación Cómo Atrapar Errores y Usar la Instrucción MsgBox Usando el Menú Debug: Stepping, Breakpoints y Watch

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  29  

Para depurar una aplicación, la habilidad con la que se cuente forma parte esencial, y en esta sección se presentarán un par de estrategias para depurar aplicaciones de Visual Basic. Se describirán estrategias generales, como las que has aprendido en cursos anteriores, y aprenderás algunas otras que hacen uso de las características que tiene el ambiente Visual Basic. La sección uno, "Cómo Listar, Verificar, Encontrar y Reemplazar Código de Aplicación", presentará algunas estrategias básicas desde cómo listar las propiedades y el código de aplicación, hasta técnicas para resolver problemas de variables que comúnmente se presentan. Las técnicas que se presentan en las siguientes secciones son más complejas: la sección dos cubre el tema de cómo atrapar er rores y el uso la instrucción MsgBox; en la sección tres, nos enfocaremos en las funciones que se encuentran en el menú Debug de Visual Basic stepping, breakpoints y watch.

L ecturas:

Zak, las secciones de depuración que se encuentran en las páginas 76, 132-33, 208, 281, 358, 406 y 565. Observación: Termina esta parte de la lectura después de leer la seccción "Usando el Menú Debug: Stepping, Breakpoints y Watch" que se encuentra a continuación.

Cómo L istar , Verificar , Encontrar y Reemplazar Código de Aplicación

Entre los procedimientos básicos de depuración se encuentran los siguientes: listar el código de aplicaciones y sus propiedades, verificar la ortografía de los nombres de variables, y revisar si los datos tienen asignado tipo de dato adecuado. Además de estos, en esta sección conocerás la herramienta que tiene Visual Basic para encontrar y reemplazar y como se usa para depurar las aplicaciones.

Trabaja con las secciones de depuración que se encuentran en los capítulos 1 al 6.

Cómo Atrapar er rores y Utilizar la Instrucción MsgBox

Muchos de los tipos de problemas de programación desde problemas con información inválida hasta problemas con fallas lógicas requieren de estrategias más complejas que las que se estudiaron en la sección pasada. Para empezar, mucha de la información crítica para saber qué sucedió se pierde cuando una aplicación "truena". Así que, la habilidad para resolver estos problemas se enriquece al contar con herramientas que previenen que "truene" la aplicación, que nos permiten indicarle que hacer cuando sucede algún error (proceso llamado atrapar er rores), y que nos da opciones para desplegar información crítica de lo que está pasando (por ejemplo, desplegar el valor de una variable). En esta sección estudiaremos el funcionamiento del objeto E rr y los estatutos On E rror y MsgBox y las maneras de usarlas para diagnosticar una serie de problemas.

Cómo Usar el Menú Debug: Stepping, Breakpoints y Watch

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  30  

No todos los datos inválidos y problemas lógicos presentan errores que pueda detectar una aplicación. Como dicen "la basura de entrada se convierte en basura de salida," y la aplicación continuará su proceso sin saber que tiene errores. Como es de esperarse, las técnicas basadas en estatutos como On E rror no sirven de nada. Así que, como una manera alterna de esperar que los errores interrumpan la ejecución, un desarrollador requiere de herramientas que permitan "interrumpir" la ejecución de la aplicación en puntos clave para observar los resultados que presenta la ejecución en ese punto específico. Esta sección presenta las funciones stepping, breakpoints y watch que permiten hacer esto.

1.3 H erramientas para Evaluar la Usabilidad de un Sistema: Pruebas H eurísticas y de Pensamiento en Voz Alta

1.3.1 Evaluación Heurística Hásica 1.3.2 Pruebas Básicas de Usabilidad Utilizando Técnicas de Pensamiento en

Voz Alta 1.3.3 Cómo Escribir un Reporte de Aspectos de Usabilidad (UAR)

1.3.1 Evaluación H eurística Básica

Evaluación Heurística Generalidades del Procedimiento de Uso de Heurísticas

o Visibilidad del Estatus del Sistema o Comparación Entre el Sistema y el Mundo Real o Control y Libertad del Usuario o Estándares y Consistencia o Prevención de Errores o Reconocer en Vez de Recordar o Flexibilidad y Eficiencia de Uso o Diseño Estético y Minimalista o Como Ayudar a los Usuarios a Reconocer, Diagnosticar y Recuperar

Errores o Ayuda y Documentación

Resumen

Evaluación H eurística

La evaluación heurística (HE) es una técnica utilizada para analizar la facilidad de uso en las primeras etapas del diseño de interfaces de usuario. Se desarrolló en Dinamarca hace diez años (Molich y Nielsen, 1990) con el objetivo de crear un método para analizar el diseño de interfaces de una manera informal, manejable y fácil de enseñar. La técnica se ha investigado, se han refinado las heurísticas, resultando en una técnica bien establecida. (Nielsen, 1993).

Las heurísticas HE, o los principios de usabilidad, se han establecido con la práctica en el diseño y evaluación de interfaces de usuario. Esto es, contienen una compilación de prácticas de buen diseño y fallas en diseño conocidas que han surgido en el campo del

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  31  

desarrollo de interfaces de usuario en los últimos treinta años. No son derivadas de las teorías de psicología de procesamiento de información que se expuso previamente, aunque se pueden comprender en términos de esa teoría. Se expondrá una breve descripción de como se usa esta técnica y la descripción de cada heurística y su relación con la teoría de proceso de información. Se presentarán ejemplos detallados de cada heurística conforme vayan surgiendo en el resto del curso

G eneralidades del Procedimiento para Utilizar H eurísticas

Para llevar a cabo una evaluación heurística es necesario que varias personas analicen el diseño de interfazde usuario para verificar si infringe alguna de las heurísticas. Si infringe alguna heurística es necesario modificar el diseño.

El diseño puede estar en cualquier etapa de desarrollo del producto. Puede ser tan preliminar como un borrador a lápiz del sistema; un prototipo parcial en Visual Basic; o un sistema operacional completo. Sin embargo, conforme el sistema esté más avanzado, más caro costará arreglar los problemas de usabilidad - por lo tanto HE tiene más valor en los primeros borradores o prototipos.

De manera general, varias personas harán evaluación HE de un diseño porque las investigaciones han demostrado que diferentes personas encontrarán diferentes infracciones. En un sistema sencillo (como el de un cajero automático que permite aproximadamente 6 funciones diferentes), probablemente cuatro o cinco examinadores serán suficiente para encontrar problemas de utilidad (Nielsen, 1993). Para sistemas más complicados se necesitan un número mayor de personas que evalúen el sistema. (Slavkovic y Cross, 1999). Sin embargo, debido a que es una técnica muy simple de aprender a usar, no es difícil encontrar miembros del equipo de desarrollo que realicen la evaluación. Además, con que una o dos personas evalúen el sistema se encontrarán errores de usabilidad que una vez corregidos mejorarán el uso del sistema que estas diseñando.

Una vez que comprendas las heurísticas, te darás cuenta que ya las usado de manera implícita al diseñar. Por lo tanto, las heurísticas pueden servir de inspiración para algunos detalles en el diseño de interfaces de usuario (por ejemplo, que palabras utilizar como etiquetas en los botones o menús) así como servir como una técnica de evaluación una vez que se haya hecho el diseño.

A continuación se encuentran nueve heurísticas enumeradas en Nielsen (1993) y una (la última) es de Nielsen y Mack (1994).

Visibilidad del Estatus del Sistema

Explicación breve de la heurística. La computadora debe mantener al usuario informado de lo que esta ocurriendo; las entradas que ha recibido la computadora; el proceso que se esta llevando a cabo y los resultados del procesamiento.

Relación con el modelo de procesamiento de información del usuario. La computadora debe proveerle información al usuario de manera visual o a través de algún sonido. Si no es así, el usuario no tiene la información necesaria para entender lo que está sucediendo.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  32  

Comparación Entre el Sistema y el Mundo Real

Breve explicación de la heurística. El diseño de la interfaz del usuario debe utilizar los conceptos, lenguaje, y las convenciones del mundo real que sean familiares para el usuario. Esto significa que el programador del sistema debe comprender la tarea que el sistema debe desempeñar - desde el punto de vista del usuario. Los aspectos culturales se hacen relevantes para el diseño de sistemas computacionales globales.

Relación con el modelo de procesamiento de información del usuario. Los conceptos familiares, el idioma, y las convenciones del mundo real de la interfazpueden hacer uso del conocimiento en la memoria a largo plazo del usuario por su experiencia con la tarea (independiente de la computadora).

Control y L ibertad del Usuario

Breve explicación de la heurística. Permite que el usuario tenga control de la interacción. Los usuarios deben poder corregir sus acciones facilmente, salirse de la interacción rápidamente en cualquier momento, y no verse forzados a hacer una serie de acciones controladas por la computadora.

Relación con el modelo de procesamiento de información del usuario. Los usuarios cometerán errores y por lo tanto, necesitan una opción fácil para corregirlos.

Estándares y Consistencia

Breve explicación de la heurística. La información que es igual debe verse igual (mismas palabras, iconos y posiciones en la pantalla). La información que es diferente debe ser expresada de manera diferente. Tal consistencia debe mantenerse dentro de la aplicación y de la plataforma. Los programadores deben conocer las convenciones de las plataformas.

Relación con el modelo de procesamiento de información del usuario. Así como la heurística de relación entre el sistema y el mundo real, esta heurística debe hacer uso del conocimiento previo del usuario y la experiencia con otras secciones de la misma aplicación y con otras aplicaciones en la misma plataforma.

Prevención de E r rores

Breve explicación de la heurística. El sistema debe prevenir que se cometan errores tanto como sea posible. Por ejemplo, si hay una cantidad limitada de acciones legales en una parte de la aplicación, ayuda a los usuarios a seleccionarlas - en lugar de permitir que lleven a cabo una acción para luego decirles que cometieron un error. Esto se puede considerar como una parte de la primera heurística, Visibilidad del Estatus del Sistema (que entradas son aceptables para el sistema computacional), pero debido a que es tan importante y tan frecuentemente violada, merece su propia heurística.

Relación con el modelo de procesamiento de información del usuario. Los usuarios pueden cometer errores debido a fallas en la percepción, a falta de conocimiento del paso siguiente, a solo recordar la esencia del comando y no todos los detalles, o un error al teclear o apuntar. Algunos de estos errores pueden se pueden prevenir al mostrar solo

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  33  

las acciones que son aceptables en un punto particular de interacción (al sombrear los botones inapropiados). Otros errores pueden ser detectados tan pronto el usuario lo cometa (no aceptar las abreviaciones incorrectas de un estado de la república en una forma de direcciones).

Reconocer en Vez de Recordar

Breve explicación de la heurística. Muéstrale al usuario todos los objetos y acciones disponibles. No le pidas al usuario que se acuerde de la información de otra pantalla de la aplicación.

Relación con el modelo de procesamiento de información del usuario. Esta heurística es una aplicación directa de las teorías de la memoria humana. Es más fácil para alguien reconocer lo que tiene que hacer si existen ciertas pistas en el amiente que le lleguen a la memoria de trabajo a través de la percepción y a través del conocimiento almacenado en la memoria de largo plazo.

F lexibilidad y E ficiencia de Uso

Breve explicación de la heurística. El diseño debe contar con atajos en tecleado que permita que los usuarios expertos puedan acelerar su interacción (en lugar de siempre usar los menús e iconos con un mouse). Los usuarios expertos deben de poder adaptar la interfazpara que las acciones frecuentes se hagan con mayor rapidez.

Relación con el modelo de procesamiento de información del usuario. El valor de los atajos proviene principalmente de los procesos motores del usuario. Por lo general es más rápido teclear que cambiar la mano contínuamente entre el tecleado y el mouse y apuntar a objetos en la pantalla. Además, los usuarios expertos desarrollan planes de acción, las cuales querrán utilizar frecuentemente, así que al personalizar pueden capturar sus planes en la interfaz.

Diseño Estético y Minimalista

Breve explicación de la heurística. Elimina los elementos irrelevantes de la pantalla que sólo representan desorden y confusión para el usuario.

Relación con el modelo de procesamiento de información del usuario. Esta heurística se relaciona con el aspecto de percepción de búsqueda visual y de memoria. Mientras exista más amontonamiento, hay más información en la que se tiene que hacer la búsqueda para encontrar la información deseada. Adicionalmente, mientras más información entre por la percepción al hacer la búsqueda visual, más información interfiere con la búsqueda en la memoria de largo plazo.

Como Ayudar a los Usuarios a Reconocer , Diagnosticar y Recuperar E r rores

Breve explicación de la heurística. Los mensajes de error deben ser escritos en un lenguaje simple, deben explicar el problema dar consejo constructivo de como corregir el error. Una vez más, esto se puede considerar parte de la primera heurística, visibilidad del estatus del sistema, pero es tan importante y violada tan frecuentemente que merece su propia heurística.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  34  

Relación con el modelo de procesamiento de información del usuario. Es necesario darle al usuario suficiente información para que comprenda la situación.

Ayuda y Documentación

Breve explicación de la heurística. Si el sistema no es extremadamente sencillo, va a ser necesario que cuente con sus opciones de ayuda y con una documentación adecuada. La ayuda y documentación debe estar siempre disponible, fácil de buscar y debe aportar consejos directos que sean aplicables a las tareas del usuario.

Relación con el modelo de procesamiento de información del usuario. Una vez más, esto es para dar al usuario suficiente información para comprender la aplicación. La característica de búsqueda debe permitir que se encuentre información al preguntar por la esencia del significado en lugar de la palabra clave exacta, porque las personas recuerdan la esencia y no las palabras exactas (si es que acaso lo supieron alguna vez).

Resumen

Si tomas en cuenta esta diez heurística al diseñar una interfazde usuario, tu sistema tendrá más utilidad. Para tener suficiente tiempo para corregir las fallas, es recomendable que el sistema sea evaluado por varias personas durante las primeras etapas de desarrollo del sistema (aunque sea en borrador o prototipo).

Durante el progreso de este curso, repetiremos las heurística y daremos ejemplos concretos de las fallas y las acciones correctivas.

Referencias

Molich, R., and Jakob Nielsen. "Improving a Human-Computer Dialog." Communications of the ACM 33, no. 3 (1990): 338 48.

Nielsen, Jakob. Usability Engineering. Boston, MA: Academic Press (AP Professional), 1993.

Nielsen, Jakob, and Robert L. Mack, eds. Usability Inspection Methods. New York, NY: Wiley, 1994.

Slavkovic, A., and K. Cross. "Novice Heuristic Evaluations of a Complex Interface." Proceedings Companion of CHI 1999 (Pittsburgh, Pennsylvania, May 15 20). New York, NY: ACM, 1999.

1.3.2 Pruebas Básicas de Usabilidad Utilizando Técnicas de Pensamiento en Voz Alta

Referencias

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  35  

Las pruebas de usabilidad que emplean pensamiento en voz alta son técnicas empíricas utilizadas para evaluar la usabilidad del prototipo de una interfaz. "Esta técnica puede ser el método ingenieril de usabilidad más valioso" (Nielsen, 1993, p. 195). Esta técnica consiste en pedirle al usuario que comente en voz alta lo que está pensando mientras lleva a cabo una tarea con tu sistema; mientras tanto, el programador debe observar silenciosamente y aprender lo que piensa el usuario de la tarea que está realizando y qué partes del sistema representan para él un problema.

Aún y cuando es posible llevar a cabo esta prueba basándote en un prototipo de papel, es más fácil y más real llevar a cabo esta prueba con un prototipo ya funcional, por lo que esta técnica, por lo general se lleva a cabo después de que se contuye el prototipo.

La evaluación heurística supone que un analista, generalmente el desarrollador del sistema, puede aplicar un par de heurísticas de diseño exitosamente y con ello pronosticar problemas de usabilidad. Un par de estas heurísticas requieren implícitamente que el analista "piense como el usuario" (por ejemplo, relación entre el sistema y el mundo real requiere que el analista conozca la tarea que va a realizar el usuario y "hable el idioma del usuario"; la consistencia y los estándares requieren que el analista conozca lo que el usuario considera consistente y las interfaces conocidas ya por el usuario.) Entre más profundice el desarrollador en este tema, mejor puede pronosticar esta técnica de evaluación heurística. Por otro lado, las pruebas de usabilidad que utilizan el pensamiento en voz alta asumen que el analista ya no puede "pensar como el usuario" debido a que el analista conoce demasiado acerca del sistema ( y a veces muy poco acerca del alcance de la tarea). En este caso, una técnica empírica con la cual ciertos usuarios representativos interactúen con un prototipo representa la mejor manera para descubrir lo que un usuario típico piense o haga con el sistema. Estas dos técnicas descubrirán diferentes problemas de usabilidad, por lo que recomendamos que uses ambas técnicas para el diseño de un sistema.

El procedimiento para hacer una prueba efectiva de usabilidad con pensamiento en voz alta es relativamente fácil. Primero, se crean las tareas típicas que un usuario realiza con frecuencia. Después se identifican los usuarios que representen el tipo de personas típicas que usarán tu sistema; deben contar con un fondo académico similar y con la experiencia computacional similar a la que tendrán los usuarios esperados. Se invita a estas personas a un laboratorio, se les informa el propósito y el procedimiento de esta prueba y luego se les da un entrenamiento sobre como pensar en voz alta. Después se les pide pensar en voz alta mientras realizan algunas tareas predefinidas. Típicamente, se les toma video mientras trabajan con el sistema. Se les permite utilizar todas las opciones del sistema sin ayuda ni interrupciones. Después, se analizan los videos para detectar "incidentes críticos" (se describe en el siguiente módulo) y algunas pistas para conocer el problema y las posibles soluciones que existen para la siguiente versión del sistema, o para detectar que funciones son fáciles de usar y se deben mantener en la siguiente versión.

El concepto psicológico base de la prueba de pensamiento en voz alta es que los usuarios pueden externar sus pensamientos; específicamente, pueden hablar del contenido de su memoria de trabajo mientras trabajan sobre una tarea (Ericsson y Simon, 1993). Es fácil expresar el contenido de la memoria mediante la linguística (como cuando buscas dentro de un menú un elemento específico), y no interfiere mucho con el desempeño de la tarea. Es posible que las personas externen en voz alta el

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  36  

contenido de su memoria de trabajo (como cuando buscas un color azul específico dentro de un panel de control), pero al hacerlo, generalmente se alenta el desempeño de la tarea. Por lo general, las personas no pueden expresar en voz alta lo que está sucediendo dentro de la memoria de trabajo, esto es, mencionan los conceptos o los objetos que están utilizando pero no describen el proceso cognitivo rápido del proceso que están realizando.

Como los usuarios externan en voz alta el contenido de su memoria de trabajo, los diseñadores de interfaz que escuchan estos pensamientos pueden aprender mucho sobre lo que están pensando. Conocen cuales comandos o elementos del menú tienen sentido para los usuarios y de que manera se conectan con la tarea que están realizando. Pueden conocer cuáles elementos ve el usuario y cuales de ellos pasan desapercibidos. Pueden detectar cuales procedimientos de la interfaz son fáciles de interpretar y cuales de ellos se interpretan de manera incorrecta. Pueden saber de que forma envía la interfaz al usuario por un camino incorrecto, como reconoce el usuario el error y da paso atrás o como ayuda o perjudica la interfaz a la fácil navegación del sistema. Por lo tanto, el pedirle al usuario que piense en voz alta y observar su interacción sin "ayudarlo" representa una forma valiosa de aprender mucho acerca de la usabilidad del sistema.

Referencias

Nielsen, J. Usability Engineering. Boston, MA: Academic Press (AP Professional), 1993.

Ericsson, K.A., and H.A Simon. Protocol Analysis: Verbal Reports as Data, Revised Edition. Cambridge, MA: MIT Press, 1993

1.3.3 Cómo Escribir un Reporte de Aspectos de Usabilidad (UAR)

Los Reportes de Aspectos de Usabilidad Los Elementos de un Reporte UAR

o Identificador UAR o Una Descripción Breve de los Aspectos de Usabilidad o La Evidencia de un Aspecto o La Explicación de un Aspecto o La Severidad de un Problema o el Beneficio de una Característica

Positiva o Las Posibles Soluciones y los Costos Potenciales (Si el Aspecto Tiene un

Problema) o La Relación que Tiene con Otros Aspectos de Usabilidad (Si Acaso

Existe) IMPORTANTE: ¡Siempre Da un Paso Atrás Para Ver Todo el Panorama!

Los Reportes de Aspectos de Usabilidad

Mientras observas una interfaz usando las técnicas que vas a aprender en este curso, vas a encontrar aspectos en la interfazque representan problemas para los usuarios ( que querrás mejorar en la siguiente versión) y aspectos que son muy útiles para los usuarios

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  37  

(que querrás mantener en la siguiente versión). El desarrollar un reporte que describa estos aspectos (llamado Reporte de Aspectos de Usabilidad o U A R) te ayudará a crear una siguiente versión más utilizable. En el mundo real, estos reportes están dirigidos hacia los miembros del equipo de desarrollo que no conocen el asunto de usabilidad; por lo tanto, el reporte debe ser claro y completo. Aún y cuando creas este reporte para tí mismo, la claridad te ayudará a que seis meses más tarde, cuando quieras implementar los cambios sugeridos, comprendas el UAR.

Los E lementos de un Reporte U A R

Nos apegaremos a una forma de reporte estándar para que recuerdes incluir las partes específicas de información para cada aspecto de usabilidad. El UAR debe incluir lo siguiente:

Identificador UAR <Problema o Característica positiva> Una descripción breve del aspecto de usabilidad Las pruebas que tienes relacionadas con este aspecto La explicación del aspecto La severidad del problema o el beneficio de una característica positiva La posible solución y los costos potenciales (si el aspecto representa un

problema) La relación que tiene con otros aspectos de usabilidad (si acaso existe)

Enseguida haremos una descripción de cada uno de los aspectos anteriores esto es, que significa y la razón por la cual es necesaria esta información. Presentaremos muchos ejemplos de UAR a medida que ahondemos en los detalles de la técnicas de HE y de pensamiento en voz alta.

Identificador U A R

Con el objetivo de que se archive el reporte, este debe contar con un identificador único. Este identificador se puede formar con números y letras, para el caso en que más de una persona esté trabajando en este proyecto o para el caso que se esté utilizando más de una técnica de análisis. Por ejemplo, si Carlos Pérez y Judith Taméz están llevando este análisis, podemos crear un identificador como CP10 o JT8. Si se están utilizando los estudios de evaluación heurística y usabilidad de pensamiento en voz alta, los identificadores pudieran ser HE4 o TA9.

Seguido de este identificador puedes usar la palabra "Problema", si el reporte describe un problema de usabilidad de interfaz, o las palabras "característica positiva", si describe un aspecto de la interfazque consideras debe permanecer en la siguiente versión.

Una Descripción Breve de los Aspectos de Usabilidad

Esta descripción será el "nombre" de la UAR que usarás cuando la menciones como relación con otra UAR. Asigna el nombre más corto que puedas (de tres a cinco palabras) asegurando que describa el aspecto y además que se distinga del resto de los aspectos del sistema.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  38  

Si la UAR trata un problema (no una característica positiva), asegúrate que el nombre contenga la descripción del problema, no de la solución. Por ejemplo, si hay un botón como el siguiente:

Figura 1: Un botón con una etiqueta muy pequeña.

y crees que la etiqueta del botón es un pequeña para una que una persona la lea cómodamente, debes llamar la UAR de la siguiente manera "etiqueta Press-Me muy pequeña" (que señala el problema) y no "etiqueta Press-Me debe ser de 24 puntos" (que es una posible solución y no el problema). La razón por la cual debes etiquetar la UAR con el problema y no con la solución, es que es probable que encuentres varios problemas similares y juntos presentan una solución común. Pero si solucionas uno de manera rápida y la mencionas en el nombre, tal vez opaquen los problemas comunes que tiene la aplicación.

Las Evidencias de un Aspecto

Este es el material de soporte objetivo que justifica el aspecto que identificaste y especifica que merece un reporte. Esta sección debe contener la información suficiente para que la persona que lea este UAR comprenda la razón que hizo que se creara este reporte. Para un reporte HE, por ejemplo, las evidencias pueden consistir en una imagen que represente desorden y la heurística que habla de diseño estético y minimalista. O puede consistir en una lista de elementos de menú que no tienen un atajo y la heurística que habla de incluir atajos. En un estudio de pensamiento en voz alta la prueba consiste, por lo general de lo que se ve en pantalla ( una impresión de la pantalla o una descripción), las acciones que realizó el usuario (teclado, movimientos de mouse), lo que hizo el sistema como respuesta a las acciones del usuario, y lo que dijo el usuario. Si cuentas con un video o con la posibilidad de editarlo, puedes incluir una animación breve.

Tienes que incluir suficiente información al respecto relacionada con la identificación de un aspecto para que la persona que lo lea comprenda lo que estaba pensando el analista cuando se identificó este aspecto (HE) o lo que el usuario estaba tratando de hacer cuando el aspecto detuvo o facilitó el progreso.

La Explicación de un Aspecto

Esta es la interpretación de la evidencia. Esto es, para la prueba de usabilidad de pensamiento en voz alta, la razón por la cual pasó lo que pasó, o, para una HE, la razón por la cual crees que se diseñó de la manera en que está diseñada. Aquí se pueden incluir leyendas como: "la etiqueta del botón XYZ, es un término de programación estándar, pero el usuario, al parecer, no estaba familiarizado con este término" o "el sistema estaba en modo de edición, pero el usuario pensó que estaba en modo ejecutable porque no hay una diferencia muy marcada entre estos modos en la pantalla." (Esto se debe expresar de manera que analice la situación que sucedió con el aspecto del sistema,

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  39  

NO de una manera que de insinúe que se debe hacer una evaluación del desarrollador o del usuario.)

Debes proveer suficiente contexto en esta explicación para que la persona que lo lea comprenda el problema aún y cuando no conozca el sistema y no lo domine al grado que tu lo dominas. (En nuestra experiencia, cuando leas estos reportes después de un par de meses, necesitarás tú también mucho contexto para comprenderlos).

La Severidad del Problema o el Beneficio de una Característica Positiva

Aquí debes especificar, según tu razonamiento, el grado de importancia que tiene este problema para que se resuelva o para mantenerlo como característica positiva. Aquí puedes incluir información referente a la frecuencia con la cual se le presentará al usuario, si acaso crees que aprenda el usuario como funciona este problema, si crees que el problema le afecta más a los usuarios nuevos, no frecuentes o con experiencia, entre otros.

Las Posibles Soluciones y los Costos Potenciales (Si el Aspecto T iene un Problema)

Si el aspecto representa un problema (opuesto a una característica positiva que debe permanecer en la siguiente versión del software), aquí es donde se debe proponer una solución. No es necesario contar con una solución al momento que identificaste un problema podrá darse el caso en que después de analizar toda la interfaz, muchos problemas estén relacionados y se puedan solucionar todos haciendo algunos cambios generales.

Sin embargo, si propones alguna posible solución, documenta cualquier costo potencial de diseño. Por ejemplo, si el problema que se presenta es que no existen atajos para los elementos de menú del sistema de correo y propones como solución uitlizar CTRL-S para ENVIAR el correo. El costo potencial de esta solución puede ser que el atajo ya exista para otra función (por ejemplo para GUARDAR), así que antes de hacer un cambio de diseño, se recomienda que analices el resto de los atajos con los que cuente el sistema.

La Relación que T iene con Otros Aspectos de Usabilidad (Si Acaso Existe)

Muchas veces los UAR están relacionados entre sí. Aquí es donde se documenta con cual UAR está relacionado cada uno y un breve enunciado que indica la forma en que está relacionado. Asegúrate que todas las UAR relacionadas documenten al resto de las UAR relacionadas. Por decir, Si el UAR #1 está relacionado con el UAR #30, el UAR #30 debe indicar en esta sección, la relación que tiene con UAR #1 y el UAR #1 debe indicar la relación que tiene con la UAR #30. (El error más común es que en la UAR más reciente indiques la relación con las UAR anteriores, pero no te regreses para documentar en las UAR previas su relación con la UAR más reciente).

I MPO R T A N T E : ¡Siempre da un Paso Atrás Para Ver Todo el Panorama!

Este último punto del UAR describe un paso muy importante para el proceso de análisis de usabilidad: da un paso hacia atrás y busca patrones en los problemas de usabilidad.

SSD4:  Diseño  y  Evaluación  Centrado  en  el  Usuario  

Diseño  de  Interfaces   Página  40  

Se recomienda que lleves a cabo este paso varias veces durante el análisis. Cuando se crea cada UAR, debes revisar los UAR previos y ver en qué forma se relacionan con el nuevo. Cuando hayas terminado todos los UAR, debes revisar todos de nuevo y buscar patrones. Este paso te ayuda a detectar problemas de interfazprofundos, cuya solución a veces es sencilla y puede resolver muchos problemas pequeños. Este paso también te puede ayudar a reunir pruebas para realizar un cambio de fondo para la interfazpropuesta, algo que no puedes lograr al considerar las UAR de forma aislada.