Author: Hajime Morrita

The Grammar of Graphics | SpringerLink

というわけで一通り読んだが・・・わけがわからん。

ハイレベルな主張はそれなりに理解できる。つまり、データの可視化というのは以下のようなステップからできていて、それぞれのステージの仕様を指定の上データをつっこめばグラフができるんだよ、というはなし。 *

• まず入力は Data. これがなんなのかははっきりしないが、最初のステップ “Variable” ではこのデータを “Varset” というやや奇妙なモデルに変換する。これは雑に Pandas の indexed Series だと思えば良い。つまり、基本的には配列だが、ここの要素に index (ID) がついている。この index のおかげで他の Varset と Join できる。
• 次のステップは “Algebra” で、ここで実際に join したりする。つまりこの Algebra は関係代数みたいなものである。なんか微妙に関係代数とは違うっぽいが、なぜなにが違うのかもその動機もはっきりしない。実際 Polaris では「我々はオリジナルを無視して関係代数に寄せます」といっている。
• 次のステップは “Scale”. たとえば線形だったのを log scale に map したりする。
• 次のステップは “Statistics”. ここで何らかの aggregation を行う。しかしどうやって group by 相当のことができるのかはナゾ。
• 次は ”Geometry”. Point, Line, Area, Bar, Histobar, Tile, Contour とかを選びます。ここまでパインプラインの上を流れてきたのは Varset だったけど、この出力は Graph です。何が違うのかはナゾ。
• 次のステップは “Coordinates” です。座標系を選びます。表示したいデータの次数が二次以上なら projection とかもします。
• 最後が Aesthetics です。これはデータをどの見た目にマップするかを選びます。 x, y, color … このステップを通るとデータは ”Graph” から “Graphics” になります。これで無事描画できます。よかったですね。

よくねえええー。

この論文から Altair 的なものの面影を見ることは、頑張ればできなくもないが、これを読んでなにか可視化システムを実装できる気が全くしない。あまりに細部や具体性がかけている。Polaris paper を読んだ瞬間に「これ我々が使ってるダッシュボードの祖先じゃん！」と全てを理解してショックを受けたのとはだいぶ違う。

この論文が（回顧論文であることを差し引いても）2012 に出ていることを考えると、ひどくない？なんか引用されてる話題も 2002-2004 あたりで止まってるしさあ。本を読むともう少し理解が深まる可能性はゼロではないが。個人的には「この著者はイマイチ」ということで打ち止めにしておきたい。重要な（かもしれない）アイデアを、ひどく不可解な形で公開してしまった Research Debt だと言えよう。$30 は無駄だった気もするが, GOG (as its original form) は overrated と結論できたのは良かった。Let’s move on.

こんな意味不明なものから GUI 側では Polaris/Tableau を生み出した Pat Hanrahan, API 側では ggplot2 を生み出した Hadley Wickham はマジ神。

そういうムカついた気分はさておき振り返ると、なぜ BQ でひっこぬいたデータを Altair で可視化する作業にもどかしさがるのか、またなぜ内製の可視化ツールはイマイチに感じるのか、理解が進んだ。

まず BQ+Altair のイマイチさは、Altair の ”Statistics” 機能の足りなさが一つの理由だと言える。GoG の世界において statistics すなわち aggregation はパイプラインの一要素である。SQL でデータを扱う我々は SQL で aggregate したいが、Altair の可視化は SQL から分断されたオンメモリの世界で起こる。オンメモリどころかデータを JSON で直列化する必要から 5000 件みたいなデータサイズの制限がある。aggregate するのは大量のデータから特徴を読み取りたいからなのに、その「大量」が 5000 件で cap されちゃうと厳しい。あと Altair というか Vega 側が色々な aggregation を実装しなおさないといけないのもムダ感がある。

よりハイレベルには, visualization と statistics は切り離せないというのが GoG の洞察なのに、Altair/Vega-Lite はそれを切り離してしまっている。これは R の世界で全てが閉じている ggplot2 にはなさそうな問題に見える。しらんけど。

