CalmTech -Mind Dump-

別にこのシリーズを忘れていたわけではなくてですね。言い訳不要ですね。再開します。
予告としてデファクトについて考えるとしました。これは事実上の標準を示す「デファクトスタンダード」のことです。これをWEBにおけるリンクを中心に考えてみます。

• デファクトを破るのはミスリードのリスクあり
• 思考の流れとUIを一致させることが重要
• 一部の色やアニメーションといった視覚効果もフィールとして考える

デファクトの色を採用する必要はない

ブラウザにおいて、リンクのデファクトは大ざっぱに分けると2つでしょう。

未訪問

リンク色：青　テキスト装飾：下線あり

訪問済

リンク色：赤紫　テキスト装飾：下線あり

白地に黒のテキスト、そして上記のようなリンク色がデファクトです。なぜこの色が採用されたのかを知らず、調べたところ情報が見つからず。ならば色彩学かなと思って、その手の本を読んでいる所です。
それはともかく、まずは2つの側面からリンク色というのを考えることができます。1つ目は、見なれたものであることです。およそ、インターネット利用者が最も目にする配色がこれという説明に尽きると思います。2つ目は、白地に黒という配色では、青が浮いて見えて、赤紫が沈んで見えるということです。ここが色彩の問題で、自分では明らかにできていないところですが。

大事なのは、未訪問がテキストの中で目立ち、訪問済が目立たなくなることです。また、そのリンク色の割合によって、自分がどこまでこのリンク群を消化したのかという目安にもなります。これを踏まえれば、リンク色はデファクトのままである必要はなく、「目立っているか、そうでないか」で決定すればよいと考えられます。

リンク以外で下線を使うのはミスリード誘発

問題は下線です。ワープロの世界だと下線とは注目するポイントを示唆するものとして扱われます。ですが、WEBで同じように使ってしまうとミスリードを誘発します。リンクのデファクトを踏まえると、下線がある場合にリンクであると想起させてしまいます。ホバーさせた際に下線が出るのも同じように捉えられると思います。

リンクしないテキストに下線は使わないと割り切ってしまう方が得策です。要は慣れとルック・アンド・フィール(以下、LnF)の問題です。リンクの色と装飾ひとつをとっても、扱いを間違えればLnFの特にフィールを大きく損ねることになります。

非テキストリンクは押せるルックを

非テキストのリンクはどういった形状をとるべきか？という話になると、ボタンがいいと言われます。何故か？と問うと、「押せると思うから」という返答がきます。私はこれについて本質ではないと考えています。なぜなら、WEBデザインの世界だけを見ても、グローバルメニューはボタン(大概はトグル)になっていないものも多いからです。

リンクという視点で考えた場合、テキストリンクを「クリック」することでリンク先のページを表示するというアクションが発生します。しかし、テキストリンク自体はボタンの形状をしているわけではありません。つまりボタンの形状をしていなくとも、「押せる」と思うわけです。これはデファクトであるからこそ、できることでもあります。では、リンクの形状を問わず共通するものは何か？「押せると思わせるルックである」ことです。

テキストであれば、浮いて見える配色で下線を、非テキストであれば押せると想起させる形状なり、注釈などを。ボタンというのは、あくまで押せると思わせる形状の代表的な存在であって、実装手段の1つに過ぎません。
あくまでこれは、前回で触れた「予測できる＝解りやすい」を踏襲しています。すると、リンクのルックとリンク先の内容が一致していることなど、芋づるで押さえるべきポイントが決まってきます。なおかつ、LnFにおけるフィールまで考慮することで、「予測した通りに動く＝使いやすいと感じる」にユーザを導くことになります。これが思考の流れとUIの一致と言えます。

エフェクトをフィールとして使う

WEB上ではJavascriptによるエフェクトの多用がよく見受けられます。いわゆるDHTMLなわけですが、そのエフェクトをどれだけ有効活用されているかと考えると、個人的には疑問に感じる点が多いです。
エフェクトはルックなのか、フィールなのかと問われると、私はフィールと考えています。フィールとして使われるエフェクトというのは、画面上で発生した事象をユーザに通知することです。

例えば、WindowsとMac両方で共通のUIで考えると、ウィンドウの最小化です。デフォルトの設定ですと、Windowsの場合は、縮小化されたタスクトレイ上のパーツに向かって、ウィンドウが徐々に縮小(およそ0.5秒？)されていきます。Mac(OSX Leopardとします)だとジニーエフェクトを利用しつつ、ドック上の格納位置に向かって吸い込まれるように(およそ1秒～1.5秒？)ウィンドウが消えます。どちらも縮小化というアクションに対して、エフェクトを適用することで、ユーザにウィンドウが縮小化され、どこに格納されたかを通知するというフィールを生み出しています。ロード時間中のインジケータ、画面切り替え時の切り替え先のポップアップ、私はこれらが正しいエフェクトの活用法だと思います。

エフェクトを認識する時間はどれぐらいか？

