• Meio piano de costelinhas de porco
• Um osso de perna de vaca com tutano e alguma carne
• Um chouriço
• Um naco (~ 3x3x1 cm ) de unto galego

https://orgulhogalego.org

• um outline
  • com vários níveis
  • este é o segundo
    • e pode haver um terceiro
      • ou até um quarto
      • com muitos filhos
      • e filhas
  • de volta ao nível 2.

Fica aqui como referência permanente. Quando se adiciona um novo elemento ao sistema, testa-se aqui primeiro.

Cabeçalhos

Os cabeçalhos estabelecem hierarquia. O h1 é o título da nota e não aparece no corpo. Aqui começa no h2.

Nível 3

Usado para subsecções dentro de uma secção principal.

Nível 4

A partir daqui, o estilo muda: caixa alta, espaçamento de letras, mesmo tamanho que o corpo. Sinal de aviso tipográfico.

Nível 5

Raramente justificável. Se chegares aqui, questiona a estrutura.

Nível 6

O fundo do poço hierárquico. Usa-o e questiona-te.

Texto e formatação inline

Parágrafo normal, com espaçamento vertical entre parágrafos sucessivos. O corpo de texto usa a escala fluida definida nos tokens — cresce ligeiramente entre viewport estreita e larga, sem saltos.

Segundo parágrafo, para verificar o espaçamento. Negrito para ênfase forte. Itálico para ênfase suave, títulos de obras, ou termos estrangeiros. Negrito e itálico em simultâneo, usado com parcimónia. código inline dentro de uma frase, para referir identificadores, comandos, ou valores.

Texto com riscado, para conteúdo revogado ou corrigido que convém manter visível.

Texto com destaque, equivalente ao marca-texto. Texto com eliminado e inserido para rastreabilidade de alterações. Referências com CSS onde a expansão acrescenta valor.

Expoentes: E = mc². Índices: H₂O. Combinados: CO₂ a 400 ppm é já ^{[citação necessária]}.

Atalhos de teclado: pressiona ⌘ + K para abrir o palete de comandos. Ou Ctrl + Shift + P no Windows.

Listas

Lista não ordenada simples

• Primeiro item
• Segundo item
• Terceiro item

Lista com vários níveis

• Primeiro nível
  • Segundo nível
  • Outro item no segundo nível
    • Terceiro nível
      • Quarto nível — aqui o outline colapsa por defeito
      • Mais um no quarto
    • De volta ao terceiro
  • De volta ao segundo
• De volta ao primeiro

Lista ordenada

1. Abre o terminal
2. Navega para o directório do projecto
3. Corre npm run build
4. Verifica o output em _site/
5. Faz deploy se tudo estiver bem

Lista ordenada com sublista mista

1. Escolhe uma abordagem
   • Abordagem A: rápida, frágil
   • Abordagem B: lenta, robusta
2. Implementa com testes
3. Documenta as decisões

Lista de definições (HTML em Markdown)

Design system

Um conjunto de decisões documentadas, componentes reutilizáveis, e princípios que tornam o design consistente à escala.

Token

Um valor nomeado que representa uma decisão de design — cor, espaçamento, tipografia — independente da sua implementação concreta.

Grelha

A estrutura invisível que torna a disposição de elementos previsível e audível.

Lista de tarefas

• Definir a paleta de cores
• Estabelecer a escala tipográfica
• Criar os tokens CSS
• Documentar os padrões de composição
• Publicar o guia de estilo
• Verificar acessibilidade em todos os componentes

Citações

Uma citação simples:

O que não está documentado não existe. O que existe sem documentação é acidente.

Uma citação mais longa, com atribuição manual:

A tipografia tem uma função antes de ter uma forma. A legibilidade não é uma restrição — é o ponto de partida. Qualquer decisão que não serve o conteúdo serve apenas o designer.

— Emil Ruder, Typographie als Ausdruck, 1959

Citação aninhada:

Perguntaram-lhe o que era o design.

"É a intenção tornada visível", respondeu.

Ninguém ficou satisfeito com a resposta. Ele também não.

Código

Código inline

Usa const em vez de let quando o valor não muda. O selector .note-body aplica estilos de prosa. A propriedade --text-base é um token CSS.

Bloco de código — CSS

