設定を自動保存するタイミングと「保存」ボタンのガイドライン
私たちのWebアプリケーションには、ユーザー設定に関連するさまざまなカテゴリのページがいくつかあります。それらのほとんどには、編集ボタン/リンクを備えた表示ページがあり、キャンセル/保存の終了パスを持つフォームに移動します。
ただし、設定の1つのカテゴリでは、別の設定を行います。アラートと通知の設定では、アラートのすべてを表示し、その場で個別にオン/オフを切り替えたり、それぞれのオプション（宛先として使用するメールアドレスなど）を変更したりするためのコントロールを表示します。保存ボタン/リンクはありません。変更はすぐに反映されます。これは、一般的なシナリオでは、ロットをバッチとして確認して編集するのではなく、1つのアラート設定のみを微調整したい場合があるためです。また、「保存」ボタンはウィンドウの折りたたみの下にあり、見逃される可能性が高いことも認識しており、アラート設定の各セットに対して保存ボタンを配置したくありませんでした。
保存ボタンがないことでユーザーが困惑するのではないかと少し心配しています。
すぐに影響を与える設定の変更に関するガイドラインと議論は何ですか？
一貫している必要があります。人々があなたのアプリケーションに期待するものを変えることは混乱を招き、良い考えではありません。
1つのセクションで自動的に保存する場合は、すべてのセクションで保存してみませんか？保存ボタンを配置する正当な理由がある場合は、すべての設定ページに配置しないのはなぜですか？
多くのアプリケーションは、設定ページを論理グループに分割し、各グループに保存ボタンがあります。私はそれを視覚的に醜く見つけていません、そして何をすべきかは明らかです。長いリストの最後だけでなく、間違いなく優れたオプションです。
一貫性は間違いなく必須です。ただし、1つの設定グループが実際に一連のフィールドに入力するのではなく、トグルオン/オフアクションを保証する場合は、変更するたびにこれらを自動的に保存してもかまいません。
トグルスタイルのスイッチを使用している場合は、フリックするとアクションが保存されることが期待されます...ライトをオンまたはオフにすることを考えてください。それが切り替えられた後、短いアニメーションまたは通知によって保存されていることを象徴することができます。
また、どのようなタイプのユーザーを持っているかについても考える必要があります。彼らは物事が自動的に保存されることを期待していますか、それとも保存ボタンをクリックしてアクションを完了する心理的な閉鎖が必要ですか？.
アプリケーション内で自動保存を使用することは、より一般的な方法になりつつあります。 Googleはほとんどのアプリで自動保存を使用していますが、必要に応じて「保存ボタン」も使用しています。 「Webに精通している」ユーザーの方が自動保存に慣れていますが、「Webに精通していない」ユーザーはボタンを期待するか、ボタンをクリックして、努力が保存されたことを確認したいと考えるかもしれません。
私の意見では、自動保存は避けるべきです：
- フォームに検証がある場合
- フォームは複数のエントリを許可します
エントリを自動保存するクライアント用のタイムシートモジュールを設計しました。クライアントはそれを気に入っていましたが、その後検証が開始され、テーブルが上下逆になりました。一部のフィールドは動的に、つまり別のフィールドの選択に基づいて必須である必要がありました。ユーザーが必須データを取得せずに移動した場合、システムは静かにエントリを無視しました。簡単な修正はなく、「保存」ボタンを導入する必要がありました。
一貫性はさておき、分析レポートからプラットフォームを確認する必要もあります。ほとんどの視聴者がmacOSのバックグラウンドを使用している場合、macOS上のほとんどのアプリケーションとダイアログボックスの動作は自動的に保存されるため、自動保存の使用を検討することをお勧めします。
Windowsユーザーの場合、少なくともほとんどのユーザーはWindows 7以下の心の中にあります。その場合、自動保存はほとんどのダイアログボックスの標準ではありません。
古代には、ドキュメントには2つの状態がありました。ディスクに「保存された」状態と、編集中の状態です。オンラインアプリケーションの場合でも、これは多くの場合適切なモデルです。接続がダウンした場合に作業が失われるのを防ぐために、編集中の状態の最新のコピーをサーバーに保存しておくとよいかもしれませんが、「保存済み」の状態は通常、誰かが肯定的に要求した場合にのみ更新する必要がありますそれ。
一部の状態が変更された後でウィンドウを閉じる場合、ユーザーは変更の破棄、変更の適用、またはドラフトとしての保持を許可する必要があります。ユーザーが後者を選択した場合、または接続が失われた場合、次に状態を編集する試みが行われたときに、システムは保存されたドラフトを取得していることをユーザーが明示的に形成する必要があります。
自動適用されるフォームに何らかの変更を加えるのは嫌いです。特定の変更を自動適用する必要がある場合は、[たとえば、チェックボックスまたはラジオボタン。「XXXをオンにする」または「モードをYYYに設定する」ための「送信」スタイルのボタンがあります。