オンラインアプリケーションでデータ/進行状況を自動的に保存する傾向が高まっているようです。接続やサービスが中断される可能性が高い多くの場合、ユーザーがタスクに夢中になって忘れてしまった場合に備えて、それは間違いなく良い考えです。 Googleドキュメントは、ユーザーが操作するたびに保存されるWebアプリケーションの良い例です。 Microsoft OneNoteは、同じ方法でデスクトップアプリケーションを実行するもう1つの例です。
自動的に保存しないと考えることができる唯一の理由は、ユーザーが変更をロールバックしたいデスクトップアプリケーションなど、元に戻す操作の参照ポイントとして機能するかどうかです。
保存アクションが実行されたときにユーザーに通知するために、ステータスメッセージではなく保存ボタンが引き続き使用される正当な理由はありますか?
Saveを、ユーザーデータをより大きな影響なしに永続化する単なるアクションとして参照しているかどうか、またはこれが他のシナリオにも適用できるかどうかに依存します。
保存アクションがより広いものに影響を与える場合(たとえば、システムに大幅な変更を引き起こす設定を適用するなど)、このアクションの手動制御を失うことはユーザーにとって望ましくない可能性があります。
ただし、大多数のシナリオでは、データを自動的に目立たないように保持することでメリットが得られることに同意します。
自動保存ボタンの使用は素晴らしいですが、ユーザーに強制するべきではありません。それはグーグルドキュメント、電子メールなどのシナリオの魅力のように機能します。しかし、私はそれをフォームで実装することはありません。
1:ユーザーから制御する
2:データを自動保存すると、多くのサーバー呼び出しが発生します
3:自動保存フォームを使用すると、クレジットカードなどのように送信せずにデータを保存しているという誤った警告がユーザーに送信される可能性があります。
ここでも、コンテキストは重要です。
自動保存は素晴らしいアイデアです。自動保存を使用したGoogleドキュメントとGmailは、データ/進行状況を自動的に保存するための最良の例であることに同意します。しかし、これはすべてのアプリケーションに理想的であるとは限りません。数分おきに自動保存するゲームをプレイしようとしていると想像してみてください。節約に時間がかかると、これはさらに煩わしくなります。 GoogleドキュメントやGmailでは、自動保存にかかる時間が非常に短いため、優れたUXが得られます。
保存などの自動タスクの介入を最小限に抑えてプログレッシブタスクを実行する場合は、[保存]ボタンの方が適しています。先に述べたように、ゲームの進行のようなタスクは、保存ボタンが理想的な場所です。保存するデータの量が多い場合、パフォーマンスの問題は確実に忍び寄り、これが再び悪いuxの原因となる可能性があります。
アプリケーションのコンテキストは、自動保存を有効にするか、保存ボタンを使用するかを決める重要な鍵です。より良いオプションは、ユーザーが自動保存オプションのオン/オフを切り替えられるようにすることです。オフにすると、[保存]ボタンが使用可能になります。
誰もが自動的に保存しないのは、これが2番目の選択肢の説明だと思います。 。 。 「特定のジョブ、コード言語、およびアーキテクチャーの技術的または技術的な制限がすでに存在しています。」
多くのバックエンドプログラマーは自動保存を適切にプログラムする方法を学んでおらず、ボタンをクリックしてページを再読み込みする必要のない情報を保存する新しい方法を経験していないため、保存されたボタンは引き続き使用されます。また、多くの場合、バックエンドのコードは、バックエンド言語が保存を十分に促進またはサポートしていなかった年から古くなっている可能性があります。
これは、現在の保存アイコンであるフロッピーディスクについての議論を思い出させます。 OPはフロッピーディスクが古く、若者はメタファーを認識しなかったと考えました。議論は、代替案を考え出そうとする人々で構成されていました。
そのことについての私の意見は、保存ボタンをすべて一緒に削除することでした。ドキュメントなどは自動的に保存されます。私たちは技術を持っています!
私の意見では、自動保存はUXの次のステップにすぎません。ユーザーが保存について心配する必要がないように、重要なタスクを自動化します。論文を書いている学生は、文書が保存されていない状態でコンピューターがクラッシュすることを恐れる必要はもうありません。
正しく行われると、ほとんど見えなくなりますが、今日では自動保存が唯一の方法だと思います。