エフェクトと一口に言ってしまっても、様々ありますが、ここのところ気になっているのは、2Dエフェクトと3Dエフェクトについてです。特にKeynoteでエフェクトを適用していると、2Dエフェクトで程よいと感じる動作時間、3Dエフェクトで程よいと感じる動作時間に差があります。

仮説としては、2Dエフェクトは0.5秒以上、1秒以下、3Dエフェクトは1秒以上、2秒以下がしきい値と考えています。といっても、それぞれのエフェクトにさらに細かく種別があるので、もう少し解析が必要とは思っています。ここは、人間の視覚の根本である、情報認知の世界だと思うので長い道のりになる気がしています。

とりあえず、次回についてはエフェクトの認知時間、もしくは時間軸による情報認知について、掘り下げてみようと考えています。

つい今朝のことですが、プロジェクトメンバーから興味深い問題提起を受けたので、それについて書こうと思います。私は彼の視点や思考方法をすごく尊敬していて、彼との出会いによって多様性への理解や発想の転換力が豊かになったと思います。

• 新聞の見出しの狙いはカクテルパーティー効果
• サムネイル＝本の背表紙
• デザインコストをかけるべき場所にずれがある

そもそもの話は、画像ビュアーを個人的にプロジェクトメンバーが作成し始めたことがきっかけでした。私も彼も、業務システム屋の出身なので、画面としてのUIというものに、自分なりのこだわりがあります。それゆえに、WEBデザインの案件をこなす傍ら、UIについて突き詰めて考えようと意見交換をすることがよくあります。

2人の中では、およそUI設計における指針は共有されており、そもそものとらえ方も似ていました。結果的に、視線移動にとどまらず、人の情報認知という事象について、裏付けを取ろうと調べだすのは当然の流れだったのかもしれません。

視覚にもカクテルパーティー効果がある

カクテルパーティー効果が視覚にも存在し、その誘導を行っているのが新聞でいう見出しのことらしいという話を受け、自分の中で腑に落ちた点が多々あります。

新聞のUIは独特で、以前のエントリでも触れている逆NとZの視線移動が混在しているにも関わらず、なぜか読み進めることができます。慣れという点を差し引いても、記事が目に入ってくるのは見出しのおかげだと思っていました。

全体を俯瞰した状態で、人はおそらく新聞の内容はほぼ見えていないと思われます。人間の目の精度はそこまで良いものではありません。乱暴に言えば、カメラレンズなので焦点の合っていない場所は、情報の内容まで認識できるレベルではないということです。

つまり、カクテルパーティー効果と同様で、見出しによって注視して初めて周辺の情報がどういった構造なのかを認識しだすと考えることができます。さらに言えば、注視が始まると、それまでの視線移動のリズムや方向などを無視していようが、人間の思考が現在のルールに合わせだすということです。

タイルは画像検索に最適なUIではない

Windowsエクスプローラでも、Macファインダーでも、ショッピングサイトの商品画像一覧でも何でもよいのですが、サムネイルがZ方向に並べられている状態を私はタイルと呼んでいます。

多数のサムネイルが存在する中から、目的の画像を視覚で探すのは困難を極めます。そのためにタグをつけて管理したりと様々な手法があるのですが、すべての画像にタグをつけて管理できる整理上手で勤勉な人間がどれほどいるというのでしょう？
結局のところ、タグ管理というよりフォークソノミーの課題そのままなのですが、画像を保存して閲覧するという過程において自動的に割り振られる情報は保存日などの時間しかありません。ファイル名は任意ですし、重複しないファイル名を望むのであれば(これは極端な思考とは思いますが)MD5で自動生成したファイル名にでもしてしまいたいところです。

実際、Googleが提供するPicasaは保存日を基準にしてグルーピングする手法をデフォルトとしており、そこからユーザが任意のルールで整理を始めるという流れを促しています。
グルーピングはソートと言い換えても同じです。ファイル名の五十音順なり、保存日の降順などでソートしない限り、同じ大きさの画像が並んだとして、視覚だけではとても探せたものではないということです。
実際にやってみるとわかります。1つ1つ丁寧に探していくと、時間がかかりすぎてうんざりし、どんどん飛ばし読みしていくようになります。

サムネイル＝縮小画像は誤解

本屋にいるとします。目的の本があり、その表紙やタイトル、著者、出版社がわかっているとします。どうやって目的の本を探し出しますか？店内の本棚のどこかにあり、店員に聞いたり、検索端末などは利用しません。
おそらく、出版社で本棚を特定し、著者が有名であれば著者で棚を特定し、そこからは背表紙か表紙で視覚による検索を始めます。平積みされない限りは、背表紙を見ていくことになるでしょう。

つまり背表紙で探している状態がサムネイルで探している状態です。目的の本を見つけたとして、表紙を確認し、中身をざっとみる。これが商品詳細のページを見るのと等価の行動となります。

では、背表紙をよく見てみます。縮小画像としてのサムネイルと決定的に違うのは、背表紙は専用のデザインとして作られていることです。文字組、フォント、文字サイズ、配色と様々な要素を駆使して、背表紙という立ち位置から本を表現しています。つまり相当のデザインコストが背表紙1つに払われていると考えます。ここはカバーデザインをされている方やDTP畑の方に何とかしてその実態を聞いてみたいところではあります。

