Smashing Podcast Episódio 37 Com Adam Argyle: O que é VisBug?

Neste episódio, estamos falando sobre o VisBug. O que é e como é diferente da variedade de opções já encontradas no Chrome DevTools? Drew McLellan fala com seu criador Adam Argyle para descobrir.

Mostrar notas

• Caixa de areia e playground VisBug
• Adão no Twitter
• Site pessoal de Adam
• VisBug no YouTube
• VisBug 101

Atualização semanal

• A plataforma de conferências que usamos para nossos eventos online: Hopin por Amanda Annandale
• Uma cartilha sobre consultas de contêiner CSS por Stephanie Eckles
• Padrões de design frustrantes que precisam ser corrigidos: seletor de aniversário de Vitaly Friedman
• Tree-Shaking: Um Guia de Referência de Átila Fassina
• Como melhoramos nossos principais Web Vitals por Beau Hartshorne

Transcrição

Drew McLellan: Ele é um engenheiro punk brilhante e apaixonado, com uma adoração pela web, que prefere usar suas habilidades para a melhor interface do usuário e UX da classe, e capacitar aqueles ao seu redor. Ele trabalhou em pequenas e grandes empresas e atualmente é um defensor do desenvolvedor trabalhando no Google no Chrome. Ele é membro do grupo de trabalho CSS e criador do VisBug, uma ferramenta de depuração de design. Então, sabemos que ele conhece o design e o UX, mas você sabia que ele possui mais pares de chinelos do que qualquer bípede vivo? Meus amigos esmagadores, por favor, dêem as boas-vindas a Adam Argyle.

Adam Argyle: Olá.

Drew: Oi Adam, como você está?

Adam: Ah, estou arrasando, você sabe disso.

Drew: Isso é bom de ouvir. Então, eu queria falar com você hoje sobre o seu projeto, VisBug, e em geral, sobre o conceito por trás da depuração de design e como ele pode se encaixar nos fluxos de trabalho do projeto. Quer dizer, nós temos ferramentas de depuração de navegador focadas em desenvolvedores há muito tempo, quer dizer, provavelmente mais de uma década agora. Mas esses são obviamente muito focados em código. Então, o que há de diferente no VisBug? E qual é o tipo de problema que ele está tentando resolver?

Adão: Incrível. Sim, o principal problema em que está enraizado é que, como engenheiro de front-end, trabalho com designers o tempo todo, e sempre adorei esse momento em que nos sentamos e eu pensava: “Ok. Estou dando os retoques finais. Temos mais um ou dois dias até a implantação. Então designer, sente-se, e você criticaria isso? Eu quero que você abra minha versão do host local em seu navegador e em seu telefone, ou qualquer outra coisa, e fale comigo sobre o que você vê.”

Adam: E depois de fazer isso por muitos anos e sempre amando essa interação, eu meio que comecei a me sentir culpado depois de um tempo por causa de quão comuns e simples eram as tarefas. Eles diriam: “Um pixel aqui embaixo. Cinco pixels de margem aqui.” E sempre foram nits e nudges, e nits e nudges para espaçamento e tipo. Quero dizer, raramente era como, “Ooh, espere um minuto enquanto passo 30 minutos alterando algum angular, ou qualquer outra coisa, para ajustar meu DOM para que o DOM possa atender ao seu pedido”, ou qualquer outra coisa.

Adam: Geralmente eram coisas pequenas. E então acabei fazendo uma pesquisa e entrevistei todos esses designers no Google. E eu fiquei tipo, “Quando você abre o DevTools, o que você faz?” E meio que foi retumbante que eles só precisam do básico. E assim nasceu, eu pensei: “Isso deveria ser mais fácil. Você não deveria ter que abrir o capô da Ferrari, mover um pedaço do motor, apenas para mudar a cor dos assentos do carro. Isso não é justo. Você deve ser capaz de tocar os assentos do carro e mudar a cor, como uma ferramenta de design.” Eu estava tipo, “Algo poderia facilitar esse fluxo de trabalho”. E eu fiquei tipo, “Ok, acho que vou hackear algo para ver se consigo criar a solução”.

Adam: E foi assim que tudo começou. Começou realmente com o espaçamento e depois a tipografia. E uma vez que eu tinha um mecanismo de seleção que emulava as ferramentas de design, era como, “Bem, o que mais posso fazer?” E continuou a partir daí. Mas sim, nascido naquele momento.

Drew: Então a ideia é que o cliente peça para você aumentar o logotipo, e o VisBug ajuda o navegador a se comportar mais como uma ferramenta de design para fazer esses tipos de ajustes. Então, mais perto de algo como Illustrator, Photoshop ou Figma, ou qualquer um desses tipos de coisas.

Adão: Sim. Esse caso de uso também é bom. Porque você pode estar com um cliente e eles dizem: “Oh, nós amamos isso”, isso é tão clássico, “nós amamos o design, mas essa cor azul é difícil para nós”. E você fica tipo, “Sério?” É tipo, as pessoas podem enviar um formulário e você pode ganhar dinheiro, mas você quer falar comigo sobre o azul agora? E normalmente isso criaria um ciclo inteiro. O PM dizia: “Ok, vamos anotar sua solicitação e depois enviar para o design”.

Adam: Mas se o designer está lá e é o navegador dele que está mostrando, eles ficam tipo, “Ok. Bem, vou clicar na coisa e mudar a cor.” E você pode cortar um ciclo inteiro de trabalho apenas prototipando a mudança no navegador. Então é. É mais eficaz contra um produto existente, certo? Porque é uma ferramenta de depuração. Não é necessariamente uma ferramenta de geração. Ele não cria um site para você. Pode, mas é meio estranho.

Drew: Então, tecnicamente, é uma extensão que você instala em um navegador Chrome. Isso está certo?

Adão: Sim. E é uma extensão. Quando você o inicia, ele baixa um arquivo JavaScript que diz: “Aqui está um elemento personalizado chamado VisBug”. E então você coloca o elemento DOM, vis-bug na página. E puf, eu apenas aproveito esse momento e o transformo em uma barra de ferramentas, e começo a ouvir os eventos na página. Eu escuto seus eventos de foco e escuto seus eventos de clique. E eu tento fazer o meu melhor para interceptá-los, e não competir com sua página principal.

