最近,AjaxやDHTMLといった技術を利用して,ページ遷移が少なく,画面の中身がダイナミックに書き換わるサイトも珍しくなくなっています…という枕詞が陳腐に感じられてしまうほど,こうしたアプリケーションがずいぶん増えてきました。例えば,Google Docs & Spreadsheetsをはじめとするワープロや表計算などを利用できるサービスも,以下のように言われるほど数多く登場しています。

Officeの文書をオンライン化して共同作業や遠隔ビューを可能にするトレンドは、いっこうに衰える気配もない。最近買収されたウェブExの対抗馬不在のまま、みんなただ使い方を知っているのでウェブExを使い続けているという状態なのだが、この市場に参入してくる新規スタートアップはほぼ毎週のように生まれ、相変わらず後を絶たない。
(TechCrunch「またオンラインのプレゼンテーション・ソリューション…zzzzzz」より引用)

 ワープロや表計算以外にも,RSSリーダーやインスタント・メッセンジャー(IM)なんかもそうです。こうしたツールがデスクトップ・アプリケーションに取って代わるんじゃないか,なんて予想を立てる人もいます。実際に,そうしたサービスが,デスクトップ・アプリケーションを駆逐してしまうかどうかは筆者にはよくわかりませんが,デスクトップ・アプリケーションに良く似たインタフェースを持ったサービスが登場し続けているのは確かです。プルダウンメニューが使えたり,タブが使えたり,ウィンドウ内に小さなウィンドウを表示したり,プログレスバーを表示したりといったインタフェースは,どれも多かれ少なかれ,デスクトップ・アプリケーションで培われてきたインタフェースの方法論をウェブに持ち込んだものです。JavaScriptの利用技術の進歩は,ウェブ・アプリケーションにおける「デスクトップ・アプリケーション」っぽさをより推し進めています。

 こうした「デスクトップ・アプリケーションの模倣」はすごく合理的です。前回,すでにあるものを模倣することの利点について考えました(「何かに似せたユーザー・インタフェース」)。デスクトップ・アプリケーションを模倣することで,これまでデスクトップ・アプリケーションになじんできた人たちがスムーズに利用できるようになるからです。前回紹介したSo-netのウェブメール・システムなんて,まさにそのものですし,ワープロや表計算も,デスクトップ・アプリケーション(というかWordとExcelですよね)になじんでいる人がたくさんいるジャンルです。

 今回は,デスクトップ・アプリケーションのインタフェースのルールと,それをウェブ・アプリケーションに応用した例をいくつか見ながら,考えていきたいと思います。

メニューにおける「...」とは

 そもそも,この話題を取り上げようと思ったのは,Google Docsを操作しているときのことでした。Google Docsはウェブ上で利用できるワープロソフトで,実際には「ワープロ風HTMLエディタ」的なものではありますが,WordやOpenOffice.orgなどとのデータのやり取りを行うことができ,PDFにも出力できるなど,デスクトップ・アプリケーションのワープロソフトの代替というか,文書作成のための新たな選択肢の一つとなることを目的としたサービスです(たぶん)。

図1: Google Docs

 Google Docsは,デスクトップ・アプリケーションのインタフェースの雰囲気を,ウェブ上のサービスに持ち込んでいます。とはいっても,前回紹介したSo-netのウェブメール・サービスのように,デスクトップ・アプリケーションそっくりにしてあるというわけではなく,ウェブ・アプリケーションならではの便利さも残しつつ,デスクトップ・アプリケーションの雰囲気を取り入れようという感じです。

 例えば,画面の左上には「ファイル」というボタンが付いています。これは,デスクトップ・アプリケーションの「ファイル」メニューを模していて,押すとその下にメニュー項目が表示されます。ためしにWordのファイルメニューとGoogle Docsのファイルメニューを比べてみます(筆者の持っているWordはWord 2003です)。

