2.1. TEORÍA PARA LA
INTERFAZ
Si tuviera que desarrollar una interfaz para
un programa de computadora en este momento, considerando los enfoques teóricos
de la creatividad, lo primero que consideraría serían tres áreas para enfocar
las herramientas: a) identificación del problema b solución de problemas y c)
guías de evaluación.
a) Identificación de problemas. En mi caso he
tenido especial éxito usando algo que he llamado bucles de retroalimentación.
En general creo que cualquier aproximación bajo un enfoque de teoría de
sistemas podría ayudar en esta parte, siempre y cuando se pusiera énfasis en
guiar hacia la generación de relaciones originales. Eso último, bajo un esquema
de software puede facilitarse mediante ejemplos, preguntas e incluso la propia
herramienta puede establecer las relaciones originales, siempre y cuando el
usuario tenga una buena base de datos, con elementos priorizados y relacionados
lógicamente, uno a uno. Establecer relaciones más globales o provocativas a
partir de las relaciones individuales puede ser tarea del programa.
b) Solución de problemas. Me parece que Triz
ha sido una excelente opción con bastantes probabilidades de traducirse a
software. Quizá aquí pudiera introducirse algún enfoque adicional, por ejemplo
los elementos planteados por Walas: Preparación, incubación, iluminación,
verificación. Claro que esto último complica las cosas pues el programa debería
tener una base de datos poderosa que pudiera utilizarse para la preparación y
la iluminación. Esto puede significar al menos dos opciones: fue alimentado ex
profeso por el usuario o el programa es desde un inicio especializado para
ciertas áreas. Aquí vale la pena destacar algo importantísimo: "el creativo
ve lo que otros no ven", entonces será necesario tener elementos en dicha
base de datos que en un enfoque tradicional no estaría, pero que bajo un
enfoque creativo pueden ser medulares. Así, el acopio de información, o
preparación, debería de tener estos datos alternativos o aparentemente fuera de
lugar bajo un enfoque tradicional de solución de problemas.
c) Evaluación. En mis cursos a esta parte
generalmente la llamo cambio con garantía. Esto significa que vamos a evaluar
las ideas, sus posibilidades de implementación, y de originalidad bajo dos
premisas: que signifiquen cambio y que tengan alguna forma de considerar sus
posibilidades de éxito. En este sentido hay varias herramientas provenientes de
otras áreas, como administración, economía, negocios, etc. que pueden
integrarse al programa sin olvidar como criterio importante la ponderación de
la originalidad.
PRINCIPIOS PARA EL DISEÑO DE INTERFACES DE USUARIO
Existen principios relevantes para el diseño e
implementación de IU, ya sea para las IU gráficas, como para la Web.
Anticipación
Las aplicaciones deberían intentar anticiparse
a las necesidades del usuario y no esperar a que el usuario tenga que buscar la
información, recopilarla o invocar las herramientas que va a utilizar.
Para ver esta imagen deberá descargar el
archivo de Word que se encuentra en la opción "Bajar trabajo" ubicado
en la parte superior de este documento
En la Figura 2 se ilustra como el procesador
de texto se anticipa a las necesidades del usuario, proporcionando las características
del texto seleccionado -fuente, tamaño, alineación, etc.- permitiendo que el
usuario pueda modificarlas ágilmente.
Autonomía
La computadora, la IU y el entorno de trabajo
deben estar a disposición del usuario. Se debe dar al usuario el ambiente flexible
para que pueda aprender rápidamente a usar la aplicación. Sin embargo, está
comprobado que el entorno de trabajo debe tener ciertas cotas, es decir, ser
explorable pero no azaroso.
Para ver esta imagen deberá descargar el
archivo de Word que se encuentra en la opción "Bajar trabajo" ubicado
en la parte superior de este documento
La cantidad de opciones propuestas propone un
grado de complejidad que no
permite que el usuario pueda aprender a utilizar el sistema en forma
progresiva.
Es importante utilizar mecanismos indicadores
de estado del sistema que mantengan a los usuarios alertas e informados. No
puede existir autonomía en ausencia de control, y el control no puede ser
ejercido sin información suficiente. Además, se debe mantener información del
estado del sistema en ubicaciones fáciles de visualizar.
Para ver esta imagen deberá descargar el
archivo de Word que se encuentra en la opción "Bajar trabajo" ubicado
en la parte superior de este documento
En la Figura 4 se ejemplifica una incorrecta
disposición de componentes en la IU. El reloj no debe ser incorporado en el
menú del sistema ya que aporta confusión al usuario. Para mantenerlo informado
sería mas adecuado colocarlo en la barra de estado del sistema.
Percepción del Color
Aunque se utilicen convenciones de color en la
IU, se deberían usar otros mecanismos secundarios para proveer la información a
aquellos usuarios con problemas en la visualización de colores
Para ver esta imagen deberá descargar el
archivo de Word que se encuentra en la opción "Bajar trabajo" ubicado
en la parte superior de este documento
En la Figura 5 se representa un mecanismo
secundario muy utilizado para ejecución de comandos: los comandos abreviados
(shortcut-keys). Sin embargo la aplicación presenta un problema de
inconsistencia ya que define combinaciones de teclas que difieren a lo esperado
por el usuario, por ejemplo Alt+< en lugar de Alt+B.
Valores por Defecto
No se debe utilizar la palabra
"Defecto" en una aplicación o servicio. Puede ser reemplazada por
"Estándar" o "Definida por el Usuario", "Restaurar
Valores Iniciales" o algún otro término especifico que describa lo que
está sucediendo. Los valores por defecto deberían ser opciones inteligentes y
sensatas. Además, los mismos tienen que ser fáciles de modificar.
Consistencia
1. Para lograr una mayor consistencia en la IU se
requiere profundizar en diferentes aspectos que están catalogados en niveles.
Se realiza un ordenamiento de mayor a menor consistencia:
2. Interpretación
del comportamiento del usuario: la IU debe comprender el significado que le
atribuye un usuario a cada requerimiento. Ejemplo: mantener el significado de
las los comandos abreviados (shortcut-keys) definidos por el usuario.
3. Estructuras
invisibles: se requiere una definición clara de las mismas, ya que sino el
usuario nunca podría llegar a descubrir su uso. Ejemplo: la ampliación de
ventanas mediante la extensión de sus bordes.
4. Pequeñas
estructuras visibles: se puede establecer un conjunto de objetos visibles
capaces de ser controlados por el usuario, que permitan ahorrar tiempo en la
ejecución de tareas específicas. Ejemplo: ícono y/o botón para impresión.
5. Una
sola aplicación o servicio: la IU permite visualizar a la aplicación o servicio
utilizado como un componente único. Ejemplo: La IU despliega un único menú,
pudiendo además acceder al mismo mediante comandos abreviados.
6. Un
conjunto de aplicaciones o servicios: la IU visualiza a la aplicación o
servicio utilizado como un conjunto de componentes. Ejemplo: La IU se presenta
como un conjunto de barras de comandos desplegadas en diferentes lugares de la
pantalla, pudiendo ser desactivadas en forma independiente.
7. Consistencia
del ambiente: la IU se mantiene en concordancia con el ambiente de trabajo.
Ejemplo: La IU utiliza objetos de control como menús, botones de comandos de
manera análoga a otras IU que se usen en el ambiente de trabajo.
8. Consistencia
de la plataforma: La IU es concordante con la plataforma. Ejemplo: La IU tiene
un esquema basado en ventanas, el cual es acorde al manejo del sistema
operativo Windows.
Para ver esta imagen deberá descargar el
archivo de Word que se encuentra en la opción "Bajar trabajo" ubicado
en la parte superior de este documento
La
inclusión de la opción X para cerrar la ventana –operación común mente
utilizada en estas aplicaciones- simplifica la operatividad del mismo.
La inconsistencia en el comportamiento de
componentes de la IU debe ser fácil de visualizar. Se debe evitar la
uniformidad en los componentes de la IU. Los objetos deben ser consistentes con
su comportamiento. Si dos objetos actúan en forma diferente, deben lucir
diferentes. La única forma de verificar si la IU satisface las expectativas del
usuario es mediante testeo
GUIAS PARA EL DESARROLLO DE INTERFAZ:
El iPhone de Apple ha representado un modelo
de interfaz de usuario revolucionario para los usuarios. Los usuarios pueden
ver páginas web, usar aplicaciones web y utilizar aplicaciones instaladas en
los iPhone como aplicaciones de email, el iPod o la cámara digital en cualquier
sitio donde estén.
Por ello, Apple ha lanzada la guía de estilo
para las interfaces de usuarios para el iPhone, donde explica como diseñar las
interfaces de usuarios para que la experiencia en el iPhone sea satisfactoria.
La guía está dividida en cuatro secciones:
• “iPhone
and the User’s Environment”. Introduce
el iPhone y describe como el entorno del usuario influencia el diseño y el uso
del contenido en el iPhone. Este capítulo también describe características de
la interfaz de usuario del iPhone que hay que tener en cuenta al diseñar
contenido.
• “Content
on iPhone: Is It a Webpage or an Application?”. En este capítulo se muestran los diferentes tipos de contenidos que se
puedes desarrollar para el iPhone y lo que tienes que tener en cuenta para
desarrollar en alguna de esas áreas.
• “Principles
and Guidelines for Creating Great iPhone Content”. Este capítulo cubro los principios del diseño de interfaces para personas
para mostrarte las guías de estilo para ayudarte a realizar los primeros pasos
de tu diseño.
• “Metrics,
Layout Guidelines, and Tips”. Presenta
la disposición y las métricas de la interfaz que deberías utilizar al
desarrollar una aplicación o una web para el iPhone.