Adam: Mas sim, essa é a essência de… A única razão pela qual é uma extensão é que é fácil de colocar na sua página. Embora neste momento ele tenha algumas configurações agora que acompanham você nos navegadores. Mas ainda é principalmente, 99,9%, um elemento personalizado sem dependências. Acho que gosto de uma biblioteca de cores que uso, e de outra forma é apenas baunilha. Sim.

Drew: Acho que foi assim que o Firebug começou, não foi? Como uma extensão do Firefox no passado.

Adão: Sim. É por isso que se chama VisBug. É muito inspirado no Firebug, mas para designers visuais.

Drew: Ah. Aqui vamos nós. Quer dizer, talvez esse não seja o formato ideal, sendo um podcast de áudio, para falar de uma ferramenta visual. Mas passe-nos, se quiser, alguns dos tipos de ferramentas e opções que o VisBug oferece.

Adão: Absolutamente. Então uma das primeiras coisas que o VisBug faz, e você também pode, se estiver em casa ou em um computador, você pode acessar visbug.web.app, e experimentar o VisBug sem a extensão, certo?

Drew: Ah.

Adam: É um componente da web, então eu carreguei uma página da web para você aqui em visbug.web.app que parece ter um monte de pranchetas de arte e, é claro, o VisBug pré-carregado. E o objetivo deste site é permitir que você jogue, explore e exclua. Eu acho que a chave delete é uma das ferramentas mais satisfatórias para começar. Você fica tipo, “O que posso fazer com uma página?” E você fica tipo, “Bem, eu posso destruí-lo.”

Adam: E eu fiz isso para que você possa segurar delete, ele encontrará o próximo… O que é bem difícil em um delete. Você exclui algo e seleciona o próximo irmão. Portanto, ele selecionará o próximo irmão para sempre. Se você segurar delete até apagar o todo… De qualquer forma, muito satisfatório. Clique em atualizar e tudo volta. Mas a primeira ferramenta que vem com o VisBug, então quando você acaba de iniciá-la, é a ferramenta de guias. E eu costumava segurar papel na minha tela, ou eu pegava uma extensão do sistema que me permitia marcar coisas e criar linhas.

Adam: Porque, sim, o alinhamento se torna muito ótico em um certo ponto para muitos designers, certo? Eles não querem, necessariamente, alinhamento matemático, certo? É por isso que a tipografia tem kerning óptico. Não é kerning matemático. Isso é kerning humano. E assim a ferramenta de guias está enraizada no fato de que muitos nits que acontecem de um designer estão ampliando as coisas, verificando o alinhamento. O espaçamento é bom?

Adam: Então essa é a segunda coisa que a ferramenta de guias faz. Quando você o inicia e apenas passa o mouse sobre as coisas, verá que o elemento sobre o qual você está passando o mouse fica com uma pequena caixa ao redor. E então os guias pontilhados aparecem, assim como os governantes normalmente fariam. E, assim como no Sketch e no Zeplin, onde você meio que passa o mouse e obtém esses guias, é o mesmo conceito, apenas ao vivo em sua página. E se você clicar em algo e passar o mouse para um novo destino, obterá ferramentas de medição. E as ferramentas de medição estão em pixels, e são calculadas... Então, visualmente, quantos pixels estão entre eles. Não o que alguém disse. Não está somando todo o espaçamento, é só você clicar nessa coisa e está tão longe daquela outra caixa.

Adam: E eu acho que isso se torna muito útil, porque você pode segurar shift e continuar clicando, e essencialmente verificar se você tem espaçamento igual entre cinco ícones. E são apenas alguns cliques. Não precisa saber código, apenas inicie o VisBug, passe o mouse, clique, clique, clique, e você verá isso, “Ah, veja, é. Sim. 15 pixels entre cada um deles.” Ou às vezes você consegue algo que é meio irritante, você clica em uma caixa e depois clica na caixa pai e percebe que a distância superior é nove e a inferior oito. E você diz: “Como vou centralizar isso? Está de alguma forma no meio.” E sacode o punho.

Adam: Mas pelo menos você consegue vê-lo bem e facilmente com a ferramenta de guias. Então, sim, essa é a ferramenta de guias.

Drew: Eu definitivamente estive lá, segurando pedaços de papel na tela. E também, o outro truque que eu usaria é abrir outra janela do navegador e usar a borda da janela para alinhar os itens. E então você meio que tenta manter tudo no lugar certo para que, à medida que você altera e atualiza o código, tudo ainda esteja alinhado. Sim, não é uma maneira ideal de trabalhar, então.

Adam: Não é uma maneira ideal de trabalhar. Sim. E há a próxima… Então, ah, e a primeira versão disso era muito solta. Ele não estalou, apenas levantou uma mira, que é um recurso que adicionarei de volta mais tarde. Então, alguns usuários dizem: “Ei, eu adoro o encaixe, é como minhas ferramentas de design. Mas e se eu quiser uma medida solta? Ou quero fazer uma carta, quero medir uma carta, não sua caixa de correio?” E assim, bem, esta ferramenta de guias pode ser facilmente alterada para ter uma tecla modificadora.

Adam: Então aqui é onde o VisBug fica um pouco diferente, mas também familiar, é que é muito pesado em modificadores de teclas de atalho. Assim como se você assistir a um designer profissional, eles são muito experientes em teclas de atalho. E eles estão pressionando teclas de atalho aqui, ampliando, pressionando teclas de atalho ali, e apenas fazendo todos os toques no teclado. E assim o VisBug é muito centrado no teclado na maneira como você muda as coisas.

Adam: É também porque o VisBug permite várias seleções e pode alterar o espaçamento de 100 itens ao mesmo tempo. E o faz relativamente. De qualquer forma, ele tem algumas peculiaridades interessantes, mas o teclado em um conceito de modificador é realmente importante. E você pode segurar a opção, ou mudar, ou comandar em muitas ferramentas e obter algo diferente, ou obter um novo tipo de recurso lá.

Drew: Então é uma daquelas ferramentas em que realmente vale a pena aprender os atalhos de teclado.

Adão: Faz. E então, quando você inicia o VisBug e passa o mouse sobre um dos ícones de ferramentas, você verá um detalhamento. Ele exibe um pequeno menu suspenso, diz a tecla de atalho para escolher essa ferramenta e informa o que ela pode fazer e quais interações fazer para obtê-las. Portanto, a ferramenta de guias diz: “Guias de elementos, apenas passe o mouse. Meça algo, clique e, em seguida, passe o mouse sobre algo novo. Medições fixas são shift + click para que elas persistam.”