/* Escala tipográfica fluida */
:root {
  --text-sm:      clamp(0.875rem, 0.825rem + 0.25vw, 1rem);
  --text-base:    clamp(1rem,     0.95rem  + 0.25vw, 1.125rem);
  --text-lg:      clamp(1.25rem,  1.1rem   + 0.65vw, 1.625rem);
  --text-xl:      clamp(1.875rem, 1.5rem   + 1.5vw,  2.75rem);
  --text-display: clamp(3rem,     2.25rem  + 3vw,    5.5rem);
}

Bloco de código — JavaScript

// Wikilink resolver — transforma [[título]] em <a href="...">
function resolveWikilinks(content, pages) {
  const pageMap = new Map(
    pages
      .filter(p => p.data.title && p.page.url)
      .map(p => [p.data.title.toLowerCase(), p.page.url])
  );

  return content.replace(/\[\[([^\]]+)\]\]/g, (_, title) => {
    const url = pageMap.get(title.toLowerCase());
    return url ? `<a href="${url}">${title}</a>` : title;
  });
}

Bloco de código — HTML

<!DOCTYPE html>
<html lang="pt">
  <head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>tavar.es</title>
  </head>
  <body>
    <a href="#main" class="skip-link">Saltar para o conteúdo</a>
    <main id="main">
      <h1>Olá.</h1>
    </main>
  </body>
</html>

Bloco de código — Bash

# Build e verificação de acessibilidade
npm run build && npm run check:a11y

# Servir localmente com hot reload
npx @11ty/eleventy --serve --port=8080

Bloco de código — Python

def encode_email(email: str, key: int = 23) -> str:
    """XOR-encode an email address for obfuscation in HTML."""
    return "".join(
        format(ord(c) ^ key, "02x")
        for c in email
    )

Bloco de código — JSON

{
  "name": "tavar.es",
  "version": "1.0.0",
  "type": "module",
  "scripts": {
    "build": "eleventy",
    "start": "eleventy --serve"
  }
}

Bloco de código sem linguagem

Texto pré-formatado sem highlighting.
Útil para output de terminal, logs, ou conteúdo ASCII.

    ┌─────────────────────────────┐
    │  nome          tipo         │
    │  ──────────    ────────     │
    │  --text-sm     clamp()      │
    │  --text-base   clamp()      │
    └─────────────────────────────┘

Tabelas

Tabela simples

Tabela com múltiplas colunas e alinhamento

Tabela com alinhamento de colunas

Imagens

Imagem simples (sem legenda)

Imagem com legenda

Imagem com largura explícita

Ligações

Wikilink para outra nota

Esta nota relaciona-se com [[design como prática]] e com [[linguagem no design]].

Ligação externa explícita

Eleventy — documentação oficial

URL exposta (linkificada automaticamente)

https://www.w3.org/WAI/WCAG22/Understanding/

Ligação de email (obfuscada automaticamente no build)

Podes contactar-me em miguel@tavar.es.

Divisória horizontal

Uma regra horizontal dentro do corpo de uma nota tem estilo diferente da regra que separa secções de layout — é tracejada e mais fina.

Após a regra.

Notas de rodapé

O sistema de notas de rodapé^[1] é gerido pelo plugin markdown-it-footnote.^[2] As notas aparecem no fim da página, separadas do corpo por uma regra horizontal.^[3]

Pode-se referenciar a mesma nota várias vezes.^[1:1]

HTML em linha

Markdown permite HTML em linha quando nenhuma sintaxe Markdown cobre o caso.

Detalhes e sumário (disclosure widget)

Sup, sub, abbr, kbd, mark, del, ins

W3C define os padrões. O WCAG 2.2 é o nível mínimo de acessibilidade que este sítio cumpre.

Pressiona Tab para navegar entre elementos interactivos. Enter ou Espaço para activar. Escape para fechar diálogos.

O texto marcado a amarelo chama a atenção para partes específicas de uma citação ou listagem.

Versão 1.0 2.0 — a primeira foi removida, a segunda inserida.

E = mc². A fórmula da água é H₂O. Nota à margem^*.

Tabela com células mais ricas

Conteúdo misto — tudo junto

Uma secção que mistura tipos de conteúdo como acontece numa nota real.

Ao rever o sistema de design, identifiquei três categorias de problemas^[4]:

1. Tokens sem uso — valores definidos mas nunca referenciados em componentes. Acumulam-se com o tempo.
2. Componentes sem tokens — valores hardcoded em vez de variáveis. Difíceis de actualizar globalmente.
3. Inconsistências de escala — espaçamentos que não pertencem a nenhuma escala definida.

