プロダクトとしてのダッシュボード【翻訳】

この記事は作者Jeromeさんの同意を得て翻訳したもので5つの一連の記事の4つ目です。
SOURCE: Dashboards as products
1. ハロー、ダッシュボード！
2.Web時代のチャート
3.ダッシュボード vs データビジュアライゼーション
4.プロダクトとしてのダッシュボード
5.チャートアセンブル！

前回の記事 でダッシュボードが以下のものとは違うことを説明しました。

• ビジュアルデザインのエクササイズ
• データビジュアライゼーションのエクササイズ

言葉を変えれば、「表示できるからとりあえず表示しよう」というのはダッシュボードデザインや幅広い意味でとらえたビジュアライゼーションとして、冴えないマントラ（主義）です。

ユーザーのために

ダッシュボードはプロダクトでなければならないというのは冗長に感じるかもしれません。だってダッシュボードは既にプロダクトなのですから。しかし厳密に言えばプロダクトはユーザーの問題うを包括的なプロセスの結果です。研究、概念、探査、実装とテストを含むプロセスです。（詳しくはProduct Designを読んでください）

最も重要なのは、ユーザーのニーズを最初におくことです。つまり、ダッシュボードをプロダクトして扱うことはダッシュボードはユーザーの次に大事ということです。

素晴らしいダッシュボードを作成することはある意味パラドックスです。

そのフレーズでググれば、

あなたをインスパイアする20の素晴らしいダッシュボード、

25の革新的なダッシュボードの概念とデザイン、 

データギークのための24の美しくデザインされたWebダッシュボード、 

25の美しいアプリダッシュボードデザインコンセプト

といったものが出てきますが、これらは本当のダッシュボードではありません。 （ヴィジュアルデザインの例としてはもちろん素晴らしいのですが）

結局のところ、 ダッシュボードそのものはどうでもよいのです。ダッシュボードをデザインするときに、誰かがあなたが美しくデザインしたダッシュボードを毎日１時間以上眺めるということを考えることは、あなたにとってうれしいことでしょう、しかそ実際だれがそれをするでしょうか？既に忙しい一日の中にただ情報を見るというだけのタスクを追加したい人はいないでしょう。そういった妄想は辞めるべきです。

その代わりに、目前のタスクにフォーカスしましょう​。ユーザーがデータとインサイトから達成しようとするタスクは何でしょうか？

目前のタスクとは?

もし、あなたが毎週の会議で何かを見せるとか、ハイレベルのダッシュボード作ると考え始めたのであれば、私はもっと深く考えることをおすすめします。ダッシュボードそのものは目的ではありません、何のためのダッシュボードなのか？ということが重要です。

では、「我々が持っているデータのショーケース」というのは？、まだいまいちです。それではまだ十分ではありません。ダッシュボードを始めるのに「データ」からスタートするのは良いアイディアではありません。それにはいくつかの理由があります。それをやってしまうと、いまあるデータにしか目がいかなくなってしまいます。しかし、そのデータはその生の状態ではユーザにとって有用でないかもしれません。有用なことを行っていないこと。

逆にいうと、すべてのデータをダッシュボードに表示したいという誘惑にかられるでしょうが、それらの追加された情報はむしろ理解するのを難しくし最終的には有害なものになるでしょう。最も重要な事は、もしあなたがユーザがデータを元に何を成し遂げたいかということを知らないのであれば、ダッシュボードのデザインの重要なポイントである優先順位を付け、整理することができないということです。

最後に -「インサイトを発見する」も不適切です、これはタスクではありません。ダッシュボードは、特定の目的のためにデータを提示するキュレーション方法と言えます。不特定、多目的分析探査ツールではないのです。つまり、ダッシュボードは、特定の定式化された問題に答えるものなのです。そのようにデザインされている限り、そのダッシュボードは可能な限り最善の形で提示してくれるでしょう。探査やアドホックな分析はエンドユーザーではなくアナリストやデータサイエンティスト向けにより向いていると言えるでしょう。

以下はタスクの参考例です。

