Great Tablesのデザイン哲学

(posit-dev.github.io)

3 ポイント投稿者 GN⁺ 2024-04-05 | 1件のコメント | WhatsAppで共有

Great Tables は、データ分析の流れをPythonコード内に保ちながら、20世紀半ばの印刷表が持っていた精緻な表現力を復活させることを目指す表作成パッケージ
表は単なる行・列の格子ではなく、列順・ラベル・区切り線によって値を見つけやすくし、比較しやすくする情報表現の形式
古代シュメールの粘土板から Manual of Tabular Presentation に至るまで、表は情報密度と形式をともに発展させてきたが、初期のスプレッドシートは計算のしやすさに比べて表現力が不足していた
Great Tables は表を 6つの構成要素 に分け、tab_*、fmt_*、opt_*() 系のAPIで構造・書式・スタイリングを分離する
このパッケージは、大規模なインタラクティブ探索よりも、論文・書籍・レポートに入る 静的な要約表 の出版・発表品質を高めることに重点を置いている

Great Tablesが解こうとする表作成のジレンマ

表は、プロットと同様に情報を提示する最後の段階で重要であり、効果的な表設計には想像以上の 精巧さとニュアンス がある
今日のデータ作業者は、たいてい次の2つの選択肢の間で妥協しなければならない
- Excelのようなツールにデータをコピーして表を作り直す
- 洗練されていない表をそのまま表示する
Great Tables は、このジレンマを Pythonコードベースのインターフェース で解決しようとするパッケージ
データ収集、分析、要約表の生成までをPython内で処理しつつ、表現力のある表を作ることが目標

表の基本定義と可読性の要素

表は2つの基本ルールに要約される
- データが 列と行 で表現される
- データが主に テキスト で表現される
例の表では、人を行に、名前・住所・都市・郵便番号・生年月日・身長・体重といった特性を列に配置する
この配置により、個々の値を探したり、行と列をまたいで比較したりしやすくなる
行間の横線は必須条件ではないが、各行を視覚的に区別する補強的な役割を果たす
列の順序も可読性に直接影響する
- Name 列が右端にあると、各レコードの主体がすぐに見えず、読者はより混乱する可能性がある
- 列ラベルは各列にどのようなデータが入っているかを示し、多くの場合、推測の必要を減らしてくれる

古代の表の歴史

表は、情報を収められるコンテナである 正方形の格子 から始まった
フランスのLascauxとNiauxの洞窟壁画には、約 2万5千年前 の格子表現が残っている
紀元前2世紀のHipparchusは緯度と経度で天体と地上の位置を表し、西暦150年ごろのPtolemyの Geographia には格子を活用した地図作成法が含まれていた
ローマの centuriation は、道路・運河・農地によって正方形の格子を形成する土地測量体系だった
農業が広く普及した約1万年前以降、農業・家畜・労働分業に関する経済取引を記録し管理する必要が大きくなった

シュメールとメソポタミアの表構造

紀元前4千年紀のメソポタミア都市は遠方の王国と交易しながら記録を保管する必要があり、Urukで発見された粘土板には初期ながら精巧な表が残っている
紀元前3200〜3000年ごろのUruk粘土板には、ビール生産のための大麦と麦芽の配送量が記録されている
- 右から左へ読む構造
- 各セルには、単語・概念を表す表意文字と、数量を表す数字が入っている
- およそ2行がそれぞれ1人に対応する
- 右側の2列には麦芽と大麦の数量が入る
- 3列目には個人ごとの小計、左端の列には総計が示される
- 最下段の行には担当管理者の名前があり、フッターのように機能する
約1000年後のNippurのEnlil神殿の粘土板には、収入源と50人の神殿スタッフの月次支出が記されている
- より規則的な格子が見られる
- 月名の形をした列見出しと、個人名・職業の形をした行見出しがある
- 情報のない空白セル、数値、6か月単位の小計、総計、説明注記が含まれる
その後、表の媒体は粘土から蝋板、パピルス、紙へと移り、書記技術と表デザインもそれに合わせて変化した

