Um usuário clica em um botão, captura a tela do bug e envia sem instalar nada

Há um momento na vida de cada aplicativo web em que um usuário encontra algo quebrado. Um botão que não faz nada quando clicado. Um layout que desaba em um tamanho de tela específico. Um formulário que engole sua própria mensagem de erro. O usuário fica olhando para a tela, confuso, e então faz uma de duas coisas. A maioria deles simplesmente sai e nunca volta. Alguns poucos se dão o trabalho de compor uma mensagem do tipo "algo está errado com seu site". Essa mensagem chega sem contexto, sem descrição do que aconteceu, sem qualquer indicação de qual navegador ou dispositivo estava envolvido, e certamente sem uma captura de tela mostrando o problema real. O desenvolvedor lê essa mensagem, tenta reproduzir o problema, falha, e o bug fica sem correção até atingir o próximo usuário. Esse ciclo se repete infinitamente pela internet, e a causa raiz não é preguiça do usuário. A causa raiz é o atrito.

Tirar uma captura de tela em um computador requer conhecer o atalho de teclado correto, que varia dependendo do sistema operacional. No Windows, pode ser Imprimir Tela, ou Alt mais Imprimir Tela para a janela ativa, ou tecla Windows mais Shift mais S para a ferramenta de captura. Em um Mac é Command mais Shift mais 3, ou 4, ou 5, cada um produzindo resultados ligeiramente diferentes. Em um telefone, o gesto envolve pressionar dois botões físicos simultaneamente, o que na metade das vezes bloqueia acidentalmente a tela. Depois que a captura de tela é tirada, ela precisa ser localizada no sistema de arquivos, anexada a um email ou colada em um formulário de suporte e enviada. Cada uma dessas etapas é outro ponto onde o usuário desiste e decide que o bug não vale a pena relatar. O resultado é que os desenvolvedores recebem aproximadamente um relatório para cada cem bugs que os usuários realmente encontram.

A solução que surgiu dessa frustração é vergonhosamente simples. Um pequeno botão aparece na página. Quando o usuário clica nele, o servidor captura uma captura de tela da página exata que o usuário está visualizando e a anexa a um relatório. Nenhuma extensão do navegador necessária. Nenhum atalho de teclado para lembrar. Nenhum arquivo para localizar e fazer upload. Um clique, uma captura de tela, um relatório. O usuário adiciona uma ou duas frases descrevendo o que deu errado, e o desenvolvedor recebe uma imagem cristalina da página quebrada junto com a descrição. Esse é todo o fluxo de trabalho, e mudou a forma como os relatórios de bug chegam.

Por que as extensões do navegador nunca resolveram esse problema

A reação inicial óbvia é que as extensões do navegador já existem para esse propósito. Existem dezenas de ferramentas de captura de tela disponíveis como extensões do Chrome, complementos do Firefox e plugins do Safari. Algumas delas são bem boas, com recursos de anotação, uploads automáticos e integração com plataformas de gerenciamento de projetos. Mas todas compartilham o mesmo defeito fundamental. Eles exigem que o usuário instale algo antes que o bug aconteça. Ninguém instala uma extensão de relatório de bug preventivamente na chance de algum site que visitar amanhã ter um layout quebrado. As extensões resolvem o problema para equipes de QA e testadores internos que podem ser instruídos a instalar ferramentas específicas. Elas não fazem absolutamente nada para o público em geral encontrando um bug pela primeira vez em um site que pode nunca visitar novamente.

Há também a questão da confiança. Pedir a um usuário que instale uma extensão do navegador para relatar um bug introduz uma mudança abrupta na interação. O usuário veio ao site para fazer algo, descobriu que estava quebrado e agora está sendo pedido para instalar software de terceiros. Esse pedido despertará suspeitamente suspeitoso para muitos usuários, e mesmo aqueles dispostos a cumprir enfrentam a sobrecarga de navegar em lojas de extensões, conceder permissões e descobrir como a ferramenta funciona. No momento em que a extensão é instalada, o bug original pode não ser mais reproduzível, ou o usuário simplesmente passou para um concorrente. A janela para capturar um relatório de bug é estreita, e qualquer coisa que amplie a lacuna entre "algo está errado" e "relatório enviado" significa que o relatório nunca é enviado.

Bibliotecas de captura de tela do lado do cliente como html2canvas tentaram resolver isso de um ângulo diferente. Essas bibliotecas JavaScript renderizam o DOM em um elemento canvas, criando efetivamente uma captura de tela sem qualquer envolvimento do servidor. Elas funcionam razoavelmente bem para layouts simples, mas falham rapidamente com CSS complexo, iframes incorporados, imagens de origem cruzada, elementos canvas e fontes personalizadas. A imagem resultante geralmente não parece nada como o que o usuário realmente vê, o que derrota completamente o propósito. Um relatório de bug contendo uma captura de tela que não corresponde à página real é pior do que nenhuma captura de tela, porque envia o desenvolvedor perseguindo um problema visual que não existe enquanto o problema real permanece oculto.

Capturas de tela do lado do servidor e como elas capturam o que o usuário vê

A abordagem por trás do screenshots.yeb.to segue um caminho completamente diferente. Em vez de tentar reconstruir a página do lado do cliente, o servidor recebe a URL e a renderiza usando um mecanismo de navegador real em execução em um ambiente controlado. A captura de tela é feita por uma instância Chromium real que carrega a página, executa JavaScript, aplica CSS, renderiza fontes e captura o resultado como uma imagem perfeita em pixels. Isso significa que a captura de tela parece exatamente como um navegador real exibe, porque é o que um navegador real exibe.