Adam: E esses guias são muito bons também para captura de tela. Então, se você estiver revisando um PR, mesmo como apenas um engenheiro de front-end, ou talvez um designer revisando um PR, essa pode ser uma maneira realmente poderosa de você entrar lá e, sim, ter uma inspeção de alta fidelidade. Que tipo de nos leva para a próxima ferramenta. Quer saber sobre a próxima ferramenta?

Drew: Sim, claro. Vamos em frente.

Adão: Incrível. A próxima é a ferramenta de inspeção. E esse aqui é tipo… Designers normalmente, eles não querem todo o CSS, certo? Quando eles esperam com… eu quase disse Firebug, mas o Chrome DevTools, você tem a lista completa, certo? Eu selecionei este H1 e aqui está tudo até a folha de estilo do navegador. E o designer diz: “O navegador o quê? O navegador tem uma folha de estilo?”

Drew: Na parte inferior obscura desse painel de rolagem.

Adam: O fundo escuro, certo?

Drew: Sim.

Adam: É como se você descascasse todas as camadas e então você fica tipo, “Ooh, eu não gosto mais dessas camadas.” E a ferramenta de inspeção aqui diz: “Ah, designers, eu sei o que vocês querem. É apenas a cor da borda.” Basicamente, só me mostre algo se for único, então não me cubra apenas com propriedades CSS. E estou realmente mais interessado em cor, tipografia e espaçamento. Então eu vou olhar para margens, alturas de linha, família de fontes é muito importante, certo? Há toda uma extensão apenas para informar qual é a família de fontes em uma página.

Adam: No VisBug isso é apenas um item de linha na ferramenta de inspeção. Então, basta iniciar o VisBug, clicar em inspecionar e passar o mouse sobre qualquer tipografia e ele informará a família de fontes. Então, sim, ele tenta fazer um designer focado no que mostra, sim.

Drew: Então essa ferramenta não está mostrando nenhum estilo herdado. Isso está certo?

Adão: Isso está correto. A menos que sejam herdados e únicos. Então, se eles... Uma cor de texto ou algo assim, se a cor do texto não for literalmente a palavra herdar, isso lhe dirá que é um valor calculado, que é algo interessante.

Drew: Sim, isso é realmente útil... Sim. Ajuda você a se concentrar nas coisas que estão literalmente se aplicando a essa instância de algo, que é obviamente o que você queria mudar. Quero dizer, acho que isso pode ser muito útil, todas essas ferramentas seriam muito úteis, como você mencionou, para obter feedback das partes interessadas. E meio que trabalhando interativamente com um cliente.

Drew: Acho que funcionaria igualmente bem no compartilhamento de tela, como temos que fazer hoje em dia, cada vez mais. Você não precisa estar sentado em um computador com alguém, você pode estar sentado do outro lado de uma chamada e compartilhar seu navegador e fazer isso dessa maneira. Acho que seria uma maneira bastante eficaz de obter feedback quando um cliente não pode apontar para a tela e dizer:

Adão: Com certeza.

Adam: É sempre mágico quando você transforma a página ao vivo no que parece uma prancheta do Zeplin. Alguém diz: “O que… acabamos de ir a algum lugar novo?” E você fica tipo, “Não, este é o seu produto. Estamos apenas interagindo com isso muito visualmente.” Sim, pode ser muito bom.

Drew: Existem outros casos de uso interessantes em que você viu o VisBug ou que ocorreu a você que pode ser interessante?

Adão: Sim. Então, sim, há tantos que é meio difícil começar. Ah, um que é importante é a comunicação de desenvolvedor para desenvolvedor. VisBug trabalha nos valores calculados. Portanto, ele não analisa seus valores de autoria. E isso pode ser muito bom, porque você está medindo e inspecionando o resultado final absoluto da maneira como os pixels foram calculados na tela. E isso pode ser muito bom, ter uma conversa dessa maneira, enquanto você está trabalhando nos resultados, em oposição ao lado da autoria.

Adam: E você pode voltar para tipo, “Ok, bem, como erramos no lado da autoria se isso é o que conseguimos visualmente?” O que também meio que desempenha, a próxima ferramenta é a ferramenta de inspeção de acessibilidade. Portanto, a ferramenta de inspeção facilita a visualização dos estilos em um elemento e os divide de uma maneira muito amigável ao designer. A ferramenta de acessibilidade ajuda você a inspecionar todos os elementos em uma página e mostra todas as propriedades acessíveis que ela possui, o que torna, espero, mais fácil verificar se algo foi feito.

Adam: Então um PR… E as coisas muitas vezes são criadas. Então, isso é, novamente, desenvolvedor para desenvolvedor, desenvolvedor designer, você está revisando interfaces. É tão crítico. Se você está olhando para uma interface e está curioso, o VisBug tem um caso de uso para você. Há também casos de uso em que você pode criar um protótipo no navegador. Então falamos sobre um em que é como se o cliente quisesse experimentar o azul. Ok, esse é um cenário muito fácil.

Adam: Mas há outros também. Se você pressionar o comando D no VisBug, duplicará um elemento. E não importa o que você está duplicando. Então você pode duplicar um cabeçalho, adicionar algum espaçamento entre os dois cabeçalhos e fazer uma variante ao vivo no navegador. Você clica duas vezes no texto do cabeçalho e ele se torna um campo de texto editável, e você tenta um novo título e vê como o título se encaixa. Vá ajustar um pouco de espaçamento e você acabou de se salvar de todo esse trabalho de desenvolvedor, encontrando um arquivo de origem e todo esse tipo de coisa, e você está apenas…

Adam: Então, sim, pode ajudá-lo a explorar e verificar. É meio estranho... quero dizer, são muitas das coisas que o DevTools faz, certo? Ele vem depois que você termina, na verdade não fornece o código-fonte com muita frequência, não é muito frequente que você copie o código do DevTools. Você pode copiar um par de valores-chave. Tipo, “Oh, eu mudei esse estilo”. Mas sim, de qualquer maneira.

Drew: Mm-hmm (afirmativo). Sim. Posso pensar em casos particularmente visuais em que você pode querer, você mencionou, duplicar itens. Você pode querer pegar uma seção inteira da página e duplicá-la para simular como seria se houvesse muito mais conteúdo do que você esperava.

Adão: Sim. Esse é o caso de uso do teste de caos.

Drew: Sim.

Adão: Absolutamente.

Drew: Que é algo com o qual todos nós temos que lidar, projetando com sistemas baseados em CMS e todos esses tipos de tarefas divertidas.

