user-interface - ユーザビリティ: 「適用」ボタンを使用して変更を保存するか、またはすべての変更後に保存しますか?

Question

ユーザー インターフェイスの設計、ユーザビリティ、および保守性に関するトピックについて、仲間の開発者の意見や経験を聞くことに興味があります。

一般的なアプローチは、ユーザーがオプションを微調整できるようにし、フォームが「ダーティ」になった後に「適用」ボタンを有効にし、ユーザーがキャンセルを押して元に戻すことができるようにすることです。これは、Windows プラットフォームで最も一般的なアプローチです (MS のユーザビリティ ガイドラインでもそうするように言われていると思います)。

もう 1 つの方法は、オプションを変更するたびに変更を適用することです。例、ユーザーがいくつかのチェックボックスをチェックすると、変更が適用されます。ユーザーがテキストボックスの値を変更すると、ボックスがフォーカスを失った後に変更が適用されます。このアプローチは、Mac OSX で最も一般的です。

私の個人的な意見 (ユーザビリティでは Apple の方が優れているが、私が通常作成するソフトウェアは Windows ユーザーを対象としている) に関係なく、皆さんはどう思いますか?

編集：これは本当の質問ではなく、議論を求めていること、そしてその場所がSOではない可能性があることを十分に認識しており、そのポリシーは回答と質問のみを持つことです。しかし、主に質問する前にそのようなものを見つけることができなかったので、それは有益な議論になると思います.

Answer 1

どちらにもそれぞれの場所があり、多くのプラットフォームで使用されています (実際には、PC と Mac を区別するものではありません)。

「適用」ボタンを使用すると、いくつかの変更を加えて適用することができ、さらに変更を加えるためにダイアログを再度開く必要はありません。これは試してみるのに便利ですが、ユーザーに自分の選択について系統的に考えてもらいたい (または安心してもらいたい) 場合は、変更が適用されるタイミングをユーザーが正確に制御できます。これは、いくつかの変更を行うまで変更をコミットしたくない場合や、ユーザーが「実験」する必要がなく、必要な設定を知っておく必要がある場合に重要です。これらのダイアログには、通常、ダイアログを開いてから行った変更を (できれば) 元に戻すキャンセル ボタンもあります。これらのダイアログは多くの場合モーダルであるため、ユーザーは選択を行うまでダイアログにロックされます。

インスタント効果ダイアログを使用すると、ユーザーは自分の選択に基づいて実験し、「ライブ」更新を確認できます。これは、ユーザーがオプションを試して、どのような効果があるかを確認したい場合に最適です。ユーザーが「ライブ」で操作していることを明確にするために、視覚的なスタイルに注意する必要があります。変更を元に戻すことはできないため、ユーザーは注意する必要があります。このタイプのダイアログに対する Microsoft のアプローチは、単一の「閉じる」ボタンを使用することです。これにより、即時効果のアプローチが明確になります。これらのダイアログは多くの場合、モーダルではありません。つまり、ダイアログではなく「ライブ編集パネル」として扱われます。

一般に、UI はフェンスのライブ編集側に傾いています。これにより、ユーザーは実験的になり、特別なボタンを押して変更をコミットする必要があるなどの技術に妨げられないようにすることができます (たとえば、Win7 のコントロール パネルを参照してください。モーダル ダイアログはほとんど比較されません)。 XPに）

ただし、最終的にこれら 2 つのオプションのどちらを選択するかは、制御したい設定の種類によって異なります。つまり、あるテキストにフォント スタイルを設定している場合、実際には実験的なスペクトルの端にいる必要がありますが、重要な関連情報グループ (DNS サーバーのアドレスやサブネット マスクなど) を構成している場合は、考えたり知ったりして意図的に変更を適用する必要があるものを使用したい場合があります（ユーザーが情報を入力して再確認し、関連するいくつかの情報を「同時に」変更できるようにします。また、 DNS サーバーのアドレスは、ユーザーが入力したとおりに有効であり、すべての数字が正しい値になるまでネット接続が失われます (有効なアドレスは意味がありません)。

Answer 2

プラットフォームの期待に一致します。

私もAppleが使いやすさの点で優れていることに同意しますが、あなたの決定はあなたのターゲットプラットフォームが示す最も一般的な振る舞いに基づくべきです。ユーザーが最も驚かないことは常に行う必要があります。ほとんどのWindowsユーザーにとって、それはその動作に固執することだと思いOK/Apply/Cancelます。

クロスプラットフォームアプリケーションを使用している場合は、プラットフォームの期待に一致するというマントラを尊重する個別のGUIを実行します。はい、それは余分な作業ですが、それはあなたが気にかけていることを示しています。