20世紀半ばの表デザインの頂点

20世紀半ばは、表デザインがとりわけ強かった時代として扱われる
オフセット印刷、タイプライター、varitype のような文書作成技術が、表の要素を精密に組版できるほど発達した
ページ空間には制約があったが、表を1ページに収めたり複数ページに分けたりするさまざまな解決策が存在した
高度化した印刷技術と表デザインの知識が結びつくことで、美しい表 を作ることができた
米国国勢調査局の Manual of Tabular Presentation は、情報密度の高い表の理想的な設計を詳細に扱った仕事
- 表のさまざまな部分を命名し、厳密に説明している
- さまざまな表作成状況で何をすべきか、何をすべきでないかを強く勧告している
- 表が見栄えよく、それでいて多くの情報を盛り込めることを示している
Great Tables はこの文書の表デザイン原則を多く取り入れており、その原則が今も有効であるという前提から出発している

スプレッドシート以後の後退と限界

1970〜1980年代にコンピューティング技術が利用しやすくなると、人々は電子形式と印刷形式の両方で表を作れるようになった
計算可能な表の大衆化は、1979年の VisiCalc とともに始まったと見なせる
VisiCalc は値をすばやく計算できたが、発表用の表を作るには表現力が限られていた
- 格子セルに発表用の罫線スタイルを与えられなかった
- 値を書式化できなかった
- 表を印刷することもできなかった
その後10〜15年にわたり、スプレッドシートの表は見た目が改善していった
- 1990年代初頭のExcelでは、表に罫線を引けるようになった
- タイポグラフィのサポートも向上した
- 値の書式設定機能もより充実した
それでも、ここ30年ほどのExcelの表は Manual of Tabular Presentation の水準に達しにくかったと評価されている
データ分析がExcelの外でも行われるようになると、3つの非効率なシナリオが生まれた
- Python内で分析と表生成をすべて処理するが、表の品質が低い
- Excel内で分析と表作成をすべて処理するが、分析の柔軟性が低い
- Pythonで分析してExcelにコピーして表を作るが、再現可能ではない

Great Tablesの表モデル

Great Tables は、20世紀半ばの表の優雅さをコードインターフェースの力と結びつけようとするPythonパッケージ
表を 6つの独立した構成要素 の組み合わせとして表現する
- Table Header: タイトルとサブタイトルを入れて、表の内容を簡潔に説明する空間
- Column Labels: 各列の内容を定義し、spannerは複数列のグループの上に置かれる見出し
- Stub Head: 左上の位置で、さまざまな種類のラベルを置ける
- Row Stub: 行情報と行グループラベルのための領域
- Table Body: セルを含み、データが配置される領域
- Table Footer: 表の内容に関連する追加情報を入れる空間
Great Tables は、コードで表本体を作成したあと、スタイリング、書式、他の構成要素を反復的に追加していく形で使う
例のコードは GT(simple_table, rowname_col="Name") から始まり、タイトル、stub head、column spanner、source note、日付・整数の書式、スタイルオプションを追加する
例の表では、青いrow stubが行ラベルを表本体から区別している
- 各人物が固有の観測値なので、行の主体を強調している
- タイトルは表に含まれる内容を説明する
- Location と Personal Characteristics のspannerは、列を意味のあるグループにまとめる
- 青い線とセル背景の一貫した使用が、プロフェッショナルな外観を作る
表構成要素を追加するメソッドは tab_ で始まる
- 例: tab_header() は Table Header を作る

書式設定とnanoplots

