アプレットのユーザビリティ：
ページから踏み出して

アプレットは大きく2つのカテゴリーに分けられる。

機能アプレット

状態遷移と複数のビューを備え、それ自体で独立したミニアプリケーション（例：タブ付きのダイアログ）。機能アプレットは、ウェブページとは別に存在する「現実世界」のデータを操作するものが多い（例：顧客が当座預金管理、在庫調整、サーバ管理できるようにするもの）。

コンテンツアプレット

ウェブページのコンテンツと密接に結びついている。例えばサイトナビゲーション制御（例：動的サイトマップ、階層的リストを展開したり収斂したりして表示するアウトライン）、動的コンテンツ（例：回転させたり、動かしたり、あるいはその場で操作したりできるエンジン模型）、あるいはちょっとした機能（例：通貨換算）などが挙げられる。だいたいにおいて、コンテンツアプレットを動作させても、現在のウェブページの見た目を変える以外には何の結果も出てこない。

コンテンツアプレットは、それが属するウェブページといっしょにブラウザ内で表示するべきだ。機能アプレットは新しい、ブラウザ以外のウィンドウに表示すべきで、そこにはウェブのナビゲーション機能は必要ない。

機能アプレットをブラウザウィンドウ内に表示してしまうと、ユーザは間違いなく、アプレットの操作をブラウザの操作と混同してしまうだろう。もっとも深刻なのは、ユーザが、ブラウザのbackボタンをクリックして、アプレットでのアクションを取り消そうとしたり、以前の状態やビューに戻ろうとすることだ。当然ながら、ブラウザでbackすると、ユーザは以前のウェブページに戻され、アプレットは消えてしまう。

ユーザがブラウザウィンドウの枠内にいるかぎり、ハイパーテキストナビゲーションというメタファーがあまりにも強力すぎることが問題なのだ。ユーザは、いくら気をつけていても、ナビゲーションとなるとついついブラウザのコマンドを使ってしまう。たとえ、アプレット内でのナビゲーションを「期待されている」場合でもだ。唯一の解決策は、アプレットをそれ専用の、一切のブラウザ操作機能なしのウィンドウで開くことだ。アプレットが別ウィンドウで開けば、ユーザも「ウェブ」と考えるのをやめて、アプレットをそれ自体として操作するようになるだろう。

長期的には、ブラウザを排除して、完璧に統合化されたナビゲーションシステムに移行することが、この問題への解決策となるだろう。システムの状態と情報オブジェクトのナビゲーションを一体化し、ウェブ上のものかどうかに関わらず、すべてのユーザオプションを単一のナビゲーションインターフェイスに保つのである。つまるところ、扱っているのがHTMLか、それともそれ以外のデータ形式なのか、あるいは、今つながっているのはインターネットかイントラネットか、あるいは自分のハードディスク上のローカルなコンテンツなのかといったことで、ユーザをわずらわせるべきではないのである。

機能アプレットは、ハイパーテキストのリンクでウェブに戻れるようにしておいてもよい。よくある例として、ヘルプのページや、異なったタイプの飛行機について、よりくわしい解説を読めるようにしてある飛行機予約システムが挙げられる。こういったハイパーリンクでは、ユーザが機能アプレットを抜けて、ウェブブラウザに戻るようにしておこう（機能アプレットは別ウィンドウに表示したまま）。

JavaSoftのErika Kindlundは、特定の機能アプレットのデザインに関して、より詳細に論じている。Java Web Server用の管理インターフェイスがそれである。サーバ管理は、明らかにそれ自体のナビゲーションを備えた「大きな」アプレットであり、その初期デザインでは、アプレットをブラウザのページ内に置くという深刻なユーザビリティ問題を犯していた。（残念ながら、この記事はHTMLではなくPDFになっている。オンラインでは読みにくいと思う人がほとんどだろう。申し訳ないとは思うが、問題のサイトは私の管理下にない。ウェブではPDFは避けるべきである。印刷を目的としたファイルだけがこの例外だ）

アプレットに関するその他のユーザビリティ問題

アプレットのユーザビリティに関するほとんどの問題は、ユーザインターフェイスデザインの伝統的法則とまったく変わらないものである。別ウィンドウを開く機能アプレットは、アプリケーションのデザインガイドラインに従うべきだ。また、ページ上に表示されるコンテンツアプレットについては、ウェブデザインのガイドライン、および優れた情報デザインの原則に従おう。

サーバにつなぎ直す場合は経過表示が必要

サーバとやり取りするアプレットは、交信時に経過表示を行うこと。経過表示（～％終了という棒グラフで示されることが多い）は、反応時間が遅い（10秒以上）操作には、どんなユーザインターフェイスでも必要なものである。サーバとやり取りするアプレットは、インターネットの弱点のせいで、遅れにかなりの幅が出る。よって、経過表示は2重の意味で重要だ。ひとつは実際の操作の進度を示すため、もうひとつは、あとどれくらいかかるか予測するためである。例えば、データベースの中で検索終了したものがどれくらいの割合になったかとか、（システム寄りの用語は抜きで）一連のステップの中で既に完了したのはどこまでか、といったことは経過表示で示すことができる。こうした経過表示では、要求に答えながらも、サーバからの情報を少しずつ読み込む必要があるだろう。

アプレットにはキャンセルボタンが必要だ。これで時間のかかる操作をいつでも中断できる。あらゆるサーバ接続に関して、中断可能であることが特に要請される。

ダブルクリック

原則として、アプレットは現状のユーザインターフェイス標準に従うべきである。このため、場合によっては、残念ながらダブルクリックをサポートしなければならないこともあるだろう。しかし、将来的にはダブルクリックはなくすべきだ。初心者ユーザには非常に難しいし、ウェブのシングルクリックの操作スタイルとも矛盾するからである。ダブルクリックが必要になった主な理由は、ワンボタンマウスに2つの操作を詰め込まなくてはならなかったせいだ。もっと新しい複数ボタンのGUIをデザインする人までが、盲目的にこの弱点を踏襲している。これは、初期のワンボタンマウスGUIの限界から求められていたものに過ぎないのだ。この先はもっとうまくやろう。コンテンツアプレットをシングルクリックのウェブコンテンツと思い込む人は多いから、ダブルクリックについては特に慎重な態度で臨むべきである。（元AppleのヒューマンエバンジェリストBruce Tognazziniは、一般によく知られたMacの弱点が、最近のウィンドウシステムにまで継承されている点について詳細に論じている。彼の著書『Tog on Software Design』を参照のこと。）

1997年10月15日