Engenharia
· 8 min de leitura

Por que construímos nosso próprio estúdio de demos

Por Amine Gaaliche · rascunho escrito com Claude, revisto e editado à mão

Porque uma demonstração gravada da tela fica desatualizada a cada mudança da interface, e a nossa existe em dezesseis versões. Começamos com uma ferramenta pronta de captura de tela, que funcionou enquanto a interface ficou parada. A nossa muda quase toda semana. Por isso criamos o Demo Studio, que grava as ações em vez da imagem.

Dezesseis versões de cada demonstração

A conta é simples: dois temas vezes oito idiomas dão dezesseis versões, e todas são necessárias. Um escritório de Lyon espera ver a interface em francês, e um de Curitiba, em português. Quem usa o tema escuro estranha um vídeo inteiro em fundo branco.

Cada versão tem custo próprio: preparar o estado do aplicativo, abrir os documentos certos, executar a sequência sem hesitar, cortar e conferir. Multiplicado por dezesseis, isso vira um pequeno projeto. Ainda é razoável para algo que será visto muitas vezes.

O problema aparece quando o produto muda. Um botão muda de lugar ou um rótulo é reescrito, e o vídeo continua mostrando a versão antiga. A imagem não sabe que só um botão mudou, então cada mudança visível exige refazer as dezesseis gravações. Com uma interface que muda quase toda semana, quanto mais depressa o produto melhora, mais depressa as demonstrações envelhecem.

O que as ferramentas de captura fazem bem

Arcade, Storylane, Supademo e Trupeer resolvem bem um problema real. Todas partem da captura: registram o que a tela mostrava e permitem editar, anotar e publicar o resultado. Para uma interface estável, num só idioma, com uma demonstração para sexta-feira, são provavelmente a escolha sensata.

Não vamos listar o que cada uma oferece, porque quem as usa conhece os recursos melhor do que nós. O que não combinava com essas ferramentas era a natureza do nosso problema. Essas ferramentas guardam a aparência da tela, e era justamente a aparência que mudava, em quatorze combinações.

Gravar as ações em vez da tela

A captura registra como a tela estava. O Demo Studio registra o que o operador fez: abrir este arquivo, clicar em Detectar, revisar esta região, codificar aquele nome. É uma lista de ações, sem nenhum pixel.

Como o roteiro não contém a tela, ele também não contém o idioma nem o tema. Os dois viram parâmetros da renderização. A mesma lista de ações, executada dezesseis vezes, produz as dezesseis versões.

O roteiro roda sobre o próprio produto, então uma mudança de interface só exige renderizar de novo. Não existe cópia da interface para manter, e a demonstração nunca fica defasada em relação ao produto, porque é o próprio produto, com um conjunto de documentos fictícios.

Um roteiro também pode quebrar. Se um passo aponta para um botão que deixou de existir, alguém precisa corrigir esse passo. A correção é feita uma vez, e as dezesseis versões saem certas na renderização seguinte.

Como o roteiro roda no aplicativo real

A rota /demo do nosso site monta no navegador o frontend verdadeiro do aplicativo de desktop: os mesmos componentes React, o mesmo CSS, os mesmos arquivos de tradução. O site chega a eles por um alias do webpack, @desktop/*, que aponta para o código-fonte do aplicativo.

O que o navegador não tem é substituído na compilação por módulos de simulação, com o NormalModuleReplacementPlugin. Isso inclui a API local que roda ao lado do aplicativo e as chamadas ao shell do desktop (Tauri). Os PDFs são renderizados no navegador com o pdf.js.

Uma mudança no aplicativo de desktop aparece em /demo na compilação seguinte do site, sem que ninguém precise copiá-la. Se o aplicativo ganha uma função que a simulação não conhece, a demonstração registra um aviso em vez de quebrar. O Demo Studio fica no painel de administração, com um espaço por demonstração, e é dali que se pede a renderização.

Para que serve a rota /demo

Como a /demo mostra o aplicativo real, é tentador achar que ela serve para experimentar o produto. Ela não serve para isso, e nossas anotações internas já fizeram essa confusão duas vezes. A rota é onde o Demo Studio renderiza. As respostas da API são simuladas, e as detecções foram calculadas antes, sobre documentos fictícios de cada idioma.

Para avaliar o promptShield com seus documentos, use o aplicativo web gratuito, em app.promptshield.ca. Ali a detecção roda de fato no seu navegador, e o documento não sai da sua máquina. Nenhum modelo local acerta todos os identificadores, por isso a revisão humana continua necessária.

O que custou e o que continua custando

A versão funcional do Demo Studio foi construída em poucos dias, por uma única pessoa trabalhando com modelos de IA. A empresa não tem funcionários, e a página da equipe, no rodapé do site, diz isso. Para um time pequeno, esse dado pesa: o custo fixo de desenvolver caiu muito, e assinar uma ferramenta continua sendo um custo recorrente.

O custo fixo não é zero, e a manutenção fica conosco. Cada função nova da API local precisa de uma resposta simulada para aparecer bem na demonstração. O atalho também depende de algo que nem todo produto tem. Nossa interface de desktop é React dentro de um shell Tauri, e por isso roda num navegador sem reescrita.

Um produto com interface nativa não teria esse atalho, e para ele a captura provavelmente sai mais barata. Alugar faz sentido com poucas variantes, interface estável e ninguém para manter uma ferramenta. Construir faz sentido quando as variantes multiplicam cada mudança e o produto já roda onde a demonstração é renderizada. O mesmo raciocínio, aplicado ao que vendemos, está em por que construímos nosso próprio motor de detecção de dados pessoais.

Perguntas frequentes

Por que não usar uma ferramenta de gravação de tela?

Para muitos produtos, é a decisão certa. Mas ela guarda a aparência da tela, e a nossa existe em dezesseis combinações (dois temas vezes oito idiomas) que mudam quase toda semana. Cada mudança obrigaria a regravar todas.

O que acontece quando a interface muda?

A mudança chega à rota /demo na compilação seguinte, porque ela usa o código do aplicativo, e basta renderizar de novo. Se um elemento usado pelo roteiro sumir, o passo é corrigido uma vez e a correção vale para todas as versões.

Como manter oito idiomas em sincronia?

O idioma é um parâmetro da renderização, e os textos vêm dos mesmos arquivos de tradução do aplicativo. Quando um rótulo muda em português, a versão em português passa a mostrá-lo. Os documentos fictícios de cada idioma ainda exigem cuidado humano.

O que mudou para nós

Antes, cada melhoria no produto deixava trabalho pendente nas demonstrações. Era fácil hesitar diante de um ajuste de interface pensando no vídeo que ele invalidaria, e essa é a pior razão para deixar de melhorar um produto. Hoje a demonstração acompanha o aplicativo porque é o aplicativo.

Se você está pesando a mesma decisão, pergunte o que seu produto precisa guardar: a aparência de um momento ou as ações que levam até ele.

Foi útil? Diga-nos.

Partilhar