これは、 OK-Cancel または Cancel-OK?という質問に触発されています。.
特定の状況で OK-Cancel/Cancel-OK を切り替えて、ユーザーが内容を読まずに情報ポップアップやダイアログ ボックスをクリックするのを防ぐという概念についてどこかで読んだことを覚えています。私が覚えている限りでは、これには、ユーザーがクリックする場所を思い出すのを防ぐために、[OK] ボタンの位置を (水平方向に、左から右に) 移動することも含まれていました。
これは本当に理にかなっていますか？これは、ユーザーに「最初に考えて読んでからクリックする」ように強制する良い方法ですか? この種の状況に適用できる他の概念はありますか?
私は特に安全関連のアプリケーションを考えています。無意識に習慣から OK を押すと潜在的に危険な状況になる可能性がありますが、キャンセルすると安全な状態になります。
絶対に必要であることが本当に、本当に、本当に確実でない限り、これを行わないでください。これは、不注意や愚かさを技術的な手段で正そうとするケースであり、そのようなことはほとんど機能しません。
できることは、典型的な Windows の [OK] / [キャンセル] ボタンのキャプションの代わりに動詞または名詞を使用することです。これにより、予測可能性を犠牲にすることなく、すぐに注目を集めることができます。
NOOOOOOOOOOO!
当社の製品の 1 つには、安全関連のコマンドに Ctrl+Click を要求するユーザー オプションがあります。
しかし、私の本では、場所を入れ替えたり移動したりするボタンでユーザーを驚かせるのは悪い設計です。
番号。ユーザーが誤って [OK] をクリックするのを難しくして考えさせたとしても、ユーザーは [OK] をクリックする方法について考えるだけで、実行しようとしている実際のことについては考えません。ユーザビリティの専門家である Aza Raskin の記事を参照してください: Undo の意味で警告を使用しないでください。見積もり：
警告を無視できないようにするのはどうですか? 問題を引き起こしているのが人間側の慣れである場合は、習慣を形成できないようにインターフェイスを設計してみませんか。そうすれば、質問に答える前に常に立ち止まって考えることを余儀なくされるので、常に意図した答えを選択することができます。それで問題は解決しますよね？
このタイプの考え方は新しいものではありません。これは、この文の n 番目の単語を入力して続行するアプローチです。たとえば、ギルドウォーズのゲームでは、キャラクターを削除するには、最初に「削除」ボタンをクリックしてから、確認としてキャラクターの名前を入力する必要があります。残念ながら、常にうまくいくとは限りません。特に：
- それは私たちが自分の仕事を捨てたいかどうかではなく、目の前の非習慣的な仕事に集中するようにします. したがって、無視できない警告は、通常の警告よりも少しましです。いずれにせよ、作業を失うことになります。これ (私たちの仕事を失うこと) は、可能な限り最悪のソフトウェア罪です。
- これは非常に煩わしく、常に注意を払う必要があるため、必然的に作業の妨げになります (これはソフトウェアの罪の中で 2 番目に悪いことです)。
- これは、標準の警告よりも常に遅く、より多くの作業を必要とします。つまり、必要以上の作業を必要とするという、3 番目に悪い罪を犯します。
[Microsoft っぽいものが必要な場合は、 MSDN の .NET 担当者が同じことを言っています!]
ダイアログを使用する必要がある場合は、ダイアログ内のボタンに説明的なキャプションを付けます。
たとえば、[OK] ボタンと [キャンセル] ボタンの代わりに、"請求書を送信" や "戻る" など、ダイアログのコンテキストに適したものを使用します。
そうすれば、テキストはカーソルのすぐ下にあり、理解できる可能性が高くなります。
Apple ヒューマン インターフェイス ガイドラインのサイトは、優れたリファレンスであり、非常に読みやすいものです。 そのサイトのこのページでは、ダイアログについて説明しています。
画像の例を次に示します: (出典: apple.com )
いいえ、意味がありません。ユーザーに読ませるつもりはありません。決定が非常に重要である場合は、不注意であると推定されるユーザーに装填された銃を渡すよりも、危険を軽減する方法を見つけたほうがよい.
「セーフ」ボタンをデフォルト (Enter/スペースバーなどでトリガー) にすることは良い考えです。単純に、ユーザーを驚かせた場合に、予想されるウィンドウを意図したキーストロークが予期しないアクションを誤ってトリガーしないためです。ただし、そのシナリオでも、ユーザーが行ったことに気付くまでに、選択は (ダイアログの説明テキストと共に) 既になくなっていることに注意する必要があります。繰り返しますが、彼らに情報を提供する別の方法を見つけたほうがよいでしょう。
私がいくつかの例で行ったことは、メッセージ ボックスが表示されている時間と閉じられている時間を比較することでした。「x」秒未満の場合は、すぐに元に戻りました。これにより、ほとんどの場合、盲目的にクリックするのではなく、画面に表示されているものを実際に読む必要がありました。
やり方も簡単で……。
このようなもの：
Dim strStart As DateTime = Now
While Now < strStart.AddSeconds(5)
MessageBox.Show("Something just happened", "Pay Attention", MessageBoxButtons.OK)
If Now < strStart.AddSeconds(5) Then strStart = Now Else Exit While
End While
しないでください。これには何のプラスの効果もありません。ユーザーが [キャンセル] ではなく [OK] をクリックするのを回避しようとしているのです。[OK] ではなく [キャンセル] をクリックする可能性があります (大丈夫、再試行する可能性があります)。しかし！人々が本当にキャンセルしたいときに [OK] をクリックすることもできますが、それは本当の惨事になる可能性があります。ダメだ。
結局のところ、ユーザーがやりたくないことを強制することはできません...ユーザーは常にそれを回避する方法を見つけます。
私が見た中で最も信頼できる方法は、書かれている内容に基づいて多肢選択式の質問をすることです。答えが正しくない場合は、続行できません... もちろん、数回後、ボタンが有効になるまで各答えを順番に選択してクリックするだけでよいことに気付くでしょう。繰り返しますが、彼らは書かれたものを読んでいないことを意味します。
ユーザーの行動に対する責任をユーザーに負わせる前に、できることは限られています。自分の行動がログに記録されていることをユーザーに伝えると、ユーザーはより注意を払うようになります。ユーザーが責任を問われれば、正しいことを行う可能性が高くなります。特に、次のような慎重に作成されたメッセージがある場合:
これはログに記録されており、この決定の影響について責任を負うことになります。テーブル ALL_CORPORATE_DATA を削除するように指示されました。そうすることで、会社全体のデータベースが機能しなくなり、会社全体が停止します。
続行することを選択する前に、この責任を受け入れることを示すチェックボックスを選択する必要があります...
そして、「はい、自分の行動について責任を負います」というチェックボックスと 2 つのボタンがあります。
彼らがテーブルを削除し、会社のグリッドが停止した場合、彼らは解雇されます。その後、バックアップが復元され、[ラリーが誰であれ] 再びラリーとして皆が幸せになります。
この問題は、適切なフィードバック、システム モデルの伝達、および組み込みの許容範囲を組み合わせることで、より適切に解決されます。
確認メカニズムを支持することは、実装の単純さを物語っています。プログラマーの観点からは、責任をユーザーに転嫁する最も簡単な方法です。 ."
ユーザーの観点から:
ユーザーにとってはより良いが、より複雑な (ソフトウェア開発の観点から) ソリューションは次のようになります。
可能な場合は、アクションがシステムに与える正確な影響を事前に伝えます (たとえば、スタック オーバーフローでは [回答を投稿] ボタンの上にメッセージ プレビューが表示されます)。
アクションが実行されたらすぐにフィードバックを送信して確認します (SO は新しく送信された回答を強調表示し、メッセージが送信されると gmail は確認を表示します)。
間違いの可能性を元に戻したり修正したりできます (つまり、SO の場合、回答を削除または編集すると、Windows ではごみ箱からファイルを復元できます)。元に戻すことができない特定のアクションについては、元に戻す機能を提供することができますが、限られた時間枠のみです (つまり、送信後の最初の 10 分間でオンライン注文をキャンセルまたは変更できるようにするか、最初の送信中に電子メールを取り消すことができるようにします)。 「送信」されてから 60 秒後ですが、実際には送信ボックスなどでキューに入れられます)。
確かに、これは確認メッセージ ボックスを挿入するよりもはるかに最初の作業ですが、責任を転嫁する代わりに、問題を解決しようとします。
さまざまなプロンプトと応答オプションを設定できるVisualBasicに存在するオプションについて考えているのではないでしょうか。1つのオプションは、デフォルトにする必要があるものに基づいて、[キャンセル]と[OK]を切り替えることができるようにすることです。そのため、ユーザーはEnterキーを押すだけで、ほとんどの場合、適切なアクションを実行できます。
本当にこの方向に進みたい場合（これは悪い考えだと思います。少し考えて、他のすべての投稿を読んだ後もそうなると思います）、OKのキャプチャ表示を含めるとさらに効果的です。
ただし、OK/キャンセルに一貫性がない場合、ユーザーの気分を害したり動揺させたりする可能性があります。
また、[同意する] ボタンをクリックできるようになる前に、ユーザーがパネルを一番下までスクロールする必要がある一部の EULA を好まないでください。ユーザーにすべてを注意深く読ませることができない場合があります。
本当に読む必要がある場合は、ボタンが表示されるまで少し時間がかかるのではないでしょうか? これはユーザーにとって迷惑になる可能性もありますが、非常に重要な質問である場合は、その価値があります。
編集：または、クリックして非常に重要な決定を「受け入れる」だけでなく、何らかの追加メカニズムが必要です。チェックボックス、キープレス、パスワードなど。
これが重要な操作であることを赤いテキストを使用してユーザーに通知し、なぜこれが安全でない操作なのかを説明することをお勧めします。
また、2 つのボタンではなく、2 つのラジオ ボタンと 1 つの [OK] ボタンがあり、[続行しない] ラジオ ボタンがデフォルトで選択されています。
これにより、ユーザーに珍しいインターフェイスが表示され、認知負荷が増加し、速度が低下します。ここであなたが望むものはどれですか。
ユーザー インタラクションを伴うものは何でもそうですが、ユーザーを助けることと迷惑をかけることの間には、わずかな余裕があります。あなたの正確な要件はわかりませんが、あなたのアイデアは私には問題ないようです（しゃれが意図されています）。
ユーザーが安全アプリで一種の入力ウィザードを使用しているようです。
ボタンを移動する代わりにいくつかのアイデア。
最後の OK を押す前に、すべての入力を確認する最終画面を表示します。
[OK] をクリックした後に、このアクションの結果がどうなるかを説明する確認ボックスを用意します。
ユーザーが続行する前に、チェックボックスをオンにして同意する必要がある免責事項。
私はOK/キャンセルにはあまり賛成ではありません。それは使いすぎで、何を OK するか、何をキャンセルするかを言うためにせせらぎを読む必要があります。MacOSX UI のアイデアに従います。ボタンには、それ自体で意味のあるシンプルで簡単なフレーズが含まれています。例 - ファイル拡張子を変更すると、次のようなダイアログがポップアップ表示されます。
"Are you sure you want to change the extension from .py to .ps?"
If you perform the change, the document could be opened by a different application.
(Use .ps) (Keep .py)
OK/Cancel よりもはるかにコミュニケートされ、質問はほとんど不要になります。つまり、標準のように見える右端のボタンをアクティブにしておくだけで済みます。
それはあなたが提起した生の質問に関するものです。絶対にしないでください。これまで。銃を突きつけられても。一貫性は、GUI の重要な要件です。一貫性がないと、ユーザー エクスペリエンスが損なわれ、ユーザーはこれを機能ではなくバグと見なす可能性が高くなります (実際、バグです)。一貫性は非常に重要です。それを破るには、非常に正当な理由が必要であり、同じ効果を達成するための別の標準的な方法があってはなりません.
それを切り替えないでください - あなたが助ける以上に混乱させるだけです.
代わりに、FireFox のように、5 秒間コントロールをアクティブにしないでください。-タイマーや、読み返す機会を与えていることを示す何らかのインジケーターを含めるようにしてください. クリックするとタイマーが切れますが、もう一度クリックする必要があります。
どれだけ改善されるかはわかりませんが、役立つかもしれません。
男が言ったように、覚えておいてください：あなたは愚かを直すことはできません。
これでは頭が痛くなります。特に、誤ってアプリケーションを閉じて、ファイルを保存するのを忘れた場合:(
クリックする前にユーザーに「読む」ことを強制する別の良い例があります。Firefox は常に「OK」ボタンをグレー表示(無効化) していました。したがって、ユーザーは何かを行う前に約 5 秒待たなければなりません。これは、ユーザーに読む (そして考える)ことを強制するために私が見た中で最高の努力だと思います
私が見た別の例は、インストーラーの「ライセンスと契約」ページにあります。それらのいくつかは、ユーザーが次のステップに進む前に、ページの最後までスクロールする必要がありました。
キーボード ショートカットは以前と同じように動作します (特に LOB アプリケーションで実際にマウスを使用する人が少ないことに驚かれることでしょう)。
Vista (および OSX IIRC) は、質問ごとに特定の動詞を使用するという考えに移行しました (アプリがクラッシュしたいときにクラッシュダンプを MS に送信したい場合の「送信」/「送信しない」など)。
私の意見では、ボタンの使用が許可される前にタイマーを使用して、アプリが COM 経由で電子メールを送信しようとするときに Outlook で使用されるアプローチが気に入っています (キーボード ショートカットにも影響します)。
これは、Submit/Reset ボタンの注文に関する質問に回答したもので、ここでも同じ原則を使用できると思います。ユーザーが 2 つのボタンを区別できることを確認する限り、順序は重要ではありません。過去に私が行ったことは、（送信/OK）ボタンにボタンを使用し、（リセット/キャンセル）ボタンにリンクを使用していました。ユーザーは、これら 2 つのアイテムが機能的に異なるため、そのように扱うことがすぐにわかります。
インターフェイスとして [ OK]と[キャンセル]を使用すると、ユーザーは常にメッセージまたは画面をスキップできます。その後、 OkとCancelを再配置すると、ユーザーを困らせるだけです。
ユーザーの理解を確実にすることが目標である場合、これに対する解決策は次のとおりです。