詰まる所、サムネイルは縮小画像として自動生成される程度の代物ではないということです。なぜならば、カバーデザイン1つで本の売れ行きも変わるという事実があるからです。
さらに付け加えると、画像1つ1つの内容は千差万別です。サムネイルを生成するにしても、その画像を簡略化した表示とするために、適切な構図なり、文字による情報の付加が必要となるはずです。それはすでに自動化不可能な話で、それこそ画像認識の話になってしまいます。
内容が異なる情報に対して、等価な情報加工(同じ倍率での画像縮小のみ)を行うことで、かえって視認性を低下させ、情報としての価値を下げている、もしくは失くしていると考えられます。

サムネイルにもデザインコストの明確化を

現実的な話に戻すと、最適なサムネイルを生成する画像認識機能付きアップローダを作るのと、1つ1つサムネイルをデザインするのと、どちらが適切か？という話になります。ここでの適切というのは、用意できる資金に現実的に収まるか？という意味で考えています。
私は1つ1つ手でデザインする方が適切だと思います。なぜなら自動化には限界があります。そして、人が分かりやすい、美しいと感じる理由を解明できて、かつ標準化できない限り現実的な精度と品質は得られませんし、そこまで行くには一生涯を費やす覚悟が必要でしょう。実際、専業として開発されている企業や団体があるのがその証拠です。

具体的な話をします。商品データのアップロードを行うと、通常は画像のアップロードに伴ってサムネイルを縮小画像として自動生成というのが一般的なパターンでしょう。しかし、これが間違いなのだとあえて言います。
例えば、静的ページを作成して何らかの施設概要や内部について紹介するページを作成したのであれば、カメラマンを用意するだけでなく、撮影結果を加工して画像を用意すると思います。

それがショッピングサイトのような多数となると、途端に自動生成で縮小した画像のみとなります。そこに対しての理由がおそらくコストと言う人がほとんどですが、それはコストではなく「面倒だから」が本音だと思います。手間を重視するのではなく、デザイナであるならば、サムネイルを1つ1つ作ることへのコストとメリットを明確化し、対価を得るようにクライアントと検討する方が健全だと思います。

どれだけ膨大な商材をもつショッピングサイトでも、1件1件のデータ登録と画像アップロードという「手間」をさけて通ることはできません。その手間に「費用としてのコスト」が発生しているのです。

かといって1枚いくらなんていう、どんぶり勘定でいきなりクライアントに提示するのは間違いです。ページ内容を踏まえ、それに対する画像数やその品質とデザインコスト、製作期間まで含めて価格を出し、それをならすと1枚いくらです。という所まで説明して合意をとっているか？というのが肝心です。

ただ理想論を言っているつもりはありません。経験則からの裏付けがあり、自動化によるコストダウンが価格競争という消耗を産み、さらにはデザイナの価値の低下、デザインの品質低下を招くという危惧も含まれています。

啓蒙の意味も含めて、デザインへの対価を考えて商売する方がデザイナも納得できると思うのです。
そこまで徹底してこそ、デザイナに価値が発生するのだと思うのです。

6/21にWDHAレギュラーミーティング#004が開催されました。前回に引き続き、また発表をさせてもらいました。

• ワークショップ＋座談会＋和室これ最強
• 懇親会への会場移動がないと発表中のテンションのまま話せて盛り上がる
• 今後は学校や他コミュニティと合同で開催してみる

第1部は私で「UI設計の基礎トレ」と題して発表しました。ここのところ「自覚的デザインシリーズ」と称してUIについて当たり前と思っていることを自分なりに考えてみているのですが、現段階での結論についてと、まだブログ上では踏み込んでいないところについても話しました。
IWDDで話した内容とフィードバックを交えつつですが、各UIの実例のラベルづけをもう少し考えたいなと思うところ。

また、SKK情報ビジネス専門学校から参加されていた方から、「学生相手にやってみない？」とのお声。WEBデザインやプログラマ向けのコースの授業でと。であれば尚更、このスライドは練りこんでいく必要がありますね。

というわけでSlideShare初体験。やっぱりいいですねこのサービス。(スライド下のViewのリンク先からダウンロードできます)

| View | Upload your own

スライドでの発表後に、この内容を踏まえてワークショップ形式でサイトデザインをしました。流れとしては、

1. 要件説明。今回はWDHAのサイトをデザインすると仮定。
2. WDHAのサイトに最も重要だと思うことを、コンテンツ・機能・ビジュアルについてそれぞれ1行で書く
3. ワイヤーフレームを書く
4. 自分のデザインの根拠を3行で書く
5. グループ分け(2つ)
6. グループ内でそれぞれの意見を持ち寄ってデザイン
7. お互いにプレゼンする

実は最初の要件で大きな縛りを設けていました。予算がないので1ページに収める。無茶苦茶かもしれませんが、そのぐらいの制約があった方が良いアイディアも出るというものです。
そんな制約お構いなしにビジュアル重視で作りこむグループと制約を守って機能重視で作りこむグループと対照的な結果になったのは良かったと思います。