個人的にはオンメモリで頑張るより Polaris みたいに可視化仕様から SQL を生成して必要なデータ整形を全部済ませるアプローチが Python の世界に来てほしい。Vega-Lite のレイヤを JS じゃなくて Python 側に持ってくるのが一つの方向性だろうけど、そういうことは起こらないだろうなあ・・・。

つぎに社内 dashboarding tool のイマイチさだが、これは可視化仕様の指定に GoG 的な composability が足りてないからだろうね。内製ツールの話をここに書いても仕方ないので細部は省略するけど、もうちょっと頑張ってほしかった。

以上。

朝起きて顔洗ってコーヒー淹れて着替えて 4:37.

Chapter 2: Thirteen Common Mistakes In Dashboard Design

• Exceeding the Boundaries of a Single Screen.
  まあこれはわかりやすいね。なお画面を分けるのも、drill down は別にしてやめとけという主張。
• Supplying Inadequate Context for the Data
  比較すべき数字が含まれていない（平均、目標など）。良い悪いだけでなく、どのくらい良い・悪いのかがわからないとだめ。
• Displaying Excessive Detail o Precision
  逆に細かすぎる、みたいなの。ビジュアルが伴わない場合はなおさらそうだよな。というか table はイマイチな気がするな。自分の dashboard もちょっと table を混ぜちゃってるけど、あれは細部として切り離したほうがよさげ。
• Expressing Measures Indirectly
  伝えたいことが伝わらない指標を使っている。例では予実の時系列チャートを挙げており、予実の額自体をプロットするのをダメとしている。かわりに予算を定数とし、予算に対する実際の出費の % をプロットしたほうが良いとしている。予算超過しているかどうかがわかりやすいから。なるほど。なお仕事ではもっとあからさまにダメな indirect measure が問題になったことがある。それは直したけど、他にもこういうのありそう。”Indirect” という語彙があると指標を殺したいときの説得には役立つげ。
• Choosing Inappropriate Display Media
  Bar chart はやめておけ、まして 3D は最悪だ。あと二種類くらいダメなチャートが乗っており、かつ後の章でも詳しくやるらしい。仕事、社内ベータユーザの OS ビルドの分布を pie chart で出しちゃってるけど、だめかな・・・。エントリが多いと bar chart はかさばるのだよなあ・・・。後の章に期待。
• Introducing Meaningless Variety
  無意味に使う chart の種類を増やすのはやめなさい、boring とか気にしないで consistency 大事にしなさい、という話。
• Using Poorly Designed Display Media
  単一のチャートのダメさについて、いくつか例を示しながら議論している。詳しくは Show Me thee Numbers という別の本を読んでねとのこと。はい
• Encoding Quantitative Data Inaccurately
  グラフはゼロベースにしろよなとか。はい。
• Arranging Information Poorly
  重要な数字は prominent に、注意すべき数字は stand out させ、比較すべきものは隣に置く。
• Highlighting Important Information Ineffectively or Not at All
  後の章で詳しくやるよ。
• Cluttering the Display with Visual Effects
  謎の装飾はやめろ、みたいなの。これは自分にはさすがに関係ないが, vendor がつくる昔ながらの dashboard ではたしかによくあったかもしれない。例示される screenshot が厳しい。
• Misusing or Overusing Color
  無駄に関心を引く色を使っちゃうとか。こういうの dashboarding tool がデフォルトの palette をまともにしてくれればいいんだけど、なんか無駄に赤とか入れてくるよな・・・。その点モダンなチャーティングライブラリはえらい。
• Designing an Unattractive Visual Display
  過剰な装飾はダメとはいえ ugly すぎるののも困るから aesthetics も気にしような、あとの章で教えてやるかんな、という話。はい。

