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枚いくらです。という所まで説明して合意をとっているか？というのが肝心です。

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

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

大分、ブログがご無沙汰ですね。このところ、インプットモードになっていましたが、そろそろアウトプットで整理していきたいと思います。インプットした内容は、主に技術ではなく生き方が中心でした。
が、自分にとってはデザインやビジネスチャンスにつながるヒントばかりだったので、それを少しずつまとめていきたいと思います。

• 個人によって安定と変化の定義が違う
• 変化し続けることが安定と感じる人種がいる
• 変化するにはぶれない軸が必要

安定とはそもそも何か？

ここ最近は、技術の勉強というよりは、人との交流を通じて人を知り、分析するという機会に恵まれていました。自分が考える展望があり、その裏付けを取るために、とにかく人と話すという時間を設けていました。

その中で、「安定」という言葉が常につきまといます。精神の安定、肉体の安定、様々ありますが今もって直面しているのは環境の安定を望む人がそこかしこにいるということです。青森は公務員が多い土地ですから、なおさら感じることではありますが、恒久的に変わらない環境、常に同じことの繰り返しによって続く日常を安定と考える人が多いようです。むしろ、それが一般的だろうと思います。

しかし、新しい知識や技術を望んで、飛びついて行く性分の人間(つまり自分)からすると、上記の安定は「停滞」と捉えます。どちらが良いか悪いかという話ではありません。すみ分けであり、割りきりであると考えています。
そして、安定の定義によって、変化が正の影響なのか、負の影響かが大きく分かれていきます。

キャズムの理論を人の生き方に適用する

ここのところ、パタンランゲージとしてのマーケティング理論に興味があり、キャズムを読んでいます。キャズムでは新たなテクノロジーに対する購買層をいくつかに分類していますが、これは人の生活様式をハイテクマーケティングという視点からとらえた理論だと私は思いました。

おそらく、技術者という職を選び、その中で自ら何かを生産しようと行動していくと、自然と環境の変化を観察し、その変化を自分の中に受け入れようという思考が働き出します。それは、新しい要素技術の習得であったり、勉強会への参加であったり、ブログでの発信だったり、手法は様々だと思います。

結果、「今日の自分は、昨日の自分とは違う」ことを実感していきます。これが私にとっての変化です。時代とともに価値観が多様化し、昨日までの常識がくつがえされるという事態が、技術の世界以外でも断続的に発生していることを目の当たりにするにつれ、その状況に対応できるか否かが真価であると、自分の価値観が構築されていく感覚がありました。

対応し、変化し続けているという事実の維持が、私にとっての安定なのだと強く思うようになってきています。それが上昇なのか下降なのかはわかりませんが、前進しているということに疑いはありません。

慣れるのは武器

だからといって、もう自分は大丈夫だとか、この先を食っていけるなんていう気分にはさらさらなれません。明日の自分を保障するものは何もなく、私にとって保障されているのは、明日の自分を保障するのは自分しかいないという事実だけです。

ですが、人間とは素晴らしい生き物で、その不安にすら慣れていき、受け入れることができるようです。システムのUI設計においてもそうです。初心者が新たなUIに慣れていき中級者となることで、次の不満なり、新しい発見がでてきます。それらに解答を出すために、また機能追加や再設計、修正といった何らかの行動を起こします。

同じサイクルが人の生活様式にも起こりうるということなのでしょう。
このサイクルを少しずつ大きくしたり、加速させていくことが成長という変化であると思います。

別に新しい話でも何でもありませんし、今更の内容ではあります。しかし、このサイクルを体現できているということ、サイクルの成長に必要なものは何かを自覚していることこそが大事だと考えました。

だいぶブログがご無沙汰でした。コーディングでのインプットと人と会うことがメイン業務でブログをまた怠け・・・なんでもないです。

現在、とあるWEBアプリのプロトをDjangoで開発中。といっても、Djangoに慣れようとしているところ。そもそもPythonが初めてですが、Rubyやった後だと違和感少ないですね。

現象

>python manage.py validate

Traceback (most recent call last):
  File "manage.py", line 2, in ?
    from django.core.management import execute_manager
ImportError: No module named django.core.management

原因

cygwinでインストールしたPythonとWindowsバイナリとしてインストールしたPythonどちらを呼び出すべきかわからなくなっていた

解決策

WindowsバイナリのPythonを利用することにし、cygwinからPythonをアンインストール

初歩的なミスを・・・

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にひかれてて、とりあえず仮サービス立ち上げたいし、そっちもいいよなとか思ったり。勉強したいことが溢れるほどあるというのは幸せなことですね。