ビジュアル重視のグループは、アンカーリンクで1ページに収める手法をとり、アンカーリンク移動の煩わしさを船のイカリが下りていく動きになぞらえることで移動の様子に意味を持たせようとアプローチ。
機能重視のグループはAjaxによってページ遷移をなくすることで、1ページに収めたように見せかける手法を取っていました。

それぞれの成果物とメンバ構成を見てわかったのは、プログラマの存在でアプローチが変わってくるようです。プログラマが入ると、どっかでCGIが動いていることが前提になっているように見受けられます。
WDHAは業種が割とWEBデザイナ多めに偏っているので、制約を練りこんで、わざと偏ったメンバでワークショップを行った方が、おもしろい成果が出そうです。

第2部はOQUGAR-DESIGNさんによるWordPress入門でした。実際のソースを交えながら、テンプレートの使い方や実際に使った時のはまり所などについて。
個人的にWordPressは非常によくできてるなと思いますし、いざとなったらPHPでゴリゴリしちゃえばいいし(邪道)という逃げ道があるので好きです。

あとはOQUGARさんから、うまく動かないのですがこれはどう書けば？という話が出たので、その場で修正。無料です。

会の最後に、今後のWDHAの方向性について話していたのですが、県内の専門学校などを開催場所にして、学生を交えつつやってみるとか、岩手・秋田と合同でやってみるか？とか、活動範囲が広がっていきそうです。
実は東北という単位でみると、こういったコミュニティが多いのだとか。コミュニティを越えて設計合宿やったりして、自分たちで何かサービスを立ち上げたりするところまで行きたいというのは個人的に考えているところです。

話は変わりますが、Ruby勉強会@青森を開催しよう！ということで水面下で進行中です。
RubyKaigi2008やRejectKaigi2008が開催され盛り上がりを見せているRubyですが、青森にもその波が。業務でRubyもRailsも使っている者として、新たな出会いや情報がありそうで楽しみです。

といいつつ、Google App EngineでDjangoにひかれてて、とりあえず仮サービス立ち上げたいし、そっちもいいよなとか思ったり。勉強したいことが溢れるほどあるというのは幸せなことですね。

前回のエントリではModelからViewへの写像と、視線誘導における前提知識みたいなことをまとめてみました。今回は、視線誘導の形にどういった種類があるか考えてみようと思います。また、分析に加えてUIとして個人的に思うところも書いていきたいと思います。

• 視線はZ、N、L、ランダムとリンクの組み合わせで構成される
• 視線移動のヒントを視界の一部に捉えさせる工夫が必要
• 視線の開始位置を基点に次を予測できるようにレイアウトを決めて行く

始点が左上か右上かで視線の方向は決まる

まず、ごく基本的な視線の動きを考えてみます。文章で考える場合、文章は文字列という1次元のModelです。それを最大の横幅が決まっている領域を持つViewに対して写像すると、「折り返し」が発生します。つまりX軸とY軸の2次元への写像となります。これを考慮して代表的な形式を考えてみます。

欧文(横書き)

Zの動き。左から右に向かって進み、折り返した後に、上から下に向かって文章の最後まで左から右に進む動きを繰り返す。

邦文(縦書き)

Nの動き。上から下に向かって進み、折り返した後に、左から右に向かって文章の最後まで上から下に進む動きを繰り返す。

折り込みチラシ

ランダムに視線を移動する。各情報の優先順位や重み付けがあまり無いので、どこから見始めても良いし、次に見る場所が制限されていない。

Windowsエクスローラ

Lもしくは逆Lの動き。任意の列を上から下に向かって進み、目的の情報が見つかるか、関連があると思われる情報の位置に来た所で、左右どちらかの方向へ動く。

基本の動きを組み合わせてみる

では、上記のようなパターンを組み合わせてみます。個人的にUIが優れていると思っている実例をあげます。分析してて自分で思ったのは、新聞というUIは非常によく考えられているということでした。以後、逆Nという言葉が出てきますが、これはNを左右反転させたものを意味します。

新聞

Z + N + ランダムの動き。遠目から見ると、ランダムに記事が配置されているように見えるが、基本は右上からNの動きとなる。しかし、見出しの強調によって、ランダムに視線を動かすことがほとんど。
その代わり、見出し周辺の文章を縦書き、もしくは横書きでブロックになるよう構成し、見出しにフォーカスした後にどう読み進めるべきか誘導している。

wikipedia

逆N + Z + リンクの動き。左上を始点として、基本はZの動き。ただし、左側にグローバルメニューとなるサイドバーがあるため、逆Nの視線移動となる。装飾は最小限に抑えられ、リンク色もデフォルトのままとしているので、予想外の動きがなく違和感無く読み進めることができる。

iTunesのグループ表示

