Personal tools
You are here: Home ブログ takatsuka Categories UI/UX
Document Actions

UI/UX

Up one level

Document Actions

フォルダは「実装モデル」なのか、「脳内モデル」なのか?

タグによるドキュメント管理はディレクトリ構造の呪縛から私たちを解放してくれる、
そしてそれは、情報へアクセスする方法を革新し、情報活用を新たな次元に引き上げることになるかも、
なんてことを、この数年、考えていました。
どう考えても、ファイルシステムに依存したディレクトリによる構造化よりも、
複数の属性の付与と集合演算的な操作の方が、情報の整理と再現の自由度が格段に高くなるはず、
と考えていたからです。
しかし、その考えが最近、揺らいできました。

理屈ではタグは自由度を高めるはずなのですが、
現実にはそのポテンシャルを人間の側が使いこなせるのだろうかという疑念を拭えないのです。
どれだけ高機能であったとしても、当然、使いこなされない限り意味がありません。
なのに、タグ操作のポテンシャルを発揮できて、かつ「直感的」なUIがどうも見つからないのです。

アラン・クーパーは「About Face 3」で、UIをユーザーの「脳内モデル」で表現すべきである、と述べています。
つまり、コンピューターのハードウェアやソフトウェアの実装の都合をユーザーに押しつけるべきではない、ということです。
なるほど、使う側のイメージが既にある場合、そのイメージに沿ったUIの方が使い易いに決まっています。

そして、アラン・クーバーは、「脳内モデル」ではなく「実装モデル」が適用されている例として、
ファイル操作をユーザーに意識させることの弊害を訴えています。
ファイルシステムという実装に沿ったディレクトリという概念をユーザーが使いこなすことを期待するのではなく、
保管場所を意識しないで済む仕組み、属性検索の仕組みを提供すべきだと述べています。

おお、私の思いと同じようなことを、巨匠が言っている、とか思ったのですが、
ホントにそうなのかな、というのが最近の率直な気分なのです。
果たして、どこか自分が預かり知らないところに保管され、その時々に応じた手がかりで探し出せる、
というのがドキュメントの保存と再利用の「脳内モデル」なのでしょうか?
どうも私にはそうは思えません。
人は、物理的に何かを保管する際に、棚や引き出しなど置き場所を手がかりにするものです。
その観点に立てば、フォルダメタファは、ファイルシステムの「実装モデル」ではなく、
人間の習慣的な整理整頓の「脳内モデル」とも考えられます。
私は最近では、後者だと思うようになりました。

例えばGoogle Docsでは、一覧画面の左側ペインにタグをフォルダアイコンで表示してあり、
そのアイコンをクリックすると右側のペインに選択されたタグが付与されているドキュメントが一覧されます。
これは見慣れたWindowsのExplorer的なドキュメントナビゲーションです。
そしてその中で、見慣れた「フォルダ」風にタグが表現されています。
GoogleがこのようなUIを提供している理由は、
タグよりもフォルダの方がドキュメントを保管したいユーザーにとって「直感的」だと判断したからなのかもしれません。

ただ、このフォルダアイコンでの表示は、タグの特徴を伝えるという面では明らかな後退です。
私自身、Google Docsを利用していて、フォルダアイコンでナビゲーションされると、
ドキュメントがそのフォルダ内に「ある」という感覚を拭えません。
一つのドキュメントに複数のタグを付与していて、そのドキュメントを探そうとする場合、
探している状況に応じて複数のタグを使い分けて選択するよりも、あれは「どこに」あったっけ?と考えてしまいがちなのです。

私がこう感じるのは、私が旧来のパラダイムに囚われているせいかもしれませんし、
多少なりともソフトウェアに関わって来てファイルシステムに慣れているからかもしれません。
でもこれは、私個人の問題ではなく、多くの人に共通する感覚とは言えないものでしょうか?

