Di - Unidad 1

SSD4: Diseño y Evaluación Centrado en el Usuario
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 Iterativo

¿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.
Diseño de Interfaces Página 1

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
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.
V isual 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.
E valuació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
M anipulació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

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).
L a F uncionalidad 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

Debido a que la
sostenerse con la mano. 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
Figura 2: El nudillo simulado nos invita a"manejarlo" con el mouse. 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.
T areas Básicas y el C iclo de E ventos/Redibujar

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

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,O bjetos 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

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
Figura 3: Dos formas para cambiar el valor modelo.
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

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.
E ncapsulació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

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.

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

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.

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.

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

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.
M emoria
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"). C hunk 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 A uditivo: C hunks 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

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

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.
C apacidad 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.

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:

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 r rores
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.
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.

1.2 Una Herramienta 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
E valuaciones
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
visual mente-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

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 U I 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 U I 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 U I, 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 U I. (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.)
L as 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

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. O bservació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. O bservació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ódulo²
una 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 A mbiente 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

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 O btener A yuda
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 ,I«7KHQ«(OVH y Select C ase 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.
O bservación: Lleva a cabo esta lectura después de leer la
sección siguiente llamada "Formas, Controles, Cómo

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. O bservació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. O bservació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.
O bservación: Lleva a cabo esta lectura después de leer la
sección siguiente llamada "Manipulación de Strings".
Formularios, Controles, Cómo Escribir y E ditar 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.
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 ,I«7KHQ«(OVH y
Select C ase, y acerca de los estatutos que inicializan y terminan los ciclos - las
estructuras repetitivas For Next, Do W hile, 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 C hange 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.
M anipulació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 M id 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

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.
O bservació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, E ncontrar y Reemplazar Código de A plicació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 A trapar 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 r r y los
estatutos O n E r ror y MsgBox²y las maneras de usarlas para diagnosticar una serie de
problemas.
Cómo Usar el M enú Debug: Stepping, B reakpoints y W atch

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 O n E r ror 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 Herramientas para Evaluar la Usabilidad de un Sistema: Pruebas

Heurí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 Heurí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
E valuació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

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).
V isibilidad 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.

Comparación E ntre el Sistema y el M undo 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 procesa miento 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 m anera 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, V isibilidad 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 procesa miento 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

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 V ez 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 M inimalista
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 A yudar 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.

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 .
A yuda 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 C HI 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

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

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 (U AR)

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
(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 B reve 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.

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.
L as E videncias 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.
L a E xplicació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,

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).
L a Severidad del Problema o el Beneficio de una C aracterí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.
L as 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.
L a Relación que T iene con O tros Aspectos de Usabilidad (Si A caso E xiste)
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 M P O R T A N T E : ¡Siempre da un Paso A trá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.

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.

Di - Unidad 1

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Di - Unidad 1

Загружено:

Авторское право:

Доступные форматы

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

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

1.1 Fundamentos del Diseño y Pruebas Centradas en el Usuario

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

1.1.1 Diseño Iterativo

¿Porqué Diseño Iterativo?

El razonamiento fundamental tras este curso es que un diseñador de sistemas no puede

Diseño de Interfaces Página 1

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

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

Dos dudas que provoca este método son:

La clave para responder a la primera pregunta se encuentra en una metodología de

Para contestar la segunda pregunta, se requiere mucho conocimiento y técnica. Para

Uno de los lenguajes de programación más populares en la actualidad es Visual Basic,

La evaluación heurística es un proceso que utilizan los diseñadores para estimar la

Estudios en Voz A lta

El método de pensamiento en voz alta es un método empírico poderoso para la

1.1.2 Conceptos Básicos de la Programación Interactiva

Las interfaces de usuarios gráficas modernas usan un estilo de interacción llamado

Diseño de Interfaces Página 3

los programas están estructurados de manera que las interacciones se realizan en

Figura 1: Los nudillos dan funcionalidad para que pueda

Diseño de Interfaces Página 4

Aquí se muestra el botón de cambio de tamaño en la esquina de la ventana de la interfaz

El concepto de retroalimentación tiene un propósito similar. La Retroalimentación es

T areas Básicas y el C iclo de E ventos/Redibujar

Diseño de Interfaces Página 5

El diseño de interfaces de usuario moderno tiene como objetivo proveer la apariencia de

La estructura anterior es tan común que se encuentra en uso en la mayoría de los

Diseño de Interfaces Página 6

las diversas ventanas y la modificación de la salida a pantalla es tarea del sistema de

Controles,O bjetos Modelo, y la Interpretación de Eventos

Dado el ciclo básico de evento/redibujo descrito anteriormente, la duda central radica

Diseño de Interfaces Página 7

En términos de manipulación directa, los controles proveen una presentación de los

Para modelar los detalles

Diseño de Interfaces Página 8

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

E ncapsulación y Patrones de A cceso

Es muy importante si no crítico, que los objetos modelo mantengan la encapsulación de

public class myModelClass {

Diseño de Interfaces Página 9

A diferencia de sus predecesores, Visual Basic .Net es un lenguaje orientado a

Private myDataValue As myDataType

El patrón de acceso descrito anteriormente provee la encapsulación básica necesaria

Public Sub setMyDataValue(ByVal value as myDataType)

If <value is a valid value > Then

Diseño de Interfaces Página 10

A continuación se presenta un ejemplo específico que aplica el modelo de patrón de

Public Sub setMinuteValue(ByVal min As Integer)

'Force into valid range

'Update internal value

'Prepare a two digit string (zero filled) to display

' Update the text display if this is a change

Diseño de Interfaces Página 11

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

Diseño de Interfaces Página 12

La tríada de un buen diseño de sistema consiste en

El objetivo de este módulo es ayudarte a diseñar mejores sistemas proporcionando un

Cuando alguien usa un sistema computacional, lleva a cabo diferentes actividades

Diseño de Interfaces Página 13