"Parece igual pra mim"

Me propus a redesenhar a UI do blog-manager. Uma passada anterior tinha tirado os estilos inline para Tailwind e ViewComponents, mas foi um refactor: mesmo visual, mesmos bugs. As tabelas saíam pela borda direita, o espaçamento estava solto, e o painel de syndication por post era uma pilha confusa de status e ações. Eu queria corrigir o design de verdade e incluir um seletor de blog para o caso multi-blog.

A coisa que eu fiz certo, antes de escrever qualquer código, foi dividir isso em quatro fases pequenas e combinar de olhar um screenshot renderizado depois de cada uma. A coisa que eu errei aconteceu mesmo assim. Isso é principalmente sobre isso.

Fase 1, a vitória fácil

A página de detalhe do post tinha uma coluna alinhada à direita que misturava tudo: “Medium, Publicado”, “Dev.to, Rascunho”, “Rascunho parado no Postiz”, “Postiz, Agendado”, alguns links, e uma ação “Compartilhar nas redes”. Não dava para distinguir um status de um botão. Substituí por uma única seção de syndication: uma linha por destino, organizada como nome, pílula de status, uma ação principal. Medium, Dev.to, Social, cada um consistente.

Renderizei isso com um navegador de verdade (cuprite rodando Chrome headless) e tirei um screenshot na largura real do conteúdo. Ficou limpo. Aprovado de primeira. Fiquei confortável.

Fase 2, onde eu parei de prestar atenção

A lista de posts. A reclamação foi específica: “problemas de espaçamento/padding”, mais datas quebrando em duas linhas e uma coluna “Not imported” que dizia “Not imported” em praticamente toda linha. Corrigi a quebra (whitespace-nowrap nas células de data), troquei a coluna de Medium de baixo sinal por um indicador de syndication compacto, e deixei a página usar a largura inteira da janela em vez de ficar presa numa coluna de 820px. Testes verdes. Lancei um screenshot.

A resposta: “parece igual pra mim.”

Alarguei o container mais um pouco e tentei de novo. “igual só que mais largo…”

Essa segunda resposta é o post inteiro. Não é insatisfação vaga, é um bug report preciso. Eu tinha mudado a largura do container e o conteúdo das colunas. Não tinha mudado uma única coisa sobre a densidade das linhas. O padding de célula do .data-table continuava 12px, as linhas continuavam altas, os metadados continuavam flutuando no meio vertical de cada linha. A única palavra usada, “espaçamento,” era a única propriedade que eu nunca tinha tocado. Eu tinha corrigido tudo ao redor da reclamação e nada nela.

O que piorou é que minhas próprias verificações tinham passado. “Coluna visível? Sim. Sem quebra de linha? Sim. Testes verdes? Sim.” Nenhuma delas checa “o espaçamento de fato mudou.” Então lancei um diff que comprovadamente não atendia o report, e fiz isso com confiança.

A correção, quando finalmente mirei nela de verdade: as linhas eram altas porque toda linha carregava uma linha de descrição embaixo do título, dobrando a altura dela. Movi a descrição para um tooltip de hover (já está na página de detalhe de qualquer jeito) e deixei as linhas de uma linha só. Mesmos dados, linhas cerca de 40% mais curtas. Coloquei o “antes” solto e o “depois” denso lado a lado para que a diferença fosse inegável dessa vez. Depois, separadamente, o cabeçalho da tabela ainda parecia labels planos apertados contra a borda de cima do card, então ganhou uma faixa com base: um fundo no tom da página e padding de verdade. Esse ganhou uma revisão mais direta, “o cabeçalho ainda parece assim,” o que, justo.

Fases 3 e 4

O seletor de blog foi a parte mais tranquila. Um controle estilo workspace no topo da sidebar, persistido na sessão, que restringe a lista de posts e o dashboard. Um link com ?blog_id= ainda tem prioridade e persiste no seletor, então URLs salvas nos favoritos mantêm seu escopo, e um blog deletado cai de volta para “todos os blogs.” É um elemento <details>, então o dropdown não precisa de JavaScript nenhum.

A Fase 4 foi o tipo de trabalho chato e satisfatório: puxar o card de seção de formulário repetido e os quatro blocos de flash feitos à mão para dentro de componentes, espalhar o header de página por tudo, e passar a tabela de blogs pelo mesmo componente de tabela que a lista de posts já usa. A tabela de blogs de sete colunas era a reclamação original de “sai pela borda” na issue, e finalmente parou de cortar quando ganhou o container mais largo e um fallback de scroll horizontal.

O que eu tirei disso

Corrija exatamente a coisa nomeada. Quando alguém diz “espaçamento,” mudar largura e conteúdo de coluna não é uma resposta, mesmo que essas coisas também valessem a pena. A palavra nomeada é o alvo.

Autoverificações precisam testar a reclamação, não fatos adjacentes. “Os testes passam” e “a coluna está visível” não diziam nada sobre densidade. Se o report é sobre espaçamento, a verificação precisa ser um antes/depois do espaçamento. Para trabalho visual isso significa realmente renderizar e olhar, não afirmar num teste unitário.

Fasear trabalho subjetivo vale a pena. Quatro PRs pequenos com um checkpoint de screenshot cada um fizeram o erro de “parece igual” custar uma iteração, não uma revelação gigante que precisaria ser desfeita. O revisor é o árbitro de “isso parece melhor,” e a única forma de aproveitar isso bem é mostrar a ele a coisa renderizada cedo e sempre.

O próximo é dark mode, que eu adiei pra própria issue. O design já roda em cima de custom properties do CSS, então é principalmente um segundo conjunto de tokens em vez de mexer em cada componente, mas isso é outro post.