最近、ひたすら頭フル回転でエントリ書いてたので、ちょっと箸休め的なものにしました。自分の思考をまとめるためとはいえ、脳みそが焦げ付きそう。

最近、GTDの考え方をもっと取り入れて行こうと思ったのをきっかけに、身の回りの道具を見直してみました。
私はスーツの時とカジュアルの時で持ち歩く鞄を変えていて、カジュアルの時に使う鞄は軽くていいのですが、収納力がかなり低い・・・けど、見た目以上の収納力と軽さが気に入ってまして。欠点はスーツに似合わないことぐらい。

持ち歩くのは基本的にmacbookと筆記用具とかメモをすぐに取れるA4用紙とかアイディア帳とか、意外と小物が多いんですよね。すると、鞄を使い分けると道具を集約してないがために面倒なことに・・・

というわけで、ブリーフケースを購入。これが良い！基本的な道具は全部ここに入ってるからいいやと、どこにおいたっけ？とかがなくなってスッキリ。大きさもたっぷりだし、中身が見えて道具を取り出しやすいしと、個人的にかなり気に入ってます。

これが350円ぐらいで買えたのだから、すごくコストパフォーマンスいいなと。それと、ついでにインデックス付きのクリアファイルも350円ほどで購入して、そのブリーフケースに入れてます。これも便利！最後尾には白紙のA4用紙入れて、打ち合わせで絵を描きながら進めたい時には重宝するし、ファイリングもできて一石二鳥。

前回のエントリでは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としては全く別物に変わっているのです。

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

いきなり話は飛びますが、人間の視認能力の限界は思いのほか低いそうです。なので、サマリを頭に３行でつけるというのを今後やって行こうかなと。というか、自分で書いたエントリを読み直して長いしまとまってないしで云々とりあえず改善したいということです。

100% Railsで開発するならサーバ屋になるしか？

当日はRails勉強会@東北からの参加予定もあったのですが、地震によって不参加確定。これに関してはまた機会があるでしょうし、仙台での開催に一度、足を運ぶ方が早いのかもしれません。
開発よりの話もそうですが、Railsはようやくmod_railsが出てきて、共用サーバでRailsが動く日が来そうですが、まだそれは先の事でしょう。
Railsは今のところ、専用サーバでしか使えませんが、Rails勉強会@東北から参加される方々は、100% Railsで開発というチャレンジャー。「Rails屋」なんてどうやったら・・・？と思ったら、自分たちでホスティングしているとのこと。ですよね。

短納期、低予算、高機能という要求が来た場合、今のところ運用費として専用サーバだけは我慢してもらってRailsでスパイラルモデルというのが私としては現実解です。共用サーバで動かせるという要件を満たすために、PHPでRailsもどきを作り、簡易ActiveRecordも作りましたが、何か努力の方向が間違っている気がしてなりません。

ですが、Railsの肝とも言うべきActiveRecordを追って、自分なりの解釈で作ったのはいい勉強になりましたけどね。

そのうちDreamweaverもAptanaもいらなくなるかもしれない

私はAptanaをIDEとして使用しています。理由は

• Railsの開発も同時にできる
• SVNがIDEに組み込み済み
• 複数ブラウザチェックが楽

といったところでしょうか。ですが、Visual Web Developer 2008がかなり良さそうです。

• Microsoftの補完はさすがの一言
• IE以外のブラウザチェックも可能
• Javascript補完もOK
• GUIベースのHTML作成もできる

Microsoft製のIDEは使い慣れてますから、フィールがなじんでいるというのも大きいです。惜しむらくは、バージョン管理のプラグインは有料である事、AjaxベースのJavascriptデバッグは無理(当たり前だけど)。デバッグはFirebugがありますが、IE上のデバッグはその仕様上いかんともしがたいので今後に期待。
少なくとも、私にとってDreamweaverを使う理由はなくなりました。が、RailsでのというかCGI関連の開発を考えると、SVNでソース管理をしているので、しばらくはAptanaになりそうです。

人間の視線誘導とUIの関係について議論中

そして、オープンUI設計をしてみるという名目のもと、バブルマップアプリについてアイディア募集してみました。というのは実は後付けでして。

発表者はもう１人一緒にいったプロジェクトメンバだったのですが、ここの所の情報を次元で考えるという議論について、私たちが出した今の結論を発表させてもらいました。
これは、このブログでの公開用にもうちょっと手を加えて作り直したい所。ModelをViewに対してどう写像するか。つまり、n次元の情報を2次元で表示するとしてどういった手法がとれるか？という点を欧文・邦文の書体や新聞、はたまたiTunesのUIを例に分析するという内容です。

実はこの内容も割愛した点が非常に多く・・・本当は遠近法におけるフォーカスの話や時間軸を4次元目としていれた場合の人間の情報認知などもあります。が、ここら辺は内部で議論中のところもあるので、またの機会にとしました。というか、このブログでも書いて行きます。

TODO管理の手法は業種によって様々。だがそれがいい。

バブルマップアプリは、もともとはTODO管理に気持ちよさとソフトウェアならではの利便性を追加という名目でしたが、IWDDの方々の意見で大きくその仕様を変えようと思いました。
やはり皆さんの日々の業務と直接関わる所ですから、アンケート形式で意見をもらいながら初めて見ると、アイディアがもうこれでもかと出てきました。そもそも、TODO管理はやってないです。という方の意見も非常に参考になりました。

これも別エントリとしてまとめたいと思います。ただ、時間軸を足すという方向性は合っているようです。あとはその実装の仕方ですね。

ひさびさにブレインストーミングをやった

大まかな流れとしては

• 白紙に問題提起をして、解決方法に文章を置き換え
• 付箋に１分〜３分で数セットのアイディアだし
• デザイナとプログラマを混ぜてグループ分け
• 模造紙に付箋を貼って整理
• ホワイトボードにワイヤーフレーム作成
• お互いのグループに向けてプレゼンテーション

その最中に若手育成の心遣いがあったりと、久々のワークショップ形式を楽しみつつ参加しました。IWDDのサイトリニューアルをという名目で、「IWDDのサイトの存在感を出すには？」という大テーマは出されていました。個人的に思ったのは、ブレインストーミングでもマインドマップでもいいのですが、この手のはテーマの具体性と参加者の背景共有がポイントで、事前のテーマについてのミーティングがなかったように見受けられたので、自分もですが、ややアイディアが散漫かなと思いました。

とはいえ、そこはIWDDの方々が自分で作ったサイトな分、理解度の高さで補えているようでした。あと興味深かったのは、私がいたグループはデザインの指向が王道的だったので、ちょっと破壊的なアイディアを出す立ち位置を振る舞ってみました。こちらのグループは機能中心で、向こうのグループはコンテンツとレイアウト中心という印象を受けました。

今後のリニューアル結果が楽しみです。

情報の往来と共育

最後に全体を通じての雑感を。IWDDは23回という開催回数をこなしているだけあって、既に様々なミーティング手法を試しており、そのノウハウは貴重です。加えて、青森と比べるとより情報の往来が多いと感じました。参加者比率が良い意味でバラバラなんですよね。
こういうのは意見が固まらないことが大事だと思うので、アイディア出ししてる時の楽しさは心地よいものした。たくさんの刺激に感謝です。こういった交流を通じて、教え育てるのではなく「共に育つ」関係でありたいと思っています。

あと、開発者の悩みがあまりにも身に染みる話でやたらと親近感わきました。
どこいっても大差ない気がしてなりません。だからこそ、LifeHack系の日々を楽しくして行く方法に目が向いているというのもあります。技術は利用目的に合わせて身につけていくし、そのための勉強は当然ですから、「やって覚えればいいだろ」ぐらいに考えてます。

どちらかというと、ノウハウやアイディア出し惜しみしない土壌を作っていきたいですね。このアイディアを出したら誰かに先を越されるかも・・・！と思うよりは、作ったのは誰であれ自分の考えが世に出た事にもなったぐらいに考えて行きたいですね。

またモチベーションがあがった1日でした。

「iPhone　日本　売れない」とググると、このところのソフトバンクiPhone発売決定に合わせて、それぞれの思うところが書かれているようです。私もつらつらと書いてみようと思った次第です。多分、脱線しますけど。簡単に要約すると

• 日本で必須のサービス(着うた、モバゲーなど)が使えない
• 月額の通信料がばかにならない(最大15MBで9,800円が現状)

この２点につきるようです。日本は世界的に見ても、独自の携帯文化を持っているのは間違いありません。もはや携帯電話は「家電製品」で持っているのが当たり前になっています。こんなことは今更いうまでもないことです。

ですが、上記２点をのぞいてデバイスとしてのiPhoneはおおむね好評のようです。といっても、フル機能を使える人、その恩恵にあずかる人は利用しているPCに１つでもMacがあり、そしてMacがメイン端末の人だけだと思います。
PDAへの現代的解答とでもいいましょうか。結局は「通話機能つき手乗りPC」が欲しいのだと思います。電話もしたいし、ブラウザも使いたいし、ドキュメントも読みたいしと。日本人はオールインワンが好きと考えてますが、「人間はオールインワンが好き」でいいのかもしれません。

結局、PCを日常的に使う人にとって、その生活はもはやPCに依存しているといって過言ではありません。それを場所を選ばず使えるようにしておきたいという願いに対して、ノートPCを持って歩くにはかさばる、通信環境が保証できないとなると、現代的にもっとも満足度の高い解法は携帯電話に採用されている環境であったのは自明の理だったのでしょう。

ソフトウェアとハードとユーザの追いかけっこ

思ったのは、ソフトウェアの進化と環境の開きが大きくなっていることです。これはいいことですし、当然です。ソフトウェアの発想は人間の脳の中で行われるのですから、可能性はその時点で無限です。
これに対し、ハードウェアつまりデバイスの進化はそれに遅れます。しかし、これも割と時の流れで解決していっていると思います。日本の通信環境はPCにとってかなり遅れていますが、携帯電話が山奥でもつながる時代ですから、その時点で解消される問題は多いと思います。

実際、PCスペックが高くなったからこそできた技術(例えばAjaxなどクライアントサイドで負荷を担う事が重要なもの)が現代を賑わせているのがいい証拠でしょう。

タイトルで私がいっている環境とは、人の環境です。iPhoneはおそらく、必要にかられて使う人というよりは、流行を追う人のシンボルとしての側面によるところが大きいと思います。それもいいと思います。
ですが、そこは表面的なものにしかすぎません。求めているのは、どうやったら人間が使いたくなるのか、使って便利だと思うのかということです。それに結論を出すために、人間の行動の中から普遍的なものを抜粋し、現在の生活に適したものとして具現化するという工程を繰り返しています。

人間が生み出した技術は人間のためにあるというのが特に最近、個人的に思うところです。Inflame Casting #123でもWEBという媒体を中心にして同じようなテーマを話していて、個人的にはこの回がお気に入りです。

人間の情報処理は3次元という仮説？

ごく小さな範囲の話をあえてしますが、私の祖母は韓国ドラマをずっと見続けています。その中で、ビデオテープではなくDVDで閲覧するとなると、DVDプレーヤーの操作方法を覚えなければいけないわけです。そこで、祖母が使い始める前からあった多機能プレーヤーは非常にインターフェースが複雑で、やっぱりビデオでいいと最初はいっていました。そのビデオデッキは以前からあるもので、再生と録画の必要最低限の機能しかないものです。
そこで、再生専用DVDプレーヤーを安く購入し、ビデオデッキとほぼ似た感覚で最小限の手順で操作できるようになると、このDVDプレーヤーはいいものだと絶賛した訳です。現代の流行は複合機に向かっているのにも関わらずです。加えて、市場の価値はかなり低いものにも関わらずです。

ああ、技術ってそういうことだなと私の中ではすべてつながってしまったし、自分が突き詰めて行くものが何なのかが見えました。大事なのはコンテンツ・制約(要求)・インターフェースなのでしょう。
ですが、これだと足りません。当たり前すぎるのです。今、情報の次元というものを考える機会が多く、およその情報は3次元で表す事ができると勝手に思っています。これは、人間が扱う情報はという前置きがつきます。いわく、人間の情報処理能力は、というか脳は３次元までしかわからないそうです。今度ちゃんと調べてみますが。

情報処理を4次元にこだわって考えてみる

Inflame Casting#123では、高齢者向けWEBサービスの可能性について少し触れています。私の祖母についていえば、

• コンテンツ=韓国ドラマ
• 制約=DVDでしか見れない
• インターフェース=再生、停止、一時停止、早送り、巻き戻し

確かに3次元だと思います。が、ここにもうひとつあって、そもそも韓国ドラマは、私の母の勧めで見るようになったのです。先に母が韓国ドラマにはまり、祖母にも勧めて・・・という経緯があったのです。これが新たな次元と仮定します。人が使いたいと思い、使って便利と思うまでの過程に4次元の情報があったと仮定するのです。
何と言うラベルを付ければいいのか分かりませんが、特定の信頼関係はブランドになるようです。facebookはこのブランドをサービスとして取り入れており興味深いです。Amazonなどの、この商品を買った人はこんなものも買っていますの先にというか、別ベクトルなのかわかりませんが、同じ根元です。

ああ、とりとめがなくなってきました。つらつらし過ぎです。バブルマップアプリのテーマも4次元です。というか今後のデザインや開発も当分は4次元がテーマです。実証されるのか、不発に終わるかは分かりません。
自分にとってのブログは発信じゃなくて、文章化による思考の整理と発展のようです。内容が変わってきたので、別エントリでまた触れたいと思います。