• 物事が上手くいっているということをチェックしてください、つまりどこにも防ぐことのできる災害がないということをチェックしましょう。例：ウェブサイトはアップしており、訪問数も想定通りである。
• 特にプロセスが期待される方法で完了したことをチェックしてください。例：すべての支払いが終わりました。
• 何かがうまくいかない場合は、 トラブルシューティングをしましょう-可能性の高い原因を見つけることです。例：私たちは、重要な製品が品切れになったたえ、売上高はダウンした。注文し今回の問題を解消し、次回は次はちゃんと在庫するようにしてください。
• タクティカルな意思決定をサポートしましょう。例：ここに新製品の売上があり、ここにコストがある。そして我々は売り続けるべきか辞めるべきか？
• どこにリソースを割り当てるか決めましょう。例：私たちは3つのバリエーションのプロダクトをローンチしました。1つは他の2つに比べて極めて良い結果をだしているので、それを後押しするために広告キャンペーンを打とう。
• より良い複雑なシステムを考えてみましょう。例：ページ間のユーザーフローはどこでユーザーがドロップアウトしたか、もしくはどのレイアウトが効果的かを示すことが出来る。

このリストは、これだけやればいいというものではありません。しかし目前の問題からきちんと考えることは、とりあえず何かビジュアライズでもしておくか、というよりははるかに有用です。

次の記事で実際にこれをどうやるかを説明します。： チャートアセンブル！

ダッシュボード vs データビジュアライゼーション【翻訳】

この記事は作者Jeromeさんの同意を得て翻訳したもので5つの一連の記事の3つ目です。
SOURCE: Dashboards versus data visualization
1. ハロー、ダッシュボード！
2.Web時代のチャート
3.ダッシュボード vs データビジュアライゼーション
4.プロダクトとしてのダッシュボード
5.チャートアセンブル！

ダッシュボードは究極のデータビジュアライゼーション

最近のInformation is Beautiful 2014 awardsで 、インフォグラフィックスとデータビジュアライゼーションのカテゴリを見つけました。私の解釈によれば、インフォグラフィックスは静的でデータビジュアライゼーションはデータから生成される動的なものという区分けのようでした。ただし、その呼び物のデータビジュアライゼーションプロジェクトの全ては、1回限りのデータセットを使っているだけでした。ですので、可視化の美しさは定のデータセットの特性に依存しています。逆に言えば特定のデータに依存しているので汎用性がありません。

これとは対照的に、私が取り組んでいるダッシュボードは、ライブ、リアルタイムのデータストリームに関するものです。データなどのようなものであれ、きちんと表示する必要があります（少なくとも機能的には）前回説明したGoogleの株価チャートは変動しやすい株、安定した株、指標、貨幣などどのようなデータがきてもきちんと動く必要があります。

もし、あなたにとってインフォグラフィックスとデータビジュアライゼーションの違いが理解できるのであれば、ダッシュボードがデータビジュアライゼーションとは違うところに位置していることが理解できると思います。ダッシュボードはデータから生成されてあるというだけでなく、リアルタイムに、そしてどのようなデータが来ても正しく機能することが求められます。（訳者注：特定のデータに最適化されたぱっと見きれいなデータビジュアライゼーションは多々あるが、それはダッシュボードとしては不十分であるといっているのだと思います）

ダッシュボードの問題は、データビジュアライゼーションの問題ではない

データビジュアライゼーションはデータを提示したり分析するための優れたツールやテクニックを提供します。データビジュアライゼーションに特化したライブラリや言語を使用すると、大概のことはできると言えるでしょう。多くの成功したビジュアライゼーションでは、完全に新しいフォームを作り出し、もしくは、既存のフォームであったとしても、観点に合わせて、非常に細かくフォームを制御します。新しいフォームを発明しなくても、多くのすでに作られたものを利用するころができます。そして比較的webでは簡単です（Excelはそうでもないですが） ツリーマップ 、 フォースダイレクトグラフと他のノードリンクダイアグラム 、 コードダイアグラム 、 ツリー 、 バブルチャートなどが挙げられます。古き良き地理マップもよいです。多くの場合、あまりにも入り組んだものや高度なフォームは良いアイディアではありません。

2014年11月中旬までは、Google Analyticsでは、モーションチャートを使うことが出来ました。

これは、全ての問題を釘に見た立てて、すべてハンマーで打ち込むという典型的な例です。（訳者注：すべて無理やり解決しようとしているという意味？）幸いなことに、この機能は最新版からはなくなりました。

同様に、Twitterのフォロワーのダッシュボードに、ツリーマップは、ちょっとやり過ぎです。

そしておそらく一部のユーザには混乱を招きかねません。一方で、それはスペースの面では経済的であり、おそらくすべてのダッシュボードで機能します。私はこれを使うことはないですが、こういう判断がされたのは理解できます。

ダッシュボードは、ビジュアルデザインのエクササイズではない

