Cuando se trata de la creación de aplicaciones, a menudo asumimos que nuestros usuarios son muy parecidos a nosotros. Nosotros los imaginamos con los últimos dispositivos, el software más reciente, y las conexiones más rápidas. Para esto debemos tener una variedad de dispositivos(o al menos emuladores) y navegadores antiguos para las pruebas, pasamos la mayoría de nuestro tiempo de construcción desde la comodidad de nuestros dispositivos de escritorio modernos, siempre en línea.
Para nosotros, un error de conexión o servicio lento es un problema temporal en la red de telefonía o wifi el cual es rutinario. Desde esta perspectiva, se tiene la tentación de pensar en la conectividad, móvil o de otro modo, como algo que se resolverá por sí mismo con el tiempo, a medida que una mayor cobertura de la red y un servicio más rápido. Y eso funciona, siempre y cuando nuestros usuarios a mantenerse por encima del suelo en grandes y muy modernas ciudades bien desarrolladas, pero este no es el caso siempre.
Pero, ¿qué sucede una vez que suben en el metropolitano o al tren eléctrico, a bordo de un avión, en un viaje por tierra, o ir a visitar el campo? O cuando se paran en la esquina con menos cobertura de un edificio o simplemente se encuentran como parte de una gran multitud? Nuestras aplicaciones con UX cuidadosamente construidas se convierten en fuentes de frustración, porque confiamos tan
plenamente en ese enlace que irá supuestamente de nuevo a nuestros servidores.
Esta dependencia hace caso omiso de una verdad fundamental: Desconectado es simplemente un hecho de la vida. Si usted usa un móvil, usted estará desconectado en algún momento. Sin embargo. Hay maneras de tratar con este hecho.
Como encontrar el balance de conexión?
Las aplicaciones web solían ser completamente dependiente del servidor que hace todo el trabajo , y el cliente sólo muestra el resultado. Cualquier interrupción en la conexión era un problema importante : si usted se encontraba desconectado, no podía usar la aplicación.
Ese problema se resuelve, en parte, por los clientes más ricos, donde más de la lógica de la aplicación se ejecuta en el navegador como google docs (actualmente google drive), por ejemplo. Pero para una experiencia adecuada de offline first, también se desea almacenar los datos en la parte front, y si se desea que se sincronice con el almacén de datos del servidor. Felizmente, las bases de datos en el navegador están madurando, y hay un número cada vez mayor de soluciones para esto como derby.js, Lawnchair, hoodie, firebase, remotestorage.io, sencha touch entre otros- los cuales resuelven los aspectos técnicos
cada vez de manera más fácil.
Pero tenemos problemas más grandes y mucho más raros: el diseño de las aplicaciones y sus interfaces de conectividad intermitente conducen a una gran cantidad de nuevos escenarios, problemas y errores que debemos controlar dependiendo del negocio.
La experiencia de uso de un sitio web o aplicación sin conexión debe ser mucho mejor, menos frustrante y de más potencia. Necesitamos el equivalente UX de diseño de páginas web sensibles : un fuerte catálogo de guías y patrones para un mundo multidispositivo desconectado. Pues actualmente el usuario final no solo se conecta desde su móvil sino también desde la PC o tablet.
Entendiendo el ciclo de vida de la conectividad
La mayoría de las aplicaciones web tienen dos puntos de conexión relacionados de fracaso los cuales son:
el envío desde el cliente y la recepción del cliente (llega a ser equivalente a demanda de servidor).
Dependiendo de lo que hace su aplicación, es posible que el usuario final desee 3 cosas:
1. Comunicar u ocultar explícitamente el estado de conectividad y sus cambios (por ejemplo, en un cliente de chat sería informar a los usuarios que los nuevos mensajes escritos no se envían inmediatamente).
2. Permitir la creación del lado del cliente y funciones de edición, incluso cuando la aplicación se encuentre fuera de línea, y tranquilizar a los usuarios que sus datos están seguros y eventualmente se enviarán hacia al servidor (pensar en una aplicación para compartir fotos que le permite tomar y publicar fotos en cualquier circunstancia).
3. Deshabilitar, modificar, o incluso ocultar características que no pueden trabajar fuera de línea, en lugar de dejar que la gente las vea y no las pueda usar (imagine un botón de "enviar" que se transforme en un botón "enviar al recuperar la conexión").
A fin de ayudarnos entre sí y también a futuras generaciones de diseñadores, desarrolladores y expertos en interfaces de usuario (UX), te invitamos a unirte a la discusión en offlinefirst.org. La meta futura es la de crear un manual en línea que incluye los patrones UX y anti-patrones, las opciones de tecnología, y la investigación sobre el usuario. Hasta la próxima!