逆N + Z + L + ジャンプの動き。かなり複雑な組み合わせだが、あくまで基本の視線移動の組み合わせ。サイドメニューから任意のプレイリストや項目を選択した後に、右側の一覧へ逆Nの動き。次にブラウズをZの動きで見ながら絞り込み。検索結果に対し、アートワークを基準に縦方向に探すLの動き、もしくはすでにアルバムまで特定している場合には、楽曲一覧に対してZまたはLの動きで見て行く。
また、希望の情報が見つからない場合には、Finderに向かって一気に視線をジャンプさせる。これはFinderが検索結果を変化させることができるという前提の植え付けによって行われる。

サイドメニューは左なのか？右なのか？

図で説明すれば簡単なんですが、あえて言葉にしています。疲れます。でも自分にとっては文章にするのが大事なんです。続けます。
さて、上記の実例のうち、wikipediaとiTunesに共通していることがあります。それはサイドメニューの位置が両方とも左であるということです。
いつからか、WEBの世界では右にグローバルメニューという考え方がでていました。個人的には違和感があります。結論としてはケースバイケースですが、情報の優先度や流れを自覚できているかどうかが大事と考えています。

頻繁に使われるものは、視線移動の開始位置が左上であれば、やはり左から始まる方が自然と考えます。加えて、ユーザが利用する機能の流れと一致していることが大事です。WEB以外で考えた場合、Visual Studioの画面作成モードでは、まずコントロールを選択する場所が左。実際に配置する画面が中央、そして配置したコントロールに対するプロパティは右と処理の流れにそっています。

逆に疑問を持つ例として私が真っ先にあげるのはブログの3カラムと右側にグローバルメニューを配置した場合です。ブログに関してはここのところ、3カラムでメインが左で右2カラムに残りをというレイアウトも見られます。これらについては、そのコンテンツの特性を考えれば答えは出せると思います。

ブログはその特性として、「トップに最新」「ユーザは最新の記事を基本的に追う」という2点があると思います。そうすると、真っ先に見たい情報はトップにあります。そしてZの動きで文章を読むとすれば、ブログの記事自体は左というのが自然と思います。その反対におくのは、記事よりも優先度の低いもの、もしくは記事を読んだ後に進むべきものとします。

ユーザを大きくリピータと初見に分けるなら、リピータにとっては視線移動の開始位置に記事があるというのは余計な視線移動がなく好都合と考えてくれると思います。初見については、Googleから検索してたどり着くか、リンクをたどってきたとして、他の記事も読みたいと思ったときに初めて、今見ている記事以外のコンテンツについて視線を移動すると思います。その場合、右にメニューがあるのはZの動きで考えると自然に動かせるでしょう。
ただし、スクロールによってサイドメニューが見えなくなっている場合には、逆Nの動きで画面ごと上部に戻って、右へ視線を動かす事になります。それを考えると、記事を読み終わった時にフッタで他の記事への誘導を見せるというのも余計な視線移動がなく、自然だと思います。

予測できる=解りやすい

様々なUIを見て思うのは、自分が行おうとしている動きについて予測しやすいというのは、非常にストレスが少ないという事です。おそらく、自分で思うようにコントロールできるという意識を植え付けるからです。
予測しにくいものでおもしろさをという場面は間違いなくありますが、日常的に使うもの、使用頻度が高いものについてはストレスにしかなりません。予想外がおもしろいのは最初だけ、つまりインパクト勝負になってしまいます。

私がUI設計の時に心がけているのは、複数回使うことを前提に、使うほど便利になっていくようにすることです。その場合、「予測しやすい」というのは短時間で慣れ、作業速度を上げて行くことに一役買います。もちろんここには、操作デバイスという概念ははずせないのですが、今は視覚に絞って進めて行きます。

ここまでで、ようやく外枠の部分が決まりました。次はより細部について考えて行きたいと思います。「予測しやすい」という側面で考えてきましたが、最も利用者の多い方法は常識となる - つまり、「デファクト」に従うことも必要ということについて考えてみます。

IWDDミーティング#23でUI設計を人間の視覚で考えるという手法について発表しました。が、前回のエントリで割愛した内容について補足しながらまとめて行きたいと思います。

• 現代的にModel設計はプログラマの仕事、View設計はデザイナの仕事
• Modelは不変でViewは可変
• 人間の脳は立体(3次元)で情報を捉えて平面(2次元)に写像している

ModelからViewへ写像するのがデザイン

Modelというのは複数の次元からなる情報のカタマリをここでは指します。バブルマップを私が解釈すると

• X軸：内容
• Y軸：達成度(進捗)
• Z軸：優先度(期限、ストレス)

となります。この3次元で構成されるModelだという解釈ですね。なぜこういう解釈にできるのか？と言われると、これがいわゆるプログラマと呼ばれる人たちにとっての「設計」にあたる部分なので一言では語れません。分析的思考は経験則によるところも大きいですし。そもそもModelの次元は3とは限りません。ですが、人間が一度に処理できる情報に限界があるため、様々な制約を利用して次元を絞っているという側面があると思います。

よって、Modelはn次元と考えることにします。

では、Modelができたところで、人間が見る・使うとしてどういうUIにするか？という話になります。ここでViewという概念が出てきます。ViewというのはModelを人が視認できるように平面に結び付けた結果です。ここが、いわゆるデザイナと呼ばれる人たちの本業となる所だと考えています。