A correcção passa por um processo iterativo:

• Auditar o código existente (ver [[ferramentas que uso]] para a lista de ferramentas)
• Mapear cada valor para o token mais próximo
• Eliminar duplicados
• Documentar excepções justificadas

A disciplina não é a ausência de exceções. É saber exactamente onde e porquê existem.

O estado actual do sistema:

Os três espaçamentos e duas bordas sem token são excepções documentadas. Não são erros — são decisões.^[4:1]

Cosine similarity is a measure of similarity between two non-zero vectors of an inner product space that measures the cosine of the angle between them. The cosine of 0° is 1, and it is less than 1 for any angle in the interval ### (0,π] radians . It is thus a judgment of orientation and not magnitude: two vectors with the same orientation have a cosine similarity of 1, two vectors oriented at 90° relative to each other have a similarity of 0, and two vectors diametrically opposed have a similarity of -1, independent of their magnitude. The cosine similarity is particularly used in positive space, where the outcome is neatly bounded in [0,1]. The name derives from the term "direction cosine": in this case, unit vectors are maximally "similar" if they're parallel and maximally "dissimilar" if they're orthogonal (perpendicular). This is analogous to the cosine, which is unity (maximum value) when the segments subtend a zero angle and zero (uncorrelated) when the segments are perpendicular.

These bounds apply for any number of dimensions, and the cosine similarity is most commonly used in high-dimensional positive spaces. For example, in information retrieval and text mining , each term is notionally assigned a different dimension and a document is characterised by a vector where the value in each dimension corresponds to the number of times the term appears in the document. Cosine similarity then gives a useful measure of how similar two documents are likely to be in terms of their subject matter.

Há um argumento a fazer de que construir o próprio sítio web é, em si, um acto de design tão revelador como qualquer projeto para um cliente.

Aqui, não há brief. Não há utilizador a não ser eu próprio — e ao mesmo tempo, todos os que passarem por aqui. Não há prazo senão o da minha paciência. O que fica é o que eu consigo defender até ao fim.

Estou a pensar muito sobre [[design como prática]] ultimamente. O que significa trabalhar com intenção, sem a urgência artificial dos deadlines comerciais.

O que procuro numa ferramenta

Antes da lista, o critério:

• Faz uma coisa bem. Ferramentas que tentam fazer tudo raramente fazem algo com excelência.
• Sai do caminho. O melhor software é invisível durante o trabalho — só existe quando preciso dele.
• Tem uma filosofia. Isso revela-se no comportamento nos casos extremos, não nos casos normais.
• Exporta dados limpos. Nunca devo ficar refém de um formato proprietário.

O que uso agora

Desenho e prototipagem

Figma continua a ser o padrão. Não porque seja perfeita — tem problemas sérios de performance com ficheiros grandes — mas porque a colaboração em tempo real mudou fundamentalmente como trabalho com equipas de engenharia.

Pixelmator Pro para trabalho de imagem raster. É uma das aplicações macOS mais bem construídas que conheço.

Escrita e pensamento

Obsidian para notas, journaling e gestão de conhecimento. A decisão de guardar tudo em Markdown local foi das melhores que tomei. Este sítio está inteiramente escrito no Obsidian.

iA Writer para rascunhos longos. A ausência total de opções é a funcionalidade.

Desenvolvimento

Cursor com reservas. A assistência de IA é genuinamente útil; a tendência para gerar código que parece correto mas não é exige atenção constante.

Warp como terminal. O historial de comandos com pesquisa em linguagem natural é, sem exagero, transformador.

A ferramenta certa não é a mais poderosa. É a que te deixa pensar no problema em vez de pensar na ferramenta.

Vou atualizar esta lista quando algo mudar de forma significativa. O que uso dentro de seis meses será provavelmente diferente — e isso é bom sinal.

O argumento central era simples: a tipografia tem uma função antes de ter uma forma. A legibilidade não é uma restrição — é o ponto de partida.

A grelha como argumento

O sistema tipográfico suíço não era decoração. Era uma posição filosófica: a ordem serve o conteúdo, não o contrário. A grelha tornava explícitas as decisões que outros designers tomavam de forma intuitiva e inconsistente.

Há um paralelo direto com sistemas de design modernos. Um design system bem construído faz a mesma coisa: torna explícitas as decisões que de outra forma viveriam apenas na cabeça das pessoas.

O que não está documentado não existe. O que existe sem documentação é acidente.