今や自明なものもあるし、なるほどというものもあるし、よくわからんから後の章に期待というものもある。コンテクストの不足、情報の過剰、Arrangement の工夫、一画面に収める、とかはできてないときもあるので次からはちゃんとやりましょう自分。

Chapter 3: Assessing What’s Needed

• 要件定義ちゃんとしような、という章。
• Begin With a Definition
  “It is an information display that will keep them aware of what’s going on in their specific realm of concerns”. EDA とかのツールじゃないからね、という話。
• Focus on the Goals, Not on the Means
  エンドユーザからの fancy にして欲しいという要望は無視し、彼らの必要とするものを作ってあげなさいね、という話。はいはい。
• Get into People’s Heads
  Dashboard を読む人のメンタルモデルに沿って画面をデザインしてあげようね、読み手のメンタルモデルをインタビューするときはホワイトボードに図を描いてもらって、いろいろ質問しながら図に矢印とかを書き足してもらおうね、初心者はそもそもメンタルモデルがないときもあるから育ててあげようね。という話。
• 最後は余計なお世話というか出過ぎた主張だと思うが、Dashboard はさておきメンタルモデルや問題意識の共有というのは必要で、しかし自分はしばしばさぼりがちである。PM とかこういうの話し合うの好きで、話が長くなって仕事が進まないのでイヤだなーといつも思っているが、数字を中心とした design doc 的なものを書いてそれを dashboard という形で実装する、というフローは必要なのだろうなあ。business objective の定義みたいな。まあ business ってほどじゃない性能上の指標なんだけど。
• Ask the Right Questions
  • Dashboard の更新頻度は?
  • 誰が読むの?
  • 何をモニタするの? なんの目的で?
  • どういう疑問にこたえたいの?
  • Dashboard をみてどんなアクションをとりたいの?
  • 具体的に表示したい項目は? それぞれ何がわかるの? 詳細が必要なのサマリが必要なの?
  • 目的のために一番重要なのはそのうちどの数字なの?
  • どういう logical grouping があるの? 各数字はどの group なの?
  • どの数字とどの数字を比べたいの? 互いにコンテクストを提供できる数字たちはどれ?
• このリストは comprehensive ではないといってるが、良いリストだね。耳が痛い。Dashboard design doc があるとしたらこういう質問には答えてしかるべきだな。作ってみないとわからないものもありそうだけど。
• Identify Information that Really Matters
  上の質問リストに出てきた数字のうち、実際に性能に影響を与えるものだけを dashboard に含めなさい。人々は実際には使わない数字を念のためと入れたがるけど、空間や関心を無駄遣いするのでやめなさい。入れたがり屋さんには「あんたその数字をみてどう行動するわけ？」と聞きなさい。そうですねー。EDA してた名残でなんとなく入れちゃうチャートとか、割とあるよね。
• Identify Useful context for Measures
  それぞれの数字を読むにあたって役立つ context が何か identify しなさい。たとえば “targets, standards, measures of the norm, or the past data.” – “Compared to What?” – これ全くその通りだけど一方で内製の dashboarding tool はチャートにこういう情報を埋め込む支援が全くない、というか不可能。Altair も支援といえるものはないけど、コードを書けば任意の線を埋め込めるのでなんとかなる。むしろ dashboarding tool 側ではなくそいつの参照する SQL の側にこういう指標を埋め込んで、可視化用のデータを生成を生成すべきなのだろうな。

短いがなかなか有用な章だった。読書はここまで。

The Food Lab: Better Home Cooking Through Science

夜は眠くてやる気なくても読める本を寝る前にちょっとだけ読むことが多い。その記録もつけてみる試み。

Chapter 2: Soups, Stews, and the Science of Stock

• Collagen/Gelatin は connective tissue である。legs, wing, back and skin に豊富。
• Meat only stock -> flavor. Bone only stock -> body. Carcasses -> Both
• carcasses は food processor で砕いたのちに simmer する。Flavor が短時間 (45min) でよく出る。Gelatin は摘出されないがそれは市販の gelatin を足せばよい。