インターフェイスの限界

これまでの議論を整理してみたい。

身につけるPCであるスマートフォン。「PCを身につける」ことで可能になったのは、他でもないモバイル下での、つまり移動中あるいは屋外でのネット接続や情報処理である。スマートフォンのセンサー群をモバイル下で活用すると、さらにユニークなサービスが構築できる。まち歩き観光案内サービスはその典型であるが、屋外作業や避難誘導など幅広い用途への応用が期待されている。

本稿では、それらをジオアプリの中でも特に「行動連動アプリ」と呼んで、特徴を洗い出してきた。サービスは、ユーザーの行動をトリガーに発生させるイベントから組み立て、デザインもスマートフォンを使う動作から決めるというアプリである。

しかし、行動連動アプリを真の意味で普及させるには、問題がいくつか横たわっている。最大の問題は、ユーザー現在地などの測位精度であり、それには測位環境という大仕掛けの社会インフラを改良していく必要がある（この点については次節で説明）が、スマートフォン側にもそれに匹敵する問題がある。

それが「インターフェイス」である。スマートフォンのインターフェイスは「スクリーン」であり、移動中や屋外の利用に適しているとは決していえない。太陽光の反射や、端末の揺動などから、従来のＰＣ利用時に前提となっていた「視覚による没入効果」が期待できず、また、"ながら作業"が中心になる移動中に、視覚に集中しすぎると、足元が疎かになるなど利用者の安全性にも問題が生じる。そのため、まち歩き観光案内には音声ガイドが意外に役立つことはこれまで見てきた通りである。
また、スマートフォンの主要な入力機能であるタッチ・インターフェイスも、歩行中は満足に操作できない。

一方、スクリーンの限界を補う新しいインターフェイス「ウェアラブル・ディスプレイ」が登場している。スマートフォン本体は懐に仕舞い込み、bluetoothでウェアラブル・ディスプレイと接続、両手をフリーにしたまま、背景と重ね合わせて情報を表示するといった新しい利用シーンが提案されている。

移動利用と可動利用

下表は、ユーザーの利用シーンに着目して、インターフェイス状況を整理したものである。固定ＰＣを使う従来型の「固定利用」と、スマートフォンを利用する「移動利用」や「可動利用」とでは、そもそも利用者の情報処理や知覚のあり方が大きく異なっている。

「移動利用」は、これまでに見られなかった利用シーンである。「移動利用」時は自動車運転中と同様に、視覚は歩行のための情報獲得に集中しており、それ以外に処理できる情報量は限られている。そこに新たなインターフェイスとして音声入出力装置やウェアラブル・ディスプレイが台頭しているのも、運転中にラジオを聴いたり、視界の一部にカーナビを入れて参照することを考えれば、当然といえば当然だろう。近い将来、「移動利用」の場面では、スマートフォンのスクリーンに代わり、異なる入出力装置を組み合わせた新たなインターフェイスが台頭していく。ウェアラブル・ディスプレイは、その選択肢の一つである。

また、「移動利用」時のコンテンツについては、情報処理量が限られるなかで、ユーザーの行動に連動するだけでなく、行動を誘導したり、次なる動作を誘発したりする役割が求められる。まち歩き観光案内であれば、現状のようにスクリーン表示を前提に過剰な情報を提供するのではなく、目前にある関心対象（の気配）や、行くべき方向を簡潔に指し示すといったところである。

一方、「可動利用」は、スマートフォンの中心的な利用シーンである。典型的なシーンは、電車内での利用であり、また、まち歩き途中で立ち止まっての利用である。スクリーンは揺動しており、そもそもスクリーンサイズが小さく、表示される情報量は限られている。このため、入力出力ともに視覚を補完する聴覚の重要性は高い。入力装置をみれば、当面はタッチインターフェイスが採用されていくだろうが、NTTドコモ「しゃべってコンシェル」やiphone「Siri」の普及で汎用化しつつある音声認識装置がそこに加わっていくことは間違いない。

また、「可動利用」や「移動利用」では、従来型のGUIに代わるデザイン上の工夫が求められてくる。揺動や太陽光の影響でスクリーンの没入効果が薄れ、アフォーダンスも期待できないので、これまで意識の外にあったスクリーンそのものが、残念ながら認識すべき対象に浮上してしまう。そこで、従来に負けず劣らず直感的なインターフェイス性を確保するためには、新たなデザイン手法が必要になる。

一つは、従来のGUIが主に対象にしてきたアイコンやボタン、タブなどにの小部品の細工ではなく、スクリーン全体を一つのピクチャーに見立て、出来るだけ大きくスクリーンをデザインする手法である。これは揺動するスクリーンに対して効果は大きい。

また、注目されるのは３Ｄ効果やアニメーションなどによって単なるイメージ（画像）を、シンボルに転換させる手法である。地図をはじめ３Ｄ化が当たり前になり、対象範囲はどんどん広がっていくだろう。