表の構造化だけでは十分ではなく、分野ごとに値の表示要件が異なる
1つの数値であっても、コミュニティの規範や期待によってさまざまな形で表示されうる
日付、時刻、通貨まで含めると、書式設定の範囲はさらに広がる
生の値 134,000 も、要件に応じて異なる表現が可能
- fmt_scientific(): 科学表記 1.34 × 10^5
- fmt_number(): ドイツロケールの数値 134.000,00
- fmt_integer(): 圧縮整数 134K
値を画像やプロットとして伝える必要がある場合、書式設定の問題はさらに大きくなる
医療アナリストが患者の検査結果の改善・悪化傾向を伝えなければならない場合、行全体の数値列を読む方式では解釈が遅くなることがある
fmt_nanoplot() は、nanoplots によって表内に小さなトレンド可視化を提供する
- データポイントにマウスを重ねると、各日付の値を確認できる
- nanoplotsは、プロットの素早い視覚的解釈と表のコンパクトさのバランスを目指している
Great Tables の書式メソッドは fmt_ で始まる
- 例: fmt_date(), fmt_integer(), fmt_nanoplot()
パッケージは、さまざまなユーザーの要件に合わせて多くの書式メソッドと有用なオプションを提供しようとしている

出版・発表向けの静的要約表に集中

Great Tables は、表とのさまざまな関わり方の中でも 出版と発表のための表示 に焦点を当てている
データベース分析では、数百、数千、あるいはそれ以上のレコードを探索・フィルタリングする単純な表表示が適している場合がある
結果の出版は別の作業であり、ここでは構造化・書式設定・スタイリングが中心となる
美しい表表示は次を満たすべき
- 情報をより消化しやすくする
- 必要な場所に追加の文脈を提供する
- 文書や組織のスタイルに従う
想定されるユースケースは、学術誌の論文、書籍、レポートで見られるようなデータ提示
Great Tables は、静的要約表が独立した焦点を与えるに値する領域だと考え、opt_*() メソッドによって読者により良い表を提供しやすくしようとしている
パッケージの成功基準は、作り出せる表の品質であり、API改善の作業を継続する予定
コミュニティからのフィードバックのために Discord Server を公開している

1件のコメント

GN⁺ 2024-04-05

Hacker Newsのコメント

Great TablesはPython/Jupyterのテーブル方面でかなり素晴らしい仕事をしてきており、グラフィック文法（grammar of graphics）のように、ほとんどテーブル文法を作りつつあるように見える
もっと多くのプロジェクトが、このように哲学や目標を説明してくれるとよいと思う
Jupyter向けにBuckarooという別のテーブルライブラリを作ったが、アプローチは異なる
Buckarooは、インタラクティブに作業しながら複数の形式や後処理関数を素早く試し、テーブルから重要な洞察を得られるようにすることを目指している
基本的な探索的データ分析をしていると同じコマンドを何度も入力することになるので、そうしたコマンドや洞察はテーブルの中に入るべきだと考えた
Great Tablesは、発表用のテーブルを手作業で書式設定するために作られたものに近く見える
https://github.com/paddymul/buckaroo
https://youtu.be/GPl6_9n31NE
- Buckarooの作業に感謝する。Jupyterのprint()とIPythonのdisplay()には、死んだ静的出力という限界があり、昔のprintfデバッグのように感じられるが、Buckarooはそれを解決するために作られたものだと理解している
  Visidataのショートカットキーと操作方式をどう見ているのか気になる
  以前Visidataを使っていて、データフレーム探索用として、なぜ結局Jupyterの中に入れないのかといつも不思議に思っていた
  Great Tablesがテーブル文法を形式化しようとするもう一つの試みに見えるという点には同意するし、表形式の力と、R/pandas/Arrow/polarsエコシステムを通じたデータフレーム概念の広がりを考えれば、このようなアプローチは歓迎できる
  ただし、この用語はもともと90年代の統計言語Sで初めて使われたものだと理解している
  [1] https://towardsdatascience.com/preventing-the-death-of-the-d...
