私は現在、「ユーザーはそれを読むべきですが、彼は愚かな猿のようにOKをクリックします」ダイアログの多くを持っているプログラムに取り組んでいます...それで私はクリックを避けるためにキャプチャのようなものを追加することを考えていました-考えずに...
私のアイデアは次のとおりです。
誰かがそのような状況で何か経験をしたことがありますか。あなたは何をすることを提案しますか？
さて、あなたは意見を求めましたが、ここに私の意見がありますが、これはあなたが聞きたいことではないと思います...
ユーザーは、信頼できるプログラムが好きです。彼らは物事が変わるのが好きではなく、余分な仕事をするのも好きではありません。
ボタンをランダムに変更し、ボタンをフォームのどこかにランダムに配置しても、間違ったボタンを押すか、アプリケーションにイライラするだけです。あなたが言うように、彼らはテキストを読まないからです。 . たとえば、[OK/キャンセル] ダイアログを考えてみると、常に [OK] ボタンが左側にあると思われますが、ほとんどの場合、それを読まずに押します。ユーザーとまったく同じことが起こります。
これらの 3 つのオプションを使用すると、アプリケーションに余分な作業が追加され、ユーザーはそのことであなたをののしります。1 日に 10 回実行しなければならないことを考えてみてください。コードをソース セーフにチェックインするとします。上司から、チェックインしようとするファイルごとにキャプチャを入力する必要があると言われたら、どう思いますか?
私たちのソフトウェアを使用する人々の生活を楽にすることが私たちの仕事だと思います. 彼らが何らかのテキストを読まなければならず、読みたくない場合、読ませる方法は絶対にありません。
人々を正しく働かせることはできません。あなたにできることは、可能な限り最高のツールを提供し、彼らが仕事をするのに十分な専門家であることを願うことだけです.
基本的に私が言いたいのは、彼らの仕事を楽にするために最善を尽くすということだけです。これがあなた（または担当者）よりも本当に重要な場合は、彼らと話し、なぜこれが重要なのかを説明する必要があります.
人々が理解していることにコミットする方法に驚くでしょう。
そうしないことをお勧めします。そして、よく知らない限り、<大手オンライン小売業者>や<オンラインバンキングサイト>のような立派な有名で十分にテストされたUIをエミュレートします。
メッセージボックスを使用しないようにアプリケーションを再設計します。
メッセージを読んでもらうためにユーザーとゲームをするのは運命づけられています。ユーザーは、メッセージを理解することよりも、ゲームを完成させることに精神的なリソースを集中させます。ボタンの移動、ラベルの変更、スカベンジャー ハント、キャプチャ、遅延などがあると、ユーザーがメッセージの重要な部分を実際に理解する可能性は低くなります。彼らは、実際の問題ではなく、ゲームの指示に焦点を当てます. エラーが増える可能性があります。
ユーザーがメッセージ ボックスを読むことを拒否するのは、ユーザーが時間をかけて何かを読むのではなく、すばやく作業を終わらせたいと考えているためです。また、メッセージ ボックスが非常に多くのアプリで過度に使用され、悪用されていることも原因です。メッセージ ボックスにばかげたゲームを含めると、ユーザーはますますそれらに憤慨し、問題が悪化します。
できることは次のとおりです。
ルール 1. メッセージ ボックスを使用しない。それらは例外的な状況でのみ表示されます。アプリに「多数」のメッセージ ボックスを含めることはできません。ユーザーがアプリを使用するたびに大量のドキュメントを読む必要はありません。アプリの通常の使用でメッセージ ボックスが表示される場合は、UI が間違っています。別の方法を見つけてください。
確認メッセージの代わりに、何が起こったかをメイン ウィンドウに明確に示し、それを元に戻す明確な方法を提供します。
エラーメッセージではなく、自動修正、画像/マスクフィールド、および無効化を使用してください。
メッセージを回避するには、適切なデフォルトと自動化を使用してください。たとえば、ユーザーがサーバーに接続されていないためにアップロードできないというエラー メッセージを表示するのではなく、単に自動的に再接続します。
オプションに沿ってコマンドを分割します。ユーザーが書式付きまたは書式なしで貼り付けたいかどうかを尋ねるメッセージ ボックスではなく、メニューに 2 つの異なるコマンドを提供します。
すべてが正常に機能したことをユーザーに知らせる情報メッセージが自発的にポップアップ表示されないようにします (例: 「設定が保存されました!」)。
役立つヒントやドキュメントを提供するポップアップを表示しないでください。UI を自己文書化できない場合は、チュートリアルまたはバルーン ヘルプを提供します。
「アップグレードしてください」というしつこいメッセージはありません。
別のメッセージ ボックスではなく、メイン ウィンドウにメッセージ テキストを提供することを検討してください (たとえば、「セキュリティのために ActiveX がオフになっているため、ページが正しく表示されない、または正しく動作しない可能性があります。」)。Web サーフィンからのポップアップにより、ユーザーは、ポップアップするものを無関係として自動的に却下するようになりました。
ルール 2.メッセージを使用する必要がある場合:
重要な情報を理解できるように、テキストはできるだけ簡潔にします。より多くのテキストはより役立つとは限りません。「[パス] の [ファイルマスク] に一致しません」を使用します。「致命的でないエラー 307: 検索アクションが中止されました。[Appname] は、指定した正規表現の文字列検索を完了できません。指定したファイル マスク、つまり [filemask] では、指定したディレクトリ ([path]) に一致するファイルが見つからないためです。ファイルマスクまたはパスの選択を確認し、[検索するファイル] ダイアログ ボックスに再度入力してください。このメッセージ ボックスの下にある [OK] ボタンをクリックして、[検索するファイル] ダイアログ ボックスに戻ります。「検索するファイル」ダイアログが表示されたら、「検索するファイル」ダイアログの「キャンセル」ボタンをクリックして、文字列の検索をキャンセルしてください。」短いメッセージで達成できる以上の説明が必要なユーザーがいる場合は、
メッセージには平易な言葉を使用し、専門用語は使用しないでください。これには、「ダイアログ」、「データベース」、「トナー」などの「罪のない」言葉が含まれます。生の例外テキストを取得して、エラー メッセージにスローしないでください。エラー番号やダンプは含めないでください。代わりにこれらをログに記録してください。開発者が残したデバッグ メッセージ ボックスをアプリから削除します。専門用語でいっぱいのメッセージを表示してからアプリが消えるよりも、致命的なエラーでアプリが消えるのを待つほうがよいでしょう。
メッセージ ボックスのボタンには、「OK」ではなく、アクションの内容を示すラベルを付けます。少なくとも、ユーザーはメッセージ ボックスを閉じるためのアクティブ化ボタンに集中する必要があります。そのボタンに「削除」や「インストール」などのラベルが付いている場合は、一時停止する必要があります。各ボタンの機能をメッセージ テキストで説明する必要はありません。ところで、このようなラベル付けは、ほとんどのプラットフォームの GUI 標準です。
私の提案は、それを受け入れるか、ダイアログ/インターフェースを再設計してください。ダイアログにランダム性を追加したり、ユーザーをばかのように扱ったりしないでください。
私はつい最近 Joel on Software の記事、Designing for People Who Have Better Things To Do With Your Life を読みました。ほとんどの人は何も読まないことを指摘し、それを回避する方法、または少なくとも悪化させない方法について説明します。
送信ボタンを有効にする前に、「想定される読み取り時間」を待機するタイマーを試すことができます。単語数から想定読書時間を計算することもできます。
ユーザーにテキストを読ませる微妙な方法（ボタンを動かしたり、キャプチャを読んでもらうなど）を行うと、愚かなサルのように感じることがあると思います。
ユーザーが何を読むべきかに基づいて、選択の質問を使用できます。