|
|
Hay veces que
el negocio al cual nuestro sistema está orientado es perfectamente
modelado; y que la implementación de nuestros subsistemas es realmente
buena desde el punto de vista del re uso, la escalabilidad y el mantenimiento.
He visto de estos casos en que todo parece planeado y desarrollado a la perfección.
Casos en que ningún detalle parece haberse escapado. Cuando se presenten
esas situaciones, nunca está de más preguntarte... chico, ¿
qué es de tu interfaz de usuario?
Alguna vez creo que conté del desarrollo de un sistema para administrar
una sala de bingo. Entre sus interfaces de usuario, descubrí algunos
de los aspectos que me llevaron a la recomendación anterior. La computadora
que controlaba la máquina de juego ( motor paso a paso, aspiradora
de bolas, carteles indicadores y proyección de video) y la partida
de juego (en tiempo real); era manejada durante una partida por un operador.
Éste digitaba los números que iban saliendo en secuencia. Era
tan rápido para realizar esta tarea que mi sistema tuvo que ser modificado.
Tuve que cambiar por una alternativa más eficiente algunas de las partes
ya diseñadas, sino, los carteles indicadores así como las terminales
remotas de juego recibían la información de los números
digitados por este señor con retrasos. Esto impedía que los
jugadores pudieran seguir el juego con información actualizada. Mi
desafío fue optimizar los algoritmos de seguimiento de la partida para
que entre cada número digitado, el sistema pudiese realizar las tareas
de publicación de la información mencionada. Hasta que mi sistema
no cayó bajo los dedos de este operador, éste era un ejemplo
de diseño e implementación. Olvidé hacerme la pregunta
que estoy recomendando. Conclusión, investigue las habilidades de sus
usuarios cuando releve los requerimientos.
Y aunque ese problema pude resolverlo, tiempo después apareció
otro más que interesante. Las doce terminales remotas se alquilaban
a un determinado precio a jugadores compradores de varios cartones por partida.
Estas terminales ejecutaban un algoritmo de seguimiento de la partida y detectaban
las tres, de todas las tarjetas adquiridas, con mayor probabilidad de ganar.
Es decir, funcionaban como una ayuda para los jugadores. Les recuerdo que
cuando se completa una línea en un cartón o cuando se completa
un cartón, el jugador debe cantar "línea" o "bingo"
y así ganar. De no hacerlo, y ante el próximo número,
si otro jugador canta su logro, el anterior lo perdió. Es decir, hay
que ganar, darse cuenta de ello y hacerlo saber.
Debido a determinados requerimientos fijados por el cliente, era necesario
poder bloquear el funcionamiento del equipo desde una de esas terminales.
Creo que estaba orientado a situaciones extremas en las cuales podía
ser necesario inutilizar el sistema. Para ello mi sistema leía el tecladito
de las terminales y ante una secuencia de seis caracteres realizaba esta operación.
La próxima partida no podía generarse, pues el sistema se bloqueaba
y mostraba un mensaje al operador, "Sistema inhabilitado, consulte al
fabricante".
Los usuarios de estas terminales solo usaban el tecladito para ingresar el
número de sus tarjetas de juego. Nunca sospeché que podía
haber alguno aburrido durante una partida, que trataría de matar su
tiempo toqueteando el tecladito. Resultado, el teléfono de mi oficina
sonó una noche registrando una llamada que pedía hablar con
el fabricante. Conclusión, no subestime a un usuario aburrido y codifique
claves mucho más largas de seis caracteres.
En otra oportunidad desarrollamos un sistema de telefonía pública
para ser manejados por operadores de una empresa de un país de Latinoamérica.
Estos operadores, hasta el momento de la instalación de nuestro sistema,
operaban centrales telefónicas analógicas con las clásicas
clavijas y auriculares. Muchos de ellos no habían visto una computadora
en su vida y mucho menos la habían utilizado. Fue decepcionante ver
que los operadores observaban con cierto temor a ese periférico llamado
"mouse" y no solo no se animaban a usarlo sino que directamente
lo rechazaban. Conclusión, investigue quiénes serán los
usuarios de su sistema, que formación poseen, qué tareas y de
qué forma las realizan.
Un sistema de mapeo cerebral es un sistema que, basándose en la distribución
de potencia en el espectro de frecuencias de señales electroencefalográficas,
muestra una representación gráfica de esta distribución.
Dicha información se codifica en una escala de colores desde la mayor
intensidad en rojo, hasta la menor en azul, pasando por los naranjas, amarillos
y verdes. La idea es que la escala debe estar compuesta por colores que hagan,
de la misma y por consiguiente de los gráficos, una superficie cuyo
gradiente de cambio muestre la tendencia de las distintas distribuciones en
los veinte electrodos que cubren la cabeza del paciente. Si los colores no
son bien elegidos, las imágenes son confusas para realizar un análisis
visual. Usamos en aquella ocasión un algoritmo de selección
que, de la paleta de colores elegida, seleccionaba colores con algún
criterio predeterminado. El médico gerente del proyecto y dueño
de la institución que contrató el desarrollo del sistema nunca
estaba de acuerdo con nuestra escala de colores. Tiempo después, terminado
el sistema y luego de infinidad de pruebas de escala de colores, durante un
workshop de neurología mientras hablábamos en un intervalo,
me contó que era daltónico.
Conclusión, las interfaces de usuario de los sistemas de software suelen
esconder problemas que deben ser detectados a tiempo para darles una solución
temprana y acertada. Problemas que van más allá del look &
feel y la buena presentación. No olvides entonces, llegado el momento,
de preguntarte ... chico, ¿ qué es de tu interfaz de usuario?.
Guillermo Pantaleo,
septiembre de 1995.