Quando um usuário clica no botão de relatório de bug, a URL da página atual é enviada para o servidor junto com metadados sobre o tamanho da janela de visualização do usuário, proporção de pixels do dispositivo e qualquer parâmetro de estado relevante. O servidor inicia uma sessão de navegador sem cabeça configurada para corresponder a esses parâmetros o mais próximo possível. Ele carrega a página, aguarda a conclusão da renderização de todos os ativos e captura a captura de tela. O resultado é armazenado e vinculado ao relatório de bug, dando ao desenvolvedor um registro visual preciso da página no momento em que o usuário clicou no botão. O processo inteiro leva alguns segundos, rápido o suficiente para que o usuário possa adicionar sua descrição enquanto a captura de tela está sendo gerada em segundo plano.

Há nuances que merecem reconhecimento. Uma captura de tela do lado do servidor captura a página como ela aparece para o servidor, não necessariamente os pixels exatos na tela do usuário. Se o bug for causado por peculiaridades de renderização específicas do navegador, conteúdo armazenado em cache ou estado armazenado localmente, a captura do lado do servidor pode não reproduzir o artefato visual exato. Mas na prática, a grande maioria dos bugs que os usuários relatam são problemas de layout, imagens quebradas, conteúdo ausente ou falhas funcionais que são consistentes independentemente de quem carrega a página. Para esses casos, uma captura de tela do lado do servidor é indistinguível de uma do lado do cliente, e a redução massiva de atrito torna a troca valiosa.

Incorporar o botão sem alterar o aplicativo

A integração é intencionalmente mínima. Um pequeno trecho de JavaScript carrega o componente do botão, que pode ser estilizado para corresponder ao sistema de design do aplicativo host. O botão flutua em um canto da página, visível mas discreto. Quando clicado, abre uma sobreposição leve onde o usuário pode digitar uma descrição breve e opcionalmente destacar a área da página onde o problema ocorreu. Nos bastidores, o trecho envia a URL atual para a API de captura de tela, que captura a página e retorna a URL da imagem. O relatório, contendo a captura de tela, a descrição, a URL e metadados básicos do navegador, é então encaminhado para o que o desenvolvedor tiver configurado: um endereço de email, um webhook Slack, uma ferramenta de gerenciamento de projeto ou um endpoint personalizado.

A integração completa não requer alterações no backend do aplicativo. Não há SDK para instalar, sem middleware para configurar, sem esquema de banco de dados para modificar. O trecho funciona independentemente, comunicando-se apenas com a API de captura de tela e o destino do relatório configurado. Isso significa que pode ser inserido em um blog WordPress, um aplicativo de página única React, um site HTML estático ou um aplicativo PHP legado com igual facilidade. O tempo desde a decisão de adicionar relatório de bug até tê-lo funcionando no site é medido em minutos, não em sprints.

Para desenvolvedores que desejam integração mais profunda, a API pode ser chamada diretamente do código do lado do servidor. Isso abre possibilidades como capturar automaticamente uma captura de tela sempre que uma exceção não tratada ocorre, ou tirar capturas de tela periódicas de páginas críticas e compará-las com uma linha de base para detectar regressões visuais. Mas para o caso de uso básico de permitir que os usuários relatem bugs com um único clique, o trecho JavaScript trata de tudo sem qualquer alteração do lado do servidor.

O que muda quando os relatórios de bug realmente chegam

A transformação na qualidade do relatório de bug é dramática. Antes de implementar o botão, o relatório de bug típico era uma frase vaga em um email. "A página parece estranha." "O checkout está quebrado." "Algo aconteceu quando tentei salvar." Esses relatórios exigiam várias séries de perguntas de acompanhamento, durante as quais o usuário frequentemente perdia a paciência e parava de responder. Depois de implementar o botão, os relatórios chegam com uma captura de tela clara mostrando exatamente o que deu errado, acompanhada de metadados que identificam a página, o tamanho da janela de visualização e a hora da ocorrência. Um desenvolvedor pode olhar para a captura de tela e entender imediatamente o problema sem nenhuma volta e meia.

O volume de relatórios também aumenta significativamente. Usuários que nunca escreveriam um email ou preencheriam um formulário de suporte clicarão em um botão e digitarão três palavras. "Menu sobrepõe o conteúdo" não é o relatório de bug mais detalhado do mundo, mas combinado com uma captura de tela mostrando um menu de navegação sobrepondo a área de conteúdo principal em uma janela de visualização móvel, ele diz ao desenvolvedor tudo o que é necessário para reproduzir e corrigir o problema. A combinação de menor atrito e contexto mais rico significa que os bugs são relatados mais cedo, corrigidos mais rápido e verificados de forma mais confiável. Os dias de descobrir um bug de layout crítico três semanas após sua introdução estão praticamente eliminados para qualquer aplicativo que implanta esse tipo de mecanismo de feedback.

Há um benefício secundário menos óbvio, mas igualmente valioso. O arquivo de captura de tela se torna um histórico visual do aplicativo. Cada relatório captura um momento no tempo, mostrando exatamente como a página parecia quando o usuário encontrou um problema. Ao longo de semanas e meses, este arquivo revela padrões. Talvez uma página específica quebra toda vez que um novo deploy sai. Talvez usuários móveis relatem problemas em uma taxa três vezes maior do que usuários de desktop. Talvez uma versão específica do navegador produza consistentemente anomalias de layout. Esses padrões são invisíveis em relatórios de bug apenas texto, mas se tornam imediatamente aparentes ao navegar por uma galeria de capturas de tela com data e hora.