もしかすると、Google Docsではタグを階層化できることも、このような感覚をもたらす要因かもしれません。
あるいは、bookmarkやRSSアグリゲーションやblogなどのフォーマットは1種類で情報を管理していると感じさせる機能と、
様々なフォーマットのドキュメント(ファイル)を自身の手で管理していると感じさせる機能との違いなのかもしれません。
つまり、「情報」は形のないもので、「ドキュメント」は形があるものとして、扱う際の意識が異なる可能性はないでしょうか?
そのことが、あらかじめどこかにあることを受け入れている状態で目印をつけるという行為として認識するのか、
どこにもない状態から保管するという行為として認識するのか、という違いを生むようにも思えます。
それとも、ただ単純に、人間は複数のファセットで情報を管理することが苦手なのかもしれません。

などと考えれば考えるほど、実はフォルダメタファは人間にとっての「脳内モデル」なのではないか、と思うのです。
しかし、親和性が高いということに留まるのではなく、人間の能力を拡張するという観点も重要で、
その意味でやはり、タグの活用は諦められません。

タグ操作のポテンシャルを発揮できて、かつ「直感的」なUI。
どこかにそれはあるのでしょうか?

Category(s)
UI/UX
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/takatsuka/30d530a930eb306f300c5b9f88c530e230eb300d306a306e304b3001300c8133518530e230eb300d306a306e304b/tbping

「直感」はどこから来るのか?

前のエントリーで、フォルダメタファは実装の都合を押し付けられただけのものではなく、意外に人間の「脳内モデル」(「メンタルモデル」と呼ぶ方がユーザビリティ界隈では通りがいいかもしれません)を表しているのではないか、それに対してタグのポテンシャルを発揮できる「直感的」なUIがないものなのか、という期待とも嘆きともぼやきともつかないことを書きました。
そもそも、タグ操作に限らず、「直感的」なUIとはどうやったら実現できるのでしょうか?

よく、「このUIがわかりにくいのは直感的ではないからだ」とか、逆に「このUIは直感的で使い易い」とか、ソフトウェアの使い勝手が「直感」という観点で評価されます。
そこでは、「直感」は自明なものでかつ普遍的に共有されていること、という合意があるかのようです。しかし果たして、誰もが同じ「直感」を持っているものなのでしょうか?

Jef Raskinは「ヒューメイン・インターフェース」で、「あるユーザが、特定のインターフェースを直感的と評価した場合、それは該当ユーザの慣れ親しんでいる他のソフトウェアや手法と、そのインターフェース操作が似ていることを意味しているだけなのです」と述べています。
また、Joel Spolsky も、彼のコラム「Joel on Software」で「ユーザモデルは、ほかのプログラムがどう振る舞うかユーザが見てきたことを反映している」と述べています。
もちろん、認知心理学的なレベル、さらには生物学的なレベルで決定される「直感」もあるのかもしれません。しかし、より高次のレベルでは、確かに私たちは文化的な習慣に支配されているようです。
例えば、今や「直感的」とも言える、フロッピーディスクのアイコンが保存操作を表すことも、私たちはいつかどこかで学習しているのです。それは、「直感」というよりも習慣、イディオムなのです。
Alan Cooperは「About Face 3」の中で、「一般にメタファと考えられているGUI要素の多くは、実際にはイディオムである」と言い、さらに「メタファ的なインターフェースは、直感的な仕組みを基礎としているので、リスキーな方法だ」とメタファと「直感」について否定的な意見も述べています。

つまり、「直感」は人によって異なる可能性を含んでいるということです。従って、特定の誰かの「直感」が自明で普遍的なものだと思い込むことは危険なのです。
もちろん、文化的なバックグラウンド、特にソフトウェアのユーザー体験が似通った人の中では、UIについての「直感」は共通性が高いでしょう。
ただし、新しい機能や概念については、慣れは存在しないため、共通性のある「直感」を当てにすることはできません。

Alan Cooperは、「すべてのイディオムは学習を必要とするが、優れたイディオムは一度学習すれば身につく」として「デザインの中心にはイディオムを据えるべき」と考えます。その実例として、優れているが未知のGUIに人々が慣れるまでの発売初期はMacも苦戦したものの、そこを超えてからはそのユーザビリティが評価される結果となったという歴史を例として挙げています。
ユーザーの学習を前提として、その学習を容易とする考え方は、新しい機能や概念を実現するUIの検討する際の指針とできるかもしれません。

