Un equipo de campo puede perder señal mientras registra una visita. Una aplicación web preparada para trabajar sin conexión podría permitirle consultar información previamente guardada o registrar datos para enviarlos más tarde. Pero abrir una web en el celular no garantiza que todas sus funciones funcionen sin internet: el comportamiento debe diseñarse y probarse para cada tarea.

Define la tarea que debe continuar

Haz una lista de lo que la persona necesita hacer sin red. Consultar una dirección descargada no tiene el mismo riesgo que aprobar un pago o modificar existencias compartidas. Prioriza operaciones que puedan completarse con información disponible y deja claro cuáles requieren una comprobación en línea.

Una pantalla accesible sin conexión puede mostrar datos antiguos. Indica cuándo se actualizó la información y evita que el usuario interprete una copia local como disponibilidad confirmada en tiempo real. La fecha de descarga y el estado de sincronización deben ser comprensibles.

Prepara datos y recursos antes de salir

Algunas aplicaciones web pueden guardar recursos y datos en el dispositivo para usarlos después. La guía de MDN sobre operación offline explica cómo un service worker puede gestionar respuestas almacenadas. Esa es una técnica posible, no una garantía de compatibilidad, espacio o comportamiento idéntico en todos los dispositivos.

Decide qué información puede guardarse localmente, durante cuánto tiempo y quién debe acceder. Un dispositivo perdido o compartido cambia el riesgo. Acuerda cómo se protege la información y qué ocurre si se cierra la sesión, se borra el almacenamiento o se cambia de equipo.

Diseña la sincronización y los conflictos

Imagina una persona que registra una visita sin señal y otra que modifica el mismo expediente desde la oficina. Al volver la conexión, ¿se conserva el cambio más reciente, se combinan campos o una persona revisa la diferencia? Es un caso hipotético; la respuesta debe acordarse por tipo de dato y por impacto de un error.

El usuario necesita saber si el registro está guardado solo en el dispositivo, pendiente de envío, enviado o rechazado. Un reintento no debe crear una operación duplicada. Para transacciones sensibles puede ser necesario esperar la confirmación del sistema central antes de comunicar el resultado.

Comprueba la experiencia con el equipo

  • Prepara el dispositivo conectado y verifica que los datos requeridos estén disponibles.
  • Desconecta la red y completa una tarea ordinaria y una excepción.
  • Cierra o reinicia la aplicación según los escenarios acordados.
  • Reconecta y comprueba el resultado en el sistema central.
  • Prueba conflictos, permisos vencidos, falta de espacio y pérdida del dispositivo.

Si la operación depende siempre de un dato que debe consultarse en tiempo real, quizá sea más seguro diseñar una alternativa para la interrupción que prometer funcionamiento completo sin conexión.

Acuerda qué no estará disponible

La aplicación puede permitir una captura local sin poder consultar cambios recientes de otras personas. También puede necesitar conexión para iniciar sesión, descargar una lista o confirmar una operación. Publica esas condiciones dentro del flujo, antes de que el equipo dependa de ellas en campo.

Durante el piloto, registra qué dispositivos, versiones de navegador y condiciones de red se probaron. Si un dispositivo se comparte, acuerda cómo cambiar de usuario sin mostrar datos guardados de otra persona. Un ensayo con el equipo revela necesidades que una prueba con la red de la oficina puede pasar por alto.

Fuentes consultadas

Diseñemos para tu contexto de trabajo

Cuéntanos qué tareas deben continuar cuando falla la conexión y revisemos sus límites.

Conversar sobre mi aplicación