履歴を元に戻す-なぜ制限するのですか？
ほとんどのアプリケーションで「元に戻す」履歴機能がかなり制限されているのはなぜですか？
グレーアウトされた[元に戻す]ボタンをクリックするためにいくつかの変更（フォトショップなど）を元に戻す必要があった（技術的には私の過失を認めた）複数の場合に遭遇しました-履歴はありません。私はあなたについては知りませんが、この制限のために多くの作業が失われる可能性があるため、ユーザーエクスペリエンスがひどいものになります。
アプリケーションが少なくとも完全なセッション履歴を保持できない理由はありますか？確かに、変更を保存するために必要なのは一時ファイルだけであり、一時ファイルはユーザーの設定（最大サイズなど）に合わせて構成できますか？
私がこれを言ったときに私を信じてください元に戻す/やり直しは、大きなサイズのアプリケーションでの最大の実装、テスト、およびメンテナンスの頭痛の1つです。
確かに、ユーザーをリラックスさせ、心配せずに環境をテストおよび調査できるように、元に戻す/やり直すことができるのは素晴らしいことです。ただし、元に戻す履歴の有用性は、最初の元に戻すとすぐに低下し始めます。ゆっくり、気に-しかし確かに。
doは完全な取り消し履歴を提供するものに対する完全な称賛ですが、サポートフレームを使用した十分に計画され、適切に実行されたアプローチの結果です1日目から実装され、すべての機能が中心となる作業。
そのフレームワークが最初に導入されない場合、後でそれをボルトで固定することは大きな課題であり、それにはまり込むのは簡単です。
問題は次のとおりです。
- anyで可能な元に戻す/やり直しのテストが急速にエスカレートする複雑さanyanyサイズの可能な変更のシーケンス。
- 各手順を元に戻した後のシステムの状態が、最初に行われる前と同じであることを確認します。次の元に戻す、または次のやり直しの準備
- 取り消し可能なアクションとは何かを正しく検討する
さらに、システムが状態を変更し、やり直しが有効でない可能性があるため、一連のアクションを取り消してから別の変更を行うと、元に戻したすべての手順をやり直すことはできません。
長い元に戻す/やり直し履歴の一般的な使用方法の1つは、戻ってそれがどのようになっていたかを調べ、次に再び進むことです。
10ステップ以上元に戻せないことの煩わしさは、50ステップを元に戻し、キーボードボタンを誤って押してやり直しの履歴を破棄するので、すべての作業をやり直すことができないという煩わしさはないでしょう。ただやった。私は、多くの手順で何かを元に戻すと非常に緊張し、フォールバックとして最初に保存する傾向があり、おそらくそこにレッスンがあります。頻繁に保存してバージョンを保存することです。
完全な取り消し履歴が非常に望ましい望ましいことに完全に同意します-それはただです単純ではありません。そのため、厳しい時間と予算の制約が発生すると、機能リストに表示されなくなります。
この問題には、技術的要因とビジネス的要因の両方があります。
技術的には、元に戻す/やり直しは、かなり複雑なアプリケーションに実装するのが非常に複雑です。アプリの複雑さを処理する必要があるだけでなく、時間の経過に伴う状態の追跡とその状態をリセットする機能も必要です。一部のアプリケーションスペース、特にグラフィック編集では、真の取り消しは技術的に実行できません。各アクションの後でスナップショットを取得して、以前のスナップショットに戻ることができます。メモ帳に文字を挿入すると、元に戻す操作でその文字を比較的簡単に削除できます。グラフィカルイメージに数学変換を適用すると、逆の数学プロセスを再生して元のイメージを取得できるとは限りません。データと状態の両方のスナップショットを無制限に保存すると、リソースが制限されます。
ビジネスの観点から、無制限の取り消しを実装するために（例として）100人日を適用できる場合、または3つの新しい要求されたユーザー機能を提供するために100人日を適用できる場合、 3つの新機能。これは近視眼的かもしれませんが、私たちは確かに以前に近視眼的なビジネス上の決定を見てきました。
本 Design Patterns は、元に戻す/やり直し機能の実装方法の概要を示しています（ コマンドパターン を参照）。これは洗練されたデザインであり、テストも簡単で、無制限の取り消しを行っても問題にはなりません。ただし、パターンを中心にシステム全体を設計するという犠牲を払っており、複雑なデータモデルでは元に戻す/やり直しが非常に困難になる可能性があるように見えます。
ただし、関連するすべてのアプリケーションの状態を各リビジョンポイントに格納するだけで、設計と実装が簡単になります。後の開発段階で、それほど手間をかけずにアプリケーションに追加することもできます。ただし、このより簡単な戦略はメモリを犠牲にして行われ、おそらく、元に戻す/やり直しの数を制限して管理することになります。 ...したがって、「制限された「元に戻す」履歴機能」。
私は、例えば、 Googleドキュメントのオファー。ドキュメントの異なるバージョン間をジャンプして、いずれかのバージョンに戻すことができます。私の意見では、これは多くの場合より有用なアプローチですが、すべての種類のアプリケーションが変更の完全な履歴を保持することは合理的ではないかもしれません。
あなたのRAMは制限されているので:-)
PS-今日8 GBのRAM=があることはわかっていますが、Adobe Photoshopや3Dソフトウェアなどのアプリケーションを使用している場合は、大幅な変更があると多くの情報が保存されます。これは非常に大きなリソースを消費する可能性があります。
複雑なアプリケーションを適切に元に戻すことは、後から考えると設計が難しく、多くのアプリケーションでは、時間（つまり、合理的なUIの遅延）またはスペース（つまり、ディスクまたはメモリのストレージ使用量が多すぎる）で効率的に実装することは不可能です。ビデオ編集者が思い浮かびます。しかし、多くのアプリケーションでは、メモリ内のドキュメントの大部分またはすべてを編集のたびに保存する必要があり、それは非常にコストがかかります。変更を保存することは、分野横断的な問題であるため、多くの場合非常に困難です。アプリケーションの状態に対するすべての変更は、取り消し可能であるかメモであるかについて分類する必要があり、（取り消しを実行するために）逆にする必要があります。
テキスト編集に適切な元に戻す機能が不足していることにうんざりして、独自のメモ帳を作成しました。これにより、基になるテキストファイルと共に編集ログ全体が実際に保存されます。そうすることで、元に戻す/やり直しがアプリケーションのインスタンス間で持続します。 「50ステップを元に戻し、次に新しいアクションで誤ってやり直し履歴を失う」という問題全体を回避するために、元に戻すログは厳密に累積されます。fooから始めて元に戻し、それをバーに置き換えると、3つのバージョン（foo、空白）が保存されます。 、およびバーなので、バージョンを失うことはありません。
取り消しを制限するUXの理由はありません。元に戻す操作が制限される理由は、ハードウェアとソフトウェアの制限によるものです（これは過去よりも今日よりも大きかった）。
開発者の能力不足を除けば、絶対に正当な理由はありません。優れたソフトウェアは、アクションをデータとそのプレゼンテーションから分離する設計原則に基づいて構築されているため、通常、元に戻す/やり直しの実装がしっかりしています。私はこれを自分で行ったので、ロジャーの答えに同意する必要があります。アプリケーションが最初からやり直しを念頭に置いて設計されている場合、テストするのはそれほど難しくありません。
使いやすさの点では、制限されるべきではありませんが、よく指摘されているように、簡単ではありません。私の経験では Notepad ++ には優れた取り消し機能があります。 Notepad ++のベースとなっている Scintilla コンポーネントの一部だと思います。そのすべてがオープンソースなので、実装方法を理解できる可能性があります。
MS Word、OneNote、およびOutlook 2010は、特定の条件下で、ほとんどの人が理解するよりも制限された取り消し履歴を持っています。
これを試してください：新しいWordドキュメントを開始し、1行または2行のテキストを入力し、次にBackspaceキーを押したままにして、最後のいくつかの単語を削除します。 元に戻すまたはCtrl-Z ...を押すと、そのバックスペーステキストが返されます。これだけでなく、ほとんどのテキストが失われていることがわかります。入力しました！
ここでの教訓は、元に戻すは困難であり、適切なテスト戦略が必要であるということです。大きな男でさえ、これはひどく間違っている可能性があります。