あえてプログラマとデザイナという分け方をしましたが、実際のところは責任範囲を分けず、どちらも考えられるのが一番よいと思います。そして、Model設計というのが最近のWEBデザイナに求められる分野かなと思っています。

ModelとViewの違いについて考えると、Modelは不変に近く変更が難しいです。これについては歴史的経緯とかデファクトスタンダードとかが概念として絡んできます。これに対し、Viewは視覚化に対する解釈の違いなので変更が簡単です。カレンダーで考えてもらえればわかると思いますが、「年月日」というほぼ普遍のModelに対し、日めくりや月めくり、年間カレンダーや週間カレンダーと様々なViewがあります。

このModelからViewへの遷移を写像と呼ぶことにします。

人間の眼は平面でしか見ることができない

導入としてModelからViewへの写像について書きましたが、あえて「平面に結び付けた結果」としたのは、人間の視覚が2次元でしか見ることができないという前提があるからです。ここからは遠近法についての話になってきます。人の眼は物体の位置関係を大きさと角度を利用して把握しているとされています。
先のリンクで透視図についても触れていますので説明はそちらに任せるとして、結局のところは立体に見えるように錯覚しているだけということです。

では、n次元から平面への写像を行います。ここで視線誘導という考え方がでてきます。この視線誘導については、人間が一度に視認する情報量という側面から考えていくことになります。
先ほどのカレンダーは視認する情報量を変えることによって、その機能を実現していると考えられます。年間全体を通して把握するのか、月なのか、週間なのか、今日だけなのか。

これは、年月日というModelについて一度に把握できる日数、つまりViewを変えることで、UIを実現していると考えられます。現在把握できる年月日が過ぎたらめくるという機能しか実はありません。が、視認できる情報量からViewを変えることによって、UIとしては全く別物に変わっているのです。

では、視線誘導としてどんな手法がとれるのか？これを次回のエントリで触れていきます。

ブログ立ち上げからしばらくたちましたが云々「怠け」という言葉で片付けます。

さて、セルフプロトタイピングしながらブログデザインを考えて行きます。とにもかくにも何を発信したいのか、コンテンツを決めない事には始まりません。自分がクライアント役にもなるというのは、なかなか新鮮ですが難しいものです。まずは動的コンテンツと静的コンテンツで分類していきます。

動的コンテンツ(エントリ増加など可変のもの)

ブログ

身の回りの出来事や既存サービス、概念への考察がメイン

勉強会やセミナーのレポートなど(既にWDHAについて公開済み)

開発実績

開発実績(WEBサイトなど)の一覧と詳細

サイトのサムネイル、クライアント、要素技術も併せて

開発において取り組んだ事や工程について詳細のところで見せる

自主制作

自分で作ったプログラムなどの公開

今は特に出せるものはほとんどない

WEBサービスの場合は専用サイトにしてしまう？要検討

静的コンテンツ

プロフィール

活動内容や経歴などを簡単に

アクセス解析の結果、Aboutのデフォルトリンクをクリックするユーザが多かったため、ニーズはある

問い合わせ

直接の問い合わせではなく、ダウンロードコンテンツの前にはさむアンケートをメイン

フォームを自動生成する自前のJavascriptライブラリがあるので、そのテストもかねる

問い合わせはコンテンツとくくりだすほどのものではありませんが、PDFでの資料公開やらをしようとしたときに、抱き合わせで必須となるものなので、一応は静的コンテンツに加えます。

さらに、ここからそれぞれのコンテンツにどういった性質があるかを考えます。私の場合、ここで表示形式も一緒に考えます。よく使う言い方として以下のように定義しています。

• list - エクセルの表のような連続した行での表示 テキストメイン
• tile- 画像メインでサムネイル一覧でよく使われる表示形式
• show - いわゆる詳細画面(大きい画像やデータ詳細など)

まずメインであるブログですが、これはいきなり特殊な形式です。人によっては、「続きを読む」といったリンクを用意して、途中までかサマリをlistで表示するパターンが多いようです。
ですが、ブログの「時系列での記録」「トップに常に最新」というデファクトの性質を考えると、showでトップに最新１件のみを表示して、その代わりに過去のエントリへの導線を用意すれば十分と考えます。

そもそも、アクセス解析を見てもブログ立ち上げの頃は他リンクを押す人が多かったようなのですが、日が経つにつれて、ブックマークから見る人の割合が増えていました。加えて、直帰率が高いです。これは、ブログ全般に言える事だと思うのですが、トップに最新があるとわかっているのですから、初見か他へ誘導するリンクがない限りは、トップの記事を見て帰る・・・というのは自然だと思います。

ああ、頭の中ではすぐの事を文章で書くとこんなにも・・・まさにdump状態ですね。
まずはここまでにしたいと思います。次回ではアーカイブの性質を考えてみたいと思います。時系列で記録したブログをたどる場合の導線として、月別やカテゴリ別がありますが、そういった類いのものの是非と、自分のブログで用意すべきアーカイブ形式を考えたいと思います。

