1997アプレットは大きく2つのカテゴリーに分けられる。機能アプレット状態遷移と複数のビューを備え、それ自体で独立したミニアプリケーション(例:タブ付きのダイアログ)。サーバ管理できるようにするもの)。コンテンツアプレットウェブページのコンテンツと密接に結びついている。サイトナビゲーション制御(例:動的サイトマップ、階層的リストを展開したり収斂したりして表示するアウトライン)、動的コンテンツ(例:回転させたり、動かしたり、あるいはその場で操作したりできるエンジン模型)、あるいはちょっとした機能(例:通貨換算)などが挙げられる。だいたいにおいて、コンテンツアプレットを動作させても、現在のウェブページの見た目を変える以外には何の結果も出てこない。コンテンツアプレットは、それが属するウェブページといっしょにブラウザ内で表示するべきだ。機能アプレットは新しい、ブラウザ以外のウィンドウに表示すべきで、そこにはウェブのナビゲーション機能は必要ない。機能アプレットをブラウザウィンドウ内に表示してしまうと、ユーザは間違いなく、アプレットの操作をブラウザの操作と混同してしまうだろう。深刻なのは、ユーザが、ブラウザのbackボタンをクリックして、アプレットでのアクションを取り消そうとしたり、以前の状態やビューに戻ろうとすることだ。当然ながら、ブラウザでbackすると、ユーザは以前のウェブページに戻され、アプレットは消えてしまう。ユーザがブラウザウィンドウの枠内にいるかぎり、ハイパーテキストナビゲーションというメタファーがあまりにも強力すぎることが問題なのだ。ユーザは、いくら気をつけていても、ナビゲーションとなるとついついブラウザのコマンドを使ってしまう。アプレット内でのナビゲーションを「期待されている」場合でもだ。唯一の解決策は、アプレットをそれ専用の、一切のブラウザ操作機能なしのウィンドウで開くことだ。アプレットが別ウィンドウで開けば、ユーザも「ウェブ」と考えるのをやめて、アプレットをそれ自体として操作するようになるだろう。長期的には、ブラウザを排除して、完璧に統合化されたナビゲーションシステムに移行することが、この問題への解決策となるだろう。システムの状態と情報オブジェクトのナビゲーションを一体化し、ウェブ上のものかどうかに関わらず、すべてのユーザオプションを単一のナビゲーションインターフェイスに保つのである。つまるところ、扱っているのがHTMLか、それともそれ以外のデータ形式なのか、あるいは、今つながっているのはインターネットかイントラネットか、あるいは自分のハードディスク上のローカルなコンテンツなのかといったことで、ユーザをわずらわせるべきではないのである。機能アプレットは、ハイパーテキストのリンクでウェブに戻れるようにしておいてもよい。ある例として、ヘルプのページや、異なったタイプの飛行機について、よりくわしい解説を読めるようにしてある飛行機予約システムが挙げられる。いったハイパーリンクでは、ユーザが機能アプレットを抜けて、ウェブブラウザに戻るようにしておこう(機能アプレットは別ウィンドウに表示したまま)。Kindlundは、特定の機能アプレットのデザインに関して、より詳細に論じている。Server用の管理インターフェイスがそれである。サーバ管理は、明らかにそれ自体のナビゲーションを備えた「大きな」アプレットであり、その初期デザインでは、アプレットをブラウザのページ内に置くという深刻なユーザビリティ問題を犯していた。(残念ながら、この記事はHTMLではなくPDFになっている。オンラインでは読みにくいと思う人がほとんどだろう。申し訳ないとは思うが、問題のサイトは私の管理下にない。ウェブではPDFは避けるべきである。印刷を目的としたファイルだけがこの例外だ)アプレットに関するその他のユーザビリティ問題アプレットのユーザビリティに関するほとんどの問題は、ユーザインターフェイスデザインの伝統的法則とまったく変わらないものである。別ウィンドウを開く機能アプレットは、アプリケーションのデザインガイドラインに従うべきだ。ページ上に表示されるコンテンツアプレットについては、ウェブデザインのガイドライン、および優れた情報デザインの原則に従おう。サーバにつなぎ直す場合は経過表示が必要サーバとやり取りするアプレットは、交信時に経過表示を行うこと。経過表示(~%終了という棒グラフで示されることが多い)は、反応時間が遅い(10秒以上)操作には、どんなユーザインターフェイスでも必要なものである。サーバとやり取りするアプレットは、インターネットの弱点のせいで、遅れにかなりの幅が出る。よって、経過表示は2重の意味で重要だ。ひとつは実際の操作の進度を示すため、もうひとつは、あとどれくらいかかるか予測するためである。データベースの中で検索終了したものがどれくらいの割合になったかとか、(システム寄りの用語は抜きで)一連のステップの中で既に完了したのはどこまでか、といったことは経過表示で示すことができる。した経過表示では、要求に答えながらも、サーバからの情報を少しずつ読み込む必要があるだろう。アプレットにはキャンセルボタンが必要だ。これで時間のかかる操作をいつでも中断できる。あらゆるサーバ接続に関して、中断可能であることが特に要請される。ダブルクリック原則として、アプレットは現状のユーザインターフェイス標準に従うべきである。このため、場合によっては、残念ながらダブルクリックをサポートしなければならないこともあるだろう。将来的にはダブルクリックはなくすべきだ。初心者ユーザには非常に難しいし、ウェブのシングルクリックの操作スタイルとも矛盾するからである。ダブルクリックが必要になった主な理由は、ワンボタンマウスに2つの操作を詰め込まなくてはならなかったせいだ。新しい複数ボタンのGUIをデザインする人までが、盲目的にこの弱点を踏襲している。これは、初期のワンボタンマウスGUIの限界から求められていたものに過ぎないのだ。この先はもっとうまくやろう。コンテンツアプレットをシングルクリックのウェブコンテンツと思い込む人は多いから、ダブルクリックについては特に慎重な態度で臨むべきである。Tognazziniは、一般によく知られたMacの弱点が、最近のウィンドウシステムにまで継承されている点について詳細に論じている。Design』を参照のこと。アプリケーションイードが提供する「ユーザビリティ評価」サービスイードは、スマートフォンアプリやサイトのUI品質をユーザー視点で評価・改善提案し、ユーザー側とビジネス側、双方の目的達成をサポートします。ラジオボタン有名ウェブサイトでも、基本的なユーザインタフェース(UI)で初歩的な間違いを犯すことがある。ダイアログボックスをデザインするたびにその都度判断するよりも、各プラットフォームでの慣習に従う方が大切だ。日付入力フォームのUXデザインガイドライン日付入力欄は、適切なデザインパターンを利用して、あいまいさのない、タスク達成に役立つものにしなければならない。小さなデザイン変更で、大きなユーザーエラーが防げる可能性もあるのだ。アプリケーションデザインの間違い・トップ10UIがワークフローを通じてユーザーをガイドし、サポートすれば、アプリケーションのユーザビリティは向上する。