La usabilidad en sistemas integrados es muy diferente a la usabilidad de sistemas computacionales en los cuales el objetivo principal, es el aspecto gráfico del sistema, para que un sistema integrado tenga una buena usabilidad interfieren cosas como la colocación de los botones, como son los botones y los interruptores, entre algunas otras cuestiones.
En esta entrada hablaré acerca de los dos enfoques fundamentales para que los sistemas integrados tenga una facilidad de uso y que por lo tanto tengan usabilidad para los clientes finales, estos enfoques son la facilidad de uso mediante la evalucación y la otra es la facilidad de uso mediante los principios.
La facilidad de uso por la evaluación consiste en encontrar puntos fuertes y débiles para hacer mejoras al ambiente no grafico, esto involucra el utilizarlo de manera constante para poder saber si este tiene una facilidad de uso, hasta que alguien se de cuenta de que el producto es difícil de usar, por lo que nadie se dará cuenta de que es difícil de usar hasta que el producto se ha construido, la parte fácil de la usabilidad es ver el diseño actual y analizarlo, la parte difícil es decidir lo que se necesita mejorar ya que en algunos casos lo pueden empeorar, por lo que es imporante utilizarlo y valoralo de manera física.
La facilidad de uso por los principios es la que trata de decir por medio de consideraciones anteriores, que características de usabilidad son deseables para que la interfaz que estas utilizando sea usable y que tipo de gente va a utilizar la interfaz que estas realizando, por lo que al utilizar estos principios, permite que cuando tengas tu prototipo fisico puedas criticarlo y ser discutido con más fuerza ya que puedes tener documentado el por qué se considera usable el producto para luego analizarlo de manera más profunda.
Ahora les hablaré de algunos de los principios más importantes de debemos de considerar al momento de realizar un análisis de un sistema integrado con usabilidad de interfaces de usuario los cuales no son gráficos, si no, físicos.
Robustez.
Muchas veces este concepto se piensa que se utiliza para saber si el sistema que estamos utilizando va a estar fuertemente ligado a una propiedad mecánica, esto es como nuestro producto puede ser utilizado en caso rudo o cuando tengamos algún descuido, pero esto no es necesariamente lo que tiene que ver con este principio, es más bien que la interfaz sea tolerante a las entradas incorrectas, o que estas sean imposibles de hacer, por lo que una interfaz robusta, no solo protege al dispositivo de daños que pudieran ser accidentales, si no que también lo protege de una entrada incorrecta y que protege al usuario de como el dispositivo pudiera actuar.
Un ejemplo es por ejemplo en el manual de la computadora Sinclair ZX Spectrum, en 1982, especificaban muy claramente que
Nada de lo que se escriba en el teclado puede dañar el equipo entonces esto demostraba una percepción de los diseñadores que a las personas que compraban sus equipos, pudieron reducir la ansiedad de los usuarios dandoles seguridad de que su computadora no se iba a destruir si ellos realizaban algo equivocadamente, no importa cuantos errores cometieran.
Podemos hablar de robustez cuando por ejemplo, se nos solicita la confirmación de realizar una acción, es la manera básica de añadir robustez al sistema integrado, del mismo modo, los mensajes de error o un sonido para indicar que la acción que esta realizando está mal, puede ser una respuesta muy buena para que el usuario final pueda saber que lo está haciendo de una manera no adecuada.
Algo muy importante y que personalmente yo lo he visto en ciertos sistemas, no nada más integrados, si no también gráficos, es el que muchas veces las personas que diseñan los sistemas formulan bien los mensajes de error o advertencias que se muestran, esto es por ejemplo si en el microondas tu picas a un boton que no esté disponible y te diga en una pantalla led "Acción ilegal" nosotros vamos a pensar que somos unos criminales como lo dice Niall Murphy en su artículo [
aquí], nosotros pudieramos hacer que proporcione mensajes mas apropiados como "No disponible" o similar, haciendo más robusto el sistema.
A veces, es necesario proporcionar conjuntos de acciones que permitan que cualquier acción pueda ser regresada a un punto anterior, por lo que si nosotros hacemos un sistema que mueve un brazo robotizado a la izquierda, pueda hacer con la misma facilidad, moverse hacia la derecha y que pueda regresar al modo izquierda de manera como movió a la derecha, solamente como ejemplo.
Algunas veces, un sistema integrado, no puede revertir algunos comandos ya que es simplemente imposible, sobretodo cuando es una acción física que recibió el dispositivo y no se pude deshacer, por lo que en estos casos es importante que requiera alguna confirmación haciendo un equilibro entre la facilidad de uso y la intención de deshacer la acción.
Consistencia
Este principio lo que nos dice es que al utilizar una consistencia global del diseño para que pueda ser más fácil aprender las reglas y que el usuario pueda utilizar toda la interfaz sin ningún problema, por lo que la consistencia en la interfaz será reflejado en los programas y por lo tanto, nosotros como programadores debemos de realizar un código que pueda detectar este tipo de inconsistencias, por lo que le permite al usuario desarrollar normas que otros productos han utilizado como normas generales acerca de cómo funciona una interfaz, entonces es importante que cuando reciba el producto sea rapido de usar y no que tenga que aprender desde cero para saber a que significa cada uso, esto lo pudieramos dejar para sistemas más avanzados en donde si es importante saber este tipo de uso.
Affordance
De este principio no encontré una traducción directa aunque lo veo un poco como facilitante de hacer las cosas, por lo que esta es una propiedad que nos dice que al ver un producto es obvia su función, desde el momento de su aparición, esto es por ejemplo si te dan unas tijeras, te vas a dar cuenta que cada uno de los extremos tiene unas cosas redondas que se ajustan a tus manos y que del otro lado están afilados, por lo que tu razonablemente sabrás para que van a servir y como usarlo.
Podemos decir que esto es algunas veces facil porque el usuario puede ver por ejemplo, todos los controles en una tableta o el teclado numérico en un celular, pero debemos de acondicionar los productos a que los botones sean visibles y muestren información relevante, también es importante el etiquetado de cada boton proporcione una buena figura para saber que es lo que hace el boton por ejemplo, muchas veces un boton de stop, tiene un cuadro pero ese mismo botón sirve para dar play a algo, por lo que es importante poner las dos simbologias y el usuario pueda entender porque están los dos.
Un fallo que algunas veces se tiene en los sistemas físicos es colocar los botones en un patrón regular para que la apariencia del dispositivo sea simétrica, esto tiene sentido si por ejemplo cada uno de los botones tienen funciones similares, pero si se tienen funciones separadas, es preferible agruparlos según lo que se va a realizar, también es importante tener botones más grandes para las funciones más utilizadas y las funciones que raramente se van a utilizar no tan grandes, también por ejemplo si se tiene un teclado con números, es preferible acomodarlos de un orden de izquierda a derecha, ya que esta la forma de leer y la forma en que se pueden representar en un display.
Compatibilidad
Consideremos que existen 3 tipos de compatibilidad en una interfaz no gráfica.
- Compatibilidad de lo que el usuario espera y lo que obtiene
- Compatibilidad entre los diferentes productos del mismo tipo
- Compatibilidad entre el dispositivos y con los que tiene que "cooperar".
La compatibilidad entre los productos no es tan facil como parece, los productos a través de la historia en el mercado, han hecho que las personas tengan ciertas prácticas, por lo que algunas veces, no todas, es importante seguir ese camino, es por eso que existen organismos de normalización que han ido haciendo intentos para estandarizar, por ejemplo los sonidos y las luces de alarma de un hospital, el ISO 9995 ha establecido un estándar para la disposición de las letras en los botones de un teléfono o un teclado numérico distinto, pero a pesar de esto los teléfonos en todo el mundo van variando la colocación de su teclado.
También los botones principales junto con los símbolos de una videograbadora, han sido normalizados, aunque existen inclusive aparatos de la misma empresa o compañía que no utilizan o separan estos botones.
Existen otras normas, los cuales hacen que el trabajo de una persona en el diseño y realización de aparatos sea más difícil, por ejemplo el estándar ISO 86901 es un estándar para los formatos de la fecha y hora, con un formato de año - mes - dia, sin embargo en Europa, se utiliza el formato dia - mes - año, como aquí en nuestro país y en paises como Estados Unidos utilizan el formato mes - dia - año. Por lo que la norma ISO es un formato más lógico ya que comienza con la unidad más importante y luego se traslada a las unidades cada vez más pequeñas, a medida que los vamos leyendo de izquierda a derecha.
Otra de las consideraciones de compatibilidad es que debe de ser compatible con el medio ambiente en donde va a trabajar un dispositivo, por ejemplo en un entorno ruidoso, suena una alarma que no se escucha o se escucha muy poco, pues no será apropiado, pero por otro lado una calculadora si la queremos utilizar en una biblioteca, no quiere decir que tenemos que tener una calcu que suene cada que tengamos que picar a un botón, pero es algunas veces difícil predecir este tipo de situaciones adivinar.
Por lo tanto podemos concluir que estos principios son importantes para la realización de sistemas que tengan usabilidad apropiada para el usuario final y que esto no es una cuestión que debemos de tomar a la ligera ya que, si en algún momento este producto deseamos venderlo, la cuestión de la usabilidad viene siendo algunas veces la clave del éxito de un producto y por lo tanto tendremos más venta y satisfacción al usuario, por lo que es relevante tomarlo en cuenta.
Bibliografía.
Usability for Embedded Sytems de Panelsoft
Usability for Non-Graphical user Interfaces por Niall Murphy