Answer 3

すべてのフィールドではなく、フォーム全体が入力された後に変更を保存するための+1。

ただし、フィールドがフォーカスを失うたびに検証を行う必要があります。これにより、何か問題が発生した場合にすぐにフィードバックを提供できます。

Answer 4

一般的に、プラットフォームの期待に一致させる必要があることに同意します。

ただし、個人的には、2つの理由から、一般的に適用/保存の使用を好みます。1）部分的に適用された変更は、混乱を招く可能性があります（遅延または実際の画面アーティファクト）2）特定の状態または組み合わせが有効でない場合があります（またはそうでない場合があります）ユーザーの認識において有効である）。3）変更を展開したり、意味のある名前で変更を保存したりする方法を提供する場合は、ユーザーが適用または保存を選択した時期に基づいて論理的にグループ化するのが理にかなっています。開発者として、私は物事へのコミット/ロールバックアプローチが好きで、UIでもそれが好きです。

Answer 5

適用ボタンを配置する正当な理由は 2 つしか思いつきません。

1. 変更をすぐに適用することはできませんが、GUI がかなりの時間ロックされます。
2. 変更は (トランザクションのように) 組み合わせてのみ意味を持ちます。

それらのどれも非常に一般的ではありません。歴史的に、1 はほとんどすべてのオプションに当てはまりました。しかし、今日のコンピュータはより高速であり、1 はほとんど関連性がありません。変更の効果がすぐにわかる場合、誰もそれを望まないでしょうか? そのため、適用ステップをスキップすることで、GUI (コードではないことが多い) を簡素化できます。ユーザーが実際にキャンセル ボタンを必要とすることもあまり一般的ではないと思います。1 つの変更を行って適用し、別の変更を行ってキャンセルを押した場合、どうすればよいですか? 最初の変更は元に戻されますか (ほとんどのアプリケーションでは、実装が簡単なため、答えはノーです)。

はいの場合、それが適用ボタンを持つポイントであり、すべてが決定され、とにかくOK/キャンセルを押しますか? それとも、ウィンドウを閉じるという別のオプションを検討する必要がありますか?

いいえの場合、基本的に適用すると、元に戻すブックマークが設定され、キャンセルが押されます。しかし、この種の複雑な動作は、実際のユースケースで本当に必要なのでしょうか?

ユーザーが期待している (と信じられている) という理由で、この種の複雑な歴史的理由を維持することは正気でしょうか? ユーザーが常に適用を押してから OK を押すのを見てきました。なんで？おそらく、GUI が複雑すぎるためです。または、「適用」が「適用して閉じるダイアログ」を意味するかどうか (一部のアプリケーションではそうです) が不明であり、OK が変更を適用しない可能性があるため (私は、OK が適用せずにウィンドウを閉じるだけのバグのあるアプリケーションを見たことがあります。もある）。少なくとも、一般のユーザーはこれらの複雑な選択肢の正確なロジックを認識していないと思います。人々は主に、「ポジティブ」（はい、OK、進む、適用する）と「ネガティブ」（いいえ、キャンセル、中止、戻る）のアクションをダイアログで区別する傾向があります。どちらかが複数ある場合、ユーザーはより多くの注意を払う必要があります。興味深いことに、ポジティブなアクションを別のアクションと交換しても、ユーザーの認識にはあまり影響がないようです。はい/いいえボタンのあるダイアログが、OK/キャンセルに変更された場合、多くのユーザーは気付かないでしょう。

それは使いやすさについてです（これははるかに重要なIMHOです）。保守性に関して言えば、即時適用は、間違って行うと非常に面倒になる可能性がありますが、適切に行うと非常にクリーンで保守しやすくなります。アプリケーションが一度にすべて適用するアプローチで作成されている場合、通常は 1 つの関数があります。もちろん、小さな変更ごとにそのような関数を呼び出すのはあまり効率的ではありません。私が見たものは、関数をいくつかの異なる関数に分割して、さまざまなものを適用することで解決されることがよくあります。理想的には、行うことができるすべての種類の変更に対して1つの専用関数です。これにより、アプリケーションの応答性が大幅に向上しますが、維持するのは大変です。だからそこに行かないでください。きちんとした解決策は、MVC (Model-View-Controller) を使用し、構成アイテムごとにモデルを作成し、それらを構成フォームのフィールドとアプリケーションの関連部分 (および構成ストレージ バック) にバインドすることです。すべての変更が自動的に保存されます)。問題の環境で MVC が使用できない場合は、MVC を作成する価値があります。