10 elementos clave para la usabilidad en aplicaciones web GIS

Si nuestras aplicaciones, y con ellas los mapas que las componen no son usables, nuestros usuarios no las usarán. Suena a perogrullo, pero es así. Lo que a nosotros nos puede paracer intuitivo, fácil, que está a la vista, puede costar un enorme esfuerzo para un usuario distinto.

A partir de ahora, y más con la aparición de los smartphones y tabletas, los usuarios de aplicaciones web GIS van a demandar cada vez más USABILIDAD. La información tendrá que mostrar lo que quieren, cuando sea necesario y de una forma casi automática. Por ejemplo, en un iPad o iPhone, solo hace falta una pulsación de nuestro dedo para abrir una app. ¿Quién está dispuesto hoy en día a rellenar un formulario que tenga campos separados para dirección, número de portal, distrito, etc…? Se puede y se debe, poder poner la dirección en una sola línea, y que sea nuestro código el que se encargue del trabajo de averigüar cúal es la dirección correcta.

Hace unos años, hacer un prototipo de una aplicación web gis, podría llevar del orden de varios días. No era fácil, ni rápido. Afortunamente hoy la tecnología, y las nuevas Web APIs y frameworks de desarrollo, permiten preparar un prototipo de aplicación en muy poco tiempo. Esto nos da la posibilidad de contar con la oponión del usuario final desde un primer momento. Sin embargo, esto rara vez se hace, o si se hace no sabemos exáctamente qué preguntas o qué información sacar de una posible sesión de usabilidad.

En este artículo se pretenden ofrecer algunas claves básicas para poder mejorar la usabilidad de nuestras aplicaciones web GIS. Estas claves se basan en las 10 claves de usabilidad de Jakob Nielsen pero adaptadas al GIS:

1. Visibilidad del estado del sistema. Nuestra aplicación debe informar en todo momento al usuario, qué está haciendo. Si hemos lanzado un geoproceso, además del típico reloj de arena, no estaría de más ir enviando mensajes de cómo va el estado del geoproceso o un porcentaje de ejecución. Con las tecnologías ajax no es complicado (por ejemplo usando DWR).
2. Que la aplicación y el usuario hablen el mismo lenguaje. «La feature #21 incumple las reglas de topología definidas en el dataset«. ¿Quién entiende un mensaje así fuera del mundo GIS? Un mensaje como «no ha sido posible insertar el elemento» sería mucho más entendible. Eso sí, tampoco está de más, ofrecer la posibilidad de ampliar detalles técnicos (ver punto 9 más abajo).
   
3. Usuarios, Control y Libertad. Ups, no quería hacer esto… ¿cómo vuelvo atrás?. Siempre es importante ofrecer puertas de escape ante acciones involuntarias de los usuarios. Si hay un botón de borrar y el usuario lo pulsa accidentalmente, debería ser posible deshacer la acción.
4. Consistencia y estándares. Si todos usamos la lupa o el símbolo + para agrandar un mapa, no es buena idea inventar un nuevo icono para esta acción (estándares). Además, si ya se ha usado un tipo de icono para representar algo, es importante volver a usarlo siempre para esa misma acción (consistencia).
5. Prevención de errores. Si dejar un polígono abierto, ya se sabe que va a provocar un error de topología en la geodatabase, hay que impedir que antes que se ejecute la transacción el usuario pueda grabar ese polígono. Todo lo que se pueda validar en cliente, debe hacerse. Si múltiples opciones son potencialmente conflictivas (crear y borrar) han de activarse/desactivarse de forma automática.
6. Reconocimiento en vez de tener que recordar. ¿Cómo se cargaba una capa? Las acciones más habituales deben ser fácilmente reconocibles, sin que el usuario deba recordar en qué oscura opción del menú oculto se encontraba.
7. Flexibilidad y eficiencia de uso. Hacer las cosas sencillas a los nuevos y dar atajos a los usuarios más avanzados. Es posible que las primeras veces que nuestro usuario quiere crear un polígono pase por ese maravilloso asistente que hemos creado, pero seguramente, tras 5 veces ya se sepa todos los pasos de memoria, y le resulte tedioso. Ha pasado a ser un usuario avanzado. ¿Por qué no ofrecerle un atajo de teclado para facilitarle la tarea? En javascript no es tan complicado como pueda parecer.
   
8. Estética y diseño minimalista. O la revolución del iPod. Pocos botones que dan acceso a la funcionalidad necesaria. Por desgracia, en el mundo del GIS es habitual ver aplicaciones muy recargadas de iconos, menús y opciones. En vez de eso, es mejor limitar al máximo el número de opciones en función de la operativa del usuario. Aunque un usuario editor pueda crear elementos, sería aconsejable no mostrar la barra completa de edición hasta que no haya decidido crear un nuevo elemento.
9. Ayudar a los usuarios con los errores, identificándolos y ayudándolos. «Contacte con el Administrador del Sistema«. Quizá no haya peor mensaje de error, porque nos deja tal y como estábamos. Siempre que sea posible, hemos de mostrar mensajes de error que ayuden a identificar el problema o que puedan servir de referencia. Si no se ha podido insertar un elemento porque ha habido una desconexión momentánea en la geodatabase, sería mejor informar de esto al usuario, y si no queda más remedio que redireccionarle al administrador, proporcionarle pre-formateada toda la información del error para que pueda solucionar el problema lo antes posible.
10. Ayuda y documentación. Si el diseño es bueno, la documentación puede parecer secundaria. Sin embargo, por mucho que nos esforcemos con el diseño siempre habrá situaciones que no habremos controlado, o que no habremos resuelto bien con el diseño. En este caso la documentación debe estar disponible ahí mismo, para mostrar la información relevante y exclusiva al problema en cuestión. Y no olvides que un vídeo o locución puede aclarar más y ahorrar mucho tiempo.

Aplicar estos 10 puntos nunca nos va a poder garantizar al 100% que nuestra aplicación sea perfectamente usable, y durante su diseño y desarrollo habrá que ir realizando ajustes para que los usuarios se encuentren cómodos con ella. Sin embargo, tener estos puntos bien presentes nos puede ayudar a planificar mejor el diseño de nuestras aplicaciones.

Si queréis profundizar más en el tema, aquí os dejo un completo informe sobre usabailidad.

Para un próximo artículo dejamos qué tipo de preguntas/tests de usubilidad podemos utilizar con nuestros potenciales usuarios finales.