Construindo meu blog, parte 2: a experiência de quem lê

Nota editorial: Esta série registra a construção inicial do blog em Hugo, separado do portfólio. A versão unificada do site reúne os dois em figueirego.com, com o blog em /blog/ (inglês) e /pt/blog/ (português). A navegação e as capturas abaixo documentam aquela etapa inicial.

Um leitor chega para encontrar um texto. Talvez lembre do assunto, talvez queira ver o que publiquei por último, talvez tenha recebido um link. A organização do blog precisa atender esses caminhos sem exigir que ele entenda como eu organizo meus arquivos.

Essa foi a parte mais iterativa da construção. Eu queria a simplicidade da base apresentada pelo Akita, com a identidade do meu site e uma experiência própria. Cores e fontes foram o começo; as decisões mais importantes apareceram na navegação, na busca e nos comentários.

Na primeira parte, explico a arquitetura. Aqui, o foco é o que acontece depois que a página abre.

A identidade precisava continuar sendo figueirego

Usei os SVGs da marca já presentes no meu site, com versões para fundos claros e escuros. Isso preserva o desenho da logo. Para títulos, interface e texto, mantive Manrope; para código, JetBrains Mono. Os arquivos das fontes são servidos pelo próprio blog.

O verde-petróleo marca links e ações no tema claro. No escuro, o destaque fica mais claro, próximo do turquesa, para continuar visível sobre o fundo. O conteúdo usa superfícies discretas, divisores e espaço entre blocos.

O cabeçalho recebeu o efeito de vidro que eu também queria no site: fundo translúcido, desfoque e uma borda leve. Há uma alternativa sólida para navegadores sem suporte e para quem prefere reduzir transparências. O efeito acompanha a leitura; não deve dificultá-la.

Quatro caminhos na barra superior

A organização passou por versões com Artigos, Notas e Experimentos no topo. Conforme surgiram Respostas e Transcrições, ficou claro que colocar cada formato na barra aumentaria a disputa por espaço, especialmente no celular.

Na versão independente descrita aqui, a navegação final ficou assim:

• Recentes: todas as publicações, da mais nova para a mais antiga.
• Arquivo: o conjunto completo, com filtros para encontrar um texto específico.
• Sobre: minha apresentação e os links para me encontrar.
• Meu site: acesso ao figueirego.com, na versão correspondente ao idioma atual.

Os links externos abrem em outra aba. Dentro do blog, a navegação continua na mesma. No celular, o cabeçalho reorganiza os controles e a navegação em linhas, preservando áreas de toque e rótulos acessíveis.

Formato e tema respondem perguntas diferentes

Um artigo sobre Go pode compartilhar assunto com um experimento e com uma resposta a alguém. Por isso, mantive os formatos separados dos temas:

Os temas são as tags: engenharia de software, aprendizado, Go e outros assuntos que aparecerem nas publicações. Um texto pode ter mais de um tema sem precisar existir em várias cópias.

No Arquivo, o leitor combina formato, ano, tema e busca textual. Os filtros ficam no endereço, permitindo compartilhar aquela seleção e usar voltar ou avançar. Sem JavaScript, a lista completa continua disponível. As contagens dos temas vêm do conteúdo publicado; não preenchi a interface com números de demonstração.

Imagens ajudam quando têm uma função

Gostei da ideia de mostrar capas nas publicações. Elas ajudam a identificar um texto e podem antecipar um conceito, como um fluxo ou uma arquitetura. Decidi mantê-las opcionais: uma nota curta pode funcionar perfeitamente só com título e texto.

A publicação mais recente recebe mais espaço na home. As demais seguem com título, resumo e metadados, acompanhados de miniatura quando existe capa. Na página do artigo, a imagem aparece inteira, com texto alternativo e legenda quando informados.

