Un quiosco puede parecer completo durante una demostración de cinco minutos y aún así fallar en el campo. Los terminales de producción deben sobrevivir a las interrupciones de la red, los errores de la aplicación, los reinicios inesperados, los fallos periféricos y las actualizaciones de rutina sin dejar a los usuarios o a los equipos de soporte varados.
Por lo tanto, el propósito de un piloto de quiosco no es demostrar que se puede iniciar una aplicación a pantalla completa. Es para demostrar que todo el servicio puede ser desplegado, observado y recuperado en condiciones realistas.
1. Define un recorrido de usuario por terminal
Anota la tarea exacta que debe admitir el quiosco, desde el primer toque del usuario hasta el resultado confirmado. Por ejemplo: registrarse, imprimir un billete, consultar un menú, pagar o encontrar una sala.
Para cada paso, especifica:
- La aplicación o URL involucrada;
- Los datos introducidos o mostrados;
- El tiempo de respuesta esperado;
- Lo que el usuario ve cuando una dependencia no está disponible;
- Cómo termina la sesión y vuelve a un estado de inicio limpio.
Si un terminal admite varios recorridos de usuario no relacionados, decide si una sola aplicación gestionada puede cubrirlos de forma segura o si el diseño se parece más a una estación de trabajo que a un quiosco.
2. Construir una matriz de preparación de aplicaciones
FydeOS Kiosk puede iniciar un sitio web designado, aplicación web, aplicación Chrome o, en dispositivos FydeOS v23 compatibles, una aplicación Android privada compatible en un entorno controlado a pantalla completa. La aplicación sigue siendo responsable de su propia disponibilidad, autenticación, contenido y manejo de errores.
Para Android Kiosk, verifica el paquete y la versión APK de producción, los permisos de Android, la configuración administrada, el comportamiento fuera de línea, el acceso periférico y el reinicio automático después de un reinicio o un fallo de la aplicación.
Prueba la versión de producción en estas condiciones:
| Condición | Qué observar |
|---|---|
| Primer arranque | La aplicación prevista comienza sin la presencia de un administrador |
| Crash de la aplicación | El terminal vuelve al servicio a través de la ruta de recuperación acordada |
| Vencimiento de la autenticación | La pantalla no se atasca en un estado de inicio de sesión inutilizable |
| Error del servidor | El usuario recibe un mensaje útil sin acceso al escritorio subyacente |
| Período fuera de línea | El comportamiento en caché o de respaldo coincide con el requisito de servicio |
| Reiniciar | El dispositivo vuelve al estado correcto de la aplicación y la política |
No uses una URL de pruebas ni una cuenta de administrador para dar por validado el flujo de producción.
3. Prueba cada periférico como parte del flujo de trabajo
Crea una matriz que contenga la pantalla exacta, el controlador táctil, el escáner, la impresora, el lector de tarjetas, la cámara, el dispositivo de audio y otros periféricos utilizados en la producción. Registra el firmware, el tipo de conexión y los requisitos del controlador.
Prueba el uso normal y los casos de fallo:
- Desconectar y volver a conectar el periférico;
- Se queda sin papel o consumibles;
- Presentar un código de barras o una tarjeta ilegible;
- Reinicia el dispositivo con un periférico conectado;
- Dejar el quiosco en funcionamiento para la ventana de servicio planificada;
- Confirma que los usuarios no pueden acceder a las funciones no deseadas del dispositivo a través de los diálogos periféricos.
El soporte de hardware varía según el modelo y la construcción de FydeOS, por lo que la compatibilidad debe confirmarse en la combinación de producción real.
4. Completa la evaluación de preparación del sitio
Para cada ubicación, registra el método de montaje, el acceso al servicio, la fuente de alimentación, el enrutamiento del cable, la ventilación, el punto de transferencia de la red, el horario de apertura, el contacto local, la protección física y los requisitos de accesibilidad aplicables.
Comprueba que un técnico puede alcanzar los componentes que se pueden reparar sin exponer a los usuarios a la energía, a los bordes afilados o a los equipos no asegurados. Fotografía la instalación aprobada y registra quién puede abrir, mover o desconectar el terminal.
5. Diseña para redes inestables
Un quiosco confiable tiene un estado de fallo de red explícito. Prueba los fallos de DNS, pérdida de acceso a Internet, portales cautivos, cambios de proxy y conectividad intermitente cuando sea relevante.
Documenta:
- Destinos, puertos y certificados requeridos;
- Propiedad de la conectividad cableada, inalámbrica o móvil;
- Si el servicio puede continuar sin conexión;
- Cuánto tiempo los datos almacenados en caché siguen siendo válidos;
- Cómo se ponen en cola o se abandonan las transacciones;
- Quién recibe una alerta y quién es el dueño del incidente.
Evita ocultar un problema de red detrás de una pantalla de carga interminable.
6. Define la línea de base administrada
Usa FydeOS Management Cloud para organizar los dispositivos de quiosco y aplicar la configuración requerida por la implementación. Dependiendo del plan y la configuración seleccionados, la línea de base puede cubrir la aplicación o URL permitida, el comportamiento de lanzamiento automático, las restricciones del dispositivo, la configuración de energía y los controles de actualización del sistema.
Deja claro quién es responsable de las políticas. Un equipo de contenido puede ser dueño de la aplicación de quiosco, mientras que TI es dueño del sistema operativo, la red y los grupos de dispositivos. Los cambios deben tener un aprobador con nombre y un método de reversión.
La documentación actual de FydeOS Kiosk proporciona orientación de configuración específica del producto.
7. Planifica las actualizaciones como parte de la operación
Una política de actualización necesita más que una hora preferida del día. Decide cómo actuará la organización:
- validará una aplicación y un conjunto de periféricos contra una versión del sistema candidato;
- desplegará a un grupo canario antes que la flota completa;
- evitará actualizar todos los terminales en una ubicación simultáneamente;
- confirmará que la aplicación regresó después de reiniciar;
- pausará el despliegue o iniciará la recuperación cuando fallen las comprobaciones de aceptación.
Incluye los cambios de aplicación, certificado y contenido en el mismo calendario de lanzamiento cuando puedan afectar el recorrido del usuario.
8. Redacta el procedimiento de recuperación remota
Antes de la implementación, el equipo de soporte técnico debería poder responder a las siguientes preguntas:
- ¿Cómo sabemos que un quiosco está fuera de línea o no es saludable?
- ¿Podemos identificar su ubicación, modelo, grupo de políticas y propietario actual?
- ¿Qué información de diagnóstico se puede recopilar de forma remota?
- ¿Cuándo es apropiado un reinicio?
- ¿Cuándo se puede usar el acceso remoto y cómo se autoriza?
- ¿Qué puede hacer un empleado local de forma segura?
- ¿Cuándo debe visitar un técnico el sitio?
- ¿Cómo se reemplaza e inscribe un dispositivo defectuoso?
Las herramientas remotas reducen los viajes innecesarios solo cuando el equipo tiene una ruta de decisión clara.
9. Realiza pruebas de campo, no solo de laboratorio
Coloca unos pocos quioscos en ubicaciones representativas. Prueba la iluminación, el ruido, la temperatura, el acceso físico, la red y los periféricos. Observa cómo se recuperan los usuarios de los errores y si entienden las instrucciones sin ayuda.
Mide:
- Tasa de finalización exitosa del viaje previsto;
- Tiempo desde el encendido hasta el estado listo para la aplicación;
- Tiempo fuera de línea no planificado;
- Tiempo desde la detección de fallas hasta el servicio restaurado;
- Incidentes que requieren una visita al sitio;
- Versiones de las aplicaciones, los periféricos y las políticas en cada dispositivo.
Estas mediciones forman una línea de base defendible para la decisión de implementación.
Lista de verificación previa al despliegue
- El viaje completo del usuario y los estados de fallo están documentados.
- Se prueban la aplicación de producción, las cuentas y los puntos finales.
- Para Android Kiosk, se han verificado la versión APK aprobada, los permisos, la configuración administrada, los periféricos y la recuperación de reinicio.
- Todos los periféricos de producción han pasado las pruebas normales y de fallo.
- El montaje, la energía, el cableado, la ventilación, el acceso al servicio y la accesibilidad han sido aprobados para cada sitio.
- Se conocen los destinos de la red, los certificados y el comportamiento fuera de línea.
- Se definen las políticas de quiosco, la propiedad y la aprobación de cambios.
- Las actualizaciones utilizan dispositivos canarios y una condición de parada escrita.
- Se documentan el diagnóstico remoto, la acción local y los umbrales de visita al sitio.
- Un piloto de campo representativo ha completado los ejercicios de recuperación.
Ejecutar una prueba de aceptación del sitio
Para obtener un proceso de soporte más amplio, consulta la guía de gestión remota de dispositivos multisitio.
Lleva la aplicación de destino, el hardware, la lista de periféricos y el diseño de red a una prueba FydeOS Kiosk. Un pequeño piloto de campo es el lugar más útil para confirmar la compatibilidad y la recuperación antes de ordenar o convertir una flota más amplia.