Googleの「保存しない」アプローチの背後にある根拠は何ですか？
何よりも、これはGoogleだけでなく、いくつかのサイトで目にしていることですが、Googleから始まったと思います。これは明らかに最もよく知られているケースです。 Googleのドキュメントではかなり議論の余地があるいくつかのUXの側面がありますが、私はこれが最も際立っているものだと思います：ドキュメントを編集すると、自動的に保存され、Saveオプションは存在しません。
いくつかの理由は想像できますが、アフォーダンスの欠如は本当に不安です。たとえば、多くのクライアントからメールで、ドキュメントが保存されているかどうか、また変更内容が表示されるかどうかわからないため、ドキュメントを編集したことがわかります。
それで、なぜこれがなぜか知っていますか？このアプローチの背後にある理論的根拠を説明する公開されているドキュメントはありますか？
保存は副産物です
Saveは、初期のハードウェアおよびソフトウェア設計の副産物です。現実の世界では、これに相当するものはありません。
考慮事項：鉛筆を使って紙にマークを付ける場合、そのマークを永続的にするために追加の手順は必要ありません。
つまり、保存する必要はありません。紙はどこかに保管して後で見つけたり、コピーして共有したりする必要があるかもしれませんが、それらは紙に永久的なマークを付けることとは別のタスクです。
昔ながらのSaveは保存以上のものになりました。次のようなタスクと組み合わされました。
- ファイルを配置する場所を決定します。
- 認識できるようにファイルに名前を付けます。
- 共有を念頭に置いて、ファイル形式を選択します。
- Save asを使用して、おそらくバックアップとしてコピーを作成することを選択します。
- より高速なハードウェアパフォーマンスを考慮して、ファイル形式を選択します。
- ソフトウェアでファイルを再フォーマットしてファイルの欠陥を「修正」することを目的として、ファイルフォーマットを変更します。
- もっと...？
保存しないアプローチは、現実の世界で何が起こるかを反映しています。鉛筆マークは、追加の手順なしで永続的です。また、保存しないアプローチでは、Saveへの学習を除いて、学習は必要ありません。
- 私のものはデフォルトの場所に行き着きます。
- 私のものは、明示的なタスクとして（私が作成することを選択した）フォルダーに移動できます。
- 私のものは別のタスクとして名前を変更できます。
- 私のものは自動的に共有することも、明示的なタスクとして手動で共有することもできます。
- 私のものは、他のユーザーが同時に共有、読み取り、変更できるため、コピーの必要がなくなります。
- 私のものは、明示的なタスクとして変換またはエクスポートできます。
- 私のものはそれ自体で変更を追跡するので、以前のバージョンにロールバックできます。
- もっと...？
グーグルと他の人々はこのパラダイムに挑戦する勇気ある一歩を踏み出した。ユーザーが本当に必要なときにSaveをクリックするようにするバックアップ、共有、export、move、またはidentifyのものは、ユーザーがソフトウェアに適応することを要求し、ユーザーの目標やユーザーのコンテンツではなくソフトウェアに焦点を当てます。
最初に来たのは技術か製品戦略か？
テクノロジーによってSaaSおよび「クラウド内のデータ」が可能になりました。しかし、それに伴うノーセーブシフトは起こりませんでした理由エンジニアリングの決定。代わりに、エンジニアリングの決定発生したの理由製品管理戦略—ソフトウェアと（自分の）コンテンツを提供することで市場シェアを獲得する必要なところすべて。この利便性は「生産同様に、複数のユーザーが同じドキュメントをリモートで編集できるようにすることは（@Rayraegahの返信で指摘されているように）、「時間と場所の生成」の別の形式です。
さておき。時間と場所の生産は経営のコンセプトです。これは、次のように簡単に説明できます。スーパーマーケットは、午後6時に閉店するまで、アイテムを1ドルで販売します。徹夜のコーナーショップでは、同じ商品を午前2時でも2ドルで販売しています。便利さも増しているので、同じアイテムの時間と場所にもっとお金を払うこともあるでしょう。角の店はあなたのために「時間と場所」を作り出しました。
Always-Onソフトウェアとデータが製品のビジョンです。保存しないパラダイム—技術的な解決法—従わなければなりません接続中断の問題を解決するために、Always-Onが一時的にオフになっているその間の瞬間。
どう思いますか？
JeromeRが回答したように、Saveパラダイムは初期のハードウェアソフトウェア設計の副産物です。簡単にするために、2種類のメモリについてのみ説明します。 「保存」とは、一時メモリ（RAM）から永続メモリ（ハードディスク、フラッシュROMなど）に情報を移動することを意味します。一時メモリ（RAM）は、電源が入っている間のみ情報を保持できます。永久メモリは、電源を切っても情報を保持できます。さらに、一時メモリは、コンピュータがすべての処理を行う場所です。したがって、ドキュメントで作業しているときは、すべてが一時メモリ（RAM）に保持されます。ほとんどのコンピュータでは、作業を保存しないと、コンピュータの電源を切るとすぐに作業が失われます。
このパラダイムは、PDAや携帯電話によって変化し始めました。セーブなしパラダイムの初期の採用者の一部はPalmでした（Palm Pilotを覚えていますか？）。このデバイスは、別のアプリケーションに切り替えた直後に作業を保存するために使用されていました。そのため、（ほとんどの場合）明示的なSaveコマンドはありませんでした。
そしてSaaS（Software as a Service））の登場により、一部の企業は「できるだけ早く保存」を使用してインターネット接続が失われたときにユーザーのデータが失われるのを回避し始めました。 Blogspot（現在はBloggerとして知られています）で、このアプローチの最初の詳細を見ました。
同様のパラダイムは、初期のMP3音楽プレーヤーの再生/一時停止/停止機能です。最近では、ストップ機能を使用することはまれですが、初期の音楽プレーヤーでは常に存在していました。コンピューターベースのMP3プレーヤーで曲を再生するには、MP3ファイルを開いて、ファイルの先頭から読み取りを開始する必要がありました。停止機能を選択した場合は、ファイルを閉じて、曲が中断したところを忘れることを意味しました。したがって、再生機能をもう一度選択すると、最初から開始されます。中断したところから続行する唯一の方法は、一時停止機能を選択してから再生機能を選択することでした。これはテーププレーヤーとは異なりますが、ビニールレコードプレーヤーに似ています。しかし、それは問題ではありませんでした。根本的な理由は、ファイルのオープンとクローズでした。一時停止機能が必要な場合は、曲を一時停止するときに中断した場所をメモしておく必要があります。
再生/一時停止/停止機能の起源は、テーププレーヤーからきています。テーププレーヤーの一時停止機能は、主に録音中に使用され、録音ボタンを押してから実際に録音を開始するまでの時間を最小限に抑えました。一時停止ボタンを使用しない場合、これは1秒近くでした。再生中に一時停止ボタンを使用することもできますが、一時停止ボタンを使用するとデバイスが動作し続け、ほとんどの人にとって快適ではないエネルギーを使用したため、再生/停止のみを使用した以外は、再生停止の組み合わせに大きな違いはありませんでした。同じ機能が社会的慣性の理由でCDプレーヤーに継承されました（なぜ、理解されたインターフェースを変更するのですか？）。 MP3プレーヤーがコンピューターとそのスタンドアロンバージョンに登場したとき、息子は同じol '同じol'インターフェイスを使い続けました。しかし、ソリッドステートのMP3プレーヤーでは、Stop関数を使用する意味がなくなりました。ユーザーの観点からは、「音楽を再生する」「音楽を再生しない」だけが本当に必要です。私がこれを最初に見たMP3プレーヤーは、卵の形をした小型のSamsungプレーヤーで、その直後にiPodで再生されました。
これらのことを後から見ると簡単ですが、より良い解決策を誰も考えていない場合は、はるかに困難になります。そして、より良い解決策が存在する場合でも、社会の惰性と戦うことはさらに困難です。
ちなみに、以前はGoogleドキュメントに保存ボタンがありました： http://googleappsupdates.blogspot.com/2010/02/new-saving-buttons-in-google-docs-and.html ただし、 、Googleドライブから削除されました。
彼らがそれを削除した理由を述べているオンラインは何も見つからないので、推測することしかできません。 Googleはエンジニアリング中心の組織であることを考えると、この変化はエンジニアリングの改善後にもたらされたと思います。私は彼らが自動保存のプロセスを十分高速にして、自動保存の間に目立ったギャップを設ける必要がなくなったと想像しています。これは事実上瞬時です。
もう1つ注意すべき点は、Googleドライブ上のドキュメントをライブで共有して編集できることです。複数のユーザーがリアルタイムでドキュメントを編集している場合、それが機能するためには、サーバーへの同期をほぼ継続的に自動保存して、全員への変更を複製する必要があります。自分だけが閲覧できるドキュメントと複数のユーザーと共有しているドキュメントとの一貫性を保つために、すべてのユーザーに対して自動保存をオンにすることを決定している場合があります。
それはエンジニアリングの決定です
これは features のいくつかを簡素化して補完します
- リアルタイムのコラボレーション
- オフライン編集
- 改訂履歴
- クラウドストレージ
...ユーザーがコンテンツの作成/編集のみに集中できるようにする一方で、テクノロジーにより貴重なコンテンツが常に保持されるようにします。
あなたがコンテンツ ドキュメントを編集 は、サーバーと他の共同編集者に（リアルタイムで）ストリーミングされます。すべてのキーストロークがすべての共同編集者から外出先で記録されるため、ここでの保存ボタンは意味がありません。
デバイスが再びオンラインになったときにコンテンツがローカルキャッシュにストリーミングされ、クラウドストレージにアップロードされることを除いて、オフラインになるときも同じ原則が適用されます。その間、共同編集者にドキュメントの編集を依頼した場合、そのバージョン管理システムを使用すると、競合を簡単に解決できます。
ウィキペディアから、
自動保存は、開いているドキュメントを自動的に保存する多くのコンピューターアプリケーションまたはプログラムの機能であり、クラッシュまたはフリーズした場合のデータ損失のリスクまたは影響を軽減するのに役立ちます。 自動保存は通常、所定の間隔で、または複雑な編集タスクが開始される前に行われます。
私は、Googleドキュメントの機能を説明するために自動保存という用語を使用しません。基本的に自動保存と同じですが、内部ではデータの自動保存の後継です保存または正確に配置-すべてのキーストロークと操作のためにストレージ領域に「ストリーミング」されます。さらに、あなたとあなたの共同編集者のカーソルがどこにあるか、あなたがハイライトしたものをマークするために、さらに一歩進んでいます。ドキュメントを編集するとき、画面を見る（ただしプライバシーを含む）と考えてください。
簡単に言うと、自動保存でデータを失う可能性がありますが、ストリーミングでは失われません。
答えを編集して、必要に応じてこの背後にあるエンジニアリングの詳細を追加できますが、@ JeromeRの応答はこれらの概念を素人または技術者でない人に説明するのに十分です