About Face 3 読書ノートの23。
About Face 3 に、階層構造（特にフォルダの中にまたフォルダがあるような、同じ種類のオブジェクトの入れ子構造）はふつうの人には理解しにくく、取り扱いも難しい。それよりも「単斜グループ」を使ったほうがいい、みたいなことが書いてあるんです。
単斜グループ？ 何それ？
説明を読めば、それが、階層を持たない一列の並び、ということで、現実世界でいえば、本棚やファイルキャビネットのようなものだとわかります。
Webでは、下記のサイトで説明が読めます。
Monocline grouping (Global Constant)
http://globalconstant.scnay.com/2009/09/10/monocline-grouping/
「A monocline grouping is a representation of data in a single layer (i.e., without a nested hierarchy)」
ってね。
しかし、これがなぜ「単斜」なんでしょう？ 地学で「単斜構造」といえば、
weblio 石油/天然ガス用語辞典 単斜構造
http://www.weblio.jp/content/%E5%8D%98%E6%96%9C%E6%A7%8B%E9%80%A0
「地層が、ある広がりにわたって、おおむね同一方向に傾斜している地質構造をいう。」
ってことで、
http://commons.wikimedia.org/wiki/File:Monocline01.gif (wikipedia commons) ← こういうことですね。
結晶の単位格子の種類にも「単斜晶」というのがあって、
http://commons.wikimedia.org/wiki/File:Monoclinic.svg (wikipedia commons) ← こういうことですよ。
これらに共通しているのは、まあ、一方向に傾斜してるってことですけど、About Face 3 がいう monocline grouping にナナメは関係あるの？
本棚がスカスカで本がナナメになっちゃってるって？
なんかぜんぜん腑に落ちないんですよ。ところが、前のエントリーを書いているとき、monocline 単斜 と、mono な cline は違うのか？と、思いまして、cline を調べてみたところ、
Google 英語辞書
http://www.google.co.jp/dictionary?langpair=en|en&q=cline&hl=ja&aq=f
「a series of similar items in which each is almost the same as the ones next to it, but the last is very different from the first」
こう出ました。
つまり、先頭から後尾にかけて、要素の性質がだんだん変化していく配列みたいなことでしょう。生物学の用語として連続変異とも訳されるようですね。
こっちのほうが、About Face 3 と Global Constant が説明している monocline grouping にフィットしませんか？
もっとも似ている者同士が隣合うように並べておいて、類似度の差が大きくなっているところが、グルーピングの境目だと心得ておく。
階層なんてややこしいことは考えず、そうしたひと並びの列にモノをしまっておいたほうが、人にはやさしいというのが monocline grouping でしょ。
というわけで、どういうつもりでクーパーが monocline という言葉を選んだのか、英語ネイティブが monocline と聞いてどんなイメージをまず心に抱くのか知りませんが、とりあえず、monocline grouping を、「単斜グループ」と訳すのは、ちょっと不適切なんじゃないかと思うのですがどうでしょう。
じゃあ、何と呼べばいいか？ もう、「クラインなかんじに並べとく」って言うしかないかな？ でも、クラインとかいうと変な形の壺が目に浮かぶしな ... 。
2009年12月25日金曜日
2009年12月24日木曜日
ぼくらの純インタラクションを守れ
about face 3 読書ノートの22。
about face 3 に、まるで一大スクープのように、
「ナビゲーションは間接税的な操作だ」
なんて大きな見出しを打っている箇所があります。
そこでは、ナビゲーションを「インターフェースの新しい場所にユーザーを連れていく動作、またはユーザーがオブジェクト、ツール、データを見つけなければならない動作」と定義してるんですが、「連れていく」ったってべつに有り難い話じゃなく、ユーザーにすればむしろわざわざ、しぶしぶってところですから、もうなんか連行されるみたいなニュアンスさえただよって、後の「見つけなければならない」ってのと合わせると、じつにこう、ツールのニーズによって道具化されてしまう人間の悲哀がよく伝わる、ドナドナ的な言いっぷりのような気がしてきます。
そして、そんな怖い怖いナビゲーションにはどんなものがあるのかって、
(以下、例によって、読書ノートなので自分の頭に入れやすいように勝手な要点抽出フィルターがかかってます。)
1.移動。アプリケーションを構成する複数のウィンドウ間、あるいはウィンドウ内の複数のペーン間の。
2.探索。ツール、コマンド、メニュー、あるいはオブジェクト、コンテンツ、データの。
3.切替。オブジェクト、コンテンツ、データを表示する範囲または粒度の。
と、こう列挙されるわけですよ。
あらためてこれらのひとつひとつに思いを馳せてみてください。ユーザーエクスペリエンスなんつって、ほとんどナビゲーションがらみで埋め尽くされているようなもんじゃありませんか。
これが全部、ゴールに直接向かうわけではない、間接税的な操作だっていうんですから、たとえ400円になったとしてもタバコのほうがよっぽど良心的なかんじがします。
で、思うんですよ。じゃあ、ナビゲーションじゃない、無税の、つまり真にゴールダイレクテッドなインタラクションって逆に何？
上のナビゲーションの定義に習って思いっきり大きく出ると、オブジェクトとかコンテンツとか、とにかく何らかのデータの表現を確認して、これになにか手を加え、その結果、データがどんなふうに変化したのかをまた確認すること、この往復、循環、ってことになるでしょう。
ナビゲーションのタイプのうち、上記の2.も3.も抜いてですよ、ほんとにそこだけ純化して取り出したら、これ、非常に僅かな、希少なもんなんじゃないですか。これを純インタラクションとでも呼んで、どっかに含有率を書いといてほしいですね。
いや、しかし、だからといって、虐げられた民びとよ立ち上がれ、今こそこの圧政に反旗を翻せ、とかって話じゃないんですよ。だってこれは、いわば、その純インタラクションの本性がもたらしている宿命ですからね。逃れることはできません。
つまり、僅かとはいえ（いや、含有率とは関係なく）、純インタラクションの全体は、デバイスの表示領域に入りきらないほどデカいわけです。だから常に部分的にしか取り扱うことができず、そのために上記の移動、探索、切替が必要になっちゃって、結果、インタラクションのほとんどがナビゲーションになってしまうということですもんね。
ほんとにもう、インタラクションデザインって、この宿命をどう受け入れるかについてのデザインだと言い切っちゃいたくなるくらいのもんで。ですから、インタラクションデザインの戦術レベルでの指針は、ユーザーの視覚、認知、記憶、運動にかかる負荷を下げ、フロー状態を良好に保つってことだと思うんですが、そうする上で障害として立ちはだかってくるのは、大抵、ナビゲーションがらみということになるはずです。
そのために、--- つまりナビゲーションの氾濫から純インタラクションを守るために --- about face 3 が立てた作戦はこうです。
●永久オブジェクト
どんなにシステムの状態が変化しても、けっして消えてなくならないものを用意し、これを一番はじめに印象づけておこう。
永久オブジェクトこそ、すべてのナビゲーション起点であり、次にとりうる選択肢を常に示している道しるべであり、そして、いよいよというとき、最後に頼るべき縁でもあります。
たとえば、システムと同じ寿命を持つトップレベルのウィンドウ、グローバルナビゲーション、デバイスの物理的なボタンとかね。
●位置情報
全体像と現在位置をいつでも知ることができるようにしておこう。
その方法は、今、まさに部分的に取り扱っているオブジェクトの性質に合わせて、いろいろな手口を考えておく必要があるでしょう。
たとえば、Webサイトならブレッドクラム。画像編集ソフトなら、現在表示している範囲を縮小された全体像中に矩型で示すオーバービュー。ウィンドウシステムでは、現在表示している位置と範囲を、全体に対する相対的な長さで表現してもいるスクロールバーとかね。
●自然な対応関係と構造
純インタラクションにおいて、ゴール達成を容易にするための交換条件としてまあまあ見合う、ということならともかく、一介のナビゲーション風情が、自分のために新しいものの見方や習慣をユーザーに押しつけるなんてことがないようにしよう。
ありがちなのが、車のウィンドウを開閉するボタンが縦一列に四つ並べられている場合、右後部座席のウィンドウを開閉するには何番目のボタンを押したらいいでしょうか？ --- 的なレイアウトの対応関係にみられる鈍感さ。
あるいは、時系列のソーティングの方向を、「昇順」「降順」というデーターベース用語で選ばせるような、ラベルと機能の対応関係にみられる普通の人にとっては不自然な実装モデルの押しつけ。
それから GoF のコンポジットパターンのような、同型のオブジェクトが入れ子になるような階層構造なんかも、マトリョーシカ的な玩具以外に現実世界ではまずありえなくて不自然。そもそも、ほとんどの人は深い階層構造を辿るような移動、探索、切替を現実世界で体験したことがない、とかね。
●ペルソナへの適応
連れていくべき場所、ユーザーが見つけなくてはならないオブジェクト、ツール、データを減らす、というか、そのうちでも、普段から意識しておくべきものを極力減らしておこう。
簡単に言えば、いつもそばにあるものと、深いところに隠しておくものとに仕分けること。仕分けの基準は、
・使用頻度
・労力と報酬の見合い
・転位の度合い（その操作によってデザイン対象の状態がどれほど大きく変化するか？）
・危険度（失敗した場合の取り返しのつかなさ）
となるんですが、いずれも、ペルソナの性質、ニーズ、ペルソナが活動するコンテクストに深い関わりを持ちます。言い換えれば、ペルソナに合わせてインタラクションを整理してみようってことです。
よく使うものは当然、いつもそばに置いておきたいですよね。注意したいのは、深いところに隠しておくもの。これには、深いところに隠して"おいても"いいものと、隠して"おいたほうが"いいものと二種類ある。
労力と報酬の見合いがとれ、（かつ、それほど頻繁に使わないものなら、）深いところに隠して"おいても"いい。
転位の度合いや危険度が高いものについては、一般に、深いところに隠して"おいたほうが"いい。とかね。
こうして、実際にはその数を減らすことはできなくても、なるべく、なるべく、ナビゲーションのやつらにユーザーの心を奪われないように気をつけて、ユーザーの心に占める純インタラクションの割り合いをもっと上げていこうよ、ということですね。
純インタラクション --- そう、今夜は特別に、My Sweet Soul Interaction って呼ぼう。My Sweet Little Interaction のほうがいいかな？
about face 3 に、まるで一大スクープのように、
「ナビゲーションは間接税的な操作だ」
なんて大きな見出しを打っている箇所があります。
そこでは、ナビゲーションを「インターフェースの新しい場所にユーザーを連れていく動作、またはユーザーがオブジェクト、ツール、データを見つけなければならない動作」と定義してるんですが、「連れていく」ったってべつに有り難い話じゃなく、ユーザーにすればむしろわざわざ、しぶしぶってところですから、もうなんか連行されるみたいなニュアンスさえただよって、後の「見つけなければならない」ってのと合わせると、じつにこう、ツールのニーズによって道具化されてしまう人間の悲哀がよく伝わる、ドナドナ的な言いっぷりのような気がしてきます。
そして、そんな怖い怖いナビゲーションにはどんなものがあるのかって、
(以下、例によって、読書ノートなので自分の頭に入れやすいように勝手な要点抽出フィルターがかかってます。)
1.移動。アプリケーションを構成する複数のウィンドウ間、あるいはウィンドウ内の複数のペーン間の。
2.探索。ツール、コマンド、メニュー、あるいはオブジェクト、コンテンツ、データの。
3.切替。オブジェクト、コンテンツ、データを表示する範囲または粒度の。
と、こう列挙されるわけですよ。
あらためてこれらのひとつひとつに思いを馳せてみてください。ユーザーエクスペリエンスなんつって、ほとんどナビゲーションがらみで埋め尽くされているようなもんじゃありませんか。
これが全部、ゴールに直接向かうわけではない、間接税的な操作だっていうんですから、たとえ400円になったとしてもタバコのほうがよっぽど良心的なかんじがします。
で、思うんですよ。じゃあ、ナビゲーションじゃない、無税の、つまり真にゴールダイレクテッドなインタラクションって逆に何？
上のナビゲーションの定義に習って思いっきり大きく出ると、オブジェクトとかコンテンツとか、とにかく何らかのデータの表現を確認して、これになにか手を加え、その結果、データがどんなふうに変化したのかをまた確認すること、この往復、循環、ってことになるでしょう。
ナビゲーションのタイプのうち、上記の2.も3.も抜いてですよ、ほんとにそこだけ純化して取り出したら、これ、非常に僅かな、希少なもんなんじゃないですか。これを純インタラクションとでも呼んで、どっかに含有率を書いといてほしいですね。
いや、しかし、だからといって、虐げられた民びとよ立ち上がれ、今こそこの圧政に反旗を翻せ、とかって話じゃないんですよ。だってこれは、いわば、その純インタラクションの本性がもたらしている宿命ですからね。逃れることはできません。
つまり、僅かとはいえ（いや、含有率とは関係なく）、純インタラクションの全体は、デバイスの表示領域に入りきらないほどデカいわけです。だから常に部分的にしか取り扱うことができず、そのために上記の移動、探索、切替が必要になっちゃって、結果、インタラクションのほとんどがナビゲーションになってしまうということですもんね。
ほんとにもう、インタラクションデザインって、この宿命をどう受け入れるかについてのデザインだと言い切っちゃいたくなるくらいのもんで。ですから、インタラクションデザインの戦術レベルでの指針は、ユーザーの視覚、認知、記憶、運動にかかる負荷を下げ、フロー状態を良好に保つってことだと思うんですが、そうする上で障害として立ちはだかってくるのは、大抵、ナビゲーションがらみということになるはずです。
そのために、--- つまりナビゲーションの氾濫から純インタラクションを守るために --- about face 3 が立てた作戦はこうです。
●永久オブジェクト
どんなにシステムの状態が変化しても、けっして消えてなくならないものを用意し、これを一番はじめに印象づけておこう。
永久オブジェクトこそ、すべてのナビゲーション起点であり、次にとりうる選択肢を常に示している道しるべであり、そして、いよいよというとき、最後に頼るべき縁でもあります。
たとえば、システムと同じ寿命を持つトップレベルのウィンドウ、グローバルナビゲーション、デバイスの物理的なボタンとかね。
●位置情報
全体像と現在位置をいつでも知ることができるようにしておこう。
その方法は、今、まさに部分的に取り扱っているオブジェクトの性質に合わせて、いろいろな手口を考えておく必要があるでしょう。
たとえば、Webサイトならブレッドクラム。画像編集ソフトなら、現在表示している範囲を縮小された全体像中に矩型で示すオーバービュー。ウィンドウシステムでは、現在表示している位置と範囲を、全体に対する相対的な長さで表現してもいるスクロールバーとかね。
●自然な対応関係と構造
純インタラクションにおいて、ゴール達成を容易にするための交換条件としてまあまあ見合う、ということならともかく、一介のナビゲーション風情が、自分のために新しいものの見方や習慣をユーザーに押しつけるなんてことがないようにしよう。
ありがちなのが、車のウィンドウを開閉するボタンが縦一列に四つ並べられている場合、右後部座席のウィンドウを開閉するには何番目のボタンを押したらいいでしょうか？ --- 的なレイアウトの対応関係にみられる鈍感さ。
あるいは、時系列のソーティングの方向を、「昇順」「降順」というデーターベース用語で選ばせるような、ラベルと機能の対応関係にみられる普通の人にとっては不自然な実装モデルの押しつけ。
それから GoF のコンポジットパターンのような、同型のオブジェクトが入れ子になるような階層構造なんかも、マトリョーシカ的な玩具以外に現実世界ではまずありえなくて不自然。そもそも、ほとんどの人は深い階層構造を辿るような移動、探索、切替を現実世界で体験したことがない、とかね。
●ペルソナへの適応
連れていくべき場所、ユーザーが見つけなくてはならないオブジェクト、ツール、データを減らす、というか、そのうちでも、普段から意識しておくべきものを極力減らしておこう。
簡単に言えば、いつもそばにあるものと、深いところに隠しておくものとに仕分けること。仕分けの基準は、
・使用頻度
・労力と報酬の見合い
・転位の度合い（その操作によってデザイン対象の状態がどれほど大きく変化するか？）
・危険度（失敗した場合の取り返しのつかなさ）
となるんですが、いずれも、ペルソナの性質、ニーズ、ペルソナが活動するコンテクストに深い関わりを持ちます。言い換えれば、ペルソナに合わせてインタラクションを整理してみようってことです。
よく使うものは当然、いつもそばに置いておきたいですよね。注意したいのは、深いところに隠しておくもの。これには、深いところに隠して"おいても"いいものと、隠して"おいたほうが"いいものと二種類ある。
労力と報酬の見合いがとれ、（かつ、それほど頻繁に使わないものなら、）深いところに隠して"おいても"いい。
転位の度合いや危険度が高いものについては、一般に、深いところに隠して"おいたほうが"いい。とかね。
こうして、実際にはその数を減らすことはできなくても、なるべく、なるべく、ナビゲーションのやつらにユーザーの心を奪われないように気をつけて、ユーザーの心に占める純インタラクションの割り合いをもっと上げていこうよ、ということですね。
純インタラクション --- そう、今夜は特別に、My Sweet Soul Interaction って呼ぼう。My Sweet Little Interaction のほうがいいかな？
2009年12月11日金曜日
ツールのニーズ
About Face 3 読書ノートの 21。
「ゴールの達成には直接的には貢献しないが、それをしなければゴールを達成できない」ような作業を About Face 3 は「間接税的な作業」と呼んでます。たとえば、遠い目的地を目指すのに車を使いたい。しかし、車を使うには、まずガレージのシャッターを上げなくちゃいけない、ああ、めんどくさい。とかね。
「ゴールの達成には直接的には貢献しないが、それをしなければゴールを達成できない」ような作業を About Face 3 は「間接税的な作業」と呼んでます。たとえば、遠い目的地を目指すのに車を使いたい。しかし、車を使うには、まずガレージのシャッターを上げなくちゃいけない、ああ、めんどくさい。とかね。
PCでいえば、まず、ソフトウェアをインストールしなくちゃいけない、ネットワークの設定をしなくちゃいけない、OSが拡張デバイスをうまく認識するように設定してあげなくちゃいけない、ファイルのバックアップのことを心配しなくちゃいけない、とっちらかったフォルダを漁って目的のファイルやアプリケーションを探し出さなくちゃいけない、ウィンドウの位置やサイズがしっくりくるようにいちいち調整しなくちゃいけない、初心者向けのおせっかいなヒントを一撃必殺の早業で消したり、いつまでもご親切なウィザードにつき合わされなくちゃいけない、煩雑な画面から必要な情報を、過剰な装飾の中から操作可能な領域を発見しなくちゃいけない、ナントカデスクだのナントカタウンだの、回りくどい喩えと機能の対応を推し量らなくちゃいけない、今、目の前に表示されている登録済みのメールアドレスを変更するために、わざわざ特別な画面に出向いて行かなくちゃいけない、理不尽であるか、あるいは取るに足りないささいな事柄に関する警告に悩まされ、挙げ句の果てに、さもこちらに落ち度があるかのように扱われる屈辱に耐えなくちゃいけない、って、いっきにまくし立ててみましたが、これみんな間接税的な作業の具体例として、About Face 3 が告発していることです。
そして言います。こういうの全部、いってみりゃアンチゴールダイレクテッドなインタラクションでしょ、できることなら根こそぎ取り除きたいよね。それが無理なら、せめてできるだけ目立たないように、できるだけの手を打ちたい。そのためにはまず、こういうことに意識的に、そして、敏感にならなきゃだめだよね、と。
なにかにつけ、そんなことがめんどくせえようなら死んじまえ、が口癖だった父に恐々としながら育ったぼくは、だから、生来、インタラクションデザインには実は不向きなのではないかとも思うのですが、ま、しかし、生まれつきや三つ子の魂だけでやっていける人生なんてないわけですから、ここはひとつがんばって、年齢不問で成長していきたいです。
さて、そう思って、間接税的な作業について取り上げているChapterを何度も繰り返し読んでいると、こうした間接税的な作業を生む温床には次のようなものがあることが自ずと腑に落ちてきます。
ひとつ、ユーザーの習熟度の多様性を無視すること
（中上級者をいつまでも初心者扱いするとか）
ひとつ、ポスチュアのあり方に無頓着であること
（本来、支配者的なポスチュアであるべきなのに、単発的なポスチュアをとってしまうとか）
ひとつ、蓋然性より可能性を重視すること
（ほとんど起こらないことに備えて、普段の作業をぎこちないものにしたり）
ひとつ、フェイルセーフではなく、フールプルーフで対応しようとすること
（やり直しがきくようにできないものだから、失敗ゼロを目指して作業をがんじがらめにしたり）
ひとつ、実装モデルを押しつけること
（入力と出力はつねに別系統とか）
ひとつ、単にさぼること
（機械でできるはずの推論と記憶を放棄してすましているとか）
しかしこれ、間接税的、と表現するのはどうなんでしょうね。About Face 3 が念頭に置いているのは消費税的なものみたいですけど。いや、わかりますよ。商品の対価に交換価値、使用価値以上の部分がふくまれているかんじ。でも、税メタファーじゃ、売り手（ツール）、買い手（ユーザー）とは別に、上前をはねてるやつが他にいそうな雰囲気じゃないですか。しかし、ここで悪いやつだとつるし上げたいのは、政府みたいなものじゃなくて、目の前でいけしゃあしゃあと不当に値をつり上げてる店のおやじのほうなんですよね。
一方で、このChapterに「ツールのニーズ」という言葉が出てくるんですけど、こっちのほうが、この問題を言い表すのにふさわしいような気がしました。ユーザーのニーズじゃなくて、ツールのニーズ。
ニーズって、あらためて言うまでもないことですけど、要するに、ゴールに達っするために何かを必要とすることですよね。ゴールに自足的に達することができないとき、不足分を補う何かを他に求めること。
何か思い定めたゴールがあるとして、しかし徒手空拳ではかなわないので、人は何か道具を探す。自足的にゴールを達成できないので、道具に対するニーズが生じる。一方で、道具のほうでも、実はそれ自体としてあるゴールを持っている。それは、つまり、ユーザーのゴール達成を支援することですね。だからこそ道具は道具としてありえるわけですけど、そのゴールを自足的に達成できないとき（間接税的な作業を生む温床）、道具にもニーズが生じてしまう。つまり、道具のほうが、今度はユーザーを道具として使おうとするわけです。これが間接税的な作業の正体。
しかも、それをうまいこと、ユーザー自身の発意による、ユーザー自身のゴールに向かうための仕事であるように見せかけるんですよね。質が悪い。案外、インタラクションデザインって、この倒錯を巧妙にカモフラージュするテクニックとして発達してきた部分も少なからずあるんじゃないでしょうか。
だから、冒頭でまくしたてたようなことに対する感性を研ぎ澄まして、目ざとく告発できるようになったあかつきには、「それって、ツールのニーズでしょ？」というセリフで決めてみたいです。ぼくは。
-----------------
sent from W-ZERO3
2009年11月18日水曜日
みんなのフロー状態を大切にしましょう
About Face 3 読書ノートの 20。
なんか作業にだーっと夢中になっちゃって、気がついたら、うわ、もうこんな時間かよ！？ハラヘッター、みたいなことがあるだろう。そういうのをフロー状態っていうんだよ。と娘に話したら、ああ、ウラシマ効果？と返されました。いや、そのフロウじゃねえよ、って。しかし、まあ、でも、うん。そうだったらどんなにいいだろうね。だけど時間ってやつは誰の身の上にもじつに公平に流れては去っていくものなんだよ。娘よ。
だからこそ、フロー状態ってのは実にかけがえのない大切なひとときなわけで、いろいろごちゃごちゃいっとりますが、インタラクションデザインの要諦はつまり、いかにして人をフロー状態に導くことができるか、そして、いったん始まったフロー状態を途切れることなく全うさせることができるかにかかっているといってもいいわけですね。
そうしたインタラクションデザインの到達点を、About Face 3 は、オーケストレーションと表現しています。
といっても、なにも美しいプレイで人々を魅了しろっていうんじゃない。そうじゃなくて、ユーザーとのコミュニケーションがオーケストレーションになってなきゃだめ、つまり、全体的に調和のとれたものになってなきゃだめだよ、ってことなんです。
例によってそうするための原則がずらっと並んでいるのですが、かいつまんでいうと、複雑なものをうまくバランスして調和をとっていくっていうより、要するに必要以上に出しゃばるな、そうすりゃ自然に調和もとれるさ、ってかんじです。
たぶんね、ロールモデルは高倉健ですよ。これ。いわく、
「いかに優れたものでも、インターフェイスは少ない方がよい」
「オーケストレーションされたユーザーインターフェースは透明である」
しぶいですね。しびれますね。不器用なのはまずいかも知れませんが、美しい魅惑のプレイなんてのは真逆の話ですね。
もうすこし具体的な水準で、16個、原則が挙げられているんですが、読み込んでいくと、言いたいことは結局、次の４つのポイントに収斂していくようです。
・なるべく直接操作で
・なるべくモードレスに
・なるべく蓋然性に合わせて
・なるべく固まらないように
そうすると、必要以上に出しゃばらずに済む。それぞれどんなかんじかというと ... 。
■ なるべく直接操作で
インタラクションというと、双方向の対話的インターフェースってかんじがしますけれども、けっしてそうじゃないよと。
「理想のインタラクションは対話のようなものではなく、むしろ道具を使うのに似ている。大工が釘を打つときに、釘についての議論をハンマーとしたりはしない。ハンマーで釘を打つのだ。」
やりたいことをいちいち問い質されながらフロー状態に入れる人なんてそうそういないでしょう。
だから、初心者でなくなった後でも強要されるウィザード形式には閉口しますし、いちいち開くのが面倒な設定画面でしか目の前のオブジェクトを操作できないようなインターフェースでは仕事になりません。メニューを辿るという行為も、やりたいことをいちいち問い質されているようなもんですからね。
煩わしいし、なにより腹が立つ。May I help you? は、低姿勢なようでも実は上から目線なんですよね。おれはお前を使うことはあっても、助けてもらうつもりは毛頭ないってなもんです。ちなみに、About Face 3 は全編を通じて特にこの点に手厳しいんです。一体何があったんだとそれこそ問い質したくなるくらい。相当ご立腹の様子です。
■ なるべくモードレスに
人のせっかくのフロー状態を阻害するものの親分が、かの悪名高い「モード」ってやつなのかも知れませんね。
モードってのは、ひらたくいうと、アプリケーションがあるひとまとまりのタスクの遂行だけに特化した状態に入ることです。それはインタラクションをシンプルに見せかけたり、一連のインタラクションを通じたシステムやデータの一貫性を保つために、まあ、よかれと思って仕組まれてるわけですが、でも、その副作用がなかなか見過ごせない。
というのも、モードの中でタスクを遂行すること自体は立派にゴールダイレクテッドでも、あるモードの中に入ること、そこから出ること、他のモードに入ること、目下のモードが何であるか確認すること、こういったことは、ゴールの達成に直接貢献するわけではないんですね。
いってみりゃ、モードに頼ってゴールを目指す以上は、どうしても支払わなければならないコスト。入場料、通行料、税金みたいなもの。しかし、これらがやけに目だってきちゃうと、そりゃもう、本来の目的からは逸れているわけですからバンバン意識を寸断しちゃって、とてもフローどころではない騒ぎになります。
ぼくの理解では、16個の原則のうち7個は、このモード関連ですね。これらを読み込んでいくと、About Face 3 は、モードが発生しそうな箇所として暗に次の3つを念頭に置いているようです。
・オブジェクトの状態やプロパティを確認するとき
・ツールを切り替えるとき
・タスクの遂行結果のフィードバックを受け取るとき
オブジェクトのプロパティや状態の確認については、とにかくできるだけその場で、つまりモードのない状態で確認できるようにしたい。その場で確認しきれずモードに頼る場合でも、やっぱりできるだけ手近なところで。つまり、そうするために何段階もメニューを辿らなければいけないようなハメにユーザーを陥れないようにとアドバイスしています。
ツールの切り替えについては、もうこれはモードに頼るのもやむなし。しかし、やっぱりこれもできるだけ手近なところで、ですね。「机から立って廊下に鉛筆を探しに行くような」ことがないようにしたい。それから、繰り返しになりますが、ツールはあくまでも直接操作をモットーに。ツールを使うことの実態が質問攻めであるようなことはあってはならない。あと、使い終わったツールをユーザーに片付けさせるような真似もしちゃいけない。
フィードバックについては、とにかくモーダルなダイアログボックスの使用を極力控えよと、これに尽きます。タスクってのは、ツールによってオブジェクトに何かしら働きかけるってことなんですから、その結果は、オブジェクトのプロパティや状態の確認として、モードレスに察知できるのが一番。
ところで、インタラクションにおけるモードとモードレスに関しては、こちらに深い考察があります。
Modeless and Modal
http://modelessandmodal.wordpress.com/
結構なペースで日々更新されているんですが、これはぜひ、ドアタマから一読されることをオススメします。ぼくは大変お世話になっています。これを読んでなかったら、About Face 3 のこの章、「オーケストレーションとフロー」のところなんて、ちゃんと読み込めなかったかも知れません。
■ なるべく蓋然性に合わせて
蓋然性と可能性の混同はよくいわれますけれども。可能性はありえるかありえないか、蓋然性はありえることが実際に起こる確率が高いか低いかですね。
About Face 3 は、UMLのユースケース図って、各ユースケースが発生しうる確率を無視して、すべて同格で記述してしまうので、開発領域を明示することには向いていても、ユーザーをゴールへダイレクトに導くためのインタラクションをデザインするためのツールとしては向いていないとかいってますね。
一方で、コンテクストシナリオなら、ごく自然に発生しうる確率が高いユースケースに重点を置いて検討することができると。インタラクションデザインにおいては、蓋然性と可能性の混同は致命的だといわんばかりです。
蓋然性がらみで About Face 3 によく出てくる例は、何時間もかけて書いたドキュメントについて「保存しますか」とか聞くな！ってやつ。この状況で「保存しない」を選ぶようなやつがいる可能性はそりゃあるよ、でも、蓋然性はほとんんどないだろ？毎回そういうことを馬鹿正直に尋ねるんじゃないお前は、という話です。
こうした、ほとんど蓋然性のない状況に関わる質問やメニューもまた、ユーザーのフロー状態の邪魔になるんですね。必要になったらこっちから相談するから、それまで黙っててよ、ってかんじです。
また、About Face 3 は、印刷することを指示すると、毎回毎回、プリンタの設定を尋ねてくるのもいかがなものか、なんてことも言っています。プリンタの設定なんて一回したらそうそう変更するもんじゃないでしょ。と。コマンドを使用する蓋然性は高くても、コマンドのコンフィギュレーションを行う蓋然性は低い。もしそうなら両者は分離しておくべきじゃないか、とかね。
あと、非常ボタンの類、パイロットの脱出ボタンとか。これを使うことなんてめったにないんだから、また、うかつに触ると危ないんだから、FMラジオのスイッチとキャビンライトのスイッチの間に配置するなんてことは絶対やめてくれ、なんてね。
実は、今、これ、マンガ喫茶で描いてるんですけど、キーボードにPCの本体の電源を落とすボタンがついてて、それが普段会社で使っているキーボードだとDeleteボタンの位置にあるんですよ。さっきから書き損じを削除するつもりでPCを2回も落としちゃいました。しかも、確認画面は一切なしで、あれよあれよと。そこは、ほんとに落とすのかどうか聞いてくれよ頼むから！
まあ、そういうことです。
逆に蓋然性の高い状況に関する配慮はウェルカム。たとえば、操作履歴に基づいて、よく使うツールをより目立つところに置くとかね。
■ なるべく固まらないように
最後のこれはもう、言うまでもありませんね。上述の原則をきっちり守っても、何かする度にいちいち待たされたんじゃあフローもへったくれもない。仮に待たせるようなことになったら、そういう状態にこれから入ることをユーザーに正直に打ち明けて、ちゃんとキャンセルもできるようにしておくこと。
待ってもらえるならどれくらい待たせるかを明らかにして、だいぶ待たせることになるなら、ユーザーがその間どうか他のことでフロー状態に入ってくれるように祈ること。
ま、そんなところです。
また間違ってPCの電源を落としちゃわないうちに、今日はこのへんにしときます。
2009年10月22日木曜日
無名の質
About Face 3 の読書ノートのつづきで、次はデザインパターンのところを書こうかな、と思ったんですが、この部分、結構あっさりしてまして。
デザインパターンといえば、GoFのやつが有名だけど、インタラクションデザイン方面では「デザイニング・インターフェース」なんてのがあるよ。そもそもデザインパターンって発想はアレグザンダーの建築論からはじまるわけだけど、インタラクションデザインの場合は、うまく作るため、というより、みんなに喜ばれるものを作るためにパターンを活用しようという点で、GoFのやつ（ソフトウェア工学）よりアレグザンダーのもの（建築学）により近いよね。とかなんとか。
どうもここは、なるほど、としか言えそうもないのでしれっとスルーの方向で、ということにしたんですけど、ただ、そういえば、アレグザンダーのデザインパターンって実際どんなものなのか、急に気になってきたんですね。なんとなく話には聞いているけど、実はちゃんと見たことがなかったんです。
それなら、素直にアレグザンダー本を読めばいいんですが、ちょっとお高いので、まずは入門編をってことで「パターン、Wiki、Xp」を手にとってみました。
この本、デザインパターン、Wiki、エクストリームプログラミングのそれぞれの発展史なんですけど、アレグザンダーの思想がそれらに与えた影響を丹念に追っていくといった趣向で書かれているですね。だから、アレグザンダー入門としても読める。
読んでみると、アレグザンダーのことだけじゃなく、デザインパターン、Wiki、エクストリームプログラミングについても、知らないことばっかり書いてあって、結構、びびりました。
それぞれいっとき夢中になったものばかりなんですが、実際上の功利ばかり追いかけて、それらがよって立つ由来や思想的な背景に思いを馳せるなんてことはまったくなかったもので。それにしても、デザインパターンだけじゃなく、エクストリームプログラミングやWikiも、アレグザンダーの影響下にあったとは。隣の席の北橋くんから聞いた話だったら、うそつけ、このやろうの一言で片付けてしまいそうです。
この本によれば、デザインパターンやアジャイルな開発手法にも影響を与えたアレグザンダーの思想のキーワードは、「無名の質（QWAN, Quality Without A Name）」ってやつなんですね。
入門書を読みたての生半可をはじめにお断りして言いますが、アレグザンダーが「無名の質」と呼ぶのは、要するに、古い街並みにみられるような、おそらく時間をかけて自然に出来上がったと思われる、なんとも言えない具合のよさ、みたいなことです。
それは、うまく定義することができないし、はっきり名指すこともできない。しかし、その場に居合わせれば、たしかに感じ取ることができるので、あるある話としては、ずらっと具体例を並べ立てることができる。でも、それ全部ひっくるめて何て言うの？とあらためて問われると、やっぱりうまく言い当てることができない。年甲斐もなくはしゃぎながら「イーンダヨ、イーンダヨ、ナンダカワカンナイケド、スッゴクイーンダヨ！」と言って回るしかない。
でも、結局、デザインとして一番いいのは、そういうものなんじゃないかと。
そこで、アレグザンダーは、そういう「無名の質」を、なんとか人工的な建築物にも持ち込むことができないかと考えるんですよね。
自然の成り行きにまかせて「無名の質」が出来上がるのをただ待つのではなく、どうにかして人為的に生産してしまおうというわけですよ。じつに大それてますね。しかし、そうして、ソフトウェアのデザインパターンやアジャイル開発プロセスにもつながるような、さまざまな原則や実践方法を編み出していったんですね。
だけど、「無名の質」って、やっぱりちょっと釈然としませんよね。
どうしても名付けられない何かなんていっちゃって、それって、「考えるな、感じよ。」式の神秘主義か、見えない何かに賭けるロマン主義かなんかじゃないの。真理や奥義のチラ見せで弟子を引っ張っていこうなんて古い手だなあ！とか言いたくなる向きも、実際少なくなかったようです。
この本もだいぶそこのところにひっかかっていて、最後、あとがきのところでは、「無名の質」はやっぱり難解すぎるとしながら、
「アレグザンダーはおそらく「読者に自分で考えてほしい」と思っていたのではないでしょうか」
なんて小学校の道徳のようなことをいってます。
まあでも、よし、それじゃあってことで、ぼくも自分で考えてみましたよ。
以下、アレグザンダーの著作に直接当たることもなしにこんなことを言う資格がないことは百も承知で言いますが、Quality Without A Nameを、「名付けられない質」じゃなくて、「名前を持たない質」と考えてみたらどうなんでしょうね。
もっとベタに言うと、「名前がないという属性を持つ何かについての質」。
名前っていうのは、コンテクストに依存しないで、つねに同じ対象を指示できるものだとしますよね。(哲学に可能世界と固有名の議論がありますね。)
すると、コンテクストに依存することによってしか存在することができない存在があるとしたら、それは名前を持たない、持つことができないといえるでしょう。
で、コンテクストに依存することによってしか存在することができない存在って、またややこしい、何だよそれ？ってことになりますけど、それは、もうコンテクストそのものですよね。
そう考えると、無名の質って、簡単に言えば、コンテクストそのものとしか言いようのないものの質ってことじゃないでしょうか。
それのいいやつを、アレグザンダーは自分たちの力で意志的に作りたいって言ってるんでしょう。
しかし、コンテクストってのはやっかいですよ。
それは関係性の無際限な広がりのことだし、いろんな観点から観察できるけど、ある一点からの観察では全体を把握することができないような全体性のことだし、さらに、つねに一回こっきりのものだし。
これは再現や再生産の対象には到底なりえませんよね。
設計図や雛形をもとにして計画的に作れるようなものではない。設計図や雛形をもとにコンテクストそのものを人為的に作ろうなんていったら、それは神をも恐れぬ悪魔の仕業ですよ。
当然、アレグザンダーは悪魔ではないので、直接「無名の質」を作ったりはしないわけです。
ただ、現に「無名の質」を作り出している自然生成のプロセスをよく観察して、シミュレートしてみたらどうかと。長い時間をかけて積み重なったたくさんの偶然の結果としてある自然生成を、リーズナブルにシミュレートする方法を考えてみようと。
アレグザンダーがデザイナーとして直接手を下したのは、そこのところですよね。シミュレートをうまくやるために必要な道具と作業のデザイン。それができたら、自分でも自然生成のシミュレーション環境に飛び込むだけ。
* * *
って、どうです。これで丸くおさまっているかんじじゃないですか。
でも、いろいろググってみたかんじでは、これは確実に「無名の質」の誤読なんですけどね。
デザインパターンといえば、GoFのやつが有名だけど、インタラクションデザイン方面では「デザイニング・インターフェース」なんてのがあるよ。そもそもデザインパターンって発想はアレグザンダーの建築論からはじまるわけだけど、インタラクションデザインの場合は、うまく作るため、というより、みんなに喜ばれるものを作るためにパターンを活用しようという点で、GoFのやつ（ソフトウェア工学）よりアレグザンダーのもの（建築学）により近いよね。とかなんとか。
どうもここは、なるほど、としか言えそうもないのでしれっとスルーの方向で、ということにしたんですけど、ただ、そういえば、アレグザンダーのデザインパターンって実際どんなものなのか、急に気になってきたんですね。なんとなく話には聞いているけど、実はちゃんと見たことがなかったんです。
それなら、素直にアレグザンダー本を読めばいいんですが、ちょっとお高いので、まずは入門編をってことで「パターン、Wiki、Xp」を手にとってみました。
この本、デザインパターン、Wiki、エクストリームプログラミングのそれぞれの発展史なんですけど、アレグザンダーの思想がそれらに与えた影響を丹念に追っていくといった趣向で書かれているですね。だから、アレグザンダー入門としても読める。
読んでみると、アレグザンダーのことだけじゃなく、デザインパターン、Wiki、エクストリームプログラミングについても、知らないことばっかり書いてあって、結構、びびりました。
それぞれいっとき夢中になったものばかりなんですが、実際上の功利ばかり追いかけて、それらがよって立つ由来や思想的な背景に思いを馳せるなんてことはまったくなかったもので。それにしても、デザインパターンだけじゃなく、エクストリームプログラミングやWikiも、アレグザンダーの影響下にあったとは。隣の席の北橋くんから聞いた話だったら、うそつけ、このやろうの一言で片付けてしまいそうです。
この本によれば、デザインパターンやアジャイルな開発手法にも影響を与えたアレグザンダーの思想のキーワードは、「無名の質（QWAN, Quality Without A Name）」ってやつなんですね。
入門書を読みたての生半可をはじめにお断りして言いますが、アレグザンダーが「無名の質」と呼ぶのは、要するに、古い街並みにみられるような、おそらく時間をかけて自然に出来上がったと思われる、なんとも言えない具合のよさ、みたいなことです。
それは、うまく定義することができないし、はっきり名指すこともできない。しかし、その場に居合わせれば、たしかに感じ取ることができるので、あるある話としては、ずらっと具体例を並べ立てることができる。でも、それ全部ひっくるめて何て言うの？とあらためて問われると、やっぱりうまく言い当てることができない。年甲斐もなくはしゃぎながら「イーンダヨ、イーンダヨ、ナンダカワカンナイケド、スッゴクイーンダヨ！」と言って回るしかない。
でも、結局、デザインとして一番いいのは、そういうものなんじゃないかと。
そこで、アレグザンダーは、そういう「無名の質」を、なんとか人工的な建築物にも持ち込むことができないかと考えるんですよね。
自然の成り行きにまかせて「無名の質」が出来上がるのをただ待つのではなく、どうにかして人為的に生産してしまおうというわけですよ。じつに大それてますね。しかし、そうして、ソフトウェアのデザインパターンやアジャイル開発プロセスにもつながるような、さまざまな原則や実践方法を編み出していったんですね。
だけど、「無名の質」って、やっぱりちょっと釈然としませんよね。
どうしても名付けられない何かなんていっちゃって、それって、「考えるな、感じよ。」式の神秘主義か、見えない何かに賭けるロマン主義かなんかじゃないの。真理や奥義のチラ見せで弟子を引っ張っていこうなんて古い手だなあ！とか言いたくなる向きも、実際少なくなかったようです。
この本もだいぶそこのところにひっかかっていて、最後、あとがきのところでは、「無名の質」はやっぱり難解すぎるとしながら、
「アレグザンダーはおそらく「読者に自分で考えてほしい」と思っていたのではないでしょうか」
なんて小学校の道徳のようなことをいってます。
まあでも、よし、それじゃあってことで、ぼくも自分で考えてみましたよ。
以下、アレグザンダーの著作に直接当たることもなしにこんなことを言う資格がないことは百も承知で言いますが、Quality Without A Nameを、「名付けられない質」じゃなくて、「名前を持たない質」と考えてみたらどうなんでしょうね。
もっとベタに言うと、「名前がないという属性を持つ何かについての質」。
名前っていうのは、コンテクストに依存しないで、つねに同じ対象を指示できるものだとしますよね。(哲学に可能世界と固有名の議論がありますね。)
すると、コンテクストに依存することによってしか存在することができない存在があるとしたら、それは名前を持たない、持つことができないといえるでしょう。
で、コンテクストに依存することによってしか存在することができない存在って、またややこしい、何だよそれ？ってことになりますけど、それは、もうコンテクストそのものですよね。
そう考えると、無名の質って、簡単に言えば、コンテクストそのものとしか言いようのないものの質ってことじゃないでしょうか。
それのいいやつを、アレグザンダーは自分たちの力で意志的に作りたいって言ってるんでしょう。
しかし、コンテクストってのはやっかいですよ。
それは関係性の無際限な広がりのことだし、いろんな観点から観察できるけど、ある一点からの観察では全体を把握することができないような全体性のことだし、さらに、つねに一回こっきりのものだし。
これは再現や再生産の対象には到底なりえませんよね。
設計図や雛形をもとにして計画的に作れるようなものではない。設計図や雛形をもとにコンテクストそのものを人為的に作ろうなんていったら、それは神をも恐れぬ悪魔の仕業ですよ。
当然、アレグザンダーは悪魔ではないので、直接「無名の質」を作ったりはしないわけです。
ただ、現に「無名の質」を作り出している自然生成のプロセスをよく観察して、シミュレートしてみたらどうかと。長い時間をかけて積み重なったたくさんの偶然の結果としてある自然生成を、リーズナブルにシミュレートする方法を考えてみようと。
アレグザンダーがデザイナーとして直接手を下したのは、そこのところですよね。シミュレートをうまくやるために必要な道具と作業のデザイン。それができたら、自分でも自然生成のシミュレーション環境に飛び込むだけ。
* * *
って、どうです。これで丸くおさまっているかんじじゃないですか。
でも、いろいろググってみたかんじでは、これは確実に「無名の質」の誤読なんですけどね。
2009年10月8日木曜日
インタラクションデザインの原則、の見取り図
About Face 3 読書ノートの19。
優れたインタラクションデザインには共通する特徴がある。はず 。クーパー目線でそれらをさらって、原則として打ち立ててみたのがこの本、といってもいいと思うんですが、PartIIの冒頭の chapter では、その原則の数々をゆるくまとめて、ざっと俯瞰して見せてくれています。
（本全体は26のchapterを3つのPartに分けた構成になっています。ちなみに今までの読書ノートはおもにPartIを対象にしていました。今回からPartIIに入ります。）
原則の、さらにその"まとめ"なんで、非常に耳触りのいい言葉が並んでいて、ツルツルと読めてしまうんですが、どうも一読しただけでは、はっきりとした手応えが得られないんですよね。ぼくの頭では。
そこで、自分なりに噛み砕いてみることにしました。自分なりにゆがむかもしれませんが、なにしろ自分の現場で使いこなすのが第一の目的ですから、まずはそれでいいことにします。
さて、原則にもいろいろな粒度がありまして。だいたい次の4つのレベルに分けて考えることができるといいます。抽象度が高い順に並べると、
レベル1. デザインの価値観に関する原則
レベル2. コンセプトに関する原則
レベル3. 振る舞いに関する原則
レベル4. インターフェースに関する原則
と、こうなります。
最初の「デザインの価値観に関する原則」なんですけど、これって他の3つと並べるようなものじゃないですね。経験から導き出された原則というより、戒律とか、カントの定言命法みたいなもんで、いわばデザインの神様の命令です。それを疑ったり、試したりしてはならない。ほかの原則たちもすべてここから導出されるか、または、その枠内でのみ存在を許されるか、みたいなかんじです。
いわく、それがデザインである以上は、
・倫理的であれ
・合目的的であれ
・実践的であれ
・エレガントであれ
と。もうすこし中身に踏み込むと、以下のようなかんじでしょうか。では、聖書でも読む気分でどうぞ。
人の権利や安全を脅かしたり、感情を害することのないよう細心の注意を払いなさい。何らかの点で必ず有益であり、どんなにわずかでも人類の進歩に寄与するものでなくてはなりません(倫理的)。
そして、いったい何のために存在し、誰のどんな目的に奉仕するのかを常にわきまえていることが肝要です。いかなる状況にあってもゴールダイレクテッドを旨としなさい(合目的的)。
それは現世において、あなたがた自身の手によって実現できるものでなければなりません。どんなにすばらしいアイディアであっても、神の奇跡を条件にしてはなりません(実践的)。
行いの正しさのみをもって神の御心にかなうと考えてはなりません。もっとうまくやりなさい。もっともシンプルで、もっとも調和のとれたものを作りなさい(エレガント)。
(念のためいっときますけど、この通り本に書いてあるわけじゃないですよ。ぼくの勝手なまとめです。)
個人的に胸に手を当てて考えてみると、案外、「倫理的」というところが穴だと思いました。実際、つい調子に乗って畜産業メタファーの紳士録とか作っちゃうほうです。ぼくは。いけませんね。ここで懺悔しておきます。
ともかく、このデザインの神様の4つの命令をよく守るために、続く「コンセプト」「振る舞い」「インターフェス」に関する原則が経験から見出されてきた、そういう構造で捉えるとわかりやすいと思います。
ただ、残りの3つもなんだかぼんやりしているんですよね。そのままでは。
「コンセプト」って何だ？ それから、「振る舞い」と「インターフェース」をどう分けて考えるんだ？ってなかんじです。
まず、「コンセプト」。各レベルの原則について、本書内のどのchapterで触れているかが案内されているんですが、「コンセプト」の部分は、
・Chapter3 初心者、上級者、中級者
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
ということです。
Chapter3は、要するに、ユーザーのあり方(ほとんどの人は中級者)、Chapter9は、逆にデザイン対象のあり方(支配的なアプリ、単発的なアプリ、デーモン的なアプリ)、で、Chapter10は、両者の理想的な関係の話です。
ということは、これ、デザイン対象の存在のしかたに関する原則ということですね。制作のプロセスでいえば企画から要件定義のところ、それが何なのか、何のためのものなのか、誰をどんなふうに喜ばせるものなのか、という概念をデザインする段階の原則。
そういえば、えらそうに「この製品のコンセプトは ...」 とかいうときの「コンセプト」がこれでしたね。
よしわかった。次。「振る舞い」。
ここにあたるのは、ちょっと多いですけど、
・Chapter8 優れたデザインの総合: 原則とパターン
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
・Chapter11 間接税的な操作を取り除く
・Chapter12 よき振る舞いのデザイン
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
・Chapter15 検索: データをもっと簡単に手に入れるために
・Chapter16 アンドゥを理解する
・Chapter17 ファイルとセーブを考え直す
・Chapter18 データ入力の改良
・Chapter19 ポイント、選択、直接操作
だそうです。
ここらへんは、これから読書ノートを作っていくところなんですけど、まあ、前に一読して了解した範囲で説明を試みますと、以下に挙げるような、コンピューター・ソフトウェアが行う基本的な仕事を遂行する上で、人間によりよく奉仕するためにとるべき配慮やお行儀の話なんですね。
・データの検索
・データの操作（選択、入力、やり直し）
・データの永続化
・GUI(ポインティングシステムとウィンドウシステム)
たとえば、いちいち保存しますか？なんて聞くな、するに決まってんだろ？どういう根性してるんだ、おまえ。とかね（インターフェースではなくて、そもそもの根性のレベルの問題）。
アラン・クーパーは既存のソフトウェアのこのレベルでの出来に相当イラついているので、ここらあたりの舌鋒は異様に鋭くて読んでいて楽しいです。
これ、いってみればソフトウェアの"資格"を問うているんですよね。あまりにも有名なハードボイルド小説の主人公のセリフにならっていえば、「優しくなければ生きていく資格がない」ってやつです。ちなみに、生き抜く力(「強くなければ生きていけない」)のほうは、上の「コンセプト」のところでしょう。
で、最後、「インターフェース」。
ここに当たるのはおもに、
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
で説明されている原則です。
生き抜く力があるか（コンセプト）、生きていく資格があるか（振る舞い）についての原則をよく守り、それぞれの水準でのデザインがうまくいったとしても、それがユーザーにちゃんと伝わらなければ意味がない。
ユーザーが、こいつはたしかに有用で、しかも、優しく接してくれるうれしいやつだという脳内モデルを育んでくれるのは、つねに具体的なインターフェースの操作によるインタラクションを通じてのことです。これが下手だと元も子もない。そのためにいろんな手管を使うわけです。
たとえば。
その存在のありようをなるべく効率的に了解してもらうためには、共有しているはずの文化的背景を当てにしたり（メタファー）、すでに一般化している慣習に従ったり（イディオム）、ヒトの知覚的な本能と経験則を利用したり（アフォーダンス）します。そしてそうする上で従うべき原則があります。
一方、行儀のよい振る舞いも、結局は、より小さなインタラクションの積み重ねです。そして、GUIの場合、インタラクションはビジュアル・インターフェースの状態の変化として表現されていきます。そこでは、ユーザーの視覚と認知と運動と記憶になるべく負担をかけないように配慮すべきなのですが、そのための原則がまたあります。
ってね。なるほど、これで「振る舞い」と「インターフェース」をどこでどう分けるのかがわかりました。
さて、以上をまとめてみますと、
・まず、デザインの神様の命令がある。
・その命令にしたがって、存在する意義と資格をデザインするための原則がある。
・さらに、その存在をよりよく表現するための原則がある。
ということになるでしょうか。これでぼく自身はすっきりしちゃいました。
一応、そんな見取り図を頭に入れて、続きを読んでいきたいと思います。
優れたインタラクションデザインには共通する特徴がある。はず 。クーパー目線でそれらをさらって、原則として打ち立ててみたのがこの本、といってもいいと思うんですが、PartIIの冒頭の chapter では、その原則の数々をゆるくまとめて、ざっと俯瞰して見せてくれています。
（本全体は26のchapterを3つのPartに分けた構成になっています。ちなみに今までの読書ノートはおもにPartIを対象にしていました。今回からPartIIに入ります。）
原則の、さらにその"まとめ"なんで、非常に耳触りのいい言葉が並んでいて、ツルツルと読めてしまうんですが、どうも一読しただけでは、はっきりとした手応えが得られないんですよね。ぼくの頭では。
そこで、自分なりに噛み砕いてみることにしました。自分なりにゆがむかもしれませんが、なにしろ自分の現場で使いこなすのが第一の目的ですから、まずはそれでいいことにします。
さて、原則にもいろいろな粒度がありまして。だいたい次の4つのレベルに分けて考えることができるといいます。抽象度が高い順に並べると、
レベル1. デザインの価値観に関する原則
レベル2. コンセプトに関する原則
レベル3. 振る舞いに関する原則
レベル4. インターフェースに関する原則
と、こうなります。
最初の「デザインの価値観に関する原則」なんですけど、これって他の3つと並べるようなものじゃないですね。経験から導き出された原則というより、戒律とか、カントの定言命法みたいなもんで、いわばデザインの神様の命令です。それを疑ったり、試したりしてはならない。ほかの原則たちもすべてここから導出されるか、または、その枠内でのみ存在を許されるか、みたいなかんじです。
いわく、それがデザインである以上は、
・倫理的であれ
・合目的的であれ
・実践的であれ
・エレガントであれ
と。もうすこし中身に踏み込むと、以下のようなかんじでしょうか。では、聖書でも読む気分でどうぞ。
人の権利や安全を脅かしたり、感情を害することのないよう細心の注意を払いなさい。何らかの点で必ず有益であり、どんなにわずかでも人類の進歩に寄与するものでなくてはなりません(倫理的)。
そして、いったい何のために存在し、誰のどんな目的に奉仕するのかを常にわきまえていることが肝要です。いかなる状況にあってもゴールダイレクテッドを旨としなさい(合目的的)。
それは現世において、あなたがた自身の手によって実現できるものでなければなりません。どんなにすばらしいアイディアであっても、神の奇跡を条件にしてはなりません(実践的)。
行いの正しさのみをもって神の御心にかなうと考えてはなりません。もっとうまくやりなさい。もっともシンプルで、もっとも調和のとれたものを作りなさい(エレガント)。
(念のためいっときますけど、この通り本に書いてあるわけじゃないですよ。ぼくの勝手なまとめです。)
個人的に胸に手を当てて考えてみると、案外、「倫理的」というところが穴だと思いました。実際、つい調子に乗って畜産業メタファーの紳士録とか作っちゃうほうです。ぼくは。いけませんね。ここで懺悔しておきます。
ともかく、このデザインの神様の4つの命令をよく守るために、続く「コンセプト」「振る舞い」「インターフェス」に関する原則が経験から見出されてきた、そういう構造で捉えるとわかりやすいと思います。
ただ、残りの3つもなんだかぼんやりしているんですよね。そのままでは。
「コンセプト」って何だ？ それから、「振る舞い」と「インターフェース」をどう分けて考えるんだ？ってなかんじです。
まず、「コンセプト」。各レベルの原則について、本書内のどのchapterで触れているかが案内されているんですが、「コンセプト」の部分は、
・Chapter3 初心者、上級者、中級者
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
ということです。
Chapter3は、要するに、ユーザーのあり方(ほとんどの人は中級者)、Chapter9は、逆にデザイン対象のあり方(支配的なアプリ、単発的なアプリ、デーモン的なアプリ)、で、Chapter10は、両者の理想的な関係の話です。
ということは、これ、デザイン対象の存在のしかたに関する原則ということですね。制作のプロセスでいえば企画から要件定義のところ、それが何なのか、何のためのものなのか、誰をどんなふうに喜ばせるものなのか、という概念をデザインする段階の原則。
そういえば、えらそうに「この製品のコンセプトは ...」 とかいうときの「コンセプト」がこれでしたね。
よしわかった。次。「振る舞い」。
ここにあたるのは、ちょっと多いですけど、
・Chapter8 優れたデザインの総合: 原則とパターン
・Chapter9 プラットフォームとポスチュア
・Chapter10 オーケストレーションとフロー
・Chapter11 間接税的な操作を取り除く
・Chapter12 よき振る舞いのデザイン
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
・Chapter15 検索: データをもっと簡単に手に入れるために
・Chapter16 アンドゥを理解する
・Chapter17 ファイルとセーブを考え直す
・Chapter18 データ入力の改良
・Chapter19 ポイント、選択、直接操作
だそうです。
ここらへんは、これから読書ノートを作っていくところなんですけど、まあ、前に一読して了解した範囲で説明を試みますと、以下に挙げるような、コンピューター・ソフトウェアが行う基本的な仕事を遂行する上で、人間によりよく奉仕するためにとるべき配慮やお行儀の話なんですね。
・データの検索
・データの操作（選択、入力、やり直し）
・データの永続化
・GUI(ポインティングシステムとウィンドウシステム)
たとえば、いちいち保存しますか？なんて聞くな、するに決まってんだろ？どういう根性してるんだ、おまえ。とかね（インターフェースではなくて、そもそもの根性のレベルの問題）。
アラン・クーパーは既存のソフトウェアのこのレベルでの出来に相当イラついているので、ここらあたりの舌鋒は異様に鋭くて読んでいて楽しいです。
これ、いってみればソフトウェアの"資格"を問うているんですよね。あまりにも有名なハードボイルド小説の主人公のセリフにならっていえば、「優しくなければ生きていく資格がない」ってやつです。ちなみに、生き抜く力(「強くなければ生きていけない」)のほうは、上の「コンセプト」のところでしょう。
で、最後、「インターフェース」。
ここに当たるのはおもに、
・Chapter13 メタファ、イディオム、アフォーダンス
・Chapter14 ビジュアルインターフェイスデザイン
で説明されている原則です。
生き抜く力があるか（コンセプト）、生きていく資格があるか（振る舞い）についての原則をよく守り、それぞれの水準でのデザインがうまくいったとしても、それがユーザーにちゃんと伝わらなければ意味がない。
ユーザーが、こいつはたしかに有用で、しかも、優しく接してくれるうれしいやつだという脳内モデルを育んでくれるのは、つねに具体的なインターフェースの操作によるインタラクションを通じてのことです。これが下手だと元も子もない。そのためにいろんな手管を使うわけです。
たとえば。
その存在のありようをなるべく効率的に了解してもらうためには、共有しているはずの文化的背景を当てにしたり（メタファー）、すでに一般化している慣習に従ったり（イディオム）、ヒトの知覚的な本能と経験則を利用したり（アフォーダンス）します。そしてそうする上で従うべき原則があります。
一方、行儀のよい振る舞いも、結局は、より小さなインタラクションの積み重ねです。そして、GUIの場合、インタラクションはビジュアル・インターフェースの状態の変化として表現されていきます。そこでは、ユーザーの視覚と認知と運動と記憶になるべく負担をかけないように配慮すべきなのですが、そのための原則がまたあります。
ってね。なるほど、これで「振る舞い」と「インターフェース」をどこでどう分けるのかがわかりました。
さて、以上をまとめてみますと、
・まず、デザインの神様の命令がある。
・その命令にしたがって、存在する意義と資格をデザインするための原則がある。
・さらに、その存在をよりよく表現するための原則がある。
ということになるでしょうか。これでぼく自身はすっきりしちゃいました。
一応、そんな見取り図を頭に入れて、続きを読んでいきたいと思います。
2009年9月6日日曜日
ライトウェイトなCMSに関するメモ
Webアプリケーションフレームワークの世界ではライトウェイトが最近の流行り(?)みたいですけど、その上の層の、CMSとかいうところにももっと軽量なのがあっていいと思う。
"軽量"ってのはこの場合、CMSをセットアップするユーザーが、システムについての脳内モデルを作る上での軽さ、ということですけどね。システムの全体象が単純で、いろいろできるわけじゃないけどお手軽で、みたいなかんじ。
いずれにしても、軽量にするためには、いろんなところで汎用性をあきらめて、目的や用途を絞り込むことが必要です。なので、次のとおりに決めちゃう。
・このCMSで作れるのは、Appleの製品ページと同じ構造を持つサイト
・このCMSで作るのは、多くても数十～100ページくらいの規模のサイト
・"コンテンツ管理"は軽視、できるだけコンテンツ作成に専念
そんなに大きくない法人サイト、キャンペーンやプロモーションで特設されるサテライトサイト ... 要するにインターネット上に、自分の存在なり活動なりをお知らせ/ご案内するための情報のパックを持つとしたら、Apple製品サイト風の情報デザインがいいかんじだと思うんですよ。そんなに大きくならなければ。
あと、ブログや"つぶやき"をつけたり、訪問者とのリレーション機能(お問い合わせ受付/回答、CRM)をつけたりして、Webサイトを電話帳やチラシの拡張形態として「置いておく」んじゃなく、コミュニケーションツールとして活用していかなくちゃならないとも思うけど、それはまた、別の話、ということにしておく。
で、そういうのを作るのに、なんか大げさなCMSをどーんと入れてカスタマイズして、ってのは勘弁してほしい。やりたいことはそんなに複雑じゃないんだから、ちょいちょいっといじって終わりにさせてほしい。
管理系の機能もできるだけ省きたい。
全体を見渡すような管理画面とかいらないし、権限とかロールとか、ワークフローとか、ステージングとか、予約実行とか、この規模では、そういうのもいらないでしょ。
実際の見た目の上でコツコツ部品を作りながら、比較的な小規模な、だけど中身は割と立派なWebサイトを構築していく、それだけできればいい。
たとえば。
初期状態では、作りかけのトップページだけが存在している。
そのトップページの、グローバルナビゲーションのところ、ウェルカムメッセージのところ、フィーチャーのところ、フッタナビゲーションのところには、編集ボタンがついている。(Appleの、たとえば、Snow Leopard のページなんかを見てイメージしてください。)
グローバルナビゲーションの編集ボタンをクリックすると、このサイトを構成するセクションを定義するための入力フォームが開く。といっても、いくつかのセクションのタイトルを入力するだけ。
入力すると、トップページにグローバルナビゲーションが出来上がる。グローバルナビゲーションにはちゃんとリンクもついてる。リンクをクリックすると、まだ存在していないページに遷移しようとして、新規ページを作成するためのフローに入る。このへんはWikiみたい。
新規ページを作成する際は、まず、ページのタイプを決める。タイプは二種類。「コンテンツページ」と、コンテンツページをタグで検索した結果の「一覧ページ」。
ちなみに、最初から存在していたトップページはコンテンツページの一種。
これから作ろうとしているのは、グローバルナビゲーションのある項目をクリックして遷移する先のページ。たとえば「おしらせ」だったら、「おしらせ」というタグをつけておいたコンテンツページの一覧にすればいいかもしれない。だから、ページのタイプには「一覧ページ」タイプを選ぶ。そして、検索条件やソート方法を設定する。
つぎに、一覧の周囲に表示したい「情報のまとまり=チャンク」を定義する。たとえば、大見出しや、ここで何を一覧表示しているのかを簡単に説明するリード文など。あるいは、意図的にピックアップしたコンテンツページのリストを常に表示させたいかもしれない。
グローバルナビゲーションの項目が「わたしたちについて」だったら、クリックした先は一覧ページではなく、きっとコンテンツページになるはず。
コンテンツページとは、いわば「チャンク」だけでできたページ。
チャンクにはいろいろな種類がある。たとえば、このページは、基本的には「左寄せ画像+見出し+本文」と「アイコンつきリンクリスト」というチャンクだけでできている。
コンテンツページには、チャンクをどんどん追加できる。チャンクの種類を選んで、チャンクごとの入力フォームに必要な情報を入力していく。
CMSには、Apple製品サイト風のサイトを構成する上で必要となりそうなチャンクがたいてい揃っている。ユーザーに伝えたいことをそうしたチャンクに当てはめてページを構成していく。もちろん、このブログのように、タイトルとでかい本文だけのチャンクひとつでページを構成する手もある。
トップページのグローバルナビゲーション、ウェルカムメッセージ、フィーチャ、フッタメニューなんかもチャンクの一種。フッタメニューは全ページ共通のチャンクで、どのページで編集しても、全ページに反映される。
チャンクの中にまだ存在していないページへのリンクを設定する。これをクリックすると、一覧ページを作るか、コンテンツページを作るか聞かれる。ふさわしいタイプを選択してあたらしいページを作る。これを繰り返してサイトを構築していく。結局、それだけのこと。
結局それだけのことなんだけど、トップページに最初から用意されている(中身は空の)チャンクや、一覧ページ、コンテンツページそれぞれに備わっていて選択可能なチャンクのラインアップによって、自然に、Apple製品サイト風のサイトデザインに習うように仕向けられている。というより、サイトデザインはあらかじめ一定の枠にはめられていて、それに従うしかない。それに従うしかないという状況ほど楽なものはないわけで。
ちなみに、すべてのチャンクを含めて、サイトのHTMLコードは完全にFIXしているので（チャンクのデータフィールドに入力されたHTMLコードは除く）、ブログと同じように、あるいは、ZenGardenと同じように、CSSの差し替えのみで、ルック&フィールやサイト提供者のビジュアルなアイデンティティ表現はコントロールできる。
このCMSでの"カスタマイズ"とは、CSSコードの差し替えとCSSが使用する画像データの差し替えのことのみとしたい。
その他のカスタマイズは一切サポートしません。それをやりたければもっと高級で大げさなCMSを使いなさい。と。
あ、でも、チャンクを増やすことはあるかも知れない。
と、まあ、そんなかんじ。そういうのがほしいし、作ってみたい。きっと便利だと思います。
"軽量"ってのはこの場合、CMSをセットアップするユーザーが、システムについての脳内モデルを作る上での軽さ、ということですけどね。システムの全体象が単純で、いろいろできるわけじゃないけどお手軽で、みたいなかんじ。
いずれにしても、軽量にするためには、いろんなところで汎用性をあきらめて、目的や用途を絞り込むことが必要です。なので、次のとおりに決めちゃう。
・このCMSで作れるのは、Appleの製品ページと同じ構造を持つサイト
・このCMSで作るのは、多くても数十～100ページくらいの規模のサイト
・"コンテンツ管理"は軽視、できるだけコンテンツ作成に専念
そんなに大きくない法人サイト、キャンペーンやプロモーションで特設されるサテライトサイト ... 要するにインターネット上に、自分の存在なり活動なりをお知らせ/ご案内するための情報のパックを持つとしたら、Apple製品サイト風の情報デザインがいいかんじだと思うんですよ。そんなに大きくならなければ。
あと、ブログや"つぶやき"をつけたり、訪問者とのリレーション機能(お問い合わせ受付/回答、CRM)をつけたりして、Webサイトを電話帳やチラシの拡張形態として「置いておく」んじゃなく、コミュニケーションツールとして活用していかなくちゃならないとも思うけど、それはまた、別の話、ということにしておく。
で、そういうのを作るのに、なんか大げさなCMSをどーんと入れてカスタマイズして、ってのは勘弁してほしい。やりたいことはそんなに複雑じゃないんだから、ちょいちょいっといじって終わりにさせてほしい。
管理系の機能もできるだけ省きたい。
全体を見渡すような管理画面とかいらないし、権限とかロールとか、ワークフローとか、ステージングとか、予約実行とか、この規模では、そういうのもいらないでしょ。
実際の見た目の上でコツコツ部品を作りながら、比較的な小規模な、だけど中身は割と立派なWebサイトを構築していく、それだけできればいい。
たとえば。
初期状態では、作りかけのトップページだけが存在している。
そのトップページの、グローバルナビゲーションのところ、ウェルカムメッセージのところ、フィーチャーのところ、フッタナビゲーションのところには、編集ボタンがついている。(Appleの、たとえば、Snow Leopard のページなんかを見てイメージしてください。)
グローバルナビゲーションの編集ボタンをクリックすると、このサイトを構成するセクションを定義するための入力フォームが開く。といっても、いくつかのセクションのタイトルを入力するだけ。
入力すると、トップページにグローバルナビゲーションが出来上がる。グローバルナビゲーションにはちゃんとリンクもついてる。リンクをクリックすると、まだ存在していないページに遷移しようとして、新規ページを作成するためのフローに入る。このへんはWikiみたい。
新規ページを作成する際は、まず、ページのタイプを決める。タイプは二種類。「コンテンツページ」と、コンテンツページをタグで検索した結果の「一覧ページ」。
ちなみに、最初から存在していたトップページはコンテンツページの一種。
これから作ろうとしているのは、グローバルナビゲーションのある項目をクリックして遷移する先のページ。たとえば「おしらせ」だったら、「おしらせ」というタグをつけておいたコンテンツページの一覧にすればいいかもしれない。だから、ページのタイプには「一覧ページ」タイプを選ぶ。そして、検索条件やソート方法を設定する。
つぎに、一覧の周囲に表示したい「情報のまとまり=チャンク」を定義する。たとえば、大見出しや、ここで何を一覧表示しているのかを簡単に説明するリード文など。あるいは、意図的にピックアップしたコンテンツページのリストを常に表示させたいかもしれない。
グローバルナビゲーションの項目が「わたしたちについて」だったら、クリックした先は一覧ページではなく、きっとコンテンツページになるはず。
コンテンツページとは、いわば「チャンク」だけでできたページ。
チャンクにはいろいろな種類がある。たとえば、このページは、基本的には「左寄せ画像+見出し+本文」と「アイコンつきリンクリスト」というチャンクだけでできている。
コンテンツページには、チャンクをどんどん追加できる。チャンクの種類を選んで、チャンクごとの入力フォームに必要な情報を入力していく。
CMSには、Apple製品サイト風のサイトを構成する上で必要となりそうなチャンクがたいてい揃っている。ユーザーに伝えたいことをそうしたチャンクに当てはめてページを構成していく。もちろん、このブログのように、タイトルとでかい本文だけのチャンクひとつでページを構成する手もある。
トップページのグローバルナビゲーション、ウェルカムメッセージ、フィーチャ、フッタメニューなんかもチャンクの一種。フッタメニューは全ページ共通のチャンクで、どのページで編集しても、全ページに反映される。
チャンクの中にまだ存在していないページへのリンクを設定する。これをクリックすると、一覧ページを作るか、コンテンツページを作るか聞かれる。ふさわしいタイプを選択してあたらしいページを作る。これを繰り返してサイトを構築していく。結局、それだけのこと。
結局それだけのことなんだけど、トップページに最初から用意されている(中身は空の)チャンクや、一覧ページ、コンテンツページそれぞれに備わっていて選択可能なチャンクのラインアップによって、自然に、Apple製品サイト風のサイトデザインに習うように仕向けられている。というより、サイトデザインはあらかじめ一定の枠にはめられていて、それに従うしかない。それに従うしかないという状況ほど楽なものはないわけで。
ちなみに、すべてのチャンクを含めて、サイトのHTMLコードは完全にFIXしているので（チャンクのデータフィールドに入力されたHTMLコードは除く）、ブログと同じように、あるいは、ZenGardenと同じように、CSSの差し替えのみで、ルック&フィールやサイト提供者のビジュアルなアイデンティティ表現はコントロールできる。
このCMSでの"カスタマイズ"とは、CSSコードの差し替えとCSSが使用する画像データの差し替えのことのみとしたい。
その他のカスタマイズは一切サポートしません。それをやりたければもっと高級で大げさなCMSを使いなさい。と。
あ、でも、チャンクを増やすことはあるかも知れない。
と、まあ、そんなかんじ。そういうのがほしいし、作ってみたい。きっと便利だと思います。
登録:
投稿 (Atom)