任天堂で1960年代後半から数々のヒット商品を開発してきた横井軍平という人がいます。アナログなおもちゃ時代から活躍しながら、ゲームボーイの開発まで行ったという凄い人です。
横井さんは、ドンキーコング開発時に、どうやって遊び方が伝わるかを検討して、女の子をさらったドンキーコングが上に登って行くデモ画面を入れたそうです。そうすることで、プレイヤーは上を目指していくということが「直感的」にわかるようになるという狙いです。
つまり、「直感」を誘導する仕組み、あるいは新しいイディオムを学習するためのガイドを用意したということです。
その発想とセンスには感嘆します。そこには、プレイヤーが当然、遊び方を自然とわかってくれるという甘えも、マニュアルを読めばわかるという言い訳もありません。

もしかすると、「直感」はどこかにあるものではなく作り出すものである、と考えてみる位の不遜な態度でなければ、「直感的」なUIは生み出せないのかもしれません。

Category(s)
UI/UX
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/takatsuka/300c76f4611f300d306f3053304b30896765308b306e304b/tbping

「創造」はどこまで許されるのか?

前のエントリーで、「直感」は実は慣習的だということと、だから新しいUIを検討する際には「直感」を創り出す位に考えてみてもいいのでは、と書きました。
その中で、Joel Spolskyの「ユーザモデルは、ほかのプログラムがどう振る舞うかユーザが見てきたことを反映している」という言葉を引きました。実は、その言葉には続きがあります。
「UIに関する決定のほとんどに関して、あなたは何かをスクラッチからデザインする前にほかの有名なプログラムが何をやっているか調べ、できるだけそれをまねるようにする必要がある」
つまり、創り出すことは避けるべきだと明確に述べているのです。

Joel Spolskyの元のコラムでは、真似る対象として、マイクロソフトのアプリケーションを想定しています。プログラマー自身の好き嫌いよりも、ユーザーのメンタルモデルへの支配的な状況を考慮すべきだという論旨です。
確かに、ユーザーにとって慣れ親しんだ操作が前提とできれば、新しいUIを学習するためのコストを避けられます。
しかも、支配者としての経歴が浅いアプリケーションのUIは、一定の慣れがある分は「直感的」に作用し、一方でまだ陳腐化していない分は、ほどよく「先進的」という評価となる美味しいポジションなのかもしれません。
facebookの存在感について井上さんが触れている、エンタープライズソフトウェアでTwitterやfacebookが参考とされるというトレンドは、そういう意味で美味しい旬の味が求められているのかな、と思えます。もちろん、facebookやTwitterのソーシャルな機能が重要なのでしょうが、機能を体現するためのUIの印象も大きく関係しているはずです。

では、ソフトウェアを開発する際には、マイクロソフトか、Twitterか、facebookか、いずれかのUIをそっくり踏襲しなければならないのでしょうか?それでは、そもそもTwitterやfacebook自身、独自のUIを工夫すべきでなかったということになってしまいます。
ソフトウェアの世界にも残酷な自然淘汰が存在します。そして、生き残ったUIが結果的に利用者に適応したUIとなるとしても、そこには常に進化の可能性も残されています。
しかし、自然の進化とは違い、進化を偶然の突然変異に委ねる必要はありません。例え残酷な生存競争があるとしても、進化の方向を決めるのは、自然でも神でもなく、開発者なのです。

Category(s)
UI/UX
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/takatsuka/300c52759020300d306f3053307e8a313055308c308b306e304b/tbping

タイポグラフィと日本語

Webサイトやアプリケーションのユーザビリティには様々な要素が関連しますが、表面的なデザイン、つまり見た目の影響も軽視できません。
表面的なデザインで考慮すべきポイントの一つとして、タイポグラフィが挙げられます。文字のフォント、サイズ、配置をきちんと考慮すると、美しさと見易さが全然違うのです。

私はデザイナーでもないので、日頃、タイポグラフィの重要性を意識することもなかったのですが、「プレゼンテーションZen」と「プレゼンテーションZen デザイン」を読んで以降、ちょっと気になるようになりました。
「プレゼンテーションZen」では、効果的なプレゼンテーションを行うための準備から、スライド作成、プレゼンテーション実施までが解説されています。その中で、スライドのデザインでもやはりタイポグラフィが重要だということが述べられていて、美しいサンプルスライドによってタイポグラフィの効果を実際に納得させられます。
ホントはこのブログエントリーでも、スライドでサンプルを作成しようかと思ったのですが、何しろ私はデザイナーでもないので…

