アラートボックスは何としてでも回避する必要がありますか？
これについてGabriel SvennerbergとSam Kに感謝します。コメントで取り上げられました here 。
私は、警告ボックスを設置してユーザーが特定の時点でオンラインコースを離れると、既に行っていた作業が失われることを警告するユーザーテストが実行されるまで、警告ボックスについてはかなりカジュアルでした。そもそもそのような状況が発生することはないはずです（！ポカよけがない）という事実を別にすれば、目にしたことに非常に不安を感じていました。
ユーザーは基本的に、他のソフトウェアでの以前のアラートボックスの経験に基づいて、完全にランダムな方法でそのアラートボックスをクリックしました。
警告ボックスのテキストを読むのは、ごく少数のユーザーだけです。ほとんどが何かをクリックしただけです：ページ上で安全にそれらを保持するボタン、または作業を削除したボタン、またはダイアログを閉じるための「X」。ほとんどは次に来るものに戸惑いました。深く掘り下げてみると、多くの人が「エラー」ボックスのアクションを設定しているように見えました。何かをクリックして、それを解消してください。
その上で、アラートボックスを回避するためにどこまで行けますか？
アラートボックスが多用される主な理由は、実装が非常に簡単であることです。寛容なユーザーインターフェイスを実装することははるかに困難です。
警告ボックスはいくつかの理由で悪いです：
まず第一に、それらは本質的にモーダルであるため、ユーザーのワークフローを中断し、そのため定期的に実行される不適切なタスクです。
第二に、Andrewが既に指摘したように、ユーザーはそれらを読まずに何かをクリックする傾向があるため、効果がありません。システムが通常のタスク中に常にアラートをスローする場合、ユーザーは最終的にそれらを無視する傾向があり、習慣的に「OK」をクリックするだけです。彼が間違ったドキュメントを削除したことに気づいたとき、それはすでに手遅れです。
私の考えでは、アラートは、定期的に実行されない不可逆的なアクション（データベースの削除など）を実行しようとしているときなど、本当に重要なイベント用に予約する必要があります。それ以外の場合は、物事を設計するはるかに良い方法があります。
ユーザーは基本的に、他のソフトウェアでの以前のアラートボックスの経験に基づいて、完全にランダムな方法でそのアラートボックスをクリックしました。 ...これに基づいて、アラートボックスを回避するためにどこまで行けますか？
質問自体はほぼ答えられます：アラートボックスを使用しないでください
モーダルアラートとダイアログボックスは、ユーザーの前にバリアを配置します。もちろん、彼らは障壁を取り除くことで対応します。多くの場合、彼らは警告を読みませんし、後悔することをしてしまいます。
ここに代替があります：
- アクションを必要としない有益なメッセージの場合は、（このサイトのように）控えめにインラインでメッセージを表示します。
- 確認メッセージはできるだけ削除する必要があります。操作を事前に確認するのではなく、実行して後でユーザーが元に戻せるようにするだけです。
- ユーザーが回答する必要がある質問は、通常のフォームでページ内に提示する必要があります。これは非表示のポップアップを表示しないので、「何かをクリックして離れる」という反射を引き起こしません。
アンドリュー、
アラートボックスに関しては、完全に問題なく使用できます。いつ、いつ使用しないかを知る必要があるだけです。簡単なときを知って、次の単純なロジックに従ってください。
元に戻すの場合は、警告を使用しないでください。
このロジックは、詳細な記事 ここで読むことができます で説明されています。
聴衆が情報を失いかけようとしていることを警告しているので、その音で警告ボックスを正しく使用しています。とはいえ、まだ質問が残っています。
- 人が何かを変更したかどうかを検出できますか？その場合、失う情報がない場合はアラートを削除できます。
- 人々はあなたの警告を読んでいない、または理解していませんか？読んでいないときに「OK」ボタンを不用意にクリックしない場合は、「OK」を使用しないでください。 「アプリケーションを終了して、私がやったことを緩めてください」という名前に変更します。彼らがあなたの警告を理解していない場合は、別の言語を試してください。
もちろん、変更を再テストします。あなたが見つける可能性が最も高いのは、誰にも警告ボックスを読ませることは決してないでしょう。しかし、満足のいくパーセンテージを得ることができれば、それで十分です。
ブレントン
本当の問題は、警告ボックスがあまりにも頻繁に実装され、ユーザーに何も考えられないことです。このコメントフィールドにフォーカスがあるときに入力したアラートを確認してください（ただし、何も入力されていません！）、このウィンドウを閉じようとしました： http://www.flickr.com/photos/jonesabi/4033266787/ =
OK/CANCEL？マジ？
うーん。非常に興味深い、アンドリュー。証拠のない仮定が一般的に悪い理由を示します。
警告ボックスの使用についての私の議論は、実際にはそれらの親しみやすさの側面に基づいていましたが、あなたの言っていることから、それは肯定的というより否定的であるように思われます。親しみやすさは無関心を生むと思います。
追加の質問は、「OK」/「キャンセル」確認アラートではなく、単一の「OK」ボタンアラートを使用するかどうかです。後者の最大の欠点の1つは、ボタンのテキストを変更できないことです。多くの場合、「OK」と「キャンセル」は誤解を招きやすく、無関係です。
すばらしい質問ですが。アラートを使用しない場合（JavaScriptの「アラート」のみを意味していると思います）、他にどのようなオプションがありますか。また、ユーザビリティの観点からどのように比較しますか？
単に：アラートはまさにそれです-アラート。彼らはそこに場所を持っていますが、それらは時々ひどく使い古されています。
警告ボックスの主な問題の1つは、それらが単に見苦しいだけであり、ほとんどの場合、あまりカスタマイズできないことです。デザイナー/開発者は、ソリューション/アプリケーションごとに異なる「カスタム」ソリューションを常に思い付くので、ユーザーが直面する別の大きな問題であるような一貫性はありません。
（それはすべての言語/テクノロジーに当てはまります）
アラートは、タスクが大規模なバッチで完全に自動化されるのを妨げるため、悪いことでもあります。あなたのプログラムまたはアプリが入力YでタスクX（30秒かかる）を実行するとします。ここで、ユーザーがYの値100に対して入力Yに対してタスクXを実行したいとします。タスクXにアラートボックスがない場合、ユーザーは100個の入力にまたがるようにタスクを設定でき、ユーザーは50分後に戻って100個すべてのタスクが完了したことを確認します。しかし、タスクXが警告ボックスのポップアップを伴う場合（ほとんど自動化された作業の30秒の任意の時点で）、コンピューターはユーザーを待つ必要があり、ユーザーは現在ユーザーに同じことを要求しているタスクを監視および監視する必要があります質問100回。より良いデザインは、オプション/設定を設定して保存するか、少なくともこれらのボックスの1つに「今後は表示しない」というチェックボックスが付いていることです。
はい、特により良い設計によって、ABを回避するすべてのものについてはい。
これを使用する場合は、設計する必要があります。
最も基本的なABには、タイトル、テキスト、ボタンの3つの部分があります。
ABの意味が伝わる「ゴミ箱交換？」のようなタイトルを使っているので、一気に読めます。
「このドキュメントを変更しましたが、今、それらの変更を破棄しようとしています。破棄するには「OK」、安全に戻るには「キャンセル」をクリックしてください。」のように説明します。
ボタンのラベル付けは重要です。主要なボタンである「実行」ボタンは、タイトルと揃える必要があります。タイトルが「drop it」の場合、主ボタンは「yes」または「OK」でなければなりません。
この種の設計により、ユーザーがABのオファリングを受け入れた結果を認識する必要がある時間を短縮しようとします。
私はそれらがすべてのコストで避けられるべきであることに同意します。率直に言って、ほとんどのユーザーはそれらを単に無視することを学ぶようになりました。
ただし、メッセージを確実に読んだり読んだりする必要がある場合はどうでしょうか。私のプロジェクトの1つで、ユーザーにはダウンタイムが近づいていることを通知する必要があります。通常、ログインするとメール（無視されます）と、ダッシュボードに明確なメッセージ（無視されます）が送られます。
最初にログインしたときにモーダルウィンドウがポップアップ表示されると考えられましたが、ここでもクリックするだけで閉じることができます。この特定のアプリケーションの場合、仕事に悪影響を与えるため、このことを認識させているのはcrucialです。
それで？ 「閉じる」ボタンが表示される前に5秒のタイマーを含めますか？はい、それはおそらくユーザーを怒らせますが、それが本当に必要な数回は効果的ではないでしょうか？
私はそれらをできるだけ避けて、前の相互作用から次に何が起こるかを明確にします。警告ボックスがスムーズなエクスペリエンスであることを自分に尋ねるだけですか？その邪魔をしないで、「警告」ハハ。
また、なぜデータを失わなければならないのですか。ユーザーがリロードしたり、別の場所に移動したりした場合でも、データを保存する方法があります。現在のセッション内でフォームがデータを失う場合があります。
ちょうど私の意見:)
厳密に必要な場合は、最終的にアプリケーションでいくつかのアラートメッセージを作成することができます。ただし、アプリケーションに入れたい情報密度という問題に留意する必要があります。
ユーザーに使用率のフィードバックを多く提供するアプリや、そのようなことを行わず、情報の流れが少ないアプリが必要になる場合があります。
とにかく、私はゾーンがあることをアドバイスする必要があります。より多くの情報があるアプリケーションでは、情報が少ないゾーン、その間にあるゾーン、およびユーザー入力に従って表示される情報を調整できるキャッシュにイベントのタイムラインを保持します。アプリケーションが使用された回数などは、素晴らしい戦略です。ユーザー入力分析に従ってUI要素の密度を試す