ユーザーに手動で保存させるのではなく、自動保存しないのはなぜですか？
Apple最新リリースのLionで自動保存に移行しましたが、誰もが自動保存の慣習を採用し始めるべきですか？
最初は間違いなくぎこちなく、ユーザーは自分がコントロールしにくいように感じるかもしれませんが、広く採用されていると、みんなの生活が楽になります。もちろん、「名前を付けて保存」または「コピーを作成」タイプのオプションを提供して、手動でコピーを保存できるようにする必要があります。
自動保存に関して技術的/パフォーマンス上の大きなハードルはありますか？そうでない場合は、すべて自動保存技術を採用する必要がありますか？
私たち（Windowsと他のプラットフォーム）がこの新しい規則を採用しない場合、WindowsユーザーとMacユーザーの間にさらに大きなギャップが生まれます。 Macのみを使用した、または今後Macを使用して成長した人は、節約に慣れません。 Windowsを使用する人々は、常に保存したいと思うので、Mac（すべてではない）に夢中になるでしょう。
Marketoでは、アプリがすべてを自動保存します。 「保存」アクションはほとんどありません。
ただし、興味深い副作用があります。電子メールエディターでは、一部のユーザーが非常に慌てて[保存して閉じる]ボタンがなかったため、1つ追加しました。これはすでに保存されているため、ボタンはウィンドウを閉じるだけですが、苦情はなくなりました。情報は保存されたとのフィードバックをたくさんいただいていますが、それで十分ではありませんでした。
本当に信頼の問題です。システムは私に聞いたのですか？私は確信していますか？
一般的に、私たちの営業部門は、それが商談成立の主要な利点であると考えています。
技術的な異論はほとんど時代遅れですが、自動保存するUXベースの異論はまだあると思います。他の回答は、バージョン管理と自動保存の関係をほのめかしています。 @sovaは代替案としてそれらについて話しますが、私はそれらが本質的な補完物であると信じています。バージョン管理（または少なくとも永続的な従来の取り消し）がない場合、自動保存には重大な潜在的な欠点があります。
ドキュメントベースの相互作用モデルでは、ドキュメントへのすべての変更は、ドキュメントが保存されるまでの一時的なものです。保存せずに閉じる機能は、ユーザーが常に最後に保存されたバージョンに戻ることができるため、きめ細かな取り消し機能を提供します。この形式の元に戻す操作は、CTRL-Z/-Yスタイルの元に戻す/やり直しに比べても使い勝手が非常に悪いですが、ユーザーに「パニックボタン」のセーフティネットを提供します。自動保存は、このオプションをユーザーから取り除きます。説得力のある置き換えがなければ、これは間違いなくデータの安全性の正味の損失になる可能性があります。
Googleドキュメントと新しいOS X Lionのバージョン管理機能は、従来のコマンド履歴スタックではなく、タイムラインに基づく元に戻す/やり直しの代替のより強力な形式を提供します。どちらのシステムも、バージョンをタイムラインに固定し、ユーザーが古い状態を全体または部分的に現在に移行できるようにします。これは、手動保存ドキュメントモデルによって提供される単一バージョンの復帰よりもはるかに優れています。これにより、自動保存の潜在的な欠点が取り除かれます。
自動保存とタイムラインベースのバージョン履歴の組み合わせにより、優れたUXが提供されます。バージョン管理なしの自動保存は、さまざまなメリットがあります。
補遺
@ andrew-neelyは、別の重要なケースを思い出させます。多くのビジネストランザクションには、データの入力と実行の間の重要な移行があります。これらの状況ではドキュメントモデルは不適切であり、別のメタファーを使用する必要があります。ただし、データの損失を防ぐことは可能です。
たとえば、クラッシュや停電後の再起動時にUIの状態を復元するようにシステムが設計されている場合があります。ユーザーは、データ入力を繰り返さずに、トランザクションをキャンセルするか続行するかを選択できます。 UIの状態の保存は自動保存の一種ですが、これはユーザーに対して透過的です。
タイムラインベースの履歴メカニズムも、この状況でのアクティブな編集操作にはあまり適していません。従来の元に戻す/やり直しは、トランザクションの相互作用が短いUXに適しています。期間が短いということは、コマンドスタックを管理する負担が少なくなることを意味し、トランザクションの性質は、遷移ポイントを過ぎて元に戻ることがいずれの場合でも不可能であることを意味します。
トランザクションシステムでのバージョン管理は引き続き可能ですが、別の性質を帯びます。編集中の各時点でトランザクションの完全な状態を表示する代わりに、永続的な変更のみに焦点を当て、それらを一連の状態遷移として監査ログに表示する場合があります。トランザクション自体は、進行中のプロセスの象徴としてのアーティファクトではありません。遷移のログは、このアクティブなワークフローの性質をよりよく反映しています。
それは部分的に歴史的です-保存がデータをサーバーに送り返すことを意味するとき、それは高価な操作でした、そしてそれがロールバックする機会なしにあなたがすでに持っていたものを上書きすることを意味するとき、それはユーザーの制御下にある必要がありました。
ただし、データをローカルに保存するか、高帯域幅の接続を使用すると、保存のオーバーヘッドはなくなります。バージョン管理により、機能をロールバックできます。
Googleは既にGoogleドキュメントで自動保存機能を備えており、Appleのように移動することで、あらゆる場所で自動保存機能が利用されるようになるという一般的な傾向があります。十分な場所にある場合、人々はそれを要求し始めます。
Microsoftが次のバージョンのOfficeでそれを導入するのではないかと思います-結局のところ、OneNoteはすでに自動保存を行っており、Wordなどはすでに自動保存を行っていますが、一時ファイルに対してのみです。実際のドキュメントに保存することは、次の論理的なステップです。
時間がかかる可能性のある領域の1つは、レコードを有効にするために完全でなければならないデータベースアプリケーションです。部分的な保存は可能ですが、ワードプロセッサやスプレッドシートアプリケーションのようなものほど簡単ではありません。
このようなものがすべてのアプリケーションに到達するまでには時間がかかります。
自動保存に2つの問題があります。
最初に、不注意な編集（間違い）：ユーザーがドキュメントを表示するために表示して間違えた場合、自動保存は有効なコピーを無効なデータで上書きし、ユーザーに追加の操作を要求します間違いを元に戻すためのアクション。
自動保存を使用して設計されたデータ入力システムがあります。誰かの入力フォーカスが間違ったウィンドウにあり、情報を上書きしたためにレコードが破損した回数はわかりません。本当のバージョン管理とロールバックはこの問題をある程度軽減することができますが、システムを複雑にし、ストレージ要件を増やし、ユーザーが使用するために習得しなければならない追加機能を追加します。
2番目、制御の欠如：ユーザーに意図的に書き込みをコミットさせるという考えが気に入っています。私はすべて一時ファイルに自動保存し、変更を破棄しようとするときにユーザーにプロンプトを表示しますが、ユーザーに「そうです、そうするつもりでした」と言ってほしいのです。
自動保存は、最初に保存することを前提としています。データを保持する意図なしにデータがプログラムに入力される場合があります。
例1ワードプロセッサを起動して、スペルをチェックしたり、エディタの同義語を検索したりすることがありますそのような機能が欠けています。その情報を保持したくない。
例2メモ帳を使用して、一時的に保持したくない一時的な情報を保存することがよくあります。自動保存では、正当な理由もなく、これらのファイルの混乱をクリーンアップする必要があります。
例部下の1人に関する問題を文書化する場合、筆記があまりきちんとしていないため、タイプすることを好みます。ワードプロセッサを使用している場合、HRセクションでは紙のみが必要で、ドキュメントをどこにも保存したくありません。ドキュメントを保存すると、不満が生じた場合に備えて、コンピュータ全体（またはネットワーク）を開いて発見できるようになります。
例4多くの場合、フォーマットされたデータをあるソースから別のソースにコピーするときに、データをメモ帳にコピーしてすべてのフォーマットを削除します、もう一度コピーして、ターゲットドキュメントに貼り付けます。その情報を保存したくない。
Alan Cooperとその友人たちは、常に保存について多くのことを述べており、適用可能な場合はいつでも元に戻すことができます。まだ読んでいない場合は、ぜひチェックしてください About Face 。
最良のユーザーインタラクションシナリオを検討するときに最初に言うことは、ソフトウェアは常に自動保存する必要があるということです。ここSEでも、入力すると下書きが自動保存されます。
2番目に注意する点は、与えられたモードレスフィードバックです。ユーザーは、自分が取り組んでいるものが実際に保存されたことを確認できる必要があります。 Googleドキュメントは、これまでに見たどのインターフェースよりも優れています。
3つ目は「今すぐ保存」機能です。ドキュメントが「保存したばかりです」と点滅するまで待つ必要のない操作を実行する必要がある場合は、続行する前に保存されたことを確認します。天気に関係なく、別の場所に移動したり、何かが閉じられたりすると、ソフトウェアは確実に保存しますが、「これは保存されていることを知っています」という感覚が欲しいです。
4つ目は、「コピーを保存」以外に、名前変更機能があるはずです。 Word文書を開いていて、別の名前を付けたい場合は、文書を閉じてファイルに移動し、そこで名前を変更する必要があります。その機能は、私が簡単にアクセスできる場所に提供する必要があります。
最後に、プログラム/ブラウザーを閉じてから3か月後に再度開いて、不要なものが保存されたことに気づいたとしても、元に戻すスタックを常にセッション間で保持する必要があります。
ユーザーは自動保存に慣れてきていると思います。プログラムがクラッシュしたときは、個人的には安心しました。すべての保存が行われたので、何も失われていません。要約すると、これについての「顔について」セクションを読み、Googleドキュメントを確認してください。
誰もがドキュメントの観点からそれについて話します。あなたの質問は、「誰もが自動保存の慣習を採用し始めるべきか？」と述べています。バージョン管理を提供しなければ、それは役に立たないということを他の人に同意する必要があります。私にとって、写真家としての自動保存だけでは、これまで存在した中で最悪の機能になります。 Photoshopで画像を「破壊」するのに何時間も費やし、多くのことを行ったことを確認し、すべてをスクラップしてやり直した。
それは私が考えることができるどんな創造的な分野にも当てはまります。作成するときは、多くの場合、実験を行いますが、自分がやったことが気に入らない場合は、すぐに元に戻すオプションを選択する必要があります。
そして、それはテキストエディタにも当てはまります。段落全体を削除して書き直す場合、古いバージョンのほうがよかった場合は、その段落に戻るオプションが必要です。
したがって、自動保存に標準を設定する場合は、バージョン管理にも標準を設定する必要があります。そうしないと、解決するよりも多くの問題が発生します。
これは誰にも言及されていないと思いますが、自動保存機能を実装してはならない1つの例は、USBメモリスティックから開いたファイルで作業しているときです。広く知られているわけではありませんが、USBドライブの読み取り/書き込みサイクルは非常に限られており、時には3000-5000と低い場合もあります（ Wikipedia：USBフラッシュドライブ）を参照 ）。アプリケーションが頻繁に、たとえば毎秒保存する場合、基本的にユーザーのデバイスは1時間程度で破壊されます。
私はたくさんのウェブアプリを作成しましたが、この問題が発生すると、次の問題の1つ以上に直面します。
ビルドには時間がかかります。通常のモデルに加えて、「ドラフト」モデルを構築する必要がある場合があります。
自動保存を検出可能にするのは難しい場合があります。ユーザーが自動保存して、変更を保存する方法を疑問に思うようにしても、あまり役に立ちません。
変更はいつアプリケーションのどこに行きますか？たとえば、時間の経過に伴う変化を確認するために、アドレスエントリの過去のバージョンが保持されている、バージョン管理されたアドレス帳について考えてみます。どのくらい小さな変更を自動保存し、これらの変更の1つとして処理する必要がありますか？時間の経過とともに多くのスライスを取得し、1つの大きな変更に集約する必要がありますか？
このデータを並行して使用する他のシステムについてはどうでしょうか。これらの変更をいつ取得する必要がありますか？たとえば、このアドレス帳を使用してシステムイベントをユーザーに通知するシステムがある場合-ユーザーがユーザーの変更をいつ取得するか-ユーザーがタイプミスをしたり、電子メールアドレスの入力中に一時停止した場合-これを使用するシステムはアドレスはこの部分的なエントリを取得し、結果として送信に失敗しましたか？
アプリケーションの使用方法によっては、ユーザーにとって有害な場合もあれば、害のない方法で構築することが非常に困難な場合もあります。たとえば、アプリケーションが任意の長さのドキュメントを編集し、ユーザーが2Gで動かなくなった携帯電話で100ページのドキュメントを編集している場合、自動保存を実装する最も明白な方法は、その接続を破壊することです。はるかに複雑な差分アプローチがありますが、それらは微弱なCPUを損なう可能性があります。
自動保存は間違いなく便利な機能ですが、多くの場合、設計の決定が難しく、システムの問題が難しい場合があります。
バージョン管理は、バージョンの表示（タイムスタンプ）がエンドユーザーに明確である限り、間違いなく重要です。それで問題は、すべての微小な変更をドキュメント履歴として記録することはどれほど役立つでしょうか？まあ、それはあなたがあなたがセッション内またはセッション外の変化を見ているかどうかに依存します。したがって、歴史の提示はこれを考慮に入れるべきです。
興味深いことに、私たちはこれを何年にもわたって行っていますが、別の経験として隠蔽されています。つまり、取り消しと保存の違いです。
セッション内を見るとき、ユーザーはおそらくマイクロレベルでバージョンに戻りたいと思うでしょう-それはすべての詳細な変更です。これは、取り消し履歴で取り消しを使用するのとまったく同じです。ここでの違いは、自動保存では、セッションはドキュメントが開いている全期間であることです。元に戻すと、セッションは最後の保存以降の期間として定義されます。ユーザーがセッション内で行った変更を確認できる限り、必要な時点までの変更を元に戻すことができます。
セッションの外を見るとき、ユーザーは時間の観点から考えて、ドキュメントを編集していたときの時間に戻る可能性が高く、特定の詳細な変更点に必ずしも移動する必要はありません。これは間違いなくよりマクロレベルで物事を表示しているので、そのように提示する必要があります。興味深いことに、自動保存の概念により、ユーザーが希望する場合、ユーザーが前のセッション内の特定の変更にドリルダウンできる「新しい」機能を提供できるようになります。
そして、データベースとドキュメントへの適用性に関しては、これらは異なります-調査する必要がある「公開」タイムラインの概念があります。データベースレコード内のコンテンツの更新を検討する場合、これらを自動保存できる必要があります。ただし、レコードは共有リソースであり、公開の概念も必要です。パブリッシュにより、他のユーザーもこれらのレコードを読み取り、編集することができます。良い例は、誰かが新しい記事を作成しなければならないが、変更をすぐに表示できないようにするCMSです。彼らが昼食や編集の途中で会議に行くときを言います。これらの変更は、ユーザーが他のユーザーが表示できるようにシステムに「公開」（またはコミット）するまで、誰にも表示されるべきではありません。
ハイブリッドシステムが一般的でないのはなぜですか？つまり、メインドキュメントはユーザーの保存時にのみ保存されますが、保存されていない編集のために並列ツリーが維持されます。ユーザーが保存を忘れた場合（またはプログラムがクラッシュした場合など）にプログラムを閉じた後でも、並列ツリーには常に戻って回復する機会があります。
ストレージが非常に安いため、編集を保存するコスト（特に増分）は信じられないほど安価です。 元に戻すオプションを忘れたソフトウェアは特に嫌いです保存
この機能を実行するプログラムの例は、Vim（エディター）です。
PS。自動保存に対する引数は、複数のアプリ/ユーザーが同じファイルを同時に開くことを許可するOSにあります。一部のユーザーが表示しているだけで、編集が誤っている可能性があります。
Macには 米国で15％の市場シェア しかありません。それらの15％のうち、自動保存が導入されたのはOS X Lionのほんの一部です。したがって、自動保存に慣れている人はほとんどいません。自動保存が優れた機能であるかどうかに関係なく、自動保存は一般的な機能ではありません。ライオン以外のほとんどのユーザーは、これを奇妙に感じるでしょう。機能の普遍性は、UIデザインで重要なすべてです。意図はあるかもしれないが、突如としては、ユーザーを混乱させる可能性があります。
私は1つとして、ずっとWindowsを使用しています。私はたまにMacを使っていましたが、それ以外の場合はMacの自動保存に不快でした。どのプログラムでも環境設定を構成するときに、Macに保存ボタンがないことを知っていますか？その設定ウィンドウを閉じると、自分の変更が消去されるのかどうか、いつも気になっています。ただし、Microsoft Windowsでは、設定ウィンドウには通常applyおよびsaveボタンがあります。これにより、[〜＃〜] x [〜＃〜]またはcancel。
繰り返しますが、私は自動保存の利点について議論していません。私はそれが前衛的であり、主流のユーザーインターフェイスに対応していない可能性があることを指摘しています。 Aza Raskin は、FirefoxのUI設計責任者であり、iPhoneが直感的である唯一の理由は、Appleが広告に数百万ドルを費やしているためです。ほぼすべての人がコマーシャルを見たことがあるiPhoneを使用している人々の数。今では、Appleがライオンズの自動保存のために同じマーケティングを行っているのを見ることはありません。彼らは、ごく少数のApple=より多くのマーケティングを行っていない限り、そしてすべての携帯電話会社がほぼすべての携帯電話会社がiPhoneを騙したように、Lionを買収した企業がなければ、この自動保存機能が普及していないと思います。
私の意見では、バージョン管理は素晴らしいことです。保存したファイルについて、エンドユーザーがアクセスできるバージョンツリーを用意しておくと便利です。
[元に戻す]/[やり直し]ボタンを1つだけ前後に移動する方法を知っていますか？ [元に戻す]を押してから何かを変更すると、元の「やり直し」に戻すことはできません。これは大きな欠陥です。トランザクションチェーンの途中まで移動して何かを変更すると、編集内容の半分が実質的に失われます。
自動保存は優れた哲学ですが、より良い代替案であるimoは、リアルタイム保存+優れたバージョン管理です。
開発者は、安定したOSベースのバージョン管理（ハードディスクのタイムトラベル）が標準になるまで、自動保存をすべての作業に組み込む必要がありますか？もちろんです。
要するに「一貫性と標準」/慣習は強力な発見的方法です。そして、データ損失は強力な動機です。
「手動保存」だけがUXの選択肢ではありませんでした。 Psion 5 は興味深い物理的なデバイスでしたが、そのソフトウェアのUXは、当時流行しているUIへの独立した経路を取ることを選択したため、おそらくより顕著でした。
Psionの規則の1つは自動保存で、編集を破棄したい場合に備えて、「最後に戻す[開いたバージョン/明示的な保存]」を使用していました。これはスタンドアロンデバイスであるため、この新しいパラダイムを課すことができます。デバイスとして受け入れることができるユーザーは一意であり、そのデフォルトでの保存は論理的な操作形式でした。少なくとも、誤って編集内容を失うことに比べて。
これは当時流行していたデスクトップワードプロセッサ、つまり199）に対する論理的な改善でした。メモリ容量が向上した複数バージョンのストレージは、この「デフォルト保存+復帰」モデルの論理的な拡張です。
したがって、すべてのUXエンジニアが当時のデフォルトの慣習が賢明であるとは思っていませんでした。では、なぜ「手動保存」が15年以上続いたのでしょうか。慣習と一貫性。そのため、ユーザーは行動の変化に不安を感じます。また、ユーザーは自分の時間を重視するため、編集内容が確実に保存されるようにしたいと考えています。
変化したこと？明らかに、Psionの範囲とそれが生成したSymbian OSソフトウェアは、当時のWindowsおよびMac OSアプリケーションと関連するOS設計ガイドの重みに対する慣習に影響を与えるには不十分でした。新しいのはAJAX=アプリケーションです。Webアプリケーションではかなり空白のキャンバスがあり、さまざまな制約（たとえば、信頼性の低い接続）がありました。特に、GMailが主導しました。特に、これにはいくつかのバリエーションがありました自動保存機能のUI。
十分な数の人々が新しい慣習にある程度の快適さを持っていれば、主流が乗り込むことができます。
ニールセンノーマングループの 期待よりも効率を優先しない は、自動保存に関する多くの問題と、それを使用したUXの問題のいくつかを軽減する方法について明確に述べています。
手順を減らすことでユーザーの効率を高めることを目的とした機能は、ユーザーが既存のメンタルモデルや過去の経験に基づく期待に準拠していない場合、ユーザーに悪影響を与える可能性があります。
これ以外のかなり標準的なフォームには何が欠けていますか？保存ボタンはありません！システムに保存されるように変更を適用するにはどうすればよいですか？コンピュータに精通している読者は、フォームが変更されている間、フォームが変更を保存している可能性があることに気付くかもしれません[...]。ただし、ほとんどのユーザーはこれに精通していません[...]。これは、標準からの最小の偏差でさえ混乱を引き起こし、認知負荷を増加させる可能性があるという優れた例です。
[保存]ボタンを削除することで、設計者はユーザーがオートパイロットモードを終了しました。これは、タスクが計画どおりに完了できなくなったためです。 [...]このフォームに遭遇したユーザーは、ページを見て回って時間を費やして、省略された[保存]ボタンを探し、次に実行するアクションを決定するために、この新しい状況を他の同様の過去の経験に関連付ける必要があります。ユーザーはこのあまり一般的でないパターンに対処するための新しい手順を見つけるために認知的努力を払わなければならないので、ステップ数の削減は対話コストの削減にはつながりません。
[...]ユーザーはコントロールを感じたいと考えています。制御感は、システムがシステムの状態をユーザーに明確に伝え、その状態を変更するためにインターフェイスを操作する方法を明らかにした場合にのみ発生します。ユーザーは、システムの現在のステータスを継続的に認識する必要があります[...]。ユーザーにとって、見ることは信じています。システムが実行するすべてのプロセスに対して視覚的なフィードバックを表示する必要があります。非表示のコンテンツの公開から待機中の進行状況の伝達までのすべてのアクションは、ユーザーが何かが起こっていることを理解するために明確に表示する必要があります。
[保存]ボタンを削除すると、ユーザーによるインターフェースの制御が低下します。突然、ウェブサイトは、いつどのように行うかを独自に決定する自律的なエンティティになります。ユーザーに制御を戻すために、システムはシステムがそれ自体で動作していないことを示す必要がありますが、ユーザーが開始したアクションに応答しているだけです。 NextDoorの例では、バックグラウンドでのみ自動保存するのではなく、新しい設定が選択されたときに保存されたことをユーザーに伝えるために、ページに視覚的なフィードバックを表示する必要があります。