A filosofia de design do Great Tables

(posit-dev.github.io)

3 pontos por GN⁺ 2024-04-05 | 1 comentários | Compartilhar no WhatsApp

Great Tables é um pacote para criação de tabelas que busca manter o fluxo de análise de dados dentro de código Python, ao mesmo tempo em que resgata a expressividade refinada das tabelas impressas de meados do século XX
Uma tabela não é apenas uma grade simples de linhas e colunas, mas um formato de representação de informação que facilita encontrar e comparar valores por meio da ordem das colunas, rótulos e linhas divisórias
Das tabuletas de argila da antiga Suméria ao Manual of Tabular Presentation, as tabelas evoluíram junto com a densidade de informação e a forma, mas as primeiras planilhas tinham pouca expressividade em comparação com sua praticidade para cálculos
O Great Tables divide a tabela em 6 componentes e separa estrutura, formatação e estilização com APIs das famílias tab_*, fmt_* e opt_*()
O pacote foca em elevar a qualidade de publicação e apresentação de tabelas-resumo estáticas usadas em artigos, livros e relatórios, em vez de exploração interativa de grandes volumes de dados

O dilema de criação de tabelas que o Great Tables quer resolver

As tabelas são importantes na etapa final de apresentação da informação, assim como os gráficos, e um bom design de tabelas exige mais sofisticação e nuance do que parece
Hoje, quem trabalha com dados normalmente precisa aceitar um compromisso entre duas opções
- copiar os dados para uma ferramenta como Excel e recriar a tabela ali
- exibir uma tabela sem refinamento do jeito que saiu
O Great Tables é um pacote que tenta resolver esse dilema com uma interface baseada em código Python
O objetivo é criar tabelas expressivas mantendo tudo dentro do Python, do processamento de dados à análise e à geração da tabela-resumo

Definição básica de tabela e elementos de legibilidade

Uma tabela pode ser resumida em duas regras básicas
- os dados são representados em colunas e linhas
- os dados são representados principalmente como texto
Na tabela de exemplo, as pessoas aparecem nas linhas, e características como nome, endereço, cidade, CEP, data de nascimento, altura e peso aparecem nas colunas
Essa disposição facilita encontrar valores específicos ou comparar informações percorrendo linhas e colunas
As linhas horizontais entre as linhas não são obrigatórias, mas ajudam a distinguir visualmente cada linha individual
A ordem das colunas também afeta diretamente a legibilidade
- se a coluna Name estiver na extrema direita, o assunto de cada registro não aparece de imediato, o que pode confundir mais o leitor
- os rótulos das colunas informam que tipo de dado há em cada coluna e, na maioria dos casos, reduzem a necessidade de adivinhação

A história das tabelas na Antiguidade

As tabelas começaram a partir da grade quadrada, um contêiner capaz de armazenar informação
Nas paredes das cavernas de Lascaux e Niaux, na França, há representações em grade de cerca de 25 mil anos atrás
No século II a.C., Hipparchus representou corpos celestes e posições terrestres com latitude e longitude, e por volta de 150 d.C. a Geographia de Ptolemy incluía métodos de cartografia com uso de grades
A centuriação romana era um sistema de medição de terras que formava grades quadradas por meio de estradas, canais e áreas agrícolas
Depois que a agricultura se disseminou amplamente, há cerca de 10 mil anos, cresceu a necessidade de registrar e administrar transações econômicas relacionadas à agricultura, ao gado e à divisão do trabalho

A estrutura tabular na Suméria e na Mesopotâmia

No 4º milênio a.C., cidades mesopotâmicas precisavam preservar registros enquanto comerciavam com reinos distantes, e tabuletas encontradas em Uruk mostram tabelas primitivas, mas sofisticadas
Tabuletas de Uruk por volta de 3200–3000 a.C. registram quantidades entregues de cevada e malte para produção de cerveja
- a estrutura é lida da direita para a esquerda
- cada célula contém pictogramas que representam palavras ou conceitos e números que representam quantidades
- cerca de duas linhas correspondem a cada pessoa
- as duas colunas à direita contêm quantidades de malte e cevada
- a terceira coluna mostra o subtotal por indivíduo, e a coluna mais à esquerda mostra o total geral
- a linha inferior traz o nome do administrador responsável, funcionando como um rodapé
Cerca de mil anos depois, uma tabuleta do templo de Enlil, em Nippur, registra fontes de receita e despesas mensais de 50 trabalhadores do templo
- há uma grade mais regular
- existem cabeçalhos de coluna na forma de nomes de meses e cabeçalhos de linha na forma de nomes de pessoas e ocupações
- aparecem células vazias para ausência de informação, valores numéricos, subtotais semestrais, totais e notas explicativas
Depois disso, o suporte das tabelas passou de argila para tabuletas enceradas, papiro e papel, e as técnicas de escrita e o design tabular também mudaram junto