バブルマップといえば、Lifehack.orgでも紹介されたTODO管理の方法です。ストレスの度合をバブルで表現するというユニークな手法で、マインドマップを元に考案されたようです。私自身、マインドマップ自体は社員教育の一環で5～6年ほど前に勉強して、実際にプロジェクトやミーティングで使用していました。

おもしろそうだと思い、実際にバブルマップを実践してみたところ、進捗を表すため部分的に消したり、TODOを消化して一気に消したりすると、落ちものパズルゲームで一気にブロックを消した時のような爽快感があって非常におもしろいです。このバブルを消すのが趣味になりそうな楽しさがあります。

バブルマップを分析してみる

手書きでやりだすと、課題も見えてきました。バブルマップはストレスを大きさという軸で表現することと、部分削除で進捗を表す方法でガントチャート的な意味合いを持たせることに成功しています。
ですが、手書きの場合ではアラートがないんですよね。つまり、「今日のTODO」というとらえ方をするのであれば、今日中に終わっているかどうかという時間の軸があるともっといいのだろうなと思いました。

おさらいします。バブルマップを構成する軸は以下のとおりです。

• ストレス
• 達成度(進捗)
• 時間 < 個人的に追加したい軸

時間という軸は、常時監視して何かの動きを持たせること - つまりタイマーの役割が必要ですが人間には無理です。せめて、思い出した時に時間の経過が一目でわかればましかなと思います。

バブルマップアプリの仕様を考えてみる

こうなると話は想像できると思いますが、アプリケーションにしてしまえばいいわけですね。タイマーの役割をプログラムにさせるのが適材適所でしょう。また、こういった常時監視で、TODO消化というトリガーごとに確認するとなると、ウィジェットがいいと思います。贅沢をいえば、世のTODO管理プログラムとかスケジューラと連動させたいですね。

私だと以下のようなイメージで考えてみました。

• 1日の就業時間を決めておく(デフォルトは9:00 - 18:00？)
• 何もないところでマウス左ボタンを押し続けるとバブルが出現(上にふわふわ浮きだす)
• ボタンを押した長さでバブルの大きさ(ストレス)が決まる
• バブルをダブルクリックして内容と心の優先度を入力
• 時間経過とともにバブルが下に落ちていく
• TODOが進んだ場合は、バブルをダブルクリックして、スライドで消化率を設定
• 消化率が増加するとバブルが円グラフのように塗りつぶされる(大きさ収縮がいいか？)
• TODOを達成した場合はバブル上でcommand + クリックなどの特殊入力ででバブルがパン！と破裂
• バブルの大きさが小さいほど、優先度が低いほど、落下速度は速くなる(明日に持ち越してもいい場合が多い)
• 就業時間内に終わらなかった(地面に落ちた)バブルは下で固形化する
• 「翌日に持ち越す」を実行すると、残ったTODOが全てバブル化してまた上に浮上(消化率などは維持)

ざっとこんなところでしょうか。誰か作ってくれないかなー・・・と思ったら自分で作れってことでしょうね。

その1はこちら

前回はその1ということで、自分が担当した第1部についてでした。今回は第2部についてです。
第2部は「サイト考察的WEBマーケティング術」というテーマでした。

要約としては、WEBサイト製作プロセスにマーケティングの世界では基本とされている法則を取り入れて、サイトコンセプト設定や企画・設計の足掛かりとするという内容です。また、サイトパターンをカテゴライズして、それぞれについて考慮すべきポイントを具体的にあげていました。

個人的には「ABC分析」しか単語を知らなかったのですが・・・それはそれとして、「50の質問」というのもおもしろかったですね。マーケティングを通じて、あなたはどういう仕事のしかたをしていますか？という自己分析を勧める内容が興味深いところでした。他に個人的になるほどと思ったのは、

1. マーケティングの法則は「公理」である
2. 各法則の内容はシステム設計の考慮すべきことと本質は一緒

1.について話を伺ったのですが、マーケティングの世界は、統計学などを利用して導き出された法則なのだろうと思っていたら、天下り的に「そういうもんだ」と言われている法則が多いのだそうです。そもそも、提唱者がそういうアプローチで広めているのだとか。

システム設計者のアプローチは「定理」というか、要件という各条件から毎回のように結論を導き出すことが仕事のひとつだと思っているので、経験則的に裏付けをとれる、結論を予測できるというのならまだしも・・・なんで？と思った場合には後付けで根拠をとっていくのですかね。勉強不足です。

2.は自分の解釈だとデザインパターンとしての存在価値があると思いました。
自分たちが設計するときに考えていることを、「マーケティング」という切り口で進めると、こういう言葉で説明するんだなと。

各マーケティングの法則は、結局はユーザビリティやページフロー、視線誘導まで落とし込むための足掛かりであって、それに法則という形で呼び名があれば、クライアントへの説明の材料となり、製作指針として容易に共有できると思います。共通ラベルがあるというのは、意思疎通をはかるには確かに便利ですし。

マーケティングそのものというより、自分の中に体系だってある、システム設計における原理や経験則をマーケティングという考え方とマッピングさせれば、また新しい結論やアイディアが生まれそうなので興味が持てました。どういう本がいいんでしょうね？最初の1冊って大事です。