Também registro suas dimensões para reservar espaço antes do carregamento. Para explicar esta construção, escolhi capturas reais do processo. A capa desta parte mostra o Arquivo na prévia local, já com os artigos desta série. A legenda identifica o ambiente: uma tela local ajuda a mostrar a interface, mas não comprova que aquela versão já foi publicada.

Buscar precisa encontrar o que está no texto

Durante as revisões, a busca virou um ponto de atenção: o botão precisava ter presença suficiente, abrir corretamente e permitir encontrar conteúdo além do título. Um controle bonito que trava interrompe o caminho do leitor.

A implementação usa FlexSearch no navegador, com um índice do idioma atual. Ela considera título, descrição, resumo, tags e texto completo. A normalização de acentos permite procurar publicacao e encontrar conteúdo com “publicação”. O botão e os atalhos Ctrl+K ou ⌘K abrem o diálogo.

Há duas buscas com objetivos diferentes. O campo do Arquivo filtra sua lista por título, resumo e temas. A busca do cabeçalho procura também dentro dos textos. Se alguém lembra de um trecho sobre translationKey, pode usar a segunda para encontrar este artigo.

A busca local acompanha o conteúdo gerado pelo Hugo. Isso exige JavaScript no navegador, mas dispensa um servidor de busca próprio.

Busca na prévia local por translationKey, antes da publicação da série.

Dois idiomas, uma publicação relacionada

Naquela versão, o inglês ocupava a raiz de blog.figueirego.com; o português ficava em /pt/ no mesmo subdomínio. Cada versão tem seu próprio Markdown. O seletor leva à tradução correspondente quando ela existe; ele não traduz o texto ao ser acionado.

A ligação entre as versões deste artigo é explícita:

translationKey: building-blog-reading

Os dois arquivos usam essa mesma chave, embora tenham títulos e endereços diferentes. Isso permite revisar a tradução como texto de verdade. Também significa que uma correção editorial precisa ser considerada nos dois idiomas.

O idioma não determina a aparência. Por padrão, o tema acompanha o sistema; um clique alterna entre claro e escuro e salva a preferência naquele navegador. As transições dos ícones respeitam a preferência por movimento reduzido.

Uma conversa para as duas versões

No teste inicial, trocar de idioma podia levar a uma conversa diferente. Para o mesmo artigo, eu preferi reunir os comentários: quem lê em inglês e quem lê em português participa da mesma discussão.

O Disqus usa uma identidade compartilhada entre as traduções, baseada na translationKey. Sua interface acompanha o idioma da página. O texto que cada pessoa escreveu permanece no idioma original.

Os comentários carregam automaticamente nas publicações elegíveis em produção. Se o carregamento falhar, há uma opção para tentar novamente. A prévia local não abre as discussões reais.

O tema exigiu um cuidado adicional. O editor do Disqus está dentro de um iframe de outro domínio. Depois que o leitor interage com ele, o blog preserva o componente ao trocar de tema, pois pode existir um comentário ainda não enviado. Nesse caso, oferece uma atualização manual. Vale enviar ou copiar o texto antes de usá-la.

É uma integração externa, com suas próprias opções de moderação, aparência e anúncios no plano escolhido. Ter um blog estático não elimina essas dependências; apenas evita que eu mantenha um backend de comentários.

Acompanhar sem acrescentar outra tarefa

Mantive o RSS no rodapé, com uma página que explica o recurso e permite copiar o endereço do feed. Os cinco formatos publicados entram no RSS do respectivo idioma. Quem usa um leitor de feeds pode acompanhar as novidades por ali.

A newsletter ficou de fora por enquanto. Já os Mais lidos dependem de dados reais e serão explicados na terceira parte, sobre publicação e operação.

Para experimentar a organização, abra o Arquivo e selecione o tema engenharia de software. Depois, procure translationKey no botão de busca e troque o idioma deste artigo. Esses caminhos são um teste mais útil da interface do que olhar apenas para uma captura da home.

Série Construindo meu blog: 1. Arquitetura · 2. Experiência de leitura · 3. Publicação e operação.