Great Tablesの例は、私の好みには複雑すぎる。タイトルの上下にある横線は不要に見えるし、1列目である行ラベルに合わせているのもいまいちだ
下側に少し余白を取り、太字を使えば、ノイズなしに視覚的な階層を与えられそうだ
行ラベルの背景は暗すぎ、フォントの太さのせいで読みにくいので、ごく薄い青のほうがよさそうだ
行グループラベルの“Name”を斜体にしているのも気に入らない
中央に浮いている上位列ラベルはテーブルをざっと見るのを難しくしており、左揃えのほうがずっとよいと思う
最後にフォントも本当に気に入らないが、これはブラウザのせいかもしれない
いくつかの変更を反映したモックアップを作った。こちらのほうがはるかに読みやすいテーブルだと思う
https://i.imgur.com/iMMf5vo.png
- Edward TufteのBeautiful Evidenceを読んでみるとよい
  読みやすさや、データのメッセージや核心を邪魔する要素など、今述べたような内容を扱っている
  スパークラインを見たことがあるなら、その用語を作ったのもTufteだ
  UIレビューをするたびに、見落としているものがないか確認するためにこの本をめくることになり、どのページを開いて読んでも面白い本だ
  さらに、PowerPointがなぜひどいのかについての長い論考もある
  [1] https://www.edwardtufte.com/tufte/books_be
  [2] https://en.wikipedia.org/wiki/Sparkline
- テーブルのタイトルは、上部中央揃えか下部のキャプションであるべきだ
  どこかの列の上で左揃えにすると、そのタイトルが、たいてい事実ではないか意図していない形で、テーブル情報階層の最上位のように見えてしまう
  上のモダニズム風の修正版では、タイトルが「names, addresses, characteristics」と言っているのに、配置上は名前を除外しているように見えて、すぐに違和感があった
  反対に、国勢調査マニュアルはほぼすべてのラベルを該当するボックス内で中央揃えにしており、そうでない場合も多くはインデントによるものだ
  また、ラベルではなくデータに合わせて列幅を決め、インデントやハイフネーションをそろえることをためらわない
  結果として、水平方向に密でありながら直感的に理解できるものになる
  さらに考えてみると、タイトル自体もあまりよくない
  タイトルやキャプションは文脈、範囲、目的を伝えるべきであり、それができないなら、自らの存在を正当化できなかったという編集上の罪により、いっそ省略してもよい
  今のタイトルは、情報や一般性を失うことなく「Table 1」に置き換えられる
  表現としてのテーブルを第一原理から論じ、再構成しようとする文章としては、やや期待外れだ
  テーブルタイトルは情報カタログの重要な層を成すので、国勢調査マニュアルがタイトル構成に丸々一章を割いているのも驚きではない
  ややドメイン特化で古風な文体ではあるが、見る価値は大きい
- 各行がそれ自体で1つのレコードだという感覚を強めるために、横線や縞模様のような要素がなぜないのか理解できない
- あなたのモックアップは改善版だ。記事の例は、テーブル内のすべての文字と数字の視覚的な重みが均一なのが問題だ
- もっと突き詰めてもよいと思う。タイトルは残りが列名と重複しているので、“remote correspondents”に短縮すればよい
  青色の強調も今ではタイトルと重複しているので全部外し、“personal characteristics”と“location”の区分も構成上あまり意味のある助けになっていないため、削除したほうがよい
歴史の話が興味深い良い記事だ
より最近の歴史としては、CALSテーブルの策定がある: https://en.wikipedia.org/wiki/CALS_Table_Model
Datalogics https://en.wikipedia.org/wiki/DatalogicsはCALSテーブルの構想に深く関与していた

Datalogics の社員は SGML を策定する ISO 委員会に参加し、文書化に関わった米国防総省の職員や契約業者を含む多くの人に SGML を教えていた
SGML ベースの文書エディタを作ったチームに参加していたが、その機能の一つが、その要素の SGML コンテキストに応じて要素の書式を設定することだった
これは XSLT とその系譜が登場する前の話だった
Datalogics 出身者たちは、Microsoft が XML を理解するのを手助けした。「いいえ、XML 要素タグの大文字小文字を勝手に変えることはできません」といった具合だった
TeX ユーザーたちも、表の書式についてかなり洗練された考えを持っている
変わった余談として、当時ある戦闘機の文書をすべて印刷すると、航空機そのものより重く、サッカー場ほどの大きさの書類キャビネット群を埋めるほどになると教わった
そして今日では XML を好まない人も多いが、SGML の世界から来た立場からすると XML は大きな恵みである