Adam: Sim, esse é um caso de uso realmente crucial também. Porque eu faço isso para… Sim, manchetes, como eu disse. Você apenas clica duas vezes em algum texto e eu bato o teclado. Blá, blá, blá, blá, e acertar um monte de espaços, blá, blá. E eu fico tipo, “Ok, como foi o layout? Ah, fez bem. Ok, bom, eu posso passar para a próxima coisa. O que acontece se eu duplicar isso quatro vezes? Ainda há espaço entre tudo? Ele flui ao lado do próximo item?”

Adam: Pode ser muito bom para essa simulação do caos do conteúdo. Título muito curto, títulos muito longos, não tem amigos, tem um milhão de amigos. Como você lida com esses casos de uso na interface do usuário? Sim.

Drew: Então funciona com qualquer conteúdo baseado em navegador. Então, PWAs, bem como páginas da Web regulares?

Adão: Sim, tem. Então, se você tem o Spotify instalado, eu faço isso o tempo todo, tenho o Spotify instalado e fico tipo, “Spotify, parece que você é um aplicativo impossível de inspecionar”. Mas adivinhem? VisBug não se importa. VisBug sobrepõe todas as suas coisas, inspeciona toda a tipografia. Eu fiz um tema light para… Ah, eu tenho um tweet em algum lugar onde fiz um tema light do Spotify.

Adam: Ah, esse foi outro caso de uso, desculpe, para prototipagem de cores. Eu posso criar um tema leve no próprio produto sem ter que mexer com um monte de folhas de adesivos, certo? Portanto, há essa mentalidade importante e equilibrada, eu adoraria que o VisBug ajudasse as pessoas a entender, ou seja, usar seu produto como um playground. Use isso como… É tão real. É mais real do que suas composições de design. Então passe um pouco mais de tempo lá. Acho que você descobrirá que pode tomar decisões de design mais eficazes trabalhando em seu produto real.

Drew: E o caso da acessibilidade também é particularmente interessante, porque muitas vezes, principalmente nos dias de hoje, estamos trabalhando muito em bibliotecas de componentes e analisando pequenos componentes de uma página. E gastar menos tempo olhando para todos aqueles integrados para criar o tipo de visão com a qual um cliente realmente interage. E fica muito difícil ficar de olho nesses detalhes mais sutis, como coisas de acessibilidade, atributos, que não são visíveis na página.

Drew: É muito difícil ficar de olho em coisas que não são visíveis. Então, é aqui que as ferramentas podem realmente ajudar a inspecionar algo e ver que, sim, ele tem as funções corretas e é...

Adão: Faz. Esse é o caso de uso exato. Eu quero que um PM possa verificar essas coisas. Eu quero que um designer seja capaz de olhar a acessibilidade e não ter que abrir as ferramentas, encontrar o nó DOM, está tudo triturado no painel de elementos e parecendo estranho. Que apenas diz: "Aqui estão os atributos da área, aqui está o título, se existir". Há também algumas outras ferramentas de acessibilidade para. O VisBug vem com o ícone de pesquisa. O ícone de pesquisa tem várias maneiras de interagir com ele.

Adam: Então, primeiro ele consulta a página. Portanto, se você souber o tipo de elemento ou o nome da classe de elemento que deseja, basta pesquisá-lo, para não precisar encontrá-lo com o mouse. Mas isso também tem comandos de barra. Portanto, há plugins no VisBug, e eles executam scripts na página. Então, se você já teve um marcador que salvou três ou quatro… Você pensa: “Vou usar este porque ele destaca todas as bordas e me mostra minhas caixas”. É como um truque de depuração ou algo assim.

Adam: Provavelmente é um plugin do VisBug. Então, você inicia o VisBug, pressiona a barra e obtém o preenchimento automático, e ele mostra todos os plugins diferentes. E há alguns de acessibilidade que são muito legais que sobrepõem erros e várias coisas assim. Então eu concordo. A acessibilidade deveria ser mais acessível. Isso é chato de dizer. Mas precisa estar mais perto do cinto de ferramentas. E acho que às vezes está muito longe, e talvez seja por isso que passa despercebido. Então, espero que se for um pouco mais na frente, no centro e mais fácil que seja verificado mais. Sim.

Drew: E é interessante você dizer que o VisBug trabalha com o tipo de valores computados das coisas, como cores. Isso significa que, se você tiver vários elementos em camadas com diferentes níveis de opacidade, poderá medir a cor exata que está sendo renderizada na tela, em vez de-

Adão: Ah.

Drew: … olhando para os elementos individuais e tentando resolver de alguma forma?

Adam: Essa é uma pergunta muito boa. Então eu acho que, se estou entendendo bem a pergunta, qual é uma dificuldade clássica no front-end é, sim, como você sabe se você tem uma palavra de texto meio opaca, qual é sua cor sobre cinza versus sobre branco ? E como você sabe o seu contraste? No momento, não sabemos. Assim, o VisBug conhece a cor e dirá “50% cinza”, ou seja qual for a cor que você tem lá. Mas não conhece nada mais inteligente do que isso. Não é capaz de…

Adam: Eu acho que o que você teria que fazer nesse caso é criar uma tela, pintar todas as camadas ali, e então usar um conta-gotas ou um… camada única pintada e, em seguida, retire o valor de pixel único para ver qual é o cinza final calculado depois que ele foi colocado em camadas nas outras coisas.

Adam: Acho que alguém especificou, ou talvez eu tenha um problema no GitHub que seria legal. Porque o VisBug poderia facilitar isso, 100%. VisBug, nos bastidores, eu já fiz com métricas de texto, onde você passa o mouse sobre as coisas e dá informações loucas sobre as fontes. É quase muita informação, como altura x e altura da tampa, mas vai ainda mais. E é como, “Ooh, eu estou meio desligado em um certo ponto.” Então eu tenho que descobrir como encontrar o sinal versus ruído lá.

Adam: Mas sim, eu gosto desse processo de pensamento, porque devemos ter uma ferramenta que faça isso. E se soubermos como calcular, podemos ensinar o VisBug a fazer isso, e esse seria um recurso muito legal de se ter, cor calculada relevante para opacidade. Adoro.

Drew: Sim, quero dizer, é o tipo de caso padrão de ter texto contra um fundo onde você não tem certeza se o contraste é suficiente para passar nos requisitos de acessibilidade. E talvez não seja, talvez seja um contraste muito baixo e você queira ajustar os valores até chegar ao ponto em que o contraste seja bom, mas não se afastou muito do que o cliente queria inicialmente em termos de cores da marca e coisas.

