Um cartão de busca com efeito de vidro real, renderizado sem motor web

A busca é um recurso usado com frequência em editores. Mas, como funcionava bem, passamos muito tempo sem mexer nela.

A janela de busca do mote também era assim. Ela sempre ocupava duas linhas e, mesmo quando era aberta depois de selecionar uma palavra no documento, o campo de busca ficava vazio.

Três aplicativos estavam dando a mesma resposta

Antes de fazer as alterações, abrimos a busca e substituição no mesmo documento no Typora, no MarkText e no Obsidian e fizemos capturas de tela. Conferimos o Notion por meio da documentação pública de ajuda. Quando reunimos tudo em uma tabela, os pontos em comum ficaram claros.

A busca começava em uma única linha. A substituição só era expandida quando necessária. A palavra selecionada entrava imediatamente no campo de busca. Na maioria deles, a contagem de correspondências também ficava dentro do campo de entrada, e era possível navegar entre as correspondências usando setas.

Decidimos que o mote também seguiria esse fluxo.

Reduzimos a tela padrão a uma linha. A substituição pode ser aberta pelo botão à esquerda ou com Ctrl+H. Se o texto selecionado estiver em uma única linha e tiver até 200 caracteres, ele será inserido automaticamente como termo de busca.

Quando não há resultados correspondentes, mostramos “Nenhum resultado” em vez do número 0. O campo de entrada também ganha uma borda vermelha. Assim, é possível verificar imediatamente se houve um erro de digitação ou se o termo realmente não existe no documento.

Foi apenas uma linha a menos, mas uma parte maior do texto passou a ficar visível. Também diminuiu a frequência com que o primeiro resultado da busca ficava escondido atrás do cartão.

Usamos a busca com muito mais frequência do que a substituição. Se um recurso usado apenas ocasionalmente fica sempre expandido, acabamos pagando esse custo toda vez que realizamos uma tarefa frequente.

Não mudamos tudo para ficar igual aos outros editores. Mantivemos o cartão flutuante no canto superior direito e o botão de opções. Não analisamos outros produtos para copiá-los. Fizemos isso para distinguir os padrões familiares das escolhas próprias do mote.

O texto sob o cartão realmente fica desfocado

O cartão de busca parece vidro. Não é apenas um efeito. O conteúdo que fica sob o cartão é realmente desenhado com desfoque.

No início, decidimos remover completamente o efeito de desfoque no Linux. O renderizador do GTK não tem um recurso para amostrar a superfície que fica atrás de widgets irmãos. Além disso, como o fundo muda sempre que o documento é rolado, seria necessário recalculá-lo a cada quadro. Julgamos que uma tela rápida era mais importante do que uma tela bonita.

A solução foi fazer com que o próprio editor desenhasse a tela desfocada, em vez de desfocar o cartão.

Ao desenhar o documento, o editor desenha mais uma vez apenas a parte coberta pelo cartão. Na segunda vez, aplica um desfoque de 18 px, e o cartão apenas adiciona uma leve tonalidade sobre ela.

As únicas linhas redesenhadas são aquelas realmente visíveis sob o cartão, e esse trabalho acontece dentro de um quadro que já seria renderizado de qualquer forma. O número de quadros agendados durante o estado ocioso continua sendo 0.

O cabeçalho funciona da mesma maneira. Quando o documento é rolado, o título passa por baixo do cabeçalho e fica naturalmente desfocado. Como a imagem nítida e a imagem desfocada são desenhadas no mesmo instante, elas não ficam desalinhadas.

Na borda do vidro, colocamos um contorno de 1 px em vez de uma sombra. Isso porque era difícil distinguir as bordas apenas pela sombra sobre um documento branco. Também deixamos uma margem de 24 px entre o cartão e o lado direito da janela para que a sombra pudesse aparecer.

Não adicionamos uma animação de entrada. Quem pressiona Ctrl+F já tem algo para procurar. Até uma breve animação se transforma em espera nesse momento. O cartão abre assim que o comando é acionado e já parece vidro desde a primeira tela.

Também voltamos a encontrar resultados de busca que passavam despercebidos

Depois de reduzir a interface, percebemos que havia lugares onde os resultados da busca não eram exibidos corretamente.

Os resultados dentro de tabelas não eram coloridos. No modo de leitura, a posição do destaque ficava desalinhada. Em código inline e dentro de marca-textos, a cor de fundo existente cobria a indicação da busca.

Cada problema tinha uma causa diferente.

Dentro das tabelas, era necessário calcular separadamente a posição em cada célula. No modo de leitura, era preciso reajustar a posição dos símbolos ocultos. Em textos com cor de fundo, a indicação da busca precisava ser desenhada primeiro.

Corrigimos a forma de calcular as posições e a ordem em que as cores eram desenhadas, resolvendo os três problemas.

Os resultados da busca são destacados em amarelo. Apenas o resultado visualizado no momento aparece em laranja. Usamos as mesmas cores na tela, no PDF e no HTML.

Não alteramos a cor do texto. Afinal, o marca-texto não pinta sobre as letras, mas deposita uma cor entre o papel e as letras.

O vidro tem um custo

Quando o documento é rolado com o cartão de busca aberto, o efeito de desfoque é recalculado para cada tela. Apenas a parte sob o cartão é redesenhada, mas isso não significa que o custo desapareça.

Por isso, não empilhamos várias camadas de vidro. Nós o usamos apenas no cabeçalho, na barra lateral e em um único cartão aberto no momento.

O vidro não é um material decorativo, mas um orçamento que precisa ser distribuído dentro dos limites de desempenho.

Deixar a janela de busca mais bonita e deixá-la mais leve pareciam objetivos opostos. Mas, no fim, restou apenas uma pergunta.

Quando esta tela precisa ser redesenhada?