そんなこんなで、WDHAは無事に終わりました。渾身会(このネーミング好きです)では、WDHAの今後の方向性や、見積もりの考え方といった具体的な話まで出たり、楽しいものでした。
WDHAはもともと、岩手で毎月第2土曜に開催されている、IWDDに倣う形で始まったそうで。今度はそちらにも行ってみたい・・・発表したいネタはまだまだあるので、今後もWDHA盛り上げていきたいところです。

その1はこちら

WDHAレギュラーミーティング#003が無事に終了しました。

第1部を私が担当し、第2部はdct-designの蝦名さんが担当されました。
私のテーマは「実学 現場のワークフロー」ということで、いわゆるクライアントとデザイナ、プログラマとデザイナが製作過程において、すれ違う理由というところにフォーカスをあてつつ話させてもらいました。

座談会のように気軽な意見交換を目指したのですが、私の進行が走ってしまったがために・・・。次回に課題を残しつつも、現場の生の声を引き出すという目論見は達成できたので、その中で出たトピックを1つ上げます。

• デザイナとプログラマの役割はどこで線引きをするのか？

デザイナとプログラマの分業を進めるためにも、ペーパープロトタイピングなどを利用して情報共有を視覚化していく方がいいという意見を出したところ、上記のような質問が出ました。
質問された方は、元々コーダとしてスタートし、実装からのアプローチをしていくので、チームで製作する場合に営業やデザイナとの擦れ違い、イメージのずれが発生しがちだとのこと。

私はプログラマの立場からでしたが、線引きはないと話しました。
分業化が当然になっている現状と矛盾すると思うかもしれませんが、あくまで得意分野を生かすように分担するのであって、責任範囲を狭める意味ではないと考えています。
プログラマという立場であっても、あくまで要件を、ユーザの欲求を満たすサービスを実現するためですから、レイアウトだけでなく、配色から何から、ありとあらゆる要素に口を出しますし、一緒に考えますよ。自分たちの得意分野から解決策を提示していきますよ。というのが私にとっての分業です。

私の場合、案件の区切りがあるごとに反省会を行ったり、クライアントとの打ち合わせ後は、作業的な話だけでなく、クライアントがどういう方だったか、それを踏まえて今後の出方を話し合うのが当たり前になっています。それに対し、質問された方は、作業に関する事務的なやり取りが中心になっているとか。

詰まる所、技術力はどれほど高くとも、日頃から情報共有をする土台、率直に意見交換できる信頼関係に基づいたコミュニケーションなくしては、製作は立ち行かなくなる。ということなのでしょう。
「デザインする」というと、ユーザに対してどのように情報を伝えるか？という外的な視点で考えがちになりますが、ワークフローという視点から考えれば、クライアントと製作側、または製作者の間といった内的な視点で、コミュニケーション方法、製作プロセスのデザインを同時に考えていくことも更に必要になると思いました。

その2へ続く

先ほど帰ってきました。パソコンスクールの講師をさせてもらってるのですが、肉体労働と言っても過言ではないですね・・・人にものを教えるレベルではないと思ってますが、教えることで学ばせてもらってます。

さて、明日はWDHA レギュラーミーティング #003にいってきます。
私は第1部で発表する側なのですが、テーマは「実学 現場のワークフロー」。

最初はSVNをWEBデザイナーも使いましょうといったテーマになる予定でしたが、途中で気が変わりまして。
「SVN導入する前にできることあるでしょ？」と思い、変更しました。

CSS-Nite in AOMORIに参加して、ビジネスアーキテクツの森田雄さんに、日頃の思ってることをありったけぶつけさせてもらって、色々と自分の中で確信をもつこともありました。(すべての質問に余すことなく、本音で答えてもらって、とてもためになりましたし、楽しかったです。ありがとうございます。)
何で作るとかWEB標準とかの前に、クライアント相手に、もしくはデザイナ同士が、何を考え遂行すべきなのか？を考えていくと、ワークフローの未成熟さの改善が先だ。と結論が出ました。
かといって、抽象論からいきなり入っても、参加者の求める内容やバックグラウンドはまちまちなので、今までの実体験をベースにした座談会形式で「あれは大変だったよなー」といった雰囲気で意見交換したいと思います。
重い話を明るく話すって大事だと思うんですよね。

で、上記のテーマです。WDHAのサイトでも、ここでも資料やフィードバックは公開していくつもりです。
というかすでに準備してあります。

#今日の寄り道
keynote買うことにした（今更。keynoteプロトタイピングってどうなんだろ？

メインはWindowsだけど、今日はMacBookでマウスなしでどこまで使えるか試してみた。ストレスが思うほどなかった。マウスなしでストレスがここまで少ないUI設計は素晴らしい・・・。
2本指タッチで縦スクロールをトラックパッドのデファクトにして欲しい。あと、マイティマウスで1ボタンやめたのだから、トラックパッドも1ボタンじゃなくすれば、もっと使いやすいのにと思う。
あと、Exposeのショートカットは、あ、ちゃんと記事にしよう。