Adam: Eu chamo isso de colisão, colisão até você passar.

Drew: Sim.

Adam: Porque é assim que se sente. Eu sou como, “Ooh, eu estou um pouco curto na pontuação.” Então é tipo, eu vou para a minha leveza HSL e eu vou bater, bater, bater, e assistir os pequenos números tiquetaquearem até que seja tipo, “Ding”, eu tenho uma marca de verificação verde. Eu estou tipo, “Ok, legal”. E sim, às vezes, um pouco dessa cor não é legal. Então, você estudou muito do trabalho de acessibilidade perceptual 3.0 que está acontecendo? Para que não tenhamos mais AA ou AAA, teremos no número e isso inclui coisas como a espessura da fonte. Então se for uma fonte fina ela terá uma pontuação menor, se for uma fonte grossa ela vai... Porque há muita coisa que entra em contraste.

Drew: Sim, não, eu não tinha visto nada disso, mas parece-

Adam: De qualquer forma, é uma coisa muito legal para explorar.

Drew: Isso parece fascinante, sim. Vou ter que encontrar alguém para conversar sobre isso. Isso é outro episódio. Então, quero dizer, tenho certeza que alguns desenvolvedores podem argumentar que tudo o que o VisBug está fazendo você pode simplesmente fazer através do painel CSS no DevTools. E eu acho que é meio justo, mas provavelmente perde o ponto, pois sim, você está manipulando CSS quando está fazendo alterações, mas está colocando uma espécie de interface de usuário focada no designer no topo, em vez de uma interface focada no desenvolvedor. Isso é uma caracterização justa dele?

Adam: Essa é realmente justa. E honestamente, as melhores ideias saem do VisBug para o DevTools. E eles já têm. Então VisBug, se você apertar a opção de comando C em qualquer elemento, ele pega todos os estilos computados, pelo menos isso é único. Mais uma vez, vamos fazer aquelas que não vamos apenas dar a você todas essas propriedades herdadas. Mas coloca todos eles na sua área de transferência e você pode colar esse estilo em outro lugar, em uma folha de estilo, em um CodePen, e literalmente recriar o elemento em alguns cliques.

Adam: E esse tipo de interação chegou ao DevTools, nesse painel de elementos. Há outras coisas, no entanto, que não, ou seja, o DevTools é uma ferramenta apenas de inspeção de nó único. E o VisBug segue o mantra da ferramenta de design que é, não, eu deveria ser capaz de multisseleção. Eu preciso ser capaz de editar em massa, inspecionar em massa. E então eu uso o VisBug o tempo todo para espaçamento. Porque posso destacar vários elementos e ver o colapso da margem.

Adam: No DevTools você nunca pode ver, porque você só pode ver um nó por vez na maioria das vezes, embora haja uma maneira de mostrar várias margens, mas não é a mesma coisa. E então, sim, tem esses casos de uso de nicho que podem ser muito divertidos assim. Outra é, se você destacar um... Digamos que você tenha um sistema de tipografia e tenha H1 a H7, como em um livro de histórias ou algo assim, você pode destacar todos eles no VisBug, segure shift, basta clicar em todos eles. Boop, boop, boop, boop, vá para a ferramenta de tipografia e aperte para cima ou para baixo, e isso faz uma alteração relativa em cada um deles.

Adam: Então cada um deles vai empurrar um para cima ou para baixo. E isso não é algo que o DevTools torna muito fácil. E então, sim, tem alguns superpoderes como esse, porque é um pouco mais agnóstico. E está preparado para sempre iterar em uma matriz. Sim.

Drew: Então qual foi a origem do VisBug? E agora é apenas um projeto pessoal? Ou é um projeto do Google? Ou qual é o estado dele?

Adão: Sim. Então, primeiro, o status é, é um projeto do Google. Seu objetivo principal é ser um lugar para prototipar e explorar antes que as coisas entrem no DevTools. Pelo menos do lado do Google das coisas. Mas, do meu lado pessoal, ainda vejo isso como um lugar para fazer as tarefas comuns ou para fazer algumas otimizações para realizar tarefas comuns. E apenas para dar a um público mais amplo uma maneira de olhar para o DOM.

Adam: Eu realmente acho que o DevTools é super poderoso, mas é muito intimidante. Apenas uma guia pode levar uma carreira para aprender. Ainda estou aprendendo coisas no DevTools e as uso o tempo todo. E então, sim, esse é um público diferente em alguns aspectos. São mais os iniciantes, as pessoas que chegam, ou talvez até mesmo pessoas como PMs, gerentes, que nunca pretendem codificar, mas estão interessados ​​na saída. E isso meio que dá a eles, sim, apenas ferramentas leves para chegar lá.

Drew: É um ponto interessante que você levanta, porque eu pessoalmente acho que luto para encontrar um fluxo de trabalho confortável no gerenciamento de todos esses tipos de DevTools. E você tem todos esses pequenos painéis claustrofóbicos, e você pode separá-los em outra janela, mas então você está tendo que acompanhar duas janelas diferentes. E uma vez que você tem algumas janelas do navegador abertas, você não pode… Você foca uma e não sabe qual DevTools pertence a ela.

Drew: E dentro dos próprios painéis, é uma espécie de Velho Oeste de convenções de interface de usuário. Você rolará e as coisas começarão a fazer coisas estranhas que você não esperava. E em termos de experiência do usuário, sinto que tudo é uma grande bagunça.

Adão: É. Sim.

Drew: Você acha que isso é inevitável? Pode ser melhor?

Adam: Eu definitivamente tenho pensamentos aqui. E sim, eu acho uma boa… Então, digamos que você tenha um ouvinte agora que diga: “Sou bastante experiente com o DevTools. Eu não acho que eles sejam tão loucos.” Eu dizia: “Ok, abra o Android Studio ou o Xcode. Comece um projeto, e vá ver o DevTools, vá ver a saída. Quão familiar você se sente agora?” Provavelmente muito estrangeiro. Você está olhando para isso, “Isso é lixo. Porque é que eles fazem isto? Por que esse painel está aqui?” E sua mente começa a correr com todas essas perguntas por que e confusão.

Adam: E é tipo, bem, é assim que todo mundo se sente na primeira vez que abre o DevTools. Então você tem que ser realmente empático com isso.

