Operar, ensaiar e receber uma experiência interativa

Participar sem depender de um único gesto

Ofereça uma forma equivalente de escolher ou responder quando a pessoa não puder pular, levantar uma mão, ficar em pé ou usar o celular. Um botão alcançável, uma escolha na tela ou a ajuda do anfitrião pode preservar o sentido da atividade.

• Instruções claras e confirmação visual; não indicar turno apenas por cor ou som.
• Preparar legendas revisadas e sincronizadas com sons necessários; descrever informação visual relevante.
• Não exigir gesto que falhou para sair. Prever tempo de escolha, pausa e ajuste de estímulos.

Ensaio proposto: participação sentada, sem voz e sem smartphone; concluir com alternativa e pedir ajuda. Revisar alcance, leitura e escuta. WAI orienta projeto; avaliar conjunto com usuários/especialistas antes de declarar conformidade.

Uma pessoa, grupo e fila exigem regras distintas

Defina o que inicia uma sessão e o que libera a seguinte: presença, confirmação, duração combinada ou encerramento pelo anfitrião. Separe a área ativa da fila de espera para que a movimentação dos espectadores não altere a imagem do participante.

• Atribuir prioridade: turno, área ou ação compartilhada. Mostrar quem age e como acompanhante entra.
• Combinar duração-alvo, aviso de fim e reinício. Não retirar sem explicação quem precisa de ajuda.
• Planejar atendimento por chegada/duração. Sessões por hora não equivalem à lotação permitida.

Ensaio proposto: chegada antecipada, abandono, acompanhante e ausência de ação. Limpar escolhas anteriores sem atribuir ao próximo. Operador pode pausar entradas e guiar saída. Coordene circulação com local e produção e combine como habilitar novas sessões pelo controle previsto.

Usar o mínimo de dados necessário

Uma onda pode precisar só de presença ou posição efêmera. Antes de câmera, voz ou nuvem, mapear entrada, processamento, saída do dispositivo e retenção. Resultado numérico não garante anonimato.

• Preferir estado de área à identificação quando desnecessária. Avaliar botão/escolha manual sem câmera.
• Se câmera necessária, definir campo/processamento sem gravação automática. Para voz, confirmar transmissão/retenção do serviço.
• Separar ativos de intérpretes autorizados e entradas do público. Usar personagens fictícios ou ativos autorizados e informar caráter sintético.

Revisão proposta: dados, serviços, retenção, acessos e responsáveis; testar alternativa não identificável. Acordar informações/permissões com organização/assessores. Escopo técnico não altera avisos legais nem comprova conformidade.

Estados claros e comando do operador

1. Ativo
2. Dado vencido → espera
3. Operador → local
4. Prévia → habilitação

Espera, escuta, resposta e pausa precisam diferir visualmente. Operador também precisa de fonte válida, idade do dado, conteúdo e modo. “Conectado” sozinho não comprova resposta correta.

• Definir prioridade manual sobre sensores/pedidos remotos; evitar comandos concorrentes.
• Acordar cues de espera, local e assistido com sistema previsto. Pedir retorno de estado quando disponível.
• Na recuperação, descartar ações vencidas e revisar prévia antes de voltar ao público.

Exemplo proposto: ativo → dado vencido → espera; qualquer estado → operador → local; recuperação → prévia → habilitação. Reinício não mostra sessão anterior.

Ensaio proposto: perda durante resposta, ordens conflitantes e recuperação. Separar comando pedido e estado observado. Escopo de imagem/áudio não críticos, sem máquinas ou segurança.

Vários dias: voltar a estado conhecido

Prepare uma sequência de abertura com um responsável por etapa: verificar a versão do conteúdo e do projeto, os serviços necessários, as entradas, a calibração e a saída antes de receber o público. Durante a operação, siga os procedimentos dos equipamentos e do local.

• Antes: comparar marcas, testar área/comando assistido, voz/legendas, reinício e conteúdo local.
• Durante: registrar degradação, luz, desgaste e recuperação. Prever pausas de revisão sem participação ativa.
• Fechamento: parar participação, guardar projeto aprovado e incidências; aplicar retenção acordada e encerramento técnico.

Ensaio proposto: faça um reinício autorizado fora da programação e recupere a mesma configuração com ajuda da documentação. Verifique quais ajustes são mantidos e quais precisam ser restaurados. Teste a contingência e a substituição antes do evento; evite atualizações de rotina durante a programação.

Troca de sensor, posição, conteúdo, firmware ou versão pode invalidar testes. Registrar e repetir verificações afetadas. Manutenção/limpeza seguem métodos aprovados.

Ensaiar condições representativas do evento

Use o personagem, conteúdo, luz, som, figurino e área previstos. Uma demonstração silenciosa com uma pessoa não basta para verificar uma atividade com fila, música e mudanças de iluminação.

• Matriz: luz e variações, ruído, uma/várias pessoas, alturas, roupas, oclusão, duração e reinício. Combinar variações relevantes.
• Por teste: versão, condição, estímulo, esperado/observado, método, tolerância, responsável e evidência autorizada. Não observado fica pendente.
• Variar condição por vez no diagnóstico; depois repetir percurso completo sob carga representativa. Incluir alternativa assistida.

Exemplo de critério a testar: “Quando duas pessoas se cruzam, o sistema mantém a seleção da sessão ativa ou volta à espera, conforme a regra combinada”. Durante o teste, registre o que acontece e compare com esse critério.

Prepare os testes de perda de dados, conexão e recuperação fora da programação, com fontes de teste. A liberação para uso depende da montagem real e de seus responsáveis. Após uma mudança relevante, identifique as verificações de aceitação que precisam ser refeitas antes de receber o público.

Entrega e aceitação: escopo, arquivos e testes

Entrega precisa permitir compreender e operar escopo aprovado. Separar projetos editáveis, recursos de reprodução, documentação e interfaces. Pasta de vídeos não descreve todo sistema.

• Inventário: projeto/build, recursos, versões, formatos, dispositivos/interfaces, licenças e direitos. Identificar transferências e dependências.
• Operação: sinais/coordenadas, estados, comandos, abertura/fechamento, contingência e responsáveis.
• Testes: esperado/observado, condições, método, data, evidência autorizada. Separar documento, simulação e físico.
• Aceitação: desvios, restrições, pendências, responsáveis e critérios. Entregar arquivos não transforma pendência em aprovação.

Verificação proposta: outra pessoa encontra a versão aprovada na documentação, segue um reinício fora da programação e demonstra os modos assistido e de contingência sob supervisão. Verifique se as cópias combinadas permitem restaurar o projeto e se as dependências estão identificadas.

Antes de liberar o sistema para uso, revise a montagem e as condições de utilização com seus responsáveis. Combine a aceitação para o sistema real e as condições testadas. Mudanças de hardware, versão, luz ou percurso podem exigir novas verificações.