一旦、その重要性に気づいてみると、世の中のあちこちのデザインでタイポグラフィが考慮されていることに気づきます。というよりも、プロのデザインではタイポグラフィは当然、考慮されているものなのです。
多くの広告ポスター、TV-CMの中で表示される文字、TVドラマや映画のエンドロールなど、一般的な文書の中の文字とは異なり、そこでは文字の大きさや配置、形、色が大胆にデザインされています。そしてその効果は、明らかに見やすさとともに美しさにもつながっています。

さて、だからソフトウェアのUIでもタイポグラフィは重要ですよね、で終わってもいいのですが、最近、文字に関して感じることがあるので、ついでに触れておきます。
文字は、(それこそが本来的な役割なので当然ですが)デザインとしての形だけではなく意味を伝える可能性があります。
漢字を理解できない外国の方が妙な単語のタトゥーを入れているとか、恥ずかしい英単語がプリントされたシャツを日本人が着ているという笑い話を聞いたことがないでしょうか?当人たちにとってはそれは純粋な造形上の問題なのに、意味を解する人にとっては造形上の問題に意識を限定することができません。どうしても、意味の方が形の印象よりも強く伝わるものです。

意味を伝えるという観点では、言語の習得状況の違いだけでなく、表音文字と表意文字の違いもあります。

日本語は、表意文字である漢字を多く含みます。そのことが、デザインの際に無視できない影響があるのではないかと思います。

書籍やWebページのレイアウトデザインを行う際に、意味が邪魔することなく純粋にタイポグラフィ的な視覚効果だけを確認するために、Lorem ipsumと呼ばれるダミーテキストがあります。
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, …
というデタラメなアルファベット文字の羅列となっていて、英語としての意味を想像されることなく、レイアウトに「それっぽい」文字列が埋めることができる仕組みです。

画面イメージを作成する必要があって、先日、Lorem ipusumと同じような日本語のダミーテキストがないものか、少しだけ調べてみたのですが、Lorem ipsumほどツールとして定着したテキストは見つかりませんでした。
(もしかすると、私が無知なだけで、日本語の定番ダミーテキストもあるのでしょうか?)
そういう定番はないものの、いくつか提供されている日本語のダミーテキストや、日本語ダミーテキストを生成するツールはありました。ただ、どれもダミーテキストとしては微妙な印象でした。

なぜ、微妙だったのか?
日本語らしく見せるためには、漢字とひらがなとカタカナが一定の割合で混在している必要があります。文字のシャッフルが不十分なのか、ダミーテキストを生成する元となった種文書の中のカタカナが想像できてしまったり、漢字の固有名詞が残っていたり、ということは改善の余地がある話です。しかし、表意文字である漢字を見ると、無意識の内にどうしても意味を追ってしまいがちになることは、如何ともしようがない気がします。漢字は1文字だけでも意味が何かしら伝わりますし、ランダムに連結された場合にも単語として意味を解釈したくなってしまいます。完全な「無意味」には見えないのです。

こうして改めて、文字表現としての日本語の複雑性を考えさせられました。
きっとその日本語の複雑性は、ソフトウェアのUIでのタイポグラフィ的なデザイン面でも影響するのでしょうが、ダミーテキストとは違って意味を伝えることを切り離せない、というよりも意味を伝えることが重要だからこそ、一層、話がややこしくなるのではないかと思います。
ややこしいということだけがわかっても、それを解きほぐす鍵がわからないと意味ないわけですが…いやあ、わかりません。

Category(s)
UI/UX
The URL to Trackback this entry is:
http://dev.ariel-networks.com/Members/takatsuka/coreblogentry.2010-11-29.0365033762/tbping

Re:タイポグラフィと日本語

Posted by Anonymous User at 2010-12-06 01:35
表意文字が適当に並んでいても意味を読み取ろうとしてしまうのを排除したいなら、
文字そのものをダミーにしないといけないと思うんですが。
存在しそうで存在しない漢字や仮名(みたいな文字)を。

Copyright(C) 2001 - 2006 Ariel Networks, Inc. All rights reserved.