O auge do design tabular em meados do século XX

Meados do século XX são tratados como um período especialmente forte para o design de tabelas
Tecnologias de produção documental como impressão offset, máquina de escrever e varitype já haviam evoluído o suficiente para compor elementos tabulares com precisão
Havia restrições de espaço na página, mas existiam várias soluções para ajustar uma tabela a uma página ou distribuí-la por várias páginas
A combinação entre técnicas de impressão avançadas e conhecimento de design tabular permitiu criar tabelas bonitas
O Manual of Tabular Presentation, do U.S. Census Bureau, é uma obra que trata em detalhe do projeto ideal de tabelas com alta densidade de informação
- nomeia e descreve com rigor as várias partes de uma tabela
- recomenda com firmeza o que fazer e o que evitar em diferentes situações de elaboração de tabelas
- mostra que uma tabela pode ser visualmente agradável e ainda conter muita informação
O Great Tables adota muitos dos princípios de design tabular desse documento e parte da premissa de que eles continuam válidos hoje

O retrocesso e os limites após as planilhas

À medida que a computação se tornou mais acessível nas décadas de 1970 e 1980, as pessoas passaram a poder criar tabelas tanto em formato eletrônico quanto impresso
A popularização das tabelas calculáveis pode ser considerada como tendo começado em 1979 com o VisiCalc
O VisiCalc permitia calcular valores rapidamente, mas tinha expressividade limitada para produzir tabelas de apresentação
- não permitia aplicar estilos de borda de apresentação às células da grade
- não permitia formatar valores
- não permitia imprimir a tabela
Nos 10 a 15 anos seguintes, as tabelas de planilha ficaram mais agradáveis visualmente
- no início dos anos 1990, o Excel já permitia aplicar bordas em tabelas
- o suporte tipográfico melhorou
- os recursos de formatação de valores também ficaram mais completos
Ainda assim, avalia-se que as tabelas do Excel dos últimos 30 anos tiveram dificuldade para alcançar o nível do Manual of Tabular Presentation
Como a análise de dados também passou a acontecer fora do Excel, surgiram três cenários ineficientes
- fazer análise e geração de tabela inteiramente no Python, mas com baixa qualidade tabular
- fazer análise e produção da tabela inteiramente no Excel, mas com pouca flexibilidade analítica
- analisar no Python e copiar para o Excel para montar a tabela, mas sem reprodutibilidade

O modelo de tabela do Great Tables

Great Tables é um pacote Python que busca combinar a elegância das tabelas de meados do século XX com o poder de interfaces baseadas em código
Ele representa uma tabela como a combinação de 6 componentes independentes
- Table Header: espaço para título e subtítulo que explicam de forma concisa o conteúdo da tabela
- Column Labels: definem o conteúdo de cada coluna, e o spanner é um título colocado sobre um grupo de várias colunas
- Stub Head: posição no canto superior esquerdo, onde diferentes tipos de rótulo podem ser colocados
- Row Stub: área para informação de linha e rótulos de grupos de linhas
- Table Body: região onde ficam os dados, incluindo as células
- Table Footer: espaço para informações adicionais relacionadas ao conteúdo da tabela
O Great Tables é usado criando primeiro o corpo da tabela em código e depois adicionando repetidamente estilização, formatação e outros componentes
O código de exemplo começa em GT(simple_table, rowname_col="Name") e adiciona título, stub head, column spanner, source note, formatação de datas e inteiros, além de opções de estilo
Na tabela de exemplo, o row stub azul separa os rótulos de linha do corpo da tabela
- como cada pessoa é uma observação única, isso destaca o sujeito de cada linha
- o título explica o conteúdo da tabela
- os spanners Location e Personal Characteristics agrupam colunas em conjuntos significativos
- o uso consistente de linhas azuis e fundo de células cria uma aparência profissional
Os métodos que adicionam componentes à tabela começam com tab_
- por exemplo: tab_header() cria o Table Header

Formatação e nanoplots

