OneNoteのようなソフトウェアは、自動保存を実装できることを示しており、手動保存ボタン/ CTRL + Sと同じように（またはそれ以上に）機能します。
とにかく、あなたが取り組んでいるものはすべて保存したいです。保存せずに閉じるような破壊的なものを試している場合に限ります。
では、プログラマー/ユーザビリティの観点から、手動の「保存」機能が今日でも事実上すべてのソフトウェアに見られるのはなぜですか？データが変更されるたびに「自動保存」を実装するのが面倒だからですか？
そして、少なくとも特定の業界や競合他社の間で牽引力を開始するために、自動保存を実装することは良い考えですか？
自動保存は通常、定義された間隔で保存します。インターバルの間に保存したい場合はどうなりますか？
環境内の他のアプリケーションとの一貫性を保つために、手動保存を実装する必要があります。
人々はファイル->保存、またはCTRL+Sが存在することを期待しています。
保存ボタンは、Jon Skeetからおばあちゃんまで誰もがよく知っている、よく知られた快適なUI機能です。あなたがそれを取り除くならば、それは何人かの人々のために窓の閉じるボタンを取り除くようなものでしょう。確かに、彼らは最終的にはそれに慣れますが、一部の人々は自分のデータが自動的に保存されたことを理解していません。
また、Webで自動保存している場合は、これらすべてのインスタンスでサーバー上の多くのスペースを占有しているだけでなく、定期的な保存で多くの帯域幅を使用しています。少なくとも手動保存では、ユーザーが意図した場合にのみスペースと帯域幅を使用しますが、これはまれにしか使用できないため、帯域幅を節約できます。もちろん、自動保存の利点は、何か問題が発生した場合でも作業を保持できることです。
「スキューモーフィズム」の定義を確認してください:)
さらに、「保存」には、通常「名前を付けて保存..」もあります。どちらもユーザーに制御とセキュリティの感覚を与えます。[保存]をクリックしたことを知っていると、データをリロードするときにデータがどのような状態になると予想できるかがわかります。
それは本当にこれに帰着します：保存ボタンは元に戻すよりも実装と維持が安価です。
自動保存を実装するのは難しくありません。通常の保存を実装して、必要なときに、またはタイマーで呼び出すだけです（怠惰な場合）。
何十年にもわたってユーザーが学んだ共通のパターンのため、保存ボタンは一般的です。
このパターンは、ハードドライブとメインメモリの古い区別に由来します。別の方法で考える場合（一部の実験的なオペレーティングシステムのように）、ファイルをロードおよび保存する必要はありません。ハードドライブをメインメモリとして、メインメモリをハードドライブの別のキャッシュレベルとして考えてください。 。その結果、すべてのファイル（リムーバブルメディア上ではない）は常にメモリ内にあり、ファイルを再度ロードまたは保存する必要はありません。
しかし、ユーザーは何年もの間古いパターンに慣れているため、この変更を行うのは簡単ではありません。さらに、古いロードと保存のパターンは、一種の原始的なアンドゥシステムを取得するための非常に簡単な方法です。
自動保存には元に戻るシステムも必要であり、それを構築するのはそれほど簡単ではありません。特に、画像、オーディオ、またはビデオの編集を実行し、大量のデータを生成している場合、適切な時間とメモリのトレードオフを見つけるのは困難です。また、ユーザーがアプリケーションを閉じて元に戻そうとし、これが機能しなかったことを認識するリスクがあります。したがって、このエラーからユーザーを保護したり、クラッシュの場合に不要な変更を保存したりするために、元に戻す情報を保持することもお勧めします。
だから、はい、私は本当に保存（およびロード）ボタンが消えるのを見たいです。永続的な元に戻る情報、さらには完全な編集履歴も欲しいです。しかし、私はこの変化が数年以内に起こるとは思わない-もしあったとしても。
私は医療の分野で働いていますが、何かを保存する責任をユーザーに負わせたい場合があります。EHRがあり、患者の処方箋を入力している場合は、必ずしも自動保存する必要はありません。ユーザーが自分の行動を認識し、責任を負う必要があります。また、このような重要なシステムで値を自動保存すると、明らかな理由で悲惨な結果になる可能性があります...
多分主観的なタグを付ける必要がありますか？
開発者として、私はいつもそのようなアプリに少し不安を感じています。私は自分のデータがいつ保存されるかを制御するのが好きですが、おそらくこれはほんの数年の作業での調整です。クローズボタン（またはショートカット）を明示的に押さずにデータを入力したウィンドウを閉じると、その小さな「うーん」という感覚が得られます。
そうは言っても、私は特定の状況でそれを受け入れるように「訓練」されています。たとえば、OneNote、またはおてんば娘。非常に多くのOSXアプリ、特にDBサーバーGUIツールなどのユーティリティアプリがこのパターンに従います。
つまり、さまざまな状況に対応するさまざまなツールです。IMO、最近のほとんどのソフトウェアは、手動保存から自動保存への移行の恩恵を受けません。
これに対する答えは「状況次第」だと思います！
他のアプリケーションとの整合性に関するユーザーの期待だけでなく、ユーザーがアプリケーションを使用する方法も考慮する必要があります。
OneNoteの非常に一般的な使用例は、誰かがOneNoteを開いて、作業中の情報とほぼ同じように情報をダンプすることです。彼らは素早く出入りする必要があります。保存に関するプロンプトは迷惑になります。
一方、Wordのようなアプリケーションは、ユーザーがドキュメントの作業に一丸となって時間を費やすことを期待しています。この場合、確認ボックスなどを手動で保存して応答するという雑用は、比較的小さな作業と見なされます。
プログラマーの観点からは、自動保存の実装は大したことではありません。タイマーを設定するだけで、コールバックが保存を行います。
ただし、使いやすさの観点から、自動保存は非常に問題があります。まず第一に、ユーザーは手動で保存することに慣れていて、それを提供しないと、大多数のユーザーを混乱させ、制御を奪うことになります。
さらに大きな問題は、自動保存によって、必要かどうかに関係なく、下にあるファイルの内容が上書きされることです。もちろん、一時ファイルに自動保存機能を保存することもできますが、元のドキュメントを上書きするかどうかの決定は、ソフトウェアではなく、常にユーザーが行う必要があります。そして、とにかくユーザーが少なくとも1つの手動保存を開始する必要があるので、手動保存を常に利用できるようにしてみませんか？
自動保存機能は、ドキュメントを処理するときに最適です。ビジネスアプリケーションはどうですか？顧客のアカウントを編集する場合、編集したフィールドからタブで移動するときにアカウントを更新する必要がありますか？もしそうなら、アカウントが無効な状態にあるとき、それは何をすべきですか？ビジネスルールはいつ施行し、どのように施行しますか？すべての編集でビジネスルールを考慮に入れる必要がある場合、どのように機能しますか？
これらの考慮事項のいずれかを考慮に入れたアプリケーションを確実に構築できますが、それは余分な努力の価値がありますか？
では、[保存]ボタンを削除する必要がありますか？場合によります。
簡単な答え： "auto save" = "auto destroy" /"auto<expletive>"。
大学のあるプロジェクトでは、私のグループと私は、実験として明示的に保存せずにアプリケーションを作成しました。
無限のアンドゥスタックを実装し、実際のデータを使用してアンドゥスタックをシリアル化したため、アプリを閉じて再度開いた場合でも、いつでも最後の操作を元に戻すことができます。すべての操作でディスク上のアクションリストに新しいエントリが書き込まれるため、電源に障害が発生した場合でも、ファイルは常に一貫性があります（ほとんどの場合...）。これは、バージョン管理システムとジャーナリングファイルシステムの間のちょっとしたクロスでした。
2つの問題がありました。1つは、それを完全に正しくする時間がありませんでした（ああ、若々しい傲慢）。2つ目は、すでに述べたすべての理由から、全員（仲間の学生、そして最も重要なのはTA）がそれを嫌っていたことです。
時には、すべての最善の意図のために、あなたは根付いた行動を無視することができないだけです。