[OK]ボタンと[適用]ボタンの背後にあるロジック
モバイルインターフェイスに酔った後、デスクトップの土地に戻ると、デスクトップダイアログにはほとんどの場合、次の3つのボタンがあります。
- OK
- 申し込む
- キャンセル
- 閉じるボタン。
このパターンは、WindowsおよびLinuxベースのUIの両方で発生するようです。他のOSを試したことはありません。 Macにも存在したかもしれませんが、思い出せないかもしれません。
それが今までredundantであったことは、今まで私には思いもよらなかった。 [キャンセル]ボタンは[閉じる]ボタンと同じです。両方が同じであるのに、なぜ最初にそこに配置されたのですか？どちらもダイアログを閉じます。
[OK]ボタンと[適用]ボタンにも適用されます。どちらかをクリックしがちです。どちらも同じことをします。確かに、適用はダイアログを閉じずに変更を適用します。しかし、ほとんどの場合、必要なすべての設定がすでに設定されており、確認するには[OK]が必要です。
- そのような設計の論理は何でしたか？
- キャンセルがあるのになぜクローズするのですか？
- 適用とOKの違いは何ですか？
それらは異なります：
OK：変更を適用してダイアログを閉じます（または前の場所に戻る/ 1レベル上に移動します）Apply：ユーザーが結果を表示/操作できるように変更を適用しますが、ダイアログを開いたままにして、さらに変更できるようにしますCancel：変更を適用せずにダイアログを閉じます。
ウィンドウタイトルの「閉じるボタン」は通常キャンセルとして機能しますが、「良好な冗長性」と見なすことができます。Close：ダイアログを閉じますが、適用する変更がないことも示します。保留中の変更がある場合、クローズは使用できません。
2つの異なるユーザーモデルから開始：
変更を永続化する前に確認する「従来のデスクトップモデル」は、科学、エンジニアリング、およびビジネスでのコンピューターの初期使用と相性がいいです。公式の州があり、誰かがその責任を負っています。
モバイルのカジュアルでエンターテインメント中心の環境では、よりカジュアルで、「好きなようにして、いつでも（理由の範囲内で）元に戻すことができます」の方がはるかに適しています。
（違いはデスクトップとモバイルではなく、主にビジネスかカジュアルかであることに注意してください。）
今、なぜそれらのボタンなのか？
「Apply」はOK/Cancelモデルの拡張機能であり、OK/Cancel APIの制限内で「手動プレビュー」を取得するためのハックとして見ることができます。
別の設計を検討してください：
- ダイアログの設定を変更すると、変更が「適用されたかのように」すぐに表示されます
- OKは変更を永続化し、ダイアログを閉じます
- キャンセルは変更を元に戻し、ダイアログを閉じます。
これには、すべての変更が元に戻せることが必要です。エラーや接続の失敗などがあった場合でも、実際のトランザクションまたはそれに近いもの、単純なGet/SetProperty APIはそのために十分ではありません。また、オブジェクトとダイアログの間のより緊密な結合を作成します。更新は、即時と見なされるのに十分な速さでなければなりません。さらに、同時変更は管理が難しくなります。
「OK /適用」モデルは、既存のAPIの上に配置できる回避策を提供します。追加のコストはほとんどかかりません。
「正しい」とは何ですか？
ここには2つの依存しているが明確な側面があることに注意してください。1つは（ビジネス）要件である「変更に対する責任を取る」、もう1つは発見性の向上と「元に戻す」の快適さです。
従来のOK/Cancelモデルは、それらを対立させます。モバイルで有名な「カジュアル」モデルは快適さを好み、重要な不可逆的なアクションについてのみ「必要な確認」にフォールバックします。
このモデルはビジネス環境にも適していますが、多くの場合、変更の追跡（いつ誰が何をするか）、ロール管理、比較/差分を追加する必要があります。
まず、 代わりに動詞を使用できる場合はOKを使用しないでくださいOKの意味は誤解しやすく、説明ボタンを使用する方がはるかに適切です。ユーザーが実行しているアクションがわかるように名前を付けます。 OKボタンを使用できると私が思う唯一の場合は、純粋に情報ダイアログです。
キャンセルがあるのになぜクローズするのですか？
CancelボタンとCloseウィジェットの冗長性は良いことです。ほとんどの場合、どちらも同じ結果になりますが、2つの異なるタスクを意味します。 Closeウィジェットは「このウィンドウを削除して何もしない」を意味し、Cancelボタンは「気が変わってこの仕事をしたくない」を意味します。
OS Xは、「シート」（Document-Modal Dialogs）を使用してこの問題を適切に回避します。ダイアログは上部のウィンドウタイトルに添付されます。ドキュメント自体は閉じるウィジェットを保持していますが、シートがアクティブな場合は無効になります。したがって、ユーザーはまだ決断する必要があることを知っています。
適用とOKの違いは何ですか？
Applyは、非モーダルダイアログボックスで特に役立ちます。たとえば、ドキュメントに変更を適用し、ダイアログを開いたまま変更がドキュメントにどのように影響するかを確認し、希望する結果が得られるまでさらに変更を加えることができます。
モーダルダイアログでは、ApplyはOKと同じであり、一部のコンテキストではOKボタンを単に置き換えます。 （上記を参照してください。可能な場合は常に、OKの代わりにアクション動詞を使用してください。）
OK-Applyポリシーは、複数のタブ（または類似の）を持つフォームがタブスイッチ間の変更を保持できなかった時期から来ていると思います。したがって、適用には、ユーザーが意図した変更のサブセットapplyを許可するという利点がありました。
確かにOK-Applyアプローチをサポートしていませんが、認めざるを得ません。適用によって、すべてまたは何も保存することを恐れずに、長い形式を慎重に保存できました。
セマンティック的にキャンセルは、クローズとは異なる意味を持つ可能性があり、それが初期の存在を説明している可能性があります。長年にわたって、あなたが言うように、それらの間で観察された違いはありませんでした。
参照してください "適用ボタンを含めるタイミング？" 回答の要点の1つは、（Macのように）リアルタイム/オンデマンドの変更を行うときに適用ボタンが継承されることです。時間および/または処理能力の点で高価になります。
よく見ると、電話やモバイルオペレーションシステムのダイアログには、閉じる/キャンセルのコンボはありません。ダイアログがポップアップしたときにキャンセルボタンしかありません。キャンセル/クローズの冗長性は、ダイアログボックスにデフォルトで閉じるボタンがあり、標準になる（JavaScriptの alert（）関数について考える などのユーザーインターフェイスフレームワークに由来する）と想定します。 ）。
多くのWindowsダイアログには、複数のタブがあります。私の意見では、適用ボタンの目的は、1つのタブで変更を加えてから、次のタブに移動する前に適用することです。
ユーザーが現在のタブで変更を加えたと確信しているとします。 適用これらの変更を行ってから、次のタブに移動して変更を加えます。
ダイアログは時々非常に設定が集中するので、それがApplyボタンの出所だと思います。
私が観察したところによると、多くのユーザーは、変更を適用するには[適用]をクリックし、終了するには[OK]をクリックする必要があるという印象を受けています。そのため、「タスクバーをロックする」のようなごくわずかな変更の場合は、単にOKではなく、[適用]と[OK]をクリックします。 適用パターンは、多くのユーザーにとって少し誤解を招くと思います。また、ほとんどの場合冗長です。ほとんどのユーザーは多くの変更を行いません。実際、多くの設定を控えめにして、複雑なUIをよりシンプルなUIに分割するのが最善です。
インターフェイスの冗長性は必ずしも悪いことではありません。
異なるユーザーがどちらかを見つける場合があります。クローズボックスを押すのがより快適な場合もあります。他の人はボタンを見て、それが何をするのかを知りたいです。一部のユーザーは、別の冗長な操作であるEscapeを押します。インターフェースが乱雑にならない限り、これで十分です。
これらのいずれかを削除することもできますが、この場合、ダイアログボックスの使いやすさはそれほど向上しません。