Apenas estruturar a tabela não é suficiente, porque cada área tem exigências próprias para exibir valores
Mesmo um único número pode ser apresentado de várias maneiras conforme as normas e expectativas de uma comunidade
Quando se incluem datas, horários e moedas, o escopo da formatação se amplia ainda mais
O valor bruto 134,000 pode ser exibido de formas diferentes conforme a necessidade
- fmt_scientific(): notação científica 1.34 × 10^5
- fmt_number(): número em localidade alemã 134.000,00
- fmt_integer(): inteiro compactado 134K
Quando valores precisam ser transmitidos por imagens ou gráficos, a questão da formatação se torna ainda maior
Se uma analista médica precisar mostrar a tendência de melhora ou piora nos resultados de exames de um paciente, ler toda a sequência numérica de uma linha pode retardar a interpretação
fmt_nanoplot() oferece pequenas visualizações de tendência dentro da tabela por meio de nanoplots
- ao passar o mouse sobre os pontos de dados, é possível ver o valor de cada data
- os nanoplots buscam equilibrar a rapidez de interpretação visual dos gráficos com a compacidade das tabelas
Os métodos de formatação do Great Tables começam com fmt_
- por exemplo: fmt_date(), fmt_integer(), fmt_nanoplot()
O pacote procura oferecer muitos métodos de formatação e opções úteis para atender às necessidades de diferentes usuários

Foco em tabelas-resumo estáticas para publicação e apresentação

O Great Tables foca na exibição para publicação e apresentação entre as várias formas de interação com tabelas
Em análise de banco de dados, uma exibição simples de tabela para explorar e filtrar centenas, milhares ou mais registros pode ser adequada
Publicar resultados é uma tarefa diferente, e aqui o centro está em estruturação, formatação e estilização
Uma bela exibição tabular deve atender aos seguintes pontos
- tornar a informação mais fácil de absorver
- fornecer contexto adicional onde necessário
- seguir o estilo do documento ou da organização
Os casos de uso visados são formas de apresentação de dados vistas em artigos acadêmicos, livros e relatórios
O Great Tables considera que as tabelas-resumo estáticas merecem um foco próprio e quer facilitar a entrega de tabelas melhores ao leitor com métodos opt_*()
O critério de sucesso do pacote é a qualidade das tabelas que ele consegue produzir, e há planos de continuar aprimorando a API
O projeto mantém aberto um Discord Server para feedback da comunidade

1 comentários

GN⁺ 2024-04-05

Opiniões no Hacker News

Great Tables vem fazendo um trabalho bem interessante na área de tabelas em Python/Jupyter e parece quase estar criando uma gramática de tabelas, no estilo da grammar of graphics
Seria bom se mais projetos explicassem sua filosofia e seus objetivos dessa forma
Eu criei outra biblioteca de tabelas para Jupyter, chamada Buckaroo, mas a abordagem é diferente
O objetivo do Buckaroo é permitir trabalhar de forma interativa, testando rapidamente vários formatos e funções de pós-processamento para obter insights importantes a partir das tabelas
Ao fazer análise exploratória de dados básica, acabamos digitando os mesmos comandos repetidamente, então achei que esses comandos e insights deveriam estar dentro da tabela
Great Tables parece estar mais voltado a formatar manualmente tabelas para apresentação
https://github.com/paddymul/buckaroo
https://youtu.be/GPl6_9n31NE
- Obrigado pelo trabalho no Buckaroo. O print() do Jupyter e o display() do IPython têm a limitação de serem saídas estáticas mortas, lembrando o antigo debugging com printf, e entendo que o Buckaroo foi criado para resolver isso
  Fico curioso para saber o que você acha dos atalhos e do modo de interação do Visidata
  Usei Visidata no passado e sempre me perguntei por que algo assim não poderia acabar dentro do Jupyter para exploração de dataframes
  Concordo que o Great Tables parece mais uma tentativa de formalizar uma gramática de tabelas; considerando o poder do formato tabular e a disseminação do conceito de dataframe pelos ecossistemas R/pandas/Arrow/polars, essa abordagem é bem-vinda
  Mas, pelo que sei, esse termo foi usado originalmente na linguagem estatística S, nos anos 90
  [1] https://towardsdatascience.com/preventing-the-death-of-the-d...