Visicalc について「グリッドセルには表示用の枠線スタイルを付けられず、値は書式設定できず、表は印刷すらできなかった」とあるが、すべて正しいわけではなさそうだ
初期バージョンにも限定的ながら 書式サポートはあったと記憶している
http://www.bricklin.com/history/refcard3.htm によると、/F コマンドで配置を指定し、数値形式を例えばドルとセントに設定できた
この文書はバージョン 1.35 基準だが、最初のリリース版も少なくともドルとセントの表示くらいはサポートしていたように思う
表のドル金額のような 数値データでいつも気になっていたのは、数量の比較が視覚的には線形ではなく対数のように見えることだ
例えば費用が $1500、$130、$110、$210 だと、最後の 3 行のテキストは最初の行のテキストの 4/5 くらいの大きさに見える
しかし 3 つを合計しても、最上段の金額の 1/3 にすぎない
人は数字の桁数を視覚的に見るが、これはおおよそ log10 に近い
この問題があまりに頻繁に起きるので、金融関連のスプレッドシートには毎回 セル内棒グラフを入れるようになった
そうしないと、会議が絶対額で最大の費用に比べれば完全に些細な項目をめぐって議論し、脱線してしまう
実際、月額ライセンス費だけで $15K のデータベースエンジンを動かしている VM で、クラウドサーバーログ収集の月額 $15 の費用をめぐって複数の会議を費やしたことがある
Great Tables の共同メンテナーの一人である
Rich Iannone と一緒に管理している
パッケージの哲学を説明してほしいと言われたときに、表表示の 5,000 年の歴史を語ってくれるソフトウェア開発者は Rich くらいしか知らない
素晴らしい。共有ありがとう
悪化していく データ表現としての表を、これほど長く放置してきたのは不思議だ
記事で指摘されている 20 世紀半ばのモダンな表は、本当に輝かしい例に見える
Python でデータ分析をまたやってみたくなったし、作りたい API の改善や拡張もいくつか思い浮かんだ
このパッケージが好きで、R で数年使っている
HTML テーブルを作るには優れているが、PDF と DOCX 出力は少し作り込みが甘い
最近は Python 版を R 版の水準に引き上げる方向へ移っていて、R の開発速度が落ちたように見えるのは少し心配だ
それでも、どの言語を使っているとしても確認する価値はある
素晴らしい。90 年代に同僚と一緒に、ほとんどが表で構成された本である EBRI Datebook on Employee Benefitsを書いた
SAS 以外の主な道具は、Table Producing Language、略して TPL という古い言語だった
1970 年代までさかのぼるものだが、文法さえつかめば TPL は信じられないほど柔軟で表現力が高く、効率的だった
Great Tables の設計者たちは TPL を見てみるとよいと思う
Great Tables が目指していることはすべて扱っており、さらにいくつか多くの技もあるかもしれない
https://www.ojp.gov/pdffiles1/Digitization/68013NCJRS.pdf
いずれにせよ、Great Tables を作ってくれてありがとう
Python での表生成の品質をずっと良くするのに大いに役立っている
この人は賞をもらうべきだ。1) 素晴らしい仕事、2) 細部へのこだわり、3) 深い調査、4) 「で、これは正確には何なの？」「どう始めればいい？」「例をもらえる？」といったよくある質問を避けられる 優れた発表の仕方まで備えている
Show HN に投稿する人たちは見て学ぶべきだ
このテーマに関する本もある: https://en.wikipedia.org/wiki/The_History_of_Mathematical_Ta...
興味深い余談として、スプレッドシートで学習した AI モデルは文脈を理解するために、列名やヘッダーのような「良い表」を必要とする
Fortap がその例である: https://arxiv.org/abs/2109.07323