これは私がPinterestで見つけたものです。ビジュアルデザインとしてよくデザインされていますし、スペースの使い方もよく、色、型、チャートもシンプルです。

しかし、実際のところこれの何が良いのでしょうか？私は何を得ることが出来、何のアクションを取ることができるのでしょうか？

私が、dribbleやBehanceで見つけたダッシュボードはほとんどがビジュアルデザインの参考に分類されます。おそらくほとんどの場合、 静的でリアルなデータは使っておらず、実際に使われているものはほとんどないでしょう。

ダッシュボードは、ダッシュボード自身の問題です

単なるビジュアルデザインの実践やインフォグラフィックスのテクニックでダッシュボードを作ることは出来ません。ダッシュボードは、最終的には、役にやつためにあり、特定の問題を解決するものなのです。

どうやって？：次の記事：プロダクトデザインとしてのダッシュボードで説明します。

Web時代のチャート【翻訳】

この記事は作者Jeromeさんの同意を得て翻訳したもので5つの一連の記事の2つ目です。
SOURCE: Charts in the age of the web
1. ハロー、ダッシュボード！
2.Web時代のチャート
3.ダッシュボード vs データビジュアライゼーション
4.プロダクトとしてのダッシュボード
5.チャートアセンブル！

2008年頃、私がOECDで働いていたとき、私の仕事の肩書はエディターでした。それは私がほとんど本の仕事に取り組んでいたことを示しています。私はチャートをデザインしていましたが、それは本の構成要素の1つとして見られていました。それはその時代としては当たり前のことでした。

ですので、私達はこんな感じのチャートを作っていました。

そして、それは最高でした（たぶん）！私たちはすべての過去のルールを尊重しました。いい感じのy軸を見てください！そしてすべてのカテゴリは、x軸上にあります。バーのサイズが順序付けられおり、どれが最大のまたは最小値を持っているかを確認するのは簡単です。そして、これらの素晴らしいグリッドラインで、値を調べることができます, 少なくとも大きさの順序を得るのは容易でしょう。

まあ、実際にやったことはExcelにスタイルを適用することだったのですが。

インタラクティブチャートVS印刷チャート

印刷チャートルールの起源

昔ながらのチャートのルールは（たくさんあります、詳しくはTufteもしくはStephen Fewに聞いてください皆が興味を引くような想定をいくつか設定することです。

まず1つ、チャートは値が容易に読み取れるようにしなければなりません（おおよその値だったとしても）。ですので、ラベルをもった軸やグリッドラインは有用なのです。また、値順に棒グラフを並べ替える理由もここにあります。このことを念頭に置くと、棒チャートまたはエリアチャートのような面を比較するチャートは、0から始めるのは理にかなっています。

次に、一度に全てのデータを表示するということです。私たちは、すべてのデータポイントが表現され、しかも読みやすいということを維持する必要があります。そしてどのデータセットを使うかきっぱりと決める必要があります。

同様にチャートの形式を決める必要があります。カテゴリを比較したい場合、棒チャートを選ぶことができます。また、時間の経過とともに進化を表示したい場合は折れ線チャートを選ぶことも出来ます。ユーザーに正確な値を知ってほしかったらテーブルビューを選ぶことができます。

ですので、テーブルビュー以外の形式が選ばれた場合は全てのデータポイントを表示することはできません、それは現実的ではありません。

このフレームワークでは、Tufteanコンセプトの土台となっている データ·インクで考えることは理にかなっていると思います：印刷で使うインクはデコーレーションでなくデータをエンコードするために使うべきである、というコンセプトです。

では今はどうだろう？

しかし、今日のWebやモバイルチャートの世界でも有効であるとは言えないでしょう。

Webチャートは、ユーザが指定したデータポイントの追加情報を取得できるような多くのメカニズムを持っています。モバイルではうまくいかないこともありますが、mouseoverで情報を更新することもできます。しかし、それは元々表示されているもの以上のものを得ることは間違いありません。正確な値を知りたい場合、単にチャートの形状からそれを推測する必要はありません。オンデマンドにそれを提供することができるのです。

例：Google Financeの株価チャート

Google Financeの株価チャートは、Webネイティブチャートの最も代表的な例の1つです。2006年以来、ニュースのコンテキストとともに、指定された株価を提供します。ビジュアルデザインそのものは、他のダッシュボード負けているかもしれませんが、だれでも見れる状態で提供されているという点で素晴らしい例です。ビジネスデータでこういったことはまれです。