Drew: É inevitável que… Podemos fazer melhor? Ou isso é apenas o tipo de ordem natural das coisas?

Adam: Então aqui está minha opinião atual sobre isso, acho que a complexidade é muito fácil de se encontrar. E DevTools é uma dessas coisas, eles são naturalmente complexos. Não há uma boa interface do usuário para facilitar muitas dessas coisas. Muitas dessas coisas são construídas por desenvolvedores. E eu acho que devs construindo ferramentas para devs é bom, porque você vai ter... Se for a única maneira, ou mesmo se for uma boa maneira, você vai aprender, e você vai ficar bom em ele, e você vai ficar confortável com ele.

Adam: E todos os DevTools são meio estranhos, porque são feitos para seus casos de uso estranhos, certo? O desenvolvimento é estranho. Vamos ser honestos. Fazemos engrenagens invisíveis e invisíveis duas a quatro, e construímos casas, basicamente, com peças invisíveis, virtuais. Então, sim, precisamos de ferramentas estranhas para inspecionar essas coisas e nos dizer o que estão produzindo.

Adam: Agora, dito isso, o que o VisBug faz, e o que eu tenho movido lentamente para o DevTools, são ferramentas menores que são mais focadas em oposição a uma grande ferramenta que afirma fazer muito. Eu acho que é difícil para as coisas fazerem muito bem. E este é um argumento clássico, certo? Isso é tudo estrelas, especialistas versus generalistas. Nem sempre vai ser perfeito.

Adam: Mas o que o VisBug está tentando fazer é criar especialistas. Portanto, a ferramenta de guias apenas faz guias. E essa ferramenta nunca vaza para as outras ferramentas da página. E estou tentando fazer mais isso com o DevTools, onde o DevTools quer ajudar mais os designers, algo que o VisBug ajudou a inspirar o DevTools a ver. E a maneira que eu continuo apresentando as coisas é, em vez de fazer um editor de grade, por exemplo, onde você pode… “Potência total da grade em uma sobreposição”, certo? “Você pode adicionar faixas, remover faixas, blá, blá, blá.”

Adam: E eu fiquei tipo, “Isso soa muito legal e também muito complexo.” I'm like, “Grid is crazy, there's no way we're going to build a GUI for that.” So I'm like, “Why don't we just handle grid template columns first, and the ability to manage the tracks in there, almost like they're chips? What if we could just add, and edit, and delete them?” They're much more physical and less of string. I'm like, “Well what we've done is, we've created a micro-experience that solves one problem really well and then doesn't leak anywhere else, and it's also really naive. It's a naive tool.”

Adam: So and a good example of that is the angel tool in DevTools. Have you seen that tool yet?

Drew: No, I haven't.

Adam: Any angle… So this is, I'm calling these type components. So their CSS is typed, and the angle is a type, and many CSS properties will take a type value of angle. And what I was like… Well, angles, those are just a wheel like a clock. Why don't we give someone a GUI so that if they click an angle they can change an angle and snap it to 45, snap it to 90, there's common interactions with just this unit of angle.

Adam: And we made a tool for it. And it's super cool. It looks great, the interaction is great, keyboard accessible the whole nine, and that's an example where I think you can make small focused things that have big impact, but don't necessarily solve some big problem. And yeah, you'll have another tool like Webflow that's trying to create entire design tool and facilitate all your CSS.

Adam: So, yeah, I don't know the right answer, but I do know that an approachability factor comes in when things do less. And so it just kind of makes it a little easier. Like VisBug, you might only know three tools on it. You only use the guides, the margin tool, and then the accessibility inspect tool. Maybe you never use the move tool or the opposition tool. Just, yeah.

Drew: I mean, talking of design tools, we've seen a big rise in the last few years of tools. Things like Figma, which are great for originating new design work in the browser. Is there overlap there with what Figma is doing and what VisBug is trying to do?

Adam: There's definitely overlap. I think they come at it from different directions. One of the things that I'm frustrated with Figma at is not something that VisBug could solve. And I think that design these days, even with the powerful tools and the Flexbox-like layouts that we have, I still think we start wrong when we draw a box on a canvas of a certain size. I'm like, “Sorry, that's just not the web. You're already not webby.”

Adam: Nothing is very content-focused. If I just drop a paragraph into Figma, it gives it some default styles and I'm like, “Why doesn't it do what the web does? Put it in one big long line.” You're like, “Contain it somehow,” right? And so I don't know. I think that Figma is empowering people to be expressive, limitless… What is the phrase I like to use? Yeah, okay, it's expression-centric. That's where I think VisBug and a lot of debug tooling is…

Adam: So yeah, one is empowering expression, and the other one is empowering inspection and augmentation. You need both, I think. I think that in one cycle of a product you're in full expression. You need to not have any limiters. You need it to feel free, create something exciting, something unique. But then as your product evolves and as more teammates get added, and just the thing grows and solidifies, you'll exit a phase of expression and into a phase of maintenance, and augmentation, and editing.

Adam: At which point your Figma files do two things, they get crusty, because your product is more… Well, it's real. Your product has made changes, and design decisions, because it's now in the medium. And so your file starts to look crusty. And then your file also just is constantly chasing production. And that's just a pain in the butt. And so VisBug is sort of waiting. So in the expression phase VisBug's like, “I can't help you very much. I'm just sort of, I'm not that powerful at expression.”

Adam: But then as you have a real product you can inspect it. And yeah, it can inspect anything. It has no limits. It goes into shadow DOM and everything. So yeah, I think they're just different mentalities for different phases of products, yeah.

Drew: So in VisBug if you have made a whole lot of changes, maybe you're sat with a client and you've tweaked some spacing, and you've changed some colors, and you've got it looking exactly how the client wants, they're happy. They obviously now think that all the work has been done.

Adam: It's done.

Drew: Which of course, it's not. We understand that. But what is the path? What is the developer journey from that point to… I mean, I presume that it's not practical to save or export, because there's no way to map what you're doing in the browser with those source files that originated that look. But what's the journey? How do you save, or export, or is it, I guess, taking a screenshot? Or what do you do?

Adam: Yeah, there's a couple paths here. And I want to reflect quickly on what we do in DevTools. So let's say, DevTools, we made a bunch of changes, there is the changes tab in DevTools, I don't think very many people know about it, which will surface your source file changes, and some other changes in there that you could go copy paste.

