¿Cómo hacer geo apps sin picar ni una línea de código?

Hace tiempo que el DIY (Do It Yourself) llegó a nuestras vidas y decidimos reparar nuestros muebles, hacer nuestra propia ropa… Sin embargo, nadie hacía pensar que el DIY llegaría a todos los ámbitos de nuestra existencia, incluido el desarrollo de Apps.

La filosofía de Esri siempre ha sido hacer llegar nuestra tecnología a todos los usuarios y simplificar la forma en la que trabajamos sin necesidad de reducir su potencial. Por este motivo, desde hace años venimos trabajando para que el desarrollo de apps sea algo que podamos hacer cualquiera de nosotros y eso significa: en 10 minutos y sin necesidad de picar código.

 

p10p3-lg

 

Haz tus propias Apps

En Esri estamos poniendo constantemente decenas de recursos a tu disposición. Uno de ellos es el Esri Apps Builder Site, una página en la que te enseñamos cómo hacer tus propias apps.

En este post te vamos presentar algunas:

  • Story Maps: los Story Maps son nuestras apps más conocidas. Los usuarios pueden elegir entre 9 plantillas y configurarlas en función de sus necesidades. Esto permite desde hacer apps para crowdsourcing, hasta apps de monitorización de redes sociales en tiempo real. Los Story Maps son unas herramientas con un poder de comunicación muy potente, ya que en ellas puedes incluir texto y cualquier recurso audiovisual (imágenes, vídeos, audios, gif…).
  • Apps configurables: te permitirán convertir un simple mapa en una app de forma rápida y sencilla. No necesita código, tan solo necesitarás elegir una de ellas en función de las características de tu proyecto, su funcionalidad y la estética que quieras aplicarle.
  • Web AppBuilder for ArcGIS: con esta aplicación podrás crear apps para agregación de datos, notificación de resultados, etc. De forma fácil e intuitiva se puede seleccionar la temática, el estilo y el diseño, así como incorporar los widgets necesarios. Con Web AppBuilder for ArcGIS tendremos una app completa y con multitud de funcionalidades, una vez más, sin incluir ni una sola línea de código.
  • AppStudio for ArcGIS: esta aplicación es una de nuestras favoritas ya que permite que cualquiera de nosotros convirtamos nuestro mapa en una una app nativa para iOs, Mac OS X, Android, Windows y Linux. Todo esto en 5 minutos y, créenos, sin necesidad de desarrollo.

Dicho esto, solo falta que te pongas a desarrollar tu propia app, que por cierto, podrás consumir automáticamente en cualquier momento, lugar y desde cualquier dispositivo. Y recuerda: en Esri Apps Builder Site encontrarás todas las herramientas.

 

 

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.

A %d blogueros les gusta esto: