自覚的デザインを目指す その3
2008.08 14

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

別にこのシリーズを忘れていたわけではなくてですね。言い訳不要ですね。再開します。
予告としてデファクトについて考えるとしました。これは事実上の標準を示す「デファクトスタンダード」のことです。これを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秒以下がしきい値と考えています。といっても、それぞれのエフェクトにさらに細かく種別があるので、もう少し解析が必要とは思っています。ここは、人間の視覚の根本である、情報認知の世界だと思うので長い道のりになる気がしています。

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

この記事へのコメント

自覚的デザインを目指す その2
2008.06 19

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

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

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

この記事へのコメント

自覚的デザインを目指す その1
2008.06 17

IWDDミーティング#23でUI設計を人間の視覚で考えるという手法について発表しました。が、前回のエントリで割愛した内容について補足しながらまとめて行きたいと思います。 現代的にModel設計はプログラマの仕事、View […]

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

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

この記事へのコメント

作者について

青森県内でソフトウェア・システム開発を行うフリーランスのプログラマー。元々は集中監視システム開発に従事。現在はウェブサイト製作・オンラインシステムの開発案件を中心に、プログラミングのスキルトレーニングや講演も行う。

TEL 0172-55-7030  FAX 0172-55-7031
10:00 - 18:00 土日祝休

恐れ入りますが、お急ぎの場合を除いて、メールにてお問い合わせください。