このチャートは、グリッド線とラベルの軸を有しているが、それは正確な値を調べるのに十分ではありません。しかし、チャート上にマウスを移動すると、ユーザーはある時点で正確な値を読み取ることができます。青い点が表示され、左上隅で正確な値を得ることが出来ます。

日付ピッカー（チャートのタイムレンジをコントロールする）は最も一般的に使われるデータフィルタの1つです。 別の時間範囲を選択することにより、チャートは、データセットの異なるスライスを表現することができます。これは、データセットの全てが一度に表示される従来の印刷されたチャートとは対照的です。例えば、「6m」をクリックすることができ、最後の6ヶ月からのデータで処理されるのです。

複数の証券を比較すると、チャートは異なるモードでデータを表示するようになります。これは、同じデータであり、同じ画面と同じコンテキストで、しかしチャートそのものはは視覚的に非常に異なっています。

他にも2つの特徴的な機能があります。元データとなるデータ全てに左のカラムからリンクすることができます。また最初のスクリーンショットの文字と小さなフラグはクリック可能であり、関連するニュースを表すことができます。それらをクリックすると、右側の欄にその記事が強調表示されます。だから、より多くの情報を得ることが常に可能です。

それは何を変えるのでしょうか？

すべて、です。

参照や比較が困難なルールやベストプラクティスはもはや重要ではありません。チャート自体は、しかし読みやすい必要があります。パイチャートやドーナツチャートを使っても構いませんが、カテゴリが読めないほど多くないという前提においてのみです。

Webチャート、なおさらダッシュボードは、関連するデータのみを表示することにフォーカスすべきです。 そして有用度の高いものを見やすく表示するのです。繰り返しますが、それに対して印刷向けのチャートの基本は可能な限りのデータを表示することです。

どうやってこれをやるかは次の記事：ダッシュボード vs データビジュアライゼーションで取り上げます。

ハロー、ダッシュボード！【翻訳】

この記事は作者Jeromeさんの同意を得て翻訳したもので5つの一連の記事の1つ目です。
SOURCE: Dashboards ahoy!
1. ハロー、ダッシュボード！
2.Web時代のチャート
3.ダッシュボード vs データビジュアライゼーション
4.プロダクトとしてのダッシュボード
5.チャートアセンブル！

私はFacebookでもっぱらダッシュボードについて取り組んできました。具体的言えば、ビジネスユーザーに対して頻繁に更新されるデータをどのように最も効率的な方法で提示するか？ということです。そして本日、ダッシュボードについての一連のブログ記事/チュートリアルを始めようと思います。

なぜダッシュボード？

それは最もな質問です。ダッシュボードはまったくクールではないし、退屈なものです。D3、Canvas、Processingを使ったより高度なチュートリアルや新しいクールなビジュアライゼーションを作るほうが良いかもしれません（実際それもやるかもしれません）。

しかし、ダッシュボードへの関心はまさにそのクールではないことにあります。Stephen Few氏のInformation Dashboard Designの最初のパートでは彼が長年収集した残念なダッシュボードを多数見ることができます。（訳者注：リンク先のamazonのプレビューで実際にみれるのでぜひ見てみましょう）これらのダッシュボードのほとんどは、重大かつ明らかなな生産上の欠陥があります。しばしば3Dのカラムやパイチャートを使って無駄に派手だったり、そうでない場合はあまりにも文字通りのゲージやメーターのメタファを無駄につかっています。これは2000年代初頭の典型的なダッシュボードの1つです。

しかし、過去5年間で、これらの問題はだいぶ解決されてきたと言えます。Stephenの別のコンセプトグラフデザインIQという言葉を借りれば、そのIQはかなり上がってきたと言えるでしょう。チャートを作る人々は、ベストプラクティスがあることや、いわゆるExcelの棒チャート、折れ線チャート、パイチャートとは違った様々な形態がありえることを徐々に認識しています。またスクラッチからチャートを作る人は、よいチャートを作るには詳細に至るまで、1つ1つの細かい意思決定が必要であるということを知っています。Excelなどのソフトはデフォルト設定に頼ることもできますが、棒チャートか折れ線グラフということだけでなく、グリッドラインが必要かどうか、軸の書式、凡例となどといった細かい調整を行うことで、良いチャートとなるのです。こういった意思決定を行うことはチャートのクオリティを上げることに貢献します。また、タブローのような製品で（正直いってExcelのすべてのバージョンも）デフォルトの選択肢は、以前よりも着実に良くなっていると思います。