Adam: And yeah, this becomes a hard thing with all these tools that are editing code output, they don't have any knowledge of source or authoring files. I mean, maybe they have source maps, but I think that's a really interesting future. If we get to something where the calculated output could be mapped all the way back to the uncompiled source, that'd be really cool. But until then, VisBug does do similar to what you do in DevTools. Where you just copy paste the sort of pieces.

Adam: But I will share some fun ways to sort of make it even better. So one thing, let's say you made a header change, color change, and a change over here. You can go to the inspect tool, and when you hover on something it will show you a delta. It'll say, “Local modifications.” And if you hold shift you can create multiple sticky pinned inspections. And so you'll go to your header, you'll click it, you'll hold shift, click your other little box, and hold shift to click another little box. And now you have tool tips showing what you changed over the actual items in the page, take a screenshot, and ship it to a dev.

Adam: And they can sort of say, “Okay, I see you changed margin top to 20 pixels. I don't use pixels or margin top in my CSS. So I'll go ahead and change to margin block start two RAM, thank you and bye bye.” And that's kind of nice, is that the editor didn't have to care or know about the system details, they just got to say something visually and screenshot it. So that workflow is nice. It's pretty hands off and creates a static asset which is fine for a lot of changes.

Adam: But if you had a lot of changes and you really changed the page and you wanted to save it, there is another extension called… Let's see. Page, single file. Single file will download the entire current page as a single file HTML element, at which point you could drag that right into Netlify and get yourself a hosted version of your prototype.

Adam: Because what VisBug does is, it writes its styles in line on the DOM notes themself. So save file comes with it all. And I've got a tweet where I went to GitHub and I made… I just totally tweaked the whole site, and it looked cool. And I was like, “All right, save file.” And I saved it, opened it up in a new tab, just dragged it into the new tab and I was like, “Well this is really cool.” Because VisBug's been wanting a feature like this for a while. But it's a whole other extension's responsibility, is taking those third party assets, dealing with all the in line… And anyway, so it's really nice that that exists.

Adam: And so you can deliver a file, if you want to, or host it somewhere, and share multiple links to multiple versions of production. You modified production and then shipped it into netlify, and someone can go inspect it, and it's still responsive at that point too, right? At that point it's not a static comp you're sharing, it's still the live, responsive… Anyway, it's exciting. I mean, there's a future here that's, I think, really, really interesting and not far away.

Adam: It's just like we're a little still stuck, as designers, in our expression land. We're just too happy expressing. And we're dipping our toes into design systems, but even those I think are starting to get a little heavy for designers. And they're like, “Ooh, maybe it's too much system now.” And like, “Ugh, I'm getting turned off. I liked making pretty stuff. And it's a whole new job if you're doing design ops,” or whatever. So…

Drew: I like the fact that VisBug takes an approach of not being another DevTools panel, because the interface, it embeds a toolbar on top of your page just like a design toolbar. I guess that was a deliberate move to make it more familiar to people who are familiar with design tools.

Adam: Yep. If you've used Paint or Photoshop, they all come that way. And so it was the sort universal thing, that if I put a toolbar on the left that floated over your content, almost everyone's going to be like, “Well I'll go hover on these and see what my options are. And here's my tools. And I get to go play.” And it made a really nice, seamless interaction there. I do have a really exciting almost finished enhancement to this.

Adam: So, it's so cool to me, but I don't know if everyone else is going to be as excited. And this'll be a mode that you can change in your extension settings, is how do you want to overlay the page? Because right now VisBug puts a toolbar right on the browser page, which the page is rendered normal, and I know this is going to be weird to say that, but okay, so you scroll the page, and the content, and the body is width to width in the browser, right? So it's filling the little viewport.

Adam: Eu tenho um mod onde, quando você inicia o VisBug, ele pega todo o documento HTML e o reduz em uma prancheta. Parece uma prancheta. Está flutuando em uma sombra em um espaço cinza. Você pode girar infinitamente em torno dele. Então você pode rolar para fora da tela da página, e o que ela permite é, veja, digamos que você tenha uma página muito longa e queira medir algo de cima para baixo, bem, você pode fazer isso agora , mas você meio que perde o contexto à medida que avança.

Adam: Bem, neste novo cenário de zoom do VisBug, você segura a opção ou alt no teclado, usa a roda do mouse ou pressiona mais menos com seu comando e pode ampliar sua página da web como se fosse uma prancheta. E eu tento torná-lo tão perfeito quanto é. Então você entra e sai, e você rola para baixo, você entra e sai, mede a partir do... E o VisBug simplesmente não se importa. Ele continua desenhando sobreposições computadas, você pode alterar o espaçamento.

Adam: Porque eu acho que é muito importante, como designer, ver o olho do pássaro de sua página ao vivo. As animações ainda estão tocando, pessoal. As áreas roláveis ​​ainda são roláveis, certo? É muito legal. Você fica tipo, “Minha página inteira em uma visualização”. De qualquer forma, está quase pronto. Está dentro-

Drew: Parece estranho.

Adam: É muito trippy. E está dentro, eu só preciso ter certeza de que funciona em vários navegadores, porque está fazendo algumas, obviamente, algumas coisas complicadas para fazer sua página ao vivo parecer assim. Mas sim.

Drew: Incrível. É... Quer dizer, presumo que o VisBug seja atualizado regularmente e esteja progredindo. O que podemos esperar ver no futuro?

Adam: Sim, esse é definitivamente um dos recursos em que estou trabalhando lá. Eu tenho um recurso onde… Então, quando você clica em algo, você obtém uma sobreposição com o que parece ser alças, certo? E é meio que uma ilusão, é para fazer você se sentir confortável. E a intenção é eventualmente fazer com que essas alças sejam arrastáveis. Mas tenho algumas coisas fundamentais que preciso resolver primeiro, como elementos no navegador não têm largura. Então, se você começar a pegar a largura, eu tenho que trabalhar para fazer essa ilusão parecer certa.

Adam: E você pode até não obter os resultados desejados, porque pode ser um elemento de nível de bloco que você está diminuindo a largura e não está obtendo o refluxo de um item próximo a ele. E você deve estar se perguntando o porquê. Então eu tenho protótipos onde você pode arrastar cantos, arrastar elementos. Mas eu realmente preciso me concentrar em como as ferramentas de design estão fazendo isso. Eles sempre têm esse botão de alternância. E é como... Veja, como se chama o botão?