図2: Wordのファイルメニュー(左)とGoogle Docsのファイルメニュー(右)
 

 もちろん,全く同じではありませんが,よく雰囲気を似せていることがわかります。そこには「新規作成」や「印刷」といった機能が並んでいます。そして,今回この話題を取り上げるきっかけとなったのは,「印刷...」や「名前を付けて保存...」の後ろについている「...」です。

 これは,「このメニューを選ぶと,この機能を実行するためには追加の情報の入力が促されることを意味します。例えば「名前を付けて保存...」の場合は,新たにファイルにつける名前,という追加情報の入力が必要となりますし,「印刷...」なら,用紙サイズや枚数,プリンタの指定などの設定が必要となります。

 こうした補足情報の入力は,別ウィンドウやダイアログが開いて行われることが多いため,「何かをたずねる別のウィンドウが開きますよ」という意味と考えてもいいでしょう。なぜこのようなものをつけるのか,ということはとりあえず後回しにしますが,この「...」は,例えばWindowsのExplorer,つまりフォルダを開いたときのウィンドウや,マイクロソフトオフィス,Firefoxなどのブラウザ…など,デスクトップ・アプリケーションのメニューの多く(というかほとんど)に付けられています。

 筆者は,以前はデスクトップ・アプリケーションも作っていたので,Google Docsに「...」が付いていたとき,ちょっと懐かしさを感じるとともに,ああ,確かにデスクトップ・アプリケーションを模倣するのなら,こうしたルールも取り入れていくべきだよなあ,と感じたのです。

 デスクトップ・アプリケーションは,ウェブ・アプリケーション,特に最近のリッチなインタフェースを持つアプリケーションと比較して,かなり長い歴史を持っていますし,その中で培われたインタフェースの概念もいろいろあります。そうしたものを取り入れていくことは,使いやすさにきっと貢献してくれるはずですし,なにより利用者に(使い慣れた)デスクトップ・アプリケーションと同様の操作性を提供することに貢献できるでしょう。

「アップル ヒューマンインタフェースガイドライン」

 デスクトップ・アプリケーションのインタフェースのルールを学ぶにあたって,最初にぜひ目を通しておきたいのは,Mac OSを作っているアップルが公開している,「アップル ヒューマンインタフェースガイドライン」です。以前は書籍として出版されていましたが,現在でもMac OS Xに対応した最新版が,ウェブ上で公開されています(Apple Human Interface Guidelines)。また,日本語訳を公開してくださっているサイトもあります。

 これは,その名のとおり,インタフェース作成のガイドライン集で,Mac OS向けのアプリケーション作成者に,Mac OS上で動作するソフトウエアのインタフェースはこうあるべき,ということを解説した文章です。「ヒューマンインタフェースガイドライン」という言葉はその後一般化して,デスクトップ環境でのインタフェースのガイドとして,GNOMEやKDEなどのもの公開されています。アップルのものは,こうしたインタフェースのガイドラインの超古典とも言うべき存在です。

 これを読むと,非常に様々なことに対してガイドラインが定められていることがわかります。もちろん先に述べた「メニューの後ろの...」についても言及されていますし,ドラッグ&ドロップの挙動,キーの持つ意味,マウスを動かしたときのデータの選択のされ方,メニューの構成や挙動など,多岐にわたる事柄について,「こうすべき」という指針と,なぜそうすべきなのか,という理由が示されています。

 これはあくまで指針であり,これを守らないとアプリケーション開発をしてはいけない,というものではありません。しかし,このガイドラインは利用者がそのアプリケーションをより使いやすくなるように定められたものですから,これを守ることで,アプリケーションの使い勝手は確実に向上します。さらに,これをきちんと守っているアプリケーションは,全体的に統一感が生まれ,あるアプリケーションに慣れていれば,同じような感覚で他のアプリケーションを使うことができるのです。これはいわば「よく使われているものを模倣する」のと同じ効果を持っているといえます。

 このガイドラインは,Macのアプリケーション開発では,かなりよく守られてきており,たとえ個人でフリーソフトを開発しているような場合でも,守っている人が多くいました。そしてこれはMacOSが「使いやすい」と言われる一因であったとされています。もっとも,最近ではアップルが率先してこのガイドラインの範疇に入らないアプリケーションを公開したりしていることもあって,若干様子が異なってきていますが。このガイドラインに書かれていることは,Windowsでも数多く取り入れられていて,OSを超えて,デスクトップ・アプリケーションのスタンダードな仕様になっている部分も多くあります。

 最近は,ドラッグ&ドロップで何らかの作業が可能なウェブ・アプリケーションも増えています。でも,アプリケーションによっては,その操作感に微妙な違和感を覚える場合ってありませんか。ドラックもドロップも,できるんだけど,どこか使いにくい感じ,とでも言うのでしょうか。

 これはおそらく,普段慣れている一般的なアプリケーションのドラッグ&ドロップの動作と微妙に感覚が異なっていることが原因なんだと思います。アップル ヒューマンインタフェースガイドラインには,ドラッグ&ドロップに関する規定も細かく掲載されているので,それを読むと,参考になるかもしれません。そこには,利用者がマウスを3ピクセル動かしたらドラッグの操作が始まること,ドロップ先はドロップが可能かどうかをきちんと表示すること,ドロップができなかった場合は,ドラッグしていたオブジェクトがすばやくもとの位置まで戻る動作をすること,ドロップされた時点(ドラッグが開始された時点ではなく)で「Optionキー」を押しているとコピーになること,などが記述されています。

 こうしたガイドラインをみながら,動作を修正していけば,より違和感の少ないインタフェースになるかもしれません。