このように、インターフェイスは単にスクリーンの多種化にとどまらず、デバイスそのものも多種化し、そこにデザイン上の新しい工夫が加わっていく。アダプティブ・デザインを適用する際も、スクリーンの向き、縦横比、解像度などに対応するだけでなく、デバイスの違いや、適用デザインにまで考慮していく必要がある。

▼表　利用シーン別インターフェイスの状況

Windows8のデザイン

蛇足であるが、Windowsの「Modern UI」（旧名Metro UI）」のデザインを考えてみたい。Microsoft社の製品デザインの中心的な哲学を成すものとして喧伝されている筋金入りのUI／UX（User eXperience）である。

▼Microsoft Windows 8のUI（画像出典：Microsoft）

Modern UIデザインにはいくつかの特徴があるが、なかでも「タイル」が象徴的である。これはアイコンやウィジェットに代わるもので、テキストや写真などが入る大きな四角い箱が印象的である。機能的には、アプリアイコンとしての操作機能に加えて、アプリが起動していない状態でも一部の情報を表示するライブタイル機能が搭載されている。意匠デザイン的には、グラデーションやライティングを排除した単色ベタ塗りが特徴である。

ベタ塗りの理由は、「Authentically Digital（真にデジタル）」という原則を貫いたからといわれているが、デジタルだからといって装飾を排除しなければならない理屈はどこにもなく、独自のデザインコンセプト、あるいは単なる好みといえるものだろう。

このベタ塗りの効果は、「移動利用」や「可動利用」の際に発揮される。利用者が動き、端末が揺動する中で、このような大柄のデザインの方が認識しやいことは、これまで検討してきた通りである。

しかし、これをデスクトップＰＣで見るとどうだろうか。確かにシンプルであるが、GUIに慣れ親しんできた我々には違和感がある。画面が大きいデスクトップには、タイルが数多く配置されることになるが、グリッドによって整然と配置されているものの、配色の乱雑さはこれが一体デザインなのかと感じさせるほどひどい。これに疑似立体的な装飾が施されていれば、まだボタンなどとして許容できるものの、ベタ塗りがゆえに不揃いの配色がそのまま乱雑さとして伝わってしまう。

このように、「固定利用」しているにも関わらず、ベタ塗りを選択してあえてGUIがもたらす没入効果を捨て去るModern UIデザインのコンセプトは、百害あって一利なしといえる。その無謀さが配色の乱雑さに端的に現れている。また、これが画面の小さいWindows Phoneではそこそこ見られるデザインなのに、デスクトップ上のWindows8が見るに耐えない理由である。

Modern UIデザインは、アダプティブ・デザインを徹底している。それがゆえに「可動利用」に適したデザインを「固定利用」にも適用して失敗したといえるだろう。あるいは将来的に旧来的な「固定利用」がなくなると考え、思い切って「固定利用」を捨てたのかもしれない。もしかするとそこまでも考えが至らず、好みを貫き通しただけなのかもしれないが。

「ウェブアプリ」×「ネイティブアプリ」

最後に、アプリ開発を巡るホットな話題に触れておきたい。ジオアプリ開発を従来通り「ネイティブアプリ」で行うか、html5を使った「ウェブアプリ」で行うか...。これは開発方式の問題と捉えられがちであるが、むしろユーザーの使い勝手や利用行動に大きく影響するサービスの質の問題である。

ウェブアプリを選択する積極的な理由は、アプリマーケットの煩わしい審査を受ける必要がなく、いつでも手軽にプログラムを更新でき、ワンソースでiOSやAndroidなどに展開できるといった開発者側のメリットに加えて、端末にアプリを一々インストールしなくてもよいという利用者側のメリットがある。同じアプリを手軽に作れて、使えるようになるのである。

一方で、ネイティブアプリに比べてウェブアプリは、ローカル側の処理分業が期待できず挙動が鈍いことや、数多いブラウザ間で互換性が低いことが、デメリットとして指摘されている。特に、ジオアプリや行動連動アプリを考えた場合、スマートフォンに搭載されたセンサー機能やカメラが使えないことが、ウェブアプリを選択する場合の大きな障害になっている。

現在、位置情報の取得については、すでに「Geolocation API」というhtml5の規格があり、JavaScriptで位置情報を取得できるように標準化されている。Firefox、Google Chrome、Safariなどでサポートされ、ブラウザ地図上での現在地表示などに活用されている。

また、カメラなどの内蔵部品についても「Device API」によってブラウザ上から操作が可能になっている。さらに今後、「Motion API」が規格化されることで、スマートフォンに搭載されている加速度センサーとジャイロセンサーについてもブラウザで操作可能になる。

こう考えると、html5では難しいと考えられてきたジオアプリや行動連動アプリのウェブアプリ化が、すでに現実になりつつあることがわかる。試行錯誤を繰り返すことになるだろうが、今後Motion APIが規格化され、ブラウザ側の対応が進んだ段階で、比較的単純なアプリは、すべてウェブアプリで作られるようになる。むしろ、ネイティブアプリをインストールさせて持ち歩かせるべきかどうか、あるいは、あえてアプリアイコンを画面に配置し、タップさせるという動作をさせるべきか、といったユーザーの行動パターンから開発方式を考えるようになるだろう。