4月下旬、iPadがいよいよ日本発売となります。iPadは様々な箇所で賛否両論を巻き起こていたようですが、その中で否定的な意見として言われたのが「シングルタスクだからダメ」というものです。おそらく、これは複数のアプリケーションを同時に起動しておきたいと言う意味だと思います。
コンピュータをマルチタスクで動かすのは当たり前になっていますが、人間がそもそもマルチタスクをできているんだろうか？という疑問が湧いたので、それについて思考実験をしたことをまとめてみました。iPhoneユーザなので、改めて各々の操作を振り返りつつ、iPadで行ったとしてどうなるだろう？と考えて行きます。
脳がそもそもマルチタスクなのか？という話を始めてしまうと、無意識や反射のことを考えなければならず、おそらく「よくわからない」と言う結論が大抵待っていると想像できるので、実際に動かしている部分がどうなっているかに焦点を当てて行きたいと思います。
追記 2010/03/08
Twitter上でマルチタスクの定義が不明確と意見がありました。ここでのマルチタスクの対象は後述しますが、目、耳、手のみとします。臓器や細胞まで考えると、話が拡散してしまうためです。また、目、耳、手を対象とするのも、アプリケーション操作において表層で主要となる部位であるためです。そこをつかさどる運動神経などには上記と同じ理由で深く言及しません。
人間のCPUは1つだと言う仮定
人間は1CPUをもったマルチタスク可能な動物で、訓練によってタスク切り替え速度をかなり向上させることができる。と私は仮定しています。よく両手でピアノが弾けるとか、ブラインドタッチができるというのが、同時進行で手が動いているように見えますが、ブラインドタッチについて言えば、指は逐次で動いています。これはキーボードでのインプット自体が逐次でないと受け付けていないからもでもありますが、同時押しも、指を逐次で押しています。それが相当な速度なため、できない人から見れば、同時に動かしているように見えています。
おもしろいのはブラインドタッチの「フリ」をしてみると、次に何を動かせば良いか意識しなくてもよくなるので、ほぼ同時に両指を誰でも動かすことができます。逆にいうと、意識が大きく影響していると言う表れです。ただ、先述の通り、意識と言うものではなく、可動部位を中心に考えます。
可動部位は重複させられない
例えばiPadというデバイスを前にしたとき、私たちが利用できる可動部位として思いつくのは、目、耳、手になると思います。まずそれぞれの部位について同時進行のように見せられる組み合わせを考えてみます。
目 + 耳
動画再生をしている時などが考えられるます。説明字幕が出ている間にナレーションが進んでいたりすると、聞き漏らし、見落としが発生する場合があります。逐次で目と耳を切り替えながら、字幕とナレーションを交互に認識していると考えられます。
目 + 手
ホームでアプリケーションを選択している時や、写真をフリップしながら見ている時などが考えられます。まず目で操作対象を決め、実行するために必要な手順に沿って手を動かして行きます。扱っている情報の性質にはよると思いますが、目で始まって手で実行と言う逐次処理を求められます。
耳 + 手
キー入力をしている時に、入力音をONにしているとします。カチッという入力音が聞こえたことで、正確に入力されたと判断して、次の入力をおこなうと言う動作が可能です。目での判断も間違いなく入っているのですが、耳から手、手から耳と言う逐次処理を行っていると考えられます。
可動部位には主従関係と優先度が発生している
どのパターンにも言えることは、主となる可動部位があり、その実行結果に従って次の可動部位が連動していると捉えられます。目がほとんどの場合、主となっているはずです。目が使えない暗闇は耳に、音が特にない場合は手でなど、状況に合わせて優先度が変わっていきます。
iPadに関しては視覚が必須のデバイスなので、目で対象を捉えるというのがトリガーになると考えられます。
ここから2つある可動部位を重複として考えます。
目 + 目
目が2つあることで焦点合わせなどを行っており、同時に違うものを見るというのはできていません。視野の端にとらえると言うことはできますが、そのものを具体的には捉えられていません。焦点を移して行くことになるので、実質は逐次処理であると思います。
耳 + 耳
反射した音などを両側から捉えるというここと、どちらの耳から聞こえるかで方向の特定などができています。おそらく同時に聞こえているというのは成立していると思いますが、同じ方向から来る音を一緒に聞いているかというと、それはできていないはずです。片方からの音をまず捉え、頭の中の振動が反対側に伝わるか、反射した音がもう一方に遅れて入ってくるかでしょう。
手 + 手
厳密には指と言うサブシステムで考えるべきですが、両手で操作する場合は、フルキーボード入力が考えられます。これは冒頭に述べた通り、実際は逐次入力となります。また、指を2本以上同時に押す場合、それぞれが完全に独立して動くことはなく、例えば画像の拡大であれば、画面の中央から外側へと同じ方向へ動かしています。他の操作もそうです。
マルチタスクはできそうだが、独立した同時処理はどうなのか？
これまでの内容から、人間はマルチタスクが可能だと考えられそうです。ここで一歩進めて、同時に複数のアプリケーションが起動できるとして、独立した状態で使いこなせるのか？と考えてみます。目、耳、手は2つあるので同時に動かすことはできますが、独立して動かすのは困難だと言うことです。
しかし、ここでそもそもの前提として足りないものがあると思いました。それはデバイス側、つまりコンピューターそのものが逐次処理のため、同時入力は受け付けていないと言うことです。2画面や複数アプリケーションという状況はあっても、フォーカス、つまりターゲットをまず決めるという処理が必要な以上、やはりコンピューター側の都合で同時入力はさせてもらえません。
GUIであれば、フォーカスによって1つずつですし、CUIだとキーボード自体は同時入力できますが、内部での解釈は逐次処理になっています。実は人間の行動様式や可動部位を考慮してデザインされていると言われるデバイスも、コンピューター側の逐次処理という制約ありきということになります。
それを考えると、複数のアプリケーションが同時に動くと言うよりは、同時に起動しているのと変わらないぐらい切り替えのストレスがないか、そう見せるインターフェースがあれば今は十分だろうと私は思います。
そういう意味では、メニューとアクティブなアプリケーションが常時表示され、アプリケーションの切り替えも兼ねるWindows7のタスクバーは、かなり秀逸なデザインだと思います。実際、そのおかげでWindows用のDockが不要になりました。
どのI/Oをどこまで独立させていけば良いのか？
ピアノは鍵盤1つ1つが独立したI/Oですし、パーカッションもそうです。しかし、音としては独立していても、人間に取っては和音と言う結果を得ることができます。コンピュータのI/O、それらを総合したUIを考える場合、どこまでの単位で独立させると良いのか？ということについて再考が必要だろうと思います。
マルチプロセッサが普及してきていますが、メモリ管理も含めて完全に独立処理というのは、できるできないがあります。演算と描画を独立させることでパフォーマンスが上がったように、同時処理ができるということは入力方式から再デザインされる必要があるのではと今は考えています。
今回の思考実験は浅い考察だと思うので、I/Oを独立させる単位を考えなおすと言う方向で、また、まとめてみたいと思います。
自覚的デザインシリーズで継続しているデザインプロセスの言語化について、ルック&フィールのうち、特にフィールについて思うところがあった。自分向けのメモを兼ねて残す。
車両用の信号は点滅した方が安全ではないのか？
そもそも、車を運転している時に困ることが1つある。青信号から黄色の信号に変わるタイミングが分かりにくいということだ。自分の視野に青信号が入ってから、自分が通り過ぎるまでに黄色に変わるかもしれないという予測は以下の要素から成り立っている。
- 信号に近づくまでの経過時間
- 現在の走行速度
- 道路状態(雪が降っていると特に余裕を持たなくてはならない)
- 歩行者用の信号の状態
ここで最も簡単に気づくのは、周辺の歩行者用の信号が点滅しているかどうかである。すでに点滅が始まっており、通過するはずの信号までの距離が遠いのであれば減速を始める。これは歩行者用の信号が赤色に変わって間もなく、車両用の信号は黄色になるからだ。
しかし、歩行者用の信号が常にあるとは限らない。であれば、車両用の信号自体、色が変わる前に点滅した方が、突然の急ブレーキとなる確率は下がるのではないか？赤か青に変わるときに点滅すると、フライングスタートする人がいそうで、危険な気もするが。
前置きはともかく、操作フィーリングについて上記の話から、「予兆」「経過」「完了」3つの要素に分けられると仮定した。しかし、能動なのか受動なのかで内容が多少変わってくる。
能動の場合
- 予兆
- 自分の意志でアクションを起こそうとしているので、その時点で不要。ルックとしてはアクションのトリガーだと認識できる状態にしておくのが好ましい。
- 経過
- 自分が起こしたアクションについて、正常に対象が作動して進行していることを示す。ローディング画面や拡大・縮小などの途中経過を表わすフィール。自分が今どこの段階にいるかを表示するナビゲーションも同様の意義を持つ。 長い時間を要するものほど、注意をはらうべき。瞬時に終わる場合は、むしろ不要だろう。
- 完了
- アクションが終了したことを示す。ポップアップ通知や画面遷移など、それぞれの動作後に正常に終わったのか、異常があったのかを明示的に示す必要がある。特に異常時には再試行についての説明、導線が必要。どこの箇所に異常があったか表示、やり直しへの導くリンクなど。
受動の場合
- 予兆
- 考える時間、次のアクションに入るまでの猶予を与える。次のアクションまでに残されている時間、注意書きなどによる告知。ポップアップなどの通知は基本、突発的に発生るものだが、最初の段階でどういった周期で通知されるのかなどが把握できていれば、なお良い。
- 経過
- 予定された処理が進んでいるという安心を与えるもの。インジケーターなどは能動の場合と同じであるが、受動の場合はそれ自体を意識からはずすことを期待しているので、経過を見せないでおくのも一つの手。
- 完了
- これについては能動と同じが良いと思われる。ただ、経過を見えなくしていた場合、経過中に何が起きていたのかを詳細に知るすべを残しておく必要性はより高い。ログの表示や閲覧の方法など。ログがあると、情報のギャップを早期に埋めることができる。
見直してみると、ソフトウェア設計の基礎とも言うべき内容が多分に盛り込まれている。情報過多になりがちな現代人にとって「気づかずに流れる」という状況が増え、確保出来る時間が細切れのため、即効性のある結果を求めている。
流れては困る情報や自分の行動の結果がどうだったかを適切に通知する設計がされているものは、「解りやすい」という評価を得られていると思う。
今年最初のWDHAは森田雄さんをゲストに迎え、特別版として開催されました。地元からの対バンという形で指名を受け、僭越ながらスピーカーを担当です。
事前に、チームマネジメントに関する内容を森田さんは発表するつもりだと伺い、であれば新年1発目だし、個人事業主として活動してきた経験の棚卸しにしようと考え、タイトルの内容としました。
個人というより、私の場合はクライアントとの折衝から開発・保守までを一通りこなすことになりますし、そのような関わり方を自分のスタイルとしています。会社員として働いた時期もありますが、独立してからは特に環境の違いを比較できるようになりました。その上で自分なりの思考法であったり、行動指針を6つにまとめてみたのが今回の内容です。
これといって目から鱗のような話ではないと思いますが、聞きに来てくれた人たちが、明日から前向きな気持ちで働くことができるようにというテーマで内容を練りました。
見方を変えて考える
これから登場するメソッドのベースとなる行動指針です。問題をソフトウェアで解決するというのが私の主な仕事ですが、そのアプローチは千差万別で、これが正解というのは常にありません。つまり一方向からだけ問題を見ていても、選択肢は少なく、より良い方法に気づかずに終わります。自身の視点を変え、仮想的に立場を入れ替えて想像する力というのは、様々な場所で役立ちます。
浅く広く学ぶ
以前、専門と専業は違うというテーマについて書きました。
おそらく職人芸というものに憧れる人は多いと思うのですが、一朝一夕でその領域に辿りつけるわけではありません。何かを深めるという過程に置いて、成長を実感できない、思うように習得できないという行き詰まりを感じることがあると思います。その時に必要なのは、周辺知識の習得、基礎知識の見直しなどによる地盤固めです。
ひとつの穴を掘り続けると、いずれ掘り返した土が自分に降り注ぎます。深く掘り進むためには、掘り返した土をよけておく広いスペースが必要です。
手を動かし続ける
頭で解っているつもりでも、実地では予想と違う結果というのはよくあるケースです。来るべき時に備え、ほんの少しでも自分の手で動かす、作るという行為を続けることは、大きなリターンと発想につながります。
そして、手を動かして学んだものは、不思議と忘れません。特にものづくりの現場に置いて、管理職であろうが、社長であろうが、良し悪しを判断して実行するためには、自分の手で確認するという行為なくして最適解は選べないと思います。
過去を現在へつなげる
過去は財産です。もしあなたに過去の失敗があったとして、後悔したまま、失敗の状態で放置しているのであれば、それが失敗です。 過去は取り返せませんが、どこかで役立てよう、活かそうと頭の片隅に とどめておけば、日の目をみる時が来るでしょう。
そのためには、過去の経験を定期的に振り返り、教訓を現在へ適用するというのは効果があります。過去あっての現在であり、過去を分析し、現在できることを積み重ねることで将来につながると考えれば、過去の失敗も見つめ直しやすくなると思います。
風通しを良くする
似た境遇の人間に仲間意識を持ち、そこからできるコミュニティは様々な活力を与えてくれます。しかし、新しいアイディアや発見が生まれるのは、自分が日々過ごす領域の外と交わる時ということがよくあります。
自分と違う業種の人との交流や、違う発想や視点を持った人の考えや意見は宝の山です。そういった機会を大事にし、積極的に取り入れ、歩み寄ることは後々の発展につながります。
パートナーになる
個人に焦点をあてようとするほど、その背景には多くの人との関わりが見えてきます。分かりやすい例で言えばクライアントになります。 契約の主従関係は現実問題ありますが、それでもパートナーのように振舞うというのが良好な結果を残すために肝要だと思います。 アドバイザーであり、実現者であり、片腕であり。そういった人が、今、求められている人材像だと感じています。
どれかできれば良いというものでもなく、6つのメソッドはそれぞれが相互関係にあると 自分では実感しています。この先、新たにメソッドが追加されるのか、何かに集約されるのか、それはわかりませんが、しばらくはこの行動指針で活動して行くと思います。
まずは皆様お疲れさまでした。恒例のイベントとなってきましたが、まさか自分が発表することになると思っていなかったので、貴重な機会をいただいて感謝しています。
使ったスライドとか
雑感
今更ながらJSRubyを使ってみたんだけどという内容だったのですが、みんなでRuby勉強会@青森に来てみませんか？という前フリでした。HotRubyに興味をもっております。
というのも前フリで、本題は異業種交流をもっとしましょうというのが言いたいことでした。業務知識でも何でもいいので、様々な知識や情報を交換、共有したいというのが切にあります。Give & Takeでそれぞれのビジネスに活かして行きたいと思っています。楽しんで仕事ができるというか、仕事すら道楽にできたら最高だよねと思っています。
そもそも、CSS Niteは敷居をさげて多様な方々にWEBの世界やそこで活躍している人の様子を伝える場と捉えているので、変なことやってる奴がいるなと思ってもらいたいと考えました。「おもしろい」というモチベーションは大事だという裏テーマが伝わるとなお嬉しいですね。
他に思ったことは、アクセシビリティという言葉が現れて久しい中、実際に音声ブラウザなどを利用してOS操作から何から実演で見ることができたのは非常に参考になりました。それを掘り下げて、考察をまた書いて行きたいと考えています。
今後について
とりあえず、交流会にそういう自分が足を運べない時期もあったので、もっとアクティブにしていこうと画策中です。初心者向けにという状況が多かったのですが、それによって基礎固めの機会に恵まれたことが資産になりました。次は自分が突き抜けて行くターンですかね。
今年はただ作るというのではなくて「クライアントが本当に欲しいもの」について精度を上げて行く取り組みを考えたいというのがテーマです。個人だと形式化が弱いので、そこらを重点的に。
目的の共有、要求の精査というものについてヒューマンスキル任せになりがちな反省が有るので、その視覚化とツール化に取り組んでいこうかなと。今のところはクライアントと直接交渉できる場合に限りですけど。そういうフィードバックを勉強会でも発信できたらと思います。
別にこのシリーズを忘れていたわけではなくてですね。言い訳不要ですね。再開します。
予告としてデファクトについて考えるとしました。これは事実上の標準を示す「デファクトスタンダード」のことです。これを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に慣れていき中級者となることで、次の不満なり、新しい発見がでてきます。それらに解答を出すために、また機能追加や再設計、修正といった何らかの行動を起こします。
同じサイクルが人の生活様式にも起こりうるということなのでしょう。
このサイクルを少しずつ大きくしたり、加速させていくことが成長という変化であると思います。
別に新しい話でも何でもありませんし、今更の内容ではあります。しかし、このサイクルを体現できているということ、サイクルの成長に必要なものは何かを自覚していることこそが大事だと考えました。
前回のエントリでは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としては全く別物に変わっているのです。
では、視線誘導としてどんな手法がとれるのか？これを次回のエントリで触れていきます。
いきなり話は飛びますが、人間の視認能力の限界は思いのほか低いそうです。なので、サマリを頭に３行でつけるというのを今後やって行こうかなと。というか、自分で書いたエントリを読み直して長いしまとまってないしで云々とりあえず改善したいということです。
- 地震の影響でRails祭りは次回以降に持ち越し
- Visual Web Developer 2008 便利すぎ
- ワークショップのいい所は全員が発表者になれる
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次元がテーマです。実証されるのか、不発に終わるかは分かりません。
自分にとってのブログは発信じゃなくて、文章化による思考の整理と発展のようです。内容が変わってきたので、別エントリでまた触れたいと思います。
niftyによりアバウトミーというサービスが公開されています。登録ユーザがアンケートに答えていくことで、他の人がどういう傾向があるか、自分がどういう傾向があるかに気づくという内容ですが、おもしろいのはユーザ自身もアンケートを作成できて、他のユーザが答えてくれたり、コメントがついたりという点です。「今どき」のWEBサービスではありますが、これも「うまいなー」と思わせる要素があります。
サービスを構成する要素を考えてみる
まず、WEBに限らず世にあるサービス(ゲームやギャンブルも含む)を構成する要素はなんだろう？とプロジェクトメンバで話していた時に、以下の4つがあるだろうという話になりました。主に娯楽サービスが根拠となっています。
- ランダム
- 毎回、問題や結果が変わる。次を予測しにくい。
- 蓄積
- アクションの結果をカテゴライズしながら蓄積していける。後から蓄積結果を参照できる。
- 単位時間
- メインのサービスを一通り利用するために要する時間。
- 即時性
- 自分が起こしたアクションに対してすぐに結果が反映される。
この4つで構成されて、かつバランスが現代の時流や生活に合っているものが成功しやすいと考えました。中でも、単位時間と即時性の関係が大事だと思われます。
アバウトミーに照らし合わせてみる
では、実際にそれぞれの要素についてアバウトミーではどうなっているかを見てみます。
- ランダム
- 毎回アンケート(質問)が変わる。ただし、「人気の質問」といった簡単な制限を加えられる。
- 蓄積
- これまでに答えた質問、作った質問の履歴を参照可能。また、回答数と作成数のランキングもある。蓄積された情報すべてについて、性別・年代で絞り込みを行うことが可能。
- 単位時間
- 複数の選択肢から1つを選ぶのみなので数秒。問題作成についても、選択肢にテキストをどんどん入力するだけで作れるという簡単さ。いつでも止められるが、中毒性も高く、延々と答え続けられる。
- 即時性
- 自分がアンケートを作成した直後から、すでに回答がある場合もある。(アンケート数の増加によってこの速度は落ちていくと思われる)
4つの要素を満たすのは最低条件
では4つの要素を満たせば、すべてのサービスは成功するのか？といえばそうではないと思います。少なくとも、ここまで来てスタートラインでしょう。次に考えるのは「サービスのローカライズ」です。
少なくとも、日本人向けのサービスであれば「匿名性」「帰属意識」という要素が必須となると思います。根拠を話せば長くなりますが、実例は枚挙にいとまがありません。(匿名掲示板、SNS・・・etc)
ですが、これを考えてもまだブレークスルーとなるサービスにたどりつけるかどうかは別問題です。ここからは、やはり人間行動を分析して分析して・・・という積み重ねによって生まれた視点が決め手となると思います。
少なくとも、アバウトミーの場合は日本人の帰属意識という本質をうまくついていると思います。また、アンケート作成後にすぐレスポンスがあるという即時性は落ちていくと述べましたが、アンケートの多様化によってカバーされていくと思います。「企業からのアンケート」「アンケート作成者のアイドル化」「特定分野アンケートの増加」・・・ひらたく言えば、ニコニコ動画と同じ道でしょう。そこでどういった想定外の効果が生まれるか楽しみでもあります。
ここ最近は、技術的な話から普遍的真理や人間の行動を分析する機会が多くなってきました。だから、新しい人と会うのが、人と話すのが楽しいのかもしれません。というわけで宣伝ではありませんが、話を変えます。
IWDDミーティング #23に参加します。かつ第3部のプレゼンテータまでやることになりました。テーマはオープンUI設計をしてみるです。先日のバブルマップアプリについて、基本的な構想はできてきました。ここらで、その内容を共有して参加者で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が全てバブル化してまた上に浮上(消化率などは維持)
ざっとこんなところでしょうか。誰か作ってくれないかなー・・・と思ったら自分で作れってことでしょうね。
母から聞いた話ですが、モスバーガーでは電話注文すると、受け取りの際に専用の袋に入れて「10円」を渡すサービスがあるそうです。私は今日までそれを知らなかったのですが、その心配りに非常に感動しました。
モスバーガーは注文を受けてから調理をするので、ある程度の待ち時間が発生します。その時間を惜しんで、あらかじめ電話注文して指定した時間に取りに行くというユーザの工夫についてまで考慮しているわけですね。
個人的な感覚では、注文や問い合わせの電話は、発信者側が負担する経費であると思っていますし、よくあるパターンではフリーダイアルを用意すればいいことだろうと考えるところです。
つまり、発想の転換というところでしょうか。電話注文をしておくというのは、待ち時間が長いというマイナス要因に対するユーザの声であると言えます。その声に対して専用の袋まで用意して10円を渡すという行為は、プラスへの変換が巧みだと思いました。
注文の通話時間が長引いたら、もっと金額が増えるのか？といった野暮な発想は置いておきますが、自分で仕方ないと思っている小さな不満に、ささやかであっても「見過ごしてはいませんよ」というメッセージは人の隠れた欲求を満たすことになると思います。また、手渡しである直接のコミュニケーションによって、人間同士のふれあいの重要さまでを再確認させられます。それで電話注文するリピーターになったら、まさにモスバーガーの思うツボですね。すごくいい気分の「してやられた感」です。
これで何かできるのではないか？と、何か頭の中でつながるものがあったのですが、まだ具体的にはなっていません。もう少し、掘り下げが必要です。
少なくとも、新しいサービスというよりは、既存のサービスでかゆいところに手をとどかせるためのサービスだと思います。こういったサービスは新規顧客というより、リピーターの増加に貢献するでしょう。もしくは、すでに存在はしっていても、踏み切れていない2次的(潜在的？)新規顧客の層に「口コミ」として広がるタイプのサービスかと思います。
長谷川恭久さんのエントリが興味深かったので、自分なりに掘り下げてみようと思います。先のエントリは、まず自分から何かしなくては。行動がたりない。と危機感をもった内容でした。何かって、何だろ？と思ったので、自分なりの回答というか自論を展開したいと思います。
個人的には、「新たな発想は異業種との交流から生まれる」という結論を今は持っています。
WEBの変遷に最初から携わっていたわけではありませんが、思うにWEBの存在意義は、異業種の参入によって変化していったと思います。しかし現状を振り返ってみると、中身のすげ替えだけのサービスの氾濫、DHTMLとAjaxの混同、ハイパーリンクの解釈違い、パソコン通信への先祖返りと、あげたらキリがありませんが、WEBという媒体にどうしようもなく閉塞感を感じることがあります。いうなれば、WEBという媒体への囚われです。
なぜそうなってしまったのでしょうか？異業種との交流という切り口から考えてみました。
私が思うに、業界をけん引するトップランナーによく見られる共通点は、異業種の出身であることだと思います。専門家としての実績の背景には、必ずと言っていいほど、それ以前の異業種での体験が生きています。その体験を新たに飛び込んだ世界で応用することで、パラダイムシフトが起きる、もしくはその足掛かりとなってきたと考えています。
逆に言うと、今は異業種の体験、発想を使いきったがために閉塞感が生まれているのでしょう。また、1つの業種に長く従事すれば、その業種が持つ本質はいやでも見えてきます。実績を積み、技術も習得し、仲間もできてきます。しかし、そこまで辿り着いた人同士で・・・つまり内輪で本業の情報を回しあっても「同意」しか出てこなくなる時がきます。
その時が、異業種と話すタイミングだと思います。とはいえ異業種なら誰でもいいわけではなく、異業種側のトップランナーが理想でしょう。よく、2割8割の法則といわれますが、組織をけん引するのは2割の人間だとか、2割の顧客の売り上げが全体の8割を占めるとかいう法則です。
8割の人間を軽視しているようで嫌なのですが、まったくの嘘ではないとも思います。達人は達人を知るというか、類は友を呼ぶというか、よくわかりませんが人は同じような背景をもった人と自然と集まるという経験則があります。ここでの背景は「異業種の出身である」を指します。同業種で職種が違うのもありですね。もっと敷居を下げるなら、自分と異なる体験についての話を求めることでしょうか。
最後に、乱暴なまとめをして終わりにします。
WEBしか知らないWEB屋はどこかで詰まると思います。
1つしか言語を知らないプログラマがそうですから。
#今日の寄り道
・iWork08届いた。新しいおもちゃ。
脳内で世をにぎわすサービスについて、あれこれ考察するのが趣味のひとつみたいなものなのですが、ここ数年で「これはやられた！」と思ったサービスのひとつとして、「ニコニコ動画」があります。
ニコニコ動画とは何か？についてはGoogle先生に聞いていただくとして、あのサービスが盛り上がる要因の切り口として、「参加しているユーザを分類」というアプローチを取ってみます。今更ですけど。
手書きしてたのをスキャンしたのですが、改めて自分の字と絵の下手さに萎えてます。
気を取り直して。ユーザを3つに分けて考えてみました。
- ヘビー(発信)：動画を自分で製作し、直接コンテンツ増強に貢献している人
- ミドル(編集)：動画にコメントを投稿したり、タグをつけることで半直接コンテンツ充実に貢献している人
- ライト(閲覧)：動画の視聴のみだが、再生数のランキング向上などで間接的にコンテンツ充実に貢献している人
さらに、ヘビー、ミドル、ライトの相関関係を簡単にまとめると
- ヘビーの動画投稿でミドルやライトに対する人集めの効果
- ミドルによるコメントやタグ管理でコンテンツ自体に想定外の付加価値
- ライトによる再生数増加がランキング向上をもたらし、ヘビーとミドルのモチベーションアップ
このサイクルが成熟すれば、あとは勝手にコンテンツが増え、盛り上がり、口コミ効果（自分のブログでの紹介や、ニュースサイトでの取り上げ)という理想的なスパイラルへ・・・といったところでしょうか。
ここまでくれば、後は運営がサービスの横展開(市場、着メロなど)を加えれば、スパイラルの数が増えるだけでなく、それぞれのスパイラル自体も大きくなっていくと、まぁ、よくできてるなと本当に思います。儲かっているかとは別として、「人が楽しむ」という点では今後も楽しみです。
あとは、日本人が好む「WEBにおける匿名性」という点、動画投稿者に対して「うｐ主」という共通の呼称(愛称？)をつけて、偶像化というかアイドル化する性質などが、絶妙に相互作用しているなと思う次第です。
自分なりにまとめると、サービスというか、ソフトウェアの本質をつかんだ結果だと思います。
人の動きや感情に合わせて、形を変えていく。
これは、人の特性、この場合は日本人の特性を研究してきた人のなせる技だと思います。たぶん、最初から研究しようと思って生きている人は少ないと思いますけど、人の特性を「おもしろい」と思ったり、「なんで？」といつも思っている人でないと、こうはいかないだろうと思います。
日頃の何気ない動作や習慣すべてがサービスの源と再認識させられますね。マンウォッチングを趣味とする人は、総じて新しいサービスを生み出すチャンスを持っているのかもしれません。
なんか、堅苦しい文章になってしまいましたね。でも、実際は雑談というか、酒飲んだり、飯くったりしながら話したことばっかりですけどね。脳内ダンプのタイトルどおり、つらつらと書いてみました。
#今日の寄り道
ブログのカテゴリをざっくり4つに分類してみた。根拠については、ペーパープロトの公開とあわせる予定。
あと、WordPressの基本設定まわりをちょこちょこといじって、ルートアクセス時にブログ表示という形に。
mod_rewriteのルールをコピペしてね！ってどうかと思うんですが代替策はまだなく。
Inflame Casting #94まで聞いてる途中。そろそろ感想まとめと聞きなおしかな・・・
DropClockを使ってみた。色々と思うところはあるけど、それは後日。
でも、こういうの嫌いじゃない。