Os exemplos do Great Tables são complexos demais para o meu gosto. As linhas horizontais acima e abaixo do título parecem desnecessárias, e também não gosto do alinhamento com a primeira coluna, que contém os rótulos das linhas
Acho que um pouco de espaço em branco abaixo e uma fonte em negrito dariam hierarquia visual sem ruído
O fundo dos rótulos das linhas é escuro demais e a espessura da fonte dificulta a leitura; um azul bem claro seria melhor
Também não gosto de deixar o rótulo do grupo de linhas “Name” em itálico
O rótulo de coluna superior flutuando no centro dificulta percorrer a tabela visualmente; acho que alinhado à esquerda ficaria muito melhor
Por fim, também não gosto nada da fonte, embora isso talvez seja culpa do navegador
Fiz um mockup com algumas mudanças e acho que esta é uma tabela muito mais fácil de ler
https://i.imgur.com/iMMf5vo.png
- Recomendo ler Beautiful Evidence, de Edward Tufte
  O livro trata justamente do que você acabou de mencionar: legibilidade e elementos que atrapalham a mensagem ou o ponto central dos dados
  Se você já viu sparklines, Tufte também foi quem cunhou esse termo
  Sempre que faço uma revisão de UI, acabo folheando esse livro para ver se deixamos algo passar; é um livro interessante mesmo abrindo em qualquer página
  Além disso, há um longo ensaio sobre por que o PowerPoint é ruim
  [1] https://www.edwardtufte.com/tufte/books_be
  [2] https://en.wikipedia.org/wiki/Sparkline
- O título da tabela deve ficar centralizado no topo ou como legenda abaixo
  Se for alinhado à esquerda sobre alguma coluna, ele passa a parecer, de um modo geralmente falso ou não intencional, o nível mais alto da hierarquia de informações da tabela
  Na revisão modernista acima, o título diz “names, addresses, characteristics”, mas pelo alinhamento parece excluir os nomes, o que me incomodou imediatamente
  Em contraste, o manual do censo centraliza quase todos os rótulos dentro de suas respectivas caixas e, quando não faz isso, geralmente usa recuo
  Além disso, define a largura das colunas com base nos dados, não nos rótulos, e não hesita em ajustar recuos e hifenização
  O resultado é denso na horizontal, mas ainda intuitivamente compreensível
  Pensando melhor, o próprio título também não é bom
  Títulos e legendas devem transmitir contexto, escopo e finalidade; se não fazem isso, podem até ser omitidos por não justificarem a própria existência editorial
  O título atual poderia ser trocado por “Table 1” sem perda de informação nem de generalidade
  Para um texto que tenta discutir e reconstruir a apresentação de tabelas a partir de primeiros princípios, isso é um pouco decepcionante
  Como os títulos de tabelas formam uma camada importante do catálogo de informações, não surpreende que o manual do censo dedique um capítulo inteiro à composição de títulos
  Embora seja um pouco específico de domínio e tenha um estilo antiquado, vale muito a pena ver
- Não entendo por que não há elementos como linhas horizontais ou faixas alternadas para reforçar a sensação de que cada linha é um registro próprio
- Seu mockup é uma versão melhorada. O problema do exemplo do texto é que todos os caracteres e números dentro da tabela têm peso visual uniforme
- Acho que dá para levar isso ainda mais longe. O título pode ser reduzido para “remote correspondents”, já que o restante duplica os nomes das colunas
  O destaque em azul agora também é redundante com o título, então eu removeria tudo; e a separação entre “personal characteristics” e “location” não ajuda de forma significativa na organização, então também seria melhor removê-la
É um bom texto, com uma história interessante
Na história mais recente, há a criação das tabelas CALS: https://en.wikipedia.org/wiki/CALS_Table_Model
A Datalogics https://en.wikipedia.org/wiki/Datalogics esteve profundamente envolvida na concepção das tabelas CALS

Funcionários da Datalogics participaram do comitê ISO que criou o SGML e ensinaram SGML a muita gente, incluindo funcionários do Departamento de Defesa dos EUA e contratados envolvidos na documentação
Participei da equipe que criou um editor de documentos baseado em SGML, e uma de suas funcionalidades era formatar elementos de acordo com o contexto SGML daquele elemento
Isso foi antes do surgimento do XSLT e de sua família
Pessoas vindas da Datalogics ajudaram a Microsoft a entender XML. Era algo como: “Não, vocês não podem mudar livremente as maiúsculas e minúsculas das tags de elementos XML”
Usuários de TeX também têm ideias bastante sofisticadas sobre formatação de tabelas
Como uma tangente curiosa, aprendi na época que, se todos os documentos de um certo caça fossem impressos, pesariam mais que a própria aeronave e encheriam um conjunto de arquivos do tamanho de um campo de futebol
E, embora hoje muita gente não goste de XML, para quem veio do mundo SGML, XML é uma grande bênção

