La conexión se perdió después de escribir una nota. El texto sigue en la pantalla, pero la app no explica si guardó un borrador, registró la información en el dispositivo o la envió a quien asumirá el cuidado. Repetir el envío sin entender el estado puede añadir otra duda.
Este artículo propone preguntas para una prueba con datos ficticios. No confirma que un producto funcione sin internet ni presenta a NiBambini como una herramienta sin conexión. Cuando haya un relevo real de cuidado, el registro debe acompañarse del canal de organización que los adultos ya acordaron.
El texto en pantalla no confirma todos los pasos
Ver el contenido permite saber que la interfaz lo está mostrando. Para concluir dónde se guardó y quién puede acceder, hace falta otra evidencia del funcionamiento del servicio. Una pantalla abierta, por sí sola, no responde esas preguntas.
La documentación de Mozilla sobre service workers explica cómo las aplicaciones web pueden usar recursos almacenados para funcionar sin conexión. Esa posibilidad técnica no demuestra que cualquier sitio guarde notas o comparta actualizaciones sin conexión. Cada producto necesita implementar y explicar su comportamiento.
En el ejemplo ficticio, Clara escribe "bolso de prueba en la repisa verde" en un entorno de demostración. Se pierde la conexión a internet y aparece "pendiente". No interpreta esa palabra como confirmación de que Tiago ya recibió la nota. Primero busca la explicación del estado.
Diferenciar borrador, guardado local y uso compartido
Estas son preguntas posibles, no estados confirmados de una app:
- ¿El texto existe solo en el campo que estoy completando?
- ¿Hay una copia guardada en este dispositivo?
- ¿La acción está pendiente de envío?
- ¿El servicio confirmó la recepción?
- ¿La otra persona puede consultar la actualización?
Busquen etiquetas que respondan a cada etapa pertinente. "Todo listo" puede ser insuficiente si el grupo necesita saber si otra persona ya puede leer. "Guardado en este dispositivo; envío pendiente" sería una descripción más específica, pero solo debe aparecer en un producto que realmente haga esos pasos.
El W3C trata los mensajes sobre resultados, espera y progreso como información de estado que debe estar disponible para las tecnologías de asistencia. La referencia orienta la accesibilidad de las interfaces, sin garantizar que el procesamiento anunciado haya ocurrido correctamente.
Verificar sin repetir la acción a ciegas
En el ensayo, lean la documentación sobre la conexión, las acciones pendientes y la reanudación. Creen una nota ficticia identificable y observen qué anuncia la pantalla. Después, al restablecer la conexión, revisen el estado y la presencia de un solo registro, usando el flujo recomendado por el proveedor.
No cierren una pantalla con datos reales ni borren los datos del navegador para "ver si guarda". Esas acciones pueden tener consecuencias que el artículo no puede prever. Una prueba debe ocurrir en un entorno autorizado y descartable, sin depender de una información de cuidado real.
Clara ve que la acción sigue pendiente después de que vuelve la conexión. Registra la duda y deja la prueba sin una conclusión. No convierte la espera en un éxito. Cuando el problema sea una nota duplicada, Ambas personas anotaron lo mismo: cómo manejar un registro duplicado ayuda a separar los registros antes de elegir una corrección.
Si la interfaz indica un error, busquen una descripción con palabras. El W3C indica que se debe identificar el campo con error y describir el problema en texto cuando se detecta automáticamente. Un color aislado no debe ser la única explicación que recibe el grupo.
Ficha de observación de la conexión
Usen estos campos en papel o en una futura ficha local:
- Tarea ficticia que intentamos hacer
- Conexión presente o ausente en esa prueba
- Mensaje exacto mostrado por la interfaz
- Qué dice la documentación sobre ese mensaje
- Qué apareció después de reanudar la conexión
- Si se confirmó la consulta en el otro dispositivo
- Duda que sigue abierta
No incluyan datos infantiles reales en la ficha de abajo. Cargar ejemplo ficticio muestra una prueba todavía no realizada; cambien los campos solo para describir un escenario inventado, sin suponer guardado ni sincronización. La vista previa permanece en la memoria del navegador, sin envío ni guardado automático. Limpiar ejercicio borra los campos.
Usar un canal alternativo acordado previamente
Si una información de organización necesita llegar antes del próximo período, los adultos deben saber qué canal usar cuando el registro no confirma el envío. Eviten improvisar varios lugares sin indicar dónde está el acuerdo vigente.
Si alguien no anotó en el momento, Olvidé anotarlo en el momento: cómo registrar sin inventar precisión propone registrar lo que sabe sin inventar precisión. Una demostración también tiene límites, que se explican en Qué puede mostrar una demo de cuidado compartido antes de una app real.
Esta guía original no valida la confiabilidad, no evita todos los errores ni reemplaza la documentación técnica. La verificación puede seguir inconclusa. En ese caso, mantengan explícito lo que no se confirmó y no dependan de la pantalla para una decisión de salud o de seguridad infantil.
Conoce la propuesta de NiBambini
Explora la demostración con datos ficticios. El registro real y el cuidado compartido con cuentas aún están en desarrollo.
