Um quiosque pode parecer completo durante uma demonstração de cinco minutos e ainda falhar no campo. Os terminais de produção devem sobreviver a interrupções de rede, erros de aplicativos, reinicializações inesperadas, falhas periféricas e atualizações de rotina sem deixar os usuários ou equipes de suporte presos.
O objetivo de um piloto de quiosque é, portanto, não provar que um aplicativo em tela cheia pode ser lançado. É para provar que todo o serviço pode ser implantado, observado e recuperado em condições realistas.
1. Defina uma jornada de usuário por terminal
Anote a tarefa exata que o quiosque deve suportar, desde o primeiro toque do usuário até um resultado confirmado. Exemplos incluem check-in, impressão de um ingresso, visualização de um menu, fazer um pagamento ou encontrar um quarto.
Para cada etapa, especifique:
- O aplicativo ou URL envolvido;
- Os dados inseridos ou exibidos;
- O tempo de resposta esperado;
- O que o usuário vê quando uma dependência não está disponível;
- Como a sessão termina e retorna a um estado inicial limpo.
Se um terminal suportar várias jornadas de uso não relacionadas, decida se um aplicativo gerenciado pode contê-las com segurança ou se o projeto está se tornando uma estação de trabalho de uso geral em vez de um quiosque.
2. Construa uma matriz de prontidão de aplicativos
O FydeOS Kiosk pode iniciar um site designado, aplicativo da web, aplicativo Chrome ou, em dispositivos FydeOS v23 compatíveis, um aplicativo Android privado compatível em um ambiente controlado de tela cheia. O aplicativo permanece responsável por sua própria disponibilidade, autenticação, conteúdo e tratamento de erros.
Para o Android Kiosk, verifique o pacote e a versão do APK de produção, as permissões do Android, a configuração gerenciada, o comportamento offline, o acesso periférico e a reinicialização automática após uma reinicialização ou falha do aplicativo.
Teste a construção de produção contra:
| Condição | O que observar |
|---|---|
| Primeira inicialização | O aplicativo pretendido começa sem a presença de um administrador |
| Falha do aplicativo | O terminal retorna ao serviço através do caminho de recuperação acordado |
| Expiração da autenticação | A tela não fica presa em um estado de login inutilizável |
| Erro do servidor | O usuário recebe uma mensagem útil sem acesso à área de trabalho subjacente |
| Período offline | O comportamento armazenado em cache ou de fallback corresponde ao requisito de serviço |
| Reiniciar | O dispositivo retorna ao estado correto do aplicativo e da política |
Não use um URL de teste ou uma conta de administrador como evidência de que a jornada de produção está pronta.
3. Teste todos os periféricos como parte do fluxo de trabalho
Crie uma matriz contendo a tela exata, controlador de toque, scanner, impressora, leitor de cartão, câmera, dispositivo de áudio e outros periféricos usados na produção. Registre firmware, tipo de conexão e requisitos de driver.
Teste casos normais de uso e falha:
- Desconecte e reconecte o periférico;
- Ficar sem papel ou consumíveis;
- Apresentar um código de barras ou cartão ilegível;
- Reinicie o dispositivo enquanto um periférico estiver conectado;
- Deixar o quiosque operando para a janela de serviço planejada;
- Confirme que os usuários não podem alcançar funções não intencionais do dispositivo por meio de caixas de diálogo periféricas.
O suporte de hardware varia de acordo com o modelo e a compilação FydeOS, portanto, a compatibilidade deve ser confirmada na combinação de produção real.
4. Complete uma pesquisa de prontidão do local
Para cada local, registre o método de montagem, acesso ao serviço, fonte de energia, roteamento de cabos, ventilação, ponto de transferência de rede, horário de funcionamento, contato local, proteção física e requisitos de acessibilidade aplicáveis.
Confirme se um técnico pode acessar componentes que podem ser reparados sem expor os usuários a energia, bordas afiadas ou equipamentos inseguros. Fotografe a instalação aprovada e registre quem pode abrir, mover ou desconectar o terminal.
5. Planeje para redes instáveis
Um quiosque confiável tem um estado explícito de falha de rede. Teste a falha do DNS, perda de acesso à Internet, portais cativos, alterações de proxy e conectividade intermitente, quando relevante.
Documente:
- Destinos, portas e certificados necessários;
- Propriedade de conectividade com fio, sem fio ou móvel;
- Se o serviço pode continuar offline;
- Por quanto tempo os dados armazenados em cache permanecem válidos;
- Como as transações são enfileiradas ou abandonadas;
- Quem recebe um alerta e quem é o dono do incidente.
Evite esconder um problema de rede atrás de uma tela de carregamento interminável.
6. Defina a linha de base gerenciada
Use FydeOS Management Cloud para organizar dispositivos de quiosque e aplicar as configurações exigidas pela implantação. Dependendo do plano e da configuração selecionados, a linha de base pode cobrir o aplicativo ou URL permitido, comportamento de lançamento automático, restrições de dispositivos, configurações de energia e controles de atualização do sistema.
Mantenha a propriedade da política clara. Uma equipe de conteúdo pode possuir o aplicativo de quiosque, enquanto a TI possui o sistema operacional, a rede e os grupos de dispositivos. As alterações devem ter um aprovador nomeado e um método de reversão.
A documentação atual do FydeOS Kiosk fornece orientação de configuração específica do produto.
7. Planeje as atualizações como um evento operacional
Uma política de atualização precisa de mais do que uma hora preferida do dia. Decida como a organização irá:
- Validar um conjunto de aplicativos e periféricos contra uma versão do sistema candidato;
- Implantar para um grupo canário antes de toda a frota;
- evitar atualizar todos os terminais em um local simultaneamente;
- Confirmar que o aplicativo retornou após a reinicialização;
- Pausar ou recuperar quando as verificações de aceitação falharem.
Inclua alterações de aplicativo, certificado e conteúdo no mesmo calendário de lançamento quando elas podem afetar a jornada do usuário.
8. Escreva o procedimento de recuperação remota
Antes da implantação, a equipe de suporte deve ser capaz de responder a estas perguntas:
- Como sabemos que um quiosque está offline ou não é saudável?
- Podemos identificar sua localização, modelo, grupo de políticas e proprietário atual?
- Quais informações de diagnóstico podem ser coletadas remotamente?
- Quando é apropriado reiniciar?
- Quando o acesso remoto pode ser usado e como ele é autorizado?
- O que um funcionário local pode fazer com segurança?
- Quando um técnico deve visitar o local?
- Como um dispositivo com falha é substituído e registrado?
As ferramentas remotas reduzem viagens desnecessárias apenas quando a equipe tem um caminho de decisão claro.
9. Execute testes de campo, não apenas testes de laboratório
Coloque um pequeno número de quiosques em locais representativos. Teste a iluminação, ruído, temperatura, acesso físico, qualidade da rede e uso real de periféricos. Observe como os usuários se recuperam de erros e se as instruções são compreensíveis sem assistência.
Meça:
- Taxa de conclusão bem-sucedida para a jornada pretendida;
- Tempo entre ligar o dispositivo e o aplicativo estar pronto;
- Tempo offline não planejado;
- Tempo desde a detecção de falhas até o serviço restaurado;
- Incidentes que exigem uma visita ao local;
- Versões de aplicativo, periférico e política em cada dispositivo.
Essas medições formam uma linha de base defensável para a decisão de implantação.
Lista de verificação pré-lançamento
- A jornada completa do usuário e os estados de falha estão documentados.
- Aplicativo de produção, contas e terminais são testados.
- Para o Android Kiosk, a versão aprovada do APK, permissões, configuração gerenciada, periféricos e recuperação de reinicialização foram verificados.
- Todos os periféricos de produção passaram por testes normais e de falha.
- Montagem, energia, cabeamento, ventilação, acesso ao serviço e acessibilidade foram aprovados para cada local.
- Destinos de rede, certificados e comportamento offline são conhecidos.
- Políticas de quiosque, propriedade e aprovação de alterações são definidas.
- As atualizações usam dispositivos canários e uma condição de parada escrita.
- Diagnóstico remoto, ação local e limites de visita ao local são documentados.
- Um piloto de campo representativo completou exercícios de recuperação.
Execute um teste de aceitação do site
Para o processo de suporte mais amplo, consulte o guia de gerenciamento remoto de dispositivos multi-site.
Traga o aplicativo de destino, hardware, lista de periféricos e design de rede para um teste FydeOS Kiosk. Um pequeno piloto de campo é o lugar mais útil para confirmar a compatibilidade e a recuperação antes de encomendar ou converter uma frota mais ampla.