Sobre o Visicalc, o texto diz que “as células da grade não podiam receber estilos de borda para apresentação, os valores não podiam ser formatados e a tabela nem sequer podia ser impressa”, mas acho que nem tudo está correto
Pelo que me lembro, mesmo a primeira versão tinha suporte a formatação, ainda que limitado
Segundo http://www.bricklin.com/history/refcard3.htm, o comando /F permitia definir alinhamento e configurar formatos numéricos, por exemplo em dólares e centavos
Esse documento se refere à versão 1.35, mas acho que a versão inicial também suportava pelo menos a exibição em dólares e centavos
Algo que sempre me incomodou em dados numéricos, como valores em dólares em uma tabela, é que a comparação de quantidades visualmente parece logarítmica, não linear
Por exemplo, se os custos são $1500, $130, $110 e $210, o texto das três últimas linhas parece ter algo como 4/5 do tamanho do texto da primeira linha
Mas, mesmo somados, esses três valores são apenas 1/3 do valor de cima
As pessoas enxergam visualmente a quantidade de dígitos dos números, o que é mais ou menos parecido com log10
Esse problema acontece com tanta frequência que comecei a colocar gráficos de barras dentro das células em todas as planilhas financeiras
Caso contrário, as reuniões descambam para discussões sobre itens totalmente insignificantes em comparação com o maior custo em termos absolutos
Já gastei várias reuniões discutindo um custo mensal de $15 para coleta de logs de servidor em nuvem, em uma VM que rodava um mecanismo de banco de dados cujo licenciamento sozinho custava $15K por mês
Sou um dos co-mantenedores do Great Tables
Mantenho o projeto junto com Rich Iannone
Quando pedem para explicar a filosofia do pacote, Rich é o único desenvolvedor de software que conheço que contaria a história de 5.000 anos da apresentação de tabelas
Sensacional. Obrigado por compartilhar
É curioso termos deixado a representação de tabelas de dados ficar cada vez pior por tanto tempo
As tabelas modernas de meados do século 20 apontadas no texto parecem exemplos realmente brilhantes
Fiquei com vontade de voltar a fazer análise de dados em Python e pensei em algumas melhorias e extensões de API que gostaria de criar
Gosto deste pacote e o uso em R há anos
Ele é excelente para criar tabelas HTML, mas a saída em PDF e DOCX é um pouco menos polida
Fico um pouco preocupado porque, recentemente, o foco parece ter mudado para levar a versão Python ao nível da versão R, e o ritmo de desenvolvimento em R parece ter desacelerado
Ainda assim, vale a pena conferir, qualquer que seja a linguagem usada
Excelente. Nos anos 90, escrevi com um colega o EBRI Datebook on Employee Benefits, um livro composto em sua maior parte por tabelas
Além do SAS, nossa principal ferramenta era uma linguagem antiga chamada Table Producing Language, ou TPL
Ela remonta aos anos 1970, mas, depois que você entendia a sintaxe, a TPL era incrivelmente flexível, expressiva e eficiente
Os designers do Great Tables fariam bem em dar uma olhada na TPL
Ela cobre tudo o que o Great Tables pretende fazer, e talvez tenha mais alguns truques
https://www.ojp.gov/pdffiles1/Digitization/68013NCJRS.pdf
De todo modo, obrigado por criarem o Great Tables
Ele ajuda muito a melhorar a qualidade da geração de tabelas em Python
Essa pessoa merece um prêmio. 1) trabalho excelente, 2) atenção aos detalhes, 3) pesquisa aprofundada, 4) e ainda uma forma de apresentação excelente que evita perguntas comuns como “então o que exatamente é isso?”, “como começo?” e “pode dar um exemplo?”
Quem posta no Show HN deveria observar e aprender
Também há um livro sobre o tema: https://en.wikipedia.org/wiki/The_History_of_Mathematical_Ta...
Como uma tangente interessante, um modelo de IA treinado em planilhas precisa de “boas tabelas”, como nomes de colunas e cabeçalhos, para entender o contexto
Fortap é um exemplo disso: https://arxiv.org/abs/2109.07323