朝起きて顔洗ってコーヒー淹れて着替えて 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 の側にこういう指標を埋め込んで、可視化用のデータを生成を生成すべきなのだろうな。

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