JavaScriptのプロンプト、確認、およびアラートは「旧式」と見なされる[終了]

最近、私はジム用のウェブベースの管理システムを開発しています。以前のアプリはVisual Basicで開発されました。新しいアプリの場合、すべてのフロントエンドスクリプトはjQueryを使用し、サーバーはPHPとMySQLを実行しています...ご存じのとおり、典型的なel-cheapo linuxベースのスタックです。

とにかく、最近JavaScriptのプロンプト、確認、警告メッセージダイアログがあまり使用されていないのはなぜかと思っていました。モーダルウィンドウ用のjQueryプラグインと、言語が既に提供しているものを模倣しようとするアラートメッセージが多数あり、すべてのブラウザーは適切にサポートする必要があります。

複雑なフォームや特別なニーズには、ハンドメイドまたはプラグインベースのソリューションを使用しても問題ありませんが、単一の値を要求するか、レコードの削除を確認するだけの場合、Webアプリケーションにこのようなオーバーヘッドを追加するのはなぜですか？さらに、プロンプト、確認、警告を使用すると、iOSとAndroidでメッセージダイアログがうまく調整されます。

1. UX：メッセージボックスはほとんどが悪

UXの観点から見ると、アラートボックスはすべての場合に不適切です。デスクトップアプリ。アラートまたはインラインJavaScriptメッセージとしてのWebアプリ。どこにでも。

理由を知りたい場合は、AlanCooper¹のFace 3について読むことができます。これがどのようにワークフローを中断してユーザーを悩ますか、そして現在のソフトウェアに存在するほぼすべてのアラートボックスが非常に間違っていることを非常によく説明しています。542ページの「「ウルフ！」と叫んだダイアログ」では、アラートボックスが定期的に閉じられているため、モデルが完全に壊れていると説明されています。本の543ページには、3つの主要な設計原則がリストされています。

• 聞かないでください。
• すべてのアクションをリバーシブルにします。
• モードレスフィードバックを提供して、ユーザーがミスを回避できるようにします。

次に、著者は、正しい設計アプローチによってアラートボックスを置き換える方法を教えてくれます。

プロンプトメッセージはわずかに異なります。それでも、それらはアプリのユーザーエクスペリエンスを損ないます。ユーザーが何かを入力したい場合は、テキストボックスまたはテキストエリアを使用して、必要に応じてJavaScriptで装飾することを検討してください。怠けてはいけません。RIAやAJAX対応アプリの時代に豊富なインターフェイスを提供してください。すべての場合において、JavaScriptが無効になっていると、プロンプトは表示されません。

Webページでは、アラートボックスとプロンプトの両方がほとんど迷惑です。いくつかの例：

1. 一部のフォーラムでは、リストアイテムの入力を無限に要求することでリストを作成できます。これは、リストの作成中は、コピーアンドペーストを含むページ自体を使用できないことを意味します。また、単一の小さなフィールドがあります。長いテキストはどうですか？太字と斜体はどうですか？

2. 「続行すると、写真はプロフィールから完全に削除されます。よろしいですか？」。もちろんそうです！それ以外の場合、[プロファイルから写真を削除]をクリックしますか？どうしてあなたのウェブアプリが私がそんなにバカだと思うの？実際、GMailとしてのGoogleアプリケーションは正しいアプローチを示しています。必要なものを削除、削除、破棄できます。削除すると、アプリに小さな「元に戻す」リンクが表示されます。

3. 「私たちの最大の調査を受けたいですか？」。まあ、実際に私はあなたのウェブサイトを訪問するためにそこにいましたが、あなたはあなたの迷惑なメッセージで私を悩ますので、私はむしろどこかに行きたいです。

4. 「著作権で保護された写真を保護するために、このウェブサイトでの右クリックは無効になっています」。実際、コメントを送信する前に、右クリックしてスペルチェッカーの言語を変更しました。もちろん、スペルをチェックせずに送信します。

結論：ユーザーエクスペリエンスの観点から、ほとんどの場合、アプリケーションは誤ってメッセージボックスを使用します。

ちょっと待って！多くの低品質Webサイトは、迷惑なJQueryメッセージをすべてのページを覆う半透明の背景で迷惑なアラートボックスに置き換えます。したがって、欠点は残ります。

さて、Webアプリケーションでメッセージボックスを使用しない別の理由があります。

2.設計：アラートボックスには独自の設計があります

警告ボックスをまったく設計することはできません。色、サイズ、フォントを変更することはできません。これにより、ユーザーはさらに煩わしくなります。Webアプリを使用していたため、ワークフローがどこからでも送信され、アプリの視覚的側面とさえ一致しないメッセージによって中断されます。ボタンの言語も、Webアプリケーションの言語ではなく、OS /ブラウザの言語と一致することをカウントしません。

デザイナーにとって、JavaScriptメッセージはアラートボックスよりもはるかに強力です。

また、はるかに広範囲です。太字と斜体を追加し、独自のボタンを選択できます（「申し訳ありませんが、入力したパスワードは無効です。[パスワードのリセット] [別のパスワードを試してください] [キャンセル]？」）。

3. JavaScript：アプリケーションフローが停止する

警告ボックスを表示すると、JavaScriptはユーザーがクリックするまで実行を停止します。ウェブサイトでは、大丈夫かもしれません。Webアプリでは、しばしば問題になります。

4.サンドボックス：ユーザーにコンピューターの再起動を強制しないでください

無限の数のメッセージボックスを表示する安っぽいWebサイトを覚えていますか？技術的背景が十分にないユーザーが作業を続行できる唯一の方法は、実際にはコンピューターを再起動することでした。これにより、問題が発生します。アラートボックスはWebサイトまたはWebアプリケーションの範囲外です。ユーザーがブラウザの他のタブにアクセスできないようにする権限はありません³。

同じ問題により、ブラウザーはさまざまな方法で解決する必要がありました。たとえば、Firefoxでは、タブにアラートを表示するときに他のタブへのアクセスが許可されます。一方、Chromeでは、ページからアラートボックスをもう表示しないことを確認できますが、他のタブへのアクセスはブロックされます。

Firefoxのアプローチは完全に有効ですが、Chromeのアプローチは（すべてのタブをブロックするため）批判される可能性があり、問題が発生します。本当に重要なものを見せようとしましたか？確かに、ユーザーには表示されません。

事実は変わりません。ほとんどのユーザーはアラートボックスに悩まされるため、ユーザーフレンドリーではなく、技術的背景が十分でないユーザーをひどくブロックする可能性があります。インラインでは、JavaScriptメッセージはページをブロックしますが、ブラウザ自体はブロックしません。Webアプリケーションのモデルは、ユーザーのキーボード例えば、アクセスのためのあなたができないサンドボックスの一種であり、またはコンピュータを再起動するか、ハードディスクからファイルを読み取るか、フルスクリーンまたは使用の2台のモニター、行くので、その遮断作用ブレークと警告ボックスを厳しくこのサンドボックスモデル。

最後になりましたが、アプリケーションがアラートボックスを表示することを決定したときにユーザーが別のタブにいた場合はどうでしょうか。ユーザーが重要なことをしていて、今すぐアプリとやり取りしたくない場合はどうなりますか？

^{¹ フェイス3、インタラクションデザインの要点、アランクーパー、ロバートレイマンおよびデビッドクローニン、ISBN 978-0-470-08411-3。第25章：エラー、アラート、および確認。}

^{²これは単なる例です。それは本当に貧弱なデザインの選択なので、あなたのウェブアプリケーションでそれをしないでください。}

^{³デスクトップアプリの世界と比較したい場合、インラインJavaScriptメッセージはデスクトップアプリケーションのメッセージボックスのようなものです。一方、ブラウザの警告ボックスは、他のデスクトップアプリケーションへのアクセスをブロックするフルスクリーンの不透明な背景に、最上部として設定された、どこからともなく現れるウィンドウのようなものです。私のコンピューターで1回実行することにしたアプリは、すぐに永久に削除されます。}

結論：デフォルトのプロンプト、確認、警告ダイアログボックスは、サイトのスタイルではなく、ブラウザのスタイルと一致します。ほとんどのUIユーザーは、すべてのダイアログボックスがサイトのUIと共に流れることを望んでいます。モーダルウィンドウを使用してメッセージを表示し、MSIEまたはFFのデフォルトのグレーとブルーではなく、サイトのUIと同じフォントと色を使用してデータを収集します。

他の場所で派手なダイアログを必要としない場合にのみ、オーバーヘッドを追加します。その時点では、機能がブラウザの一部として含まれているか、使用しているフレームワークの一部として含まれているかどうかには大きな違いはありません。また、すべてのポップアップの一貫性を保つこともできます。

Javascriptで多くのことができますが、フレームワークはありませんが、フレームワークが利用可能になる前のjavascriptでの開発のようなものを覚えており、私はそれに戻りたくありません。

ブラウザはそれらをうまく処理しないからです。お気づきかもしれませんが、通常はモーダルダイアログであり、ユーザーがブラウザを移動したりサイズ変更したりするのを防ぐだけでなく、他のタブへのアクセスも防ぎます。これは非常に迷惑です。

確認や変更などのダイアログについては、ブラウザーが動作を強制する必要があると思います。最新のFirefoxブラウザーについては、上記の問題を修正したことがわかります。現在のページを対象とするページアラートで使用します。

したがって、すべてのブラウザーが（少なくともアラート）をよりエレガントに処理できるように、アラートの動作をオーバーライドすることをお勧めします。

いくつかの要約された理由：

• これは標準のAPIであり、開発者はあなたが何をしようとしているかを把握できます。
• よりユーザーフレンドリーで、見た目もきれいです。
• プラットフォームサポート、モバイルサイトにはネイティブAPIが必要になる場合があります。