古いものは消えていくが、新しいものもやってくる

これらの古い問題は解決されたも同然ですが、ダッシュボードはクールであるとはまだ言いがたいです。なぜなら、新しい問題に悩まされているからです。

まず、 我々がずっとフォローしてきたチャートのルールとベストプラクティスは古い世界（印刷物）のために考えられたものであるということです。今日のWebやモバイルを考慮されて考えられたものではありません。このように、90年代のいくつかの勧告は、迷信で過去に追いやる必要があります。（data-ink ratio、あなたのことですよ）

次にダッシュボードのデザインについてですが、それはデータビジュアライゼーションの問題でもないし、ビジュアルデザインの問題でもありません（訳者注：原文ではUX/UIと言っていますが、ビジュアルデザインのことを指しているように見えたのでビジュアルデザインと訳しています）。つまり、デザイナー（訳者注：ビジュアルデザイナーのことを指していると思います）、もしくはデータビジュアライゼーションの専門家として教科書的な回答をしたとしても、どちらも最適なアプローチとはいえません。

半ば公然の秘密ですが、Product Thinkingを適用することが大切です。どのように人々は、ダッシュボードを使用するのだろうか？それはあなたが達成したい事へのガイドになるはずです。

最後に、正しいダッシュボードであるために本当に重要なことはダッシュボードは個々のチャートのコレクションではなく、1つのアンサンブルであるということです。ダッシュボードのコンポーネントは個別に考えられるべきではなく、お互いに調和すべきです。

これらのテーマはそれぞれ、個々の記事のテーマとなっています。
次の記事：Web時代のチャート

Pinterestでフォローしてください

Pinterestで 、皆さんが興味がありそうなボードを2つ持っています。

1つ目は野良で見つけたクオリティ判断なしの完全なダッシュボードのサンプルです。

2つ目はデータビジュアライゼーション/ダッシュボードUIエレメントです。これはもっとチャート、ダッシュボードのパーツなど個々のエレメントにフォーカスしたボードになります。実際のところ、dribbleやbehanceなどのVisualDesignプラットフォームでみられるようなダッシュボードは本当のダッシュボードというよりは単なるチャートのコレクションのようなものです。ビジュアルデザインとしては悪くはないのですが。

D3.js 3.5の新機能、Rounded ArcでApple Watch的UI

d3.js Advent Calendar 2014の20日目です。（だいぶ遅くなってすみません、Better late than neverということで‥）

少し前に D3.js v3.5がリリースされましたね。いくつかの新featureがありましたが、個人的にはarcで角丸が出来るようになったのが目を引きました。D3.jsは基本的にプリミティブな形を使ってビジュアライズしますが、そうするとどうしても「D3.js」感が強すぎてしまい、個性を出すのが難しいこともあります。そういった意味でこういった細かい見た目が調節できるようになるというのはうれしい機能です。

実装的には

arcのgemeratorを作るときに以下のように

var arc = d3.svg.arc()
  .cornerRadius(20)
  .innerRadius(100)
  .outerRadius(120);

cornerRadiusという関数を呼ぶだけです。

どういったものかはオフィシャルのデモ見たいただければ一目瞭然です。

Arc Corners

http://bl.ocks.org/mbostock/aff9e559c5c9968b7ac6

Arc Corners II

http://bl.ocks.org/mbostock/f8f88029f3a5fde00407

今回はこのcornerRadiusを使って、Apple Watch的UIをd3.jsで作ってみたいと思います。

これはarcの角丸が指定できることで表現しやすくなったデザインだと思います。

1.まずは早速cornerRadiusを使って、サークル状のarcを作ります。

2.次は背景をつけます。だいぶそれっぽくなって来ましたね。

3.ただ、角丸にすることで開始点は0にも関わらず、少し進んで（ずれて）見えてしまいますね。ちょっといけてないので、角丸の分だけ前後に開始点、終点をずらします。 これでたいぶ自然に見えるようになったのではないでしょうか？

4.次にアニメーションとアイコンをつけて完成です。

実際のiWatchのデモはもっと細かいアニメーションしてますが、ひとまずそれっぽいものはできたと思います。

iconのパスデータはIllustratorでつくってsvgで出力して作ってます。

このようにcornerRadiusを使うことで表現に幅が出来、いままでとは違ったデザインが出来るようになります、ぜひどんどん使っていきましょう。

Enjoy cornerRadius and Have a Happy holiday!