viernes, 11 de noviembre de 2011

10 elementos clave para la usabilidad en aplicaciones web GIS

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.

Si quieres ver mas a detalle visita el siguiente link



De aitorcaleroesri
Visto en:BlogESRI

No hay comentarios.: