JavaScriptプロンプト、確認、および「古い」と見なされるアラート
最近、ジム用のウェブベースの管理システムを開発しています。以前のアプリはVisual Basicで開発されました。新しいアプリの場合、すべてのフロントエンドスクリプトはjQueryを使用し、サーバーはPHP＆MySQL ...を実行しています。典型的なel-cheapo linuxベースのスタックです。
とにかく、なぜJavaScriptのプロンプト、確認、アラートメッセージダイアログが最近はあまり使われていないのかと思っていました。モーダルウィンドウ用のjQueryプラグインや、言語がすでに提供している何かを模倣しようとする警告メッセージがたくさんあり、すべてのブラウザーは適切にサポートする必要があります。
手作りまたはプラグインベースのソリューションを使用しても、複雑なフォームや特別なニーズには問題ありませんが、単一の値を要求するか、レコードの削除を確認するだけでよい場合は、そのようなオーバーヘッドをWebアプリに追加するのはなぜですか？さらに、iOSおよびAndroidは、プロンプト、確認、およびアラートを使用するときに、適切に調整されたメッセージダイアログを提供します。
1. UX：メッセージボックスはほとんど邪悪
UXボックスの観点からは、すべてのケースでアラートボックスは不適切です。デスクトップアプリでは。アラートまたはインラインJavaScriptメッセージとしてのWebアプリ。どこにでも。
理由を知りたい場合は、AlanCooper¹のAbout Face 3を参照してください。これにより、ワークフローが中断されてユーザーが不快に感じる方法と、現在のソフトウェアに存在するほぼすべてのアラートボックスが深く間違っている方法がよくわかります。 542ページの「「狼」と叫んだダイアログ」では、警告ボックスが定期的に閉じられるため、モデルが完全に壊れていると説明されています。本の543ページには、3つの主要な設計原則がリストされています。
- お願いしません。
- すべてのアクションをリバーシブルにします。
- モードレスのフィードバックを提供して、ユーザーがミスを回避できるようにします。
次に、警告ボックスを適切な設計アプローチで置き換える方法を著者に説明します。
プロンプトメッセージは少し異なります。それでも、アプリのユーザーエクスペリエンスが損なわれます。ユーザーが何かを入力したい場合は、テキストボックスまたはテキストエリアを使用して、必要に応じてJavaScriptで装飾することを検討してください。 怠惰ではなく、RIA時代とAJAX対応アプリの時代に豊富なインターフェースを提供してください;すべての場合において、JavaScriptが無効になっていると、プロンプトは表示されません。
Webページでは、アラートボックスとプロンプトの両方がほとんど迷惑です。いくつかの例：
一部のフォーラムでは、リストアイテムを無限に要求することでリストを作成できます。つまり、リストの作成中は、コピーと貼り付けを含め、ページ自体を使用できません。また、小さなフィールドが1つあります。長いテキストはどうですか？太字や斜体はどうですか？
「続行すると、写真はプロファイルから完全に削除されます。よろしいですか？」もちろんきっと！それ以外の場合は、「プロフィールから写真を削除」をクリックしますか？なぜ私がそんなに愚かだと思っているあなたのウェブアプリ？実際、GMailとしてのGoogleアプリケーションは正しいアプローチを示しています。何でも削除、削除、破棄できます。削除すると、アプリに小さな「元に戻す」リンクが表示されます。
「私たちの最大の調査を受けたいですか？」。ええと、実際に私はあなたのウェブサイトにアクセスするためにそこにいましたが、あなたの迷惑なメッセージで私を悩ませているので、どこか別の場所に行きたいと思います。
「著作権で保護された写真を保護するために、このウェブサイトでは右クリックが無効になっています」。そうですね、実際にコメントを送信する前に、右クリックしてスペルチェッカーの言語を変更しました。もちろん、スペルをチェックせずに送信します。
結論：ユーザーエクスペリエンスの観点から、アプリケーションはほとんどの場合、メッセージボックスを誤って使用します。
ちょっと待って！多くの低品質のWebサイトは、迷惑なアラートボックスを、ページ全体を覆う半透明の背景を持つJQueryメッセージに置き換えることで置き換えています。したがって、欠点は残ります。
さて、Webアプリケーションでメッセージボックスを使用しない別の理由があります。
2.デザイン：警告ボックスには独自のデザインがあります
警告ボックスをデザインすることはできません。色、サイズ、フォントを変更することはできません。これにより、ユーザーはさらに煩わしくなります。Webアプリで作業していて、どこから来たように見え、アプリの視覚的側面にも一致しないメッセージによってワークフローが壊れています。ボタンの言語は、Webアプリケーションの言語ではなく、OS /ブラウザの言語にも一致するとは見なされません。
デザイナーにとって、JavaScriptメッセージはアラートボックスよりもはるかに強力です。
彼らはまた、はるかに広範です。太字と斜体を追加したり、独自のボタンを選択したりできます（「お詫び申し上げますが、入力したパスワードは無効です。[パスワードをリセット] [別のパスワードを試してください] [キャンセル]」？）²。
3. JavaScript：アプリケーションフローが停止する
警告ボックスを表示すると、JavaScriptはユーザーがクリックするまで実行を停止します。ウェブサイトでは、大丈夫かもしれません。 Webアプリでは、問題になることがよくあります。
4.サンドボックス：ユーザーにコンピュータの再起動を強制しない
無限の数のメッセージボックスを表示するくだらないウェブサイトを覚えていますか？十分な技術的背景のないユーザーが作業を続けることができる唯一の方法は、実際にはコンピューターを再起動することでした。これにより問題が発生します。警告ボックスはWebサイトまたはWebアプリケーションの範囲外です。 あなたは、ユーザーがブラウザーの他のタブにアクセスするのを防ぐ権限がありません³。
同じ問題により、ブラウザーはさまざまな方法で解決する必要がありました。たとえば、Firefoxは、タブにアラートを表示するときに他のタブへのアクセスを許可します。一方、Chromeでは、ページからアラートボックスを表示したくないが、他のタブへのアクセスはブロックされていることを確認できます。
Firefoxのアプローチは完全に有効ですが、Chromeのアプローチは批判される可能性があり（それでもすべてのタブがブロックされるため）、問題が発生します。ユーザーがアプリによって発行されたいくつかのメッセージボックスにひどく迷惑をかけ、ケースをチェックした場合、そして本当に重要なものを見せようとしましたか？確かに、ユーザーには表示されません。
事実は変わらず、ほとんどのユーザーはアラートボックスに悩まされるため、ユーザーフレンドリーではなく、十分な技術的背景のないユーザーを深刻にブロックする可能性があります。インラインでは、JavaScriptメッセージによってページがブロックされる場合がありますが、ブラウザ自体はブロックされません。 Webアプリモデルは一種のサンドボックスなので、ユーザーキーボードにアクセスしたり、コンピューターを再起動したり、ハードディスクからファイルを読み取ったり、全画面表示したり、2つのモニターを使用したりできませんアラートボックスブロッキング効果により、このサンドボックスモデルが大幅に壊れます。
最後に重要なことですが、アプリケーションが警告ボックスを表示することを決定したときにユーザーが別のタブにいた場合はどうなりますか？ユーザーが何か重要なことをしていて、今すぐアプリと対話したくない場合はどうなりますか？
FaceFace 3について、インタラクションデザインの基本、Alan Cooper、Robert Reimann、David Cronin、ISBN 978-0-470-08411-3;第25章：エラー、アラート、および確認。
²これは単なる例です。これは実際のデザインの選択としては不適切であるため、Webアプリケーションでは実行しないでください。
desktopデスクトップアプリの世界と比較したい場合、インラインJavaScriptメッセージはデスクトップアプリケーションのメッセージボックスのようなものです。一方、ブラウザの警告ボックスは、他のデスクトップアプリケーションへのアクセスをブロックする、全画面の不透明な背景に、どこからでも表示され、最上部に設定されたウィンドウのようなものです。私のコンピューターで1回実行することを決定するアプリは、すぐに、そして永久に削除されます。
結論：デフォルトのプロンプト、確認、アラートのダイアログボックスは、サイトのスタイルではなく、ブラウザのスタイルと一致します。ほとんどのUIの人々は、すべてのダイアログボックスが自分のサイトのUIで流れることを望んでいます。彼らはモーダルウィンドウを使用してメッセージを表示し、サイトのUIと同じフォントと色を使用してデータを収集します。MSIEまたはFFのデフォルトのグレーとブルーではありません。
他の場所で派手なダイアログが必要ない場合にのみ、オーバーヘッドを追加します。その時点では、機能がブラウザの一部として含まれているか、使用しているフレームワークの一部として含まれているかに大きな違いはありません。また、すべてのポップアップの一貫性を保つこともできます。
JavaScriptを使用してフレームワークを使用しなくても多くのことを実行できますが、フレームワークが利用可能になる前のJavaScriptでの開発の様子を覚えています。
ブラウザはそれらをうまく処理しないため。お気づきかもしれませんが、これらは通常モーダルダイアログであり、ユーザーがブラウザーを移動したりサイズ変更したりすることを妨げるだけでなく、他のタブへのアクセスも妨げます。
確認や変更などのダイアログの場合でも、ブラウザーは動作を強制する必要があると思います。最新のFirefoxブラウザーの場合は、上記の問題が修正されていることがわかります。現在のページを範囲とするページアラートで使用します。
したがって、すべてのブラウザーが（少なくともアラート）をよりエレガントに処理できるように、アラートの動作をオーバーライドすることをお勧めします。
いくつかの要約された理由：
- これは標準APIであり、開発者はあなたが何をしようとしているのかを理解できます。
- ユーザーフレンドリーで見栄えがよくなります。
- プラットフォームのサポート。モバイルサイトにはネイティブAPIが必要な場合があります。