@jTakasuRyuji さんに教えていただいたConfirmations について。
https://msdn.microsoft.com/en-us/library/windows/desktop/dn742470(v=vs.85).aspx
の意訳。
(意訳が間違っている可能性があります。正確性のためには原文を参照ください。)
Is this the right user interface?節
自分の内容理解のための整理です。
Is the user being asked a question to proceed with an action that has two or more responses? If not, the message isn't a confirmation.
意訳「ある行動を進めるために2つ以上の応答を持つ質問をユーザがされていますか? そうでなければ、メッセージはconfirmationではありません。」
Is the UI presenting an error or problem that has occurred? If so, use an error message instead.
意訳「そのUIはエラーや発生済みの問題を表現していますか? もしそうであれば、error messageを代わりに使ってください」
Does proceeding with the action require the user to make a choice that doesn't have a suitable default? If so, a confirmation may be appropriate.
意訳「その行動を進めるには、ユーザが選択をしないといけなく、その選択には適正なデフォルト選択肢がないですか? もしそうなら、confirmation は適切です」
???
a suitable default を持っていない部分が未消化。
a suitable defaultというのは、「よく考えなくてもいいdefault選択肢がある場合」だろうか。
Is there an alternative design that eliminates the need for the confirmation? The need for a confirmation sometimes indicates a design flaw. Often there is a better design alternative that doesn't need a confirmation.
意訳「confirmationの必要がなくなる他のデザインはありますか? confirmationが必要というのは時々デザインの失敗を意味します。しばしばconfirmationを必要としない他のデザインがあります。」
Is the user about to perform a risky action? If so, a confirmation is appropriate if the action has significant consequences or cannot be easily undone.
意訳「ユーザがリスクのある行動を実行しようとしていますか? もしそうであり、もしその行動が重篤な結果を引き起こしたり、簡単にやりなおせないなら、confirmation は適切です。」
Is the user about to abandon a task? If so, don't confirm. Assume users understand the consequences of not completing a task.
意訳「ユーザがtaskをやめようとしていますか? もしそうなら、confirmしないでください。ユーザがそのタスクを終了しない結果を理解していると想定してください。」
Does the action have consequences that users might not be aware of? If so, a confirmation may be appropriate.
意訳「その行動はユーザが気づかないかもしれない結果を生じますか? そうであればconfirmationは適切です。」
Given the current context, are users likely to be performing an action in error? If so, a confirmation may be appropriate.
意訳「現状のコンテキストにて、ユーザが行動をあやまりそうですか? もしそうなら、confirmation は適切です。」
Do users perform the action frequently? If so, consider an alternative design. Frequent confirmations are annoying and have little value because users learn to respond without thinking.
意訳「ユーザがその行動を頻繁に行いますか? もしそうなら、他のデザインを検討しましょう。頻繁なconfirmations はいらいらするもので、価値はありません。なぜなら、ユーザはよく考えずに応答するようになるからです。」
Does the action have security implications? If so, a confirmation may be required even if the previous tests indicate otherwise.
意訳「その行動はsecurity implicationsを持ちますか? もしそうなら、confirmation は要求されるでしょう。前のテストが反対のことを指し示しているとしても。」
security implicationsの部分は未消化。
previous tests indicate otherwise.も未消化。
Design concepts節
気になる点の抜粋。
Don't use confirmations just because there is the possibility of users making a mistake. Rather, confirmations are most effective when used to confirm actions that have significant or unintended consequences. Good confirmations never state the obvious;
意訳「ユーザがミスをするかもしれないためだけにconfirmations を使わないように。むしろ、confirmations は重大な意図しない結果を引き起こす行動の確認に使うと最も効果的です。良いconfirmations は明白なことは記述しない」
Consider the design alternatives
Here are some design alternatives that eliminate the need for routine confirmations:
について以下。
Prevent errors. Design tasks so that significant mistakes are difficult to do accidentally. For example, physically separate destructive commands from other commands, and require multiple actions to complete.
意訳「間違いを防ぐ。重大な間違いを偶然的に実行することが難しくなるようにタスクをデザインしなさい。例として、複数の破壊的なコマンドを物理的に離して配置しなさい。そして、複数の行動により完了するように要求しなさい。」
Provide undo. Provide the ability to revert actions. For example, deleting a file in Microsoft Windows usually doesn't require a confirmation because deleted files can be recovered from the Recycle Bin. Note that if an action is very easy to perform, just having users redo the action may be sufficient.
意訳「undoを提供しなさい。行動をやり直す方法を提供しなさい。例として、Microsoft Windowsにおいてファイル削除はたいていconfirmation を必要としません。なぜなら削除ファイルはごみ箱から復活できるからです。注記点として、とても簡単に実行できるものなら、ユーザがそれをやり直せるようにすることで十分です。」
Provide feedback. Make undesirable outcomes obvious. Providing undo alone isn't sufficient if users don't realize when they make a mistake. For example, the effect of direct manipulation (such as a drag-and-drop operation) should always be obvious.
意訳「feedbackを提供しなさい。望まない結果は明白にしなさい。ユーザが間違いをしたことに気づかなければ、undo機能の提供だけでは不十分です。例として、直接操作(ドラッグ・ドロップのような)の効果は常に明白にしなさい。」
Assume the probable outcome, but make it easy to change. If you aren't sure what users want but there is a likely, safe, and secure choice, assume that choice, make it clear what happened, and make it easy to change using a context menu. For example, Microsoft Word assumes that users want to spell words correctly. If it recognizes a misspelled word and it knows the likely correct spelling, Word automatically makes the correction but allows users to revert.
意訳「ありえそうな結果を想定しなさい。しかし、変更はしやすくしなさい。もし、ユーザが何を望んでいるか確かでなく、選びそうな安全でsecureな選択があるとしたら、その選択と想定しなさい。何が起こったかを明白にしなさい。そして、コンテキストメニューより変更しやすいようにしなさい。例として、Microsoft Wordはユーザが単語のスペルを正しく書くと想定します。ミススペルを認識したとすれば、Wordは自動でその訂正をしますが、ユーザが訂正を取り消すことができるようにしています。」
Eliminate the choice completely. If the choice isn't important, users just won't care. Better to simplify your program and eliminate the choice.
意訳「選択を完全に取り除きなさい。もし選択が重要でないなら、ユーザは気に留めません。プログラムを単純にして選択を取り除くのがいいです。」
Make confirmations require thought
気になった部分の抜粋と補足。
If you present this confirmation immediately after the user gave the Uninstall command, the user's response is likely to be "Of course I want to uninstall!" The user will click Uninstall without giving it a second thought.
Uninstal作業を開始したユーザに対して確認ダイアログで「Uninstall」ボタンを使うのはincorrect。
When practical, it's usually better to do this by carefully phrasing commit buttons.
より良いのは「Uninstal anyway」ボタンにする。
using Yes/No commit buttons forces users to at least read the main instruction.
あるいは、「Yes/No」として、ユーザがメッセージを確認するように促す。
Provide all the information
ファイルコピーにおける確認事項について整理されている。
Vista以降のコピー確認ダイアログが好例として挙げられている。