Adam: Mas é basicamente como encolher... Eu chamo de filme plástico. Shrink wrap meu elemento, é a largura deste elemento é a largura de seu conteúdo, versus aqui está a largura do meu elemento, coloque algo nele. Então eu preciso de algo assim no navegador, sobreposto no elemento para que você possa escolher entre eles e talvez até algo que permita escolher entre bloco e inline, para que você possa obter os resultados desejados.

Adam: Mas, em última análise, o objetivo aqui é que o VisBug não quer ser totalmente controlado por teclado. Eu quero que você seja capaz de arrastar o espaçamento. Se você vir um espaçamento de 12 margens na parte superior, poderá alcançá-lo e agarrá-lo, enquanto agora você precisa pressionar o teclado para especificar que o lado superior da caixa precisa de uma margem adicional.

Adam: E então sim, eu tenho algumas peculiaridades para resolver, em termos de estratégia. Mas é muito mais um objetivo torná-lo ainda mais próximo das ferramentas de design. E talvez até eu me dobre nisso. É como, bem, se você quiser alterar a largura e obter um design estranho, sempre há maneiras de sair disso com o VisBug, como a ferramenta de posição realmente permite que você escape do fluxo. Portanto, o fluxo está arruinando sua ideia, a ferramenta de posição permite que você escape.

Adam: E então há... Se alguém fosse realmente experiente com o VisBug, eles iriam surpreender as pessoas, porque é meio que ilimitado, e é tipo, o que você pode trazer para a mesa? Tem um elemento de expressão para ele. Há definitivamente táticas expressivas. Mas de qualquer forma, para encurtar a história, a ilusão é que eu só quero torná-lo menor e menor e menor. Eu quero que a ilusão seja como, “Uau, estou realmente me sentindo como uma ferramenta de design”.

Adam: E então, sim, algumas melhorias na exportação seriam boas. Mas também, o aprimoramento da exportação para DevTools seria bom, e isso não nos impede de verdade. Então eu não sei. Há uma tonelada de problemas, definitivamente vá votar neles. Acho que um dos próximos grandes recursos que eu adoraria fazer são as linhas verdes. Então, em vez de apenas mostrar sobreposições de acessibilidade ao passar o mouse para realmente indicar algumas coisas com linhas verdes, expor mais e exibir mais informações, e eu não sei. Sim.

Drew: Pensando sobre o processo de construção de uma extensão do Chrome como esta, quero dizer, presumindo que tudo seja implementado em JavaScript, quão parecido com o desenvolvimento regular da web é? Construindo uma extensão do Chrome.

Adam: Essa é uma boa pergunta. É… Ufa, essa é difícil. É peculiar. Primeiro, o ambiente no qual você inicia seu código não é o navegador. Eles realmente não lhe dão acesso total lá. Você pode, se realmente for complicado com isso, no qual o VisBug teve que se formar, esse cenário ainda mais complicado. Então, agora, eu costumava executar no… Isso vai ficar tão confuso tão rápido.

Adam: Porque há vários sandboxes para sua extensão, por questões de privacidade. E eles dificultam a execução de scripts na página real, certo? Porque você não quer que alguém envie seu formulário quando você lançar a coisa ou algo assim, enviando para si mesmo ou qualquer outra coisa. Pode ser realmente destrutivo. Então tem algumas peculiaridades assim. Há uma ponte que você tem que passar. E um deles que tem atormentado o VisBug é, o VisBug costumava usar…

Adam: Então são todos os elementos personalizados, e os elementos personalizados permitem que você passe dados avançados para eles como propriedade. Então você está dizendo como, customelement.foo=myrichobject, cheio de arrays ou qualquer outra coisa. E o elemento personalizado obtém isso como alguns dados no próprio nó. Mas como estou neste pequeno mundo de sandbox estranho, se eu tentar definir algo único assim no meu objeto, essencialmente ele será filtrado. Eles estabeleceram que certas coisas não podem… Então eu posso passar uma string para meu elemento customizado, mas não posso passar um objeto rico.

Adam: Mas sim, além de pequenas peculiaridades como essa, uma vez que você reduz o fluxo, e se você gasta o tempo para obter um cenário de rollup, que será uma hora ou mais de trabalho para que você dê LiveReload em sua coisa , pode tornar-se bastante natural. Eu acho que o Firefox tem, honestamente, a melhor experiência de desenvolvimento de extensão, se você é experiente com a CLI, você pode criar algo com um comando e ele o instala, fornece esses recursos do LiveReload e fornece ferramentas de depuração. Ele meio que segura sua mão através dele, pode ser muito bom.

Adam: Mas no final das contas, é um pouco peculiar. É por isso que faço muito do trabalho naquele site de demonstração que parece um monte de pranchetas, porque na maioria das vezes não preciso de uma página da Web real para fazer o teste do VisBug, desde que tenha pranchetas que simular vários problemas, ou ter coisas acessíveis para ver, e me fornecer o conteúdo que preciso ver. Eu faço muito do trabalho ali mesmo no navegador como se fosse apenas uma aplicação web normal. Portanto, a experiência de desenvolvimento do VisBug é realmente fácil, a menos que você esteja tentando testá-lo no navegador e, em seguida, fica meio confuso e tudo mais.

Drew: São insights realmente interessantes. Então eu tenho aprendido tudo sobre o VisBug hoje, o que você tem aprendido ultimamente, Adam?

Adam: Ainda estou melhorando minhas habilidades no wok. Então eu quero ser um wok man, e não estou falando do toca-fitas dos anos 90. Eu quero virar vegetais e fazê-los pegar fogo um pouco no ar, cobri-los com alguns temperos deliciosos, e simplesmente queimar o alho e torná-lo crocante e delicioso. E então coloque-o em uma pequena cama de arroz e deslize-o em sua direção e veja o que você acha.

Adam: Então, estou animado para o verão agora, porque isso significa que eu posso sacar a wok e voltar para aquele ambiente de cozinha quente e acelerado, e é muito divertido.

Drew: Incrível. Isso soa delicioso. Se você, caro ouvinte, gostaria de ouvir mais de Adam, você pode segui-lo no Twitter, onde ele é @argyleinc, e encontrar seu site pessoal em nerdy.dev. Se você quiser experimentar o VisBug, pode encontrá-lo na Chrome Web Store e experimentar a versão sandbox em visbug.web.app. Obrigado por se juntar a nós hoje Adam. Você teve alguma palavra de despedida.

Adam: Não, você foi muito legal. Isso foi realmente doce. Obrigado por me receber, eu realmente aprecio isso.