web-dev-qa-db-ja.com

保存/キャンセル/閉じるボタンの動作に関する質問

添付画像は、保存/キャンセルボタンバンクとダイアログを閉じるための「x」アイコンを含むダイアログを示しています。私が持っている質問はこれです。キャンセルボタンが値のいずれかをクリア/キャンセルしない場合でも、モーダル上にある必要がありますか?ダイアログを閉じるための冗長な方法として、今持っています。 「保存」ボタンを使用して「x」で終了する必要がありますか、それとも「キャンセル」を冗長な終了として使用できますか?私の考えは、対応する否定的なアクション「キャンセル」なしで肯定的なアクション「保存」を行うことはパターンブレーカーであると考えていました。

フィードバックをお寄せいただきありがとうございます。

Save/Cancel Button Question

16
gstern1994

[キャンセル]は実際には具体的なデータをクリアまたはキャンセルしませんが、ユーザーの心の中で確認すると、ダイアログで変更した値が保存/適用されないことが確認されています。 [x]は通常常に存在している必要があります。これはユーザーにとって「退去」のような働きをし、選択をスキップして状況を直感的に回避するオプションを提供します(たとえば、彼が誤ってダイアログに入力したときなど)。 。

[x]と[save]だけの主な問題は、ユーザーが[x]の機能(および機能しない)がわからないことと、オプションがわからないことです。 [保存]と[キャンセル]を組み合わせて、ユーザーに正確に選択ダイアログで行った変更に対して実行したいことを許可します。明示的な選択により、ユーザーは自分が何をしているかを制御できるようになります。

[適用]オプションもダイアログによく表示されますが、ダイアログウィンドウに複数のタブがある場合にのみ[適用]ボタンを追加します。

19
micromilk

冗長性は必ずしも悪いことではありません。同じタスクを実行する方法が複数あると、さまざまなパターンに慣れているユーザーに対応できる場合があります。

この場合、冗長性の削除の候補はCancelではなく[X]です。これは、モーダルダイアログが編集可能なフォームであり、すでにSaveボタンが付いているため、カウンターアクションが(あなたが言ったように)その隣に。ただし、[X]を維持しても問題はありません。フローを中断したり、レイアウトを乱雑にしたりすることがないためです。

[保存/編集]ボタンのマイクロコピーと機能に重点を置きます。ユーザーがSaveが「保存して閉じる」または「保存して編集を続行」するように期待するかどうかを確認する必要があります。問い合わせの結果によっては、ボタンのラベルを変更するか、別のラベルを追加して、Applyと同等にする必要があります。 OK | Cancel

12
dnbrv

CancelXは同じことをする必要があります。 notユーザーがcancelを押したときにダイアログを閉じる意味はありません。

ここで実際のWindows/Appleのことが起こっています。 Windowsは通常、右側にキャンセルを配置し、Appleは左側に配置します。個人的には、結果の1ページから次のページに移動するなど)肯定的なアクションを右側に配置する傾向があります。左側のネガティブアクション。2つのボタンが近すぎる-私はそれらを分離する必要があります。理想的には、ユーザーがこのダイアログに何かを入力した場合は確認を求めます。そうでない場合、ユーザーを苛立たせるリスクがあります。主な質問への回答として、キャンセルと「x」の両方が絶対に必要です-多くのユーザーはウィンドウを閉じようとさえしません。

1
Peter

可能であれば、[X]を完全に削除する投票を追加します。キャンセルのように動作する必要があります。つまり、変更を破棄してダイアログを閉じる必要がありますが、ユーザーはそれが本当に同じものであるかどうかを疑問視し、そうであれば、同じように機能するが見た目が異なる2つのコントロールがあるのはなぜでしょうか。

保存というラベルの付いたボタンの動作は、いくつかの点でより難しい質問です。 WindowsとMac OSの両方で、「保存して作業を続ける」という意味で「保存」という用語を使い慣れてきましたが、それが頻繁に見られなくなっても(通常はCommand-SまたはCtrlを押します)、 -S)、私はそれをコマンドボタンのラベルとして見たときに疑念を生み出すのに十分な意味が残っていると思います。

このような状況での私のルールは、ボタンshouldがダイアログを閉じることです。他のウィンドウで行った変更をプレビューする必要がない場合、またはダイアログで実行している作業が非常に長いタスクである場合を除いて、作業を進めながら保存できないという本当の危険があります(この場合、プレビューと自動保存それぞれ)、開いたままにする理由はありません。

だから私は、良くも悪くも、「受け入れて先に進む」という意味で来たレーベル、「OK」を選ぶだろう。 OK/Cancelのペアリングは至る所にあり、フォームダイアログを「OK」で終了するのは奇妙に感じるかもしれませんが、Wordを意味のないほど長く見つめると、奇妙なことになります。ほとんどのユーザーはそれが何を意味するかを考える必要はありません、そしてそれはまさにあなたが望むものです。

(何らかの理由で「保存して続行」を意味する保存が必要な場合は、保存して閉じるまたは適用して閉じるを選択します。「保存して続行」は「キャンセル」とペアになりません。行ったすべての変更を破棄します。ダイアログを開いてから行ったすべての変更なのか、最後に保存してから行ったすべての変更なのかは明らかではありません。)

1
Drew Simchik

ケース1:「x」のクローズは相対的に最適な位置にありません。xはタイトルと整列するため、知覚上の問題が発生する可能性があり、これが最初にヘッダーの青い上の通常の位置に来る必要がある場合はどうなりますか。ウィンドウの境界線に沿って配置されたバンド。これを移動する必要がある場合は、次に何をしますか?

ケース2:ユーザーが画面に近づいてアイテムを編集しないことがわかった場合、「x」を使用して閉じることを選択できるので、[保存してキャンセル]はペアリングに適しています。少なくとも最も好ましくは90%がこの方法で行います)、少なくとも10%の人が「キャンセル」を使用します-「OK、ここでは何も編集しないので、このアクションをキャンセルさせてください」(これは私の経験が私を助けるものです)ここに統計を持ってくる)

ケース3:では、なぜ「x」が必要なのでしょうか。これは、ケース2と同じアクションを表しているのでしょうか。ユーザーは、「キャンセル」ボタンでモーダルウィンドウを閉じることを心配する必要はありません。また、ウィンドウ内に「閉じる」または「キャンセル」のアフォーダンスがすでに提供されているため、欠落している部分を見ることはありません。したがって、「キャンセル」のみで閉じることを選択できるオプションがあるため、10%は当然100%になります。

ケース3に基づいてこれを確認する最善の方法は、ユーザーがアイテムを編集して[保存]するか、ユーザーがアイテムを編集して保存せずに[キャンセル]を選択するか、画面を見て何も実行しないことです。 [保存]をクリックします(ここで[保存]ボタンをグレー表示にして、画面上で編集が行われている場合にのみユーザーにアクションを実行させる)か、アクションを実行せずに[OK、letこれを閉じる」、それ以外の場合は「キャンセル」です。したがって、長いビルドアップポインターの後の推論は、 "x"を使用せず、ボタンのペアリングのみを使用することを選択した可能性があるということです。 [保存]ボタンをグレー表示にして、リンクされている編集がある場合にのみユーザーが選択できるようにします。

0
inkmarble