Este princípio aplica-se diretamente a decisões tipográficas. Uma escala definida em código é uma decisão documentada — auditável, propagável, impossível de ignorar acidentalmente:

Um bloco de código em CSS

e como fica inline code no meio de uma prágrafo?

/* Escala tipográfica — tamanhos fluidos com clamp() */
:root {
  --text-sm:      clamp(0.875rem, 0.825rem + 0.25vw, 1rem);
  --text-base:    clamp(1rem,     0.95rem  + 0.25vw, 1.125rem);
  --text-lg:      clamp(1.25rem,  1.1rem   + 0.65vw, 1.625rem);
  --text-xl:      clamp(1.875rem, 1.5rem   + 1.5vw,  2.75rem);
  --text-display: clamp(3rem,     2.25rem  + 3vw,    5.5rem);

  /* Entrelinha */
  --leading-tight:  1.1;
  --leading-normal: 1.5;
  --leading-loose:  1.7;
}

O código acima é o deste sítio. Cada token é uma intenção expressa, não um número solto num ficheiro de design.

Comparação de abordagens tipográficas

Simplificando brutalmente, a diferença entre escola suíça e abordagens mais expressivas:

Nenhuma abordagem é superior em abstrato. A questão é sempre: o que o conteúdo exige?

O que isto tem a ver com interfaces

O problema do design de interfaces moderno não é falta de expressão — é falta de disciplina. Há demasiado movimento, demasiada cor, demasiada variação tipográfica a servir a vaidade do designer em vez do utilizador.

As melhores interfaces que conheço têm uma qualidade suíça: a sensação de que cada decisão foi tomada, não aconteceu.

Isso é o que continuo a tentar fazer.

"Submit" e "Enviar candidatura" fazem coisas diferentes ao utilizador, mesmo que a função técnica seja idêntica. O primeiro é neutro, técnico, diz o mecanismo. O segundo situa a pessoa no contexto do que está a acontecer.

Boa linguagem de interface:

• Fala do ponto de vista do utilizador, não do sistema
• Usa o tempo verbal do utilizador ("Os seus ficheiros foram guardados" vs. "Guardado")
• Evita jargão sem abandonar a precisão quando esta importa
• É consistente — o mesmo conceito tem sempre o mesmo nome

Ver também: [[design como prática]].

Ok

Uma imagem

Ver também: [[design como prática]].

A distinção importa porque implica que nunca se chega a um estado de ter design. Há sempre mais a ver, mais a questionar, mais a desaprender.

Algumas coisas que tenho aprendido a reconhecer na prática:

• A decisão mais importante raramente acontece no Figma
• A [[linguagem no design]] é design — palavras, hierarquia, tom
• Restrições são produtivas. A liberdade irrestrita paralisa
• O brief é sempre uma hipótese sobre o problema real

Esta nota está em progresso.

Uma profissão é o que aparece no contrato. Uma prática é o que acontece quando ninguém está a ver — as perguntas que fazes a ti próprio, os problemas que estudas sem serem pagos, a atenção que prestas às coisas que não têm utilidade imediata.

O que uma prática exige

Tentei escrever uma lista. Ficou assim:

1. Tempo não contabilizado. Não tempo "criativo" que podes justificar numa fatura — tempo genuinamente sem produto.
2. Tolerância para o trabalho sem audiência. Escrever notas que só tu vais ler. Fazer esboços que não levam a nenhum projeto.
3. Curiosidade sem agenda. Ler sobre [[design como prática]] não porque alguém pediu, mas porque não consegues parar de pensar nisso.
4. Uma posição. Não opiniões sobre ferramentas — isso é fácil. Uma posição sobre o que o design é e para que serve.

Sobre a posição

Não acredito que design seja resolução de problemas. Acredito que design é formulação de problemas. A resolução é consequência; a pergunta é o trabalho.

Esta distinção tem implicações práticas. Se o trabalho é formular a pergunta certa, então a maior parte do que se chama "processo de design" está a otimizar a coisa errada — a eficiência da resposta em vez da qualidade da pergunta.

O que tenho feito

Este sítio é parte da prática. Não é um portfólio — não foi construído para convencer ninguém de nada. É um lugar para pensar em público, com a lentidão que isso exige.

As [[notas]] que estou a escrever são outra parte. São pensamentos em progresso, não conclusões.

O trabalho para clientes é outra parte — a parte mais visível, mas não necessariamente a mais importante.

Não tenho uma conclusão. Isso também faz parte da prática.