Saltar para o conteúdo
Versão de apresentaçãoEstamos a preparar o lançamento do AllMyQR.
AllMyQR
PT

O código QR continua na placa. A página ainda funciona?

A placa está intacta. O telemóvel reconhece o código. Mas, depois do toque, aparece uma página de erro. A durabilidade do suporte físico e a disponibilidade do destino são problemas diferentes.

Uma página pode desaparecer sem ninguém mexer no código

Imagina uma etiqueta de assistência numa máquina de lavar já entregue ao cliente. O código aponta para o manual no site do fabricante. Numa reorganização do site, o ficheiro muda de endereço e a ligação antiga deixa de funcionar. A etiqueta continua perfeitamente legível.

Para chegar ao manual, a pessoa depende de vários passos: ler o símbolo, abrir o endereço, passar pelo eventual serviço de encaminhamento e carregar o documento. Um problema em qualquer desses pontos interrompe o percurso.

A monitorização do destino verifica periodicamente uma parte desse caminho. É semelhante a um monitor de disponibilidade de sites, aplicado às páginas associadas aos códigos. Pode ajudar a descobrir uma falha antes de uma reclamação; o momento da deteção depende da frequência e das condições das verificações.

Há falhas que uma verificação automática consegue reconhecer

Uma verificação pode encontrar uma página não encontrada, um erro do servidor, uma ligação que demora demasiado, um problema de certificado HTTPS ou uma sequência de encaminhamentos que nunca chega ao conteúdo. Os estados de resposta HTTP documentados pela MDN ajudam a interpretar parte desses resultados: 404 indica que o recurso não foi encontrado; 500 indica um erro interno do servidor.

Mas receber uma resposta de sucesso não prova que a página está certa. Um site pode devolver 200 e mostrar «conteúdo indisponível», um formulário de login ou um manual desatualizado. A validação do conteúdo exige critérios adicionais ou uma revisão humana.

Também pode acontecer o inverso: uma página acessível aos visitantes recusa pedidos do monitor. Algumas proteções distinguem navegadores de pedidos automáticos. Um resultado isolado deve ser interpretado como uma observação a confirmar.

Um alerta deve ajudar a localizar o problema

«Há um link com erro» obriga-te a começar a investigação do zero. Um aviso útil identifica o código, a peça onde está aplicado, o destino verificado, o problema observado e a hora da última confirmação.

Se dez códigos apontam para o mesmo manual, um único incidente pode agrupar os dez afetados. Evitas dez mensagens repetidas e percebes o alcance da falha. Quando o destino recuperar, uma atualização fecha o acompanhamento.

A frequência merece uma escolha proporcional ao uso. Um programa consultado intensamente no dia de um evento tem necessidades diferentes de um arquivo histórico. Verificar mais vezes reduz o intervalo potencial de deteção, mas acrescenta pedidos ao destino e custo ao serviço. Nenhuma frequência garante que todas as falhas sejam observadas.

Depois do aviso, confirma a experiência do visitante

Abre a ligação original e confirma o problema sem a sessão de administração do site. Se o conteúdo mudou de endereço, atualiza o destino. Se o servidor está temporariamente indisponível, contacta quem o gere ou encaminha para uma alternativa que realmente ajude.

Uma mudança automática para uma página alternativa é outra funcionalidade. Precisa de regras próprias: quando mudar, qual o conteúdo equivalente e quando regressar. Um alerta, por si só, não deve ser interpretado como autorização para trocar o destino.

Depois da correção, volta a ler o código e confirma a recuperação. Mantém também uma revisão ocasional do conteúdo e do estado da peça física. O monitor pode verificar um endereço; não consegue ver se alguém tapou a etiqueta ou se as instruções continuam adequadas ao equipamento.

Continua a explorar

Quando a correção envolve outro endereço, consulta como mudar o destino de um código já impresso. Para planear a manutenção a longo prazo, lê o que pode fazer um código deixar de funcionar.

Voltar ao blog