保存/キャンセル後の履歴依存ナビゲーションは良い習慣ですか？
CMSのコンテンツエディターに取り組んでいます。
ユーザーは記事のリストから開始します。
ここから、2つの異なる画面に移動できます。鉛筆ボタンは実際のコンテンツエディターに移動し、ギアボタンは公開、削除などの管理機能を備えたプロパティシート（ドキュメントメタデータ用）に移動します。
プロパティシートはそれほど興味深いものではありませんが、編集ボタンもあることに注意してください。ユーザーは記事のリストまたはプロパティシートからコンテンツエディターに移動できます。
コンテンツエディター自体は「ディストーションフリー」アプローチを採用しており、編集可能なコンテンツは画面全体を占め、唯一のインターフェースは上部のツールバーです。
このインターフェースにはまだ「保存」または「キャンセル」ボタンがありませんが、計画は右上の「元に戻す/やり直し」ボタンの横に配置することです。
問題は、「保存」ボタンまたは「キャンセル」ボタンを押すとどうなるかということです。
ユーザーは元の場所から戻ることを期待しますか？つまり、保存またはキャンセルしたときに、記事リストまたはプロパティシートに戻ることを期待しますかあなたがどこから来たのかに依存しています？
または、常に編集後に同じ場所に移動することを期待しますか？たとえば、常にプロパティシートに移動しますか？
私は両方の問題を見ることができます。
ナビゲーションが履歴に依存していて、編集ページに長い間いる場合、たとえば記事を20分間編集している場合、リストから取得したのか、プロパティから取得したのか覚えていない可能性があります。シート-これは私がそこに着いた方法によって異なりますので、私はどちらかの場所に行くことに驚かれるかもしれません、それは悪いようです。
一方、保存/キャンセル後の宛先が常に同じである場合、たとえば、常にプロパティシートである場合、プロパティシートから記事リストに戻るための余分なクリックに煩わされる可能性があります。
ボタンを追加することは実際にはオプションではありません。ボタンが多すぎるため、少なくとも4つ、「保存してリストに移動」、「キャンセルしてリストに移動」、「保存してプロパティに移動」、「キャンセルして移動」プロパティに移動します。
この質問に対する「正しい答え」はありますか？
これらのページに対するユーザーのエントリポイントであるため、コンテンツエディタとプロパティシートの両方のページが記事リストに戻るはずです。これにより、プロパティシートからコンテンツエディターページに移動する機能も削除されます。
これにより、各ページの機能separateが維持されます。記事リストページを介してコンテンツエディターとプロパティシートのページにのみ移動できるため、「キャンセル」アクションの後に記事リストページに戻るという期待は少し自然です。
プロパティシートとコンテンツエディターのページ間を移動するために追加のクリックが必要であるとの懸念を理解しました。この場合、ナビゲーションフローがより明確になること（およびユーザーにとってより直感的なエクスペリエンスが得られること）の利点は、余分なクリックよりも重要だと思います。
「正しい」アンサーは、アプリケーションを使用するユーザーのコンテキストに依存すると思いますが、私があなたの説明で理解したことから：
保存ボタン：「保存ボタン」の必要性は本当にありますか？ EvernoteやGoogleドライブなどの他のプラットフォームで見られるように、自動保存を使用し、保存するたびに上部に「ドキュメントが保存されました」というメッセージを表示する習慣が増えています。 [保存]ボタンが本当に必要な場合は、クリックしてもエディターのビューが閉じないことをお勧めします。メッセージも表示できます（ 'Document saved。'）。
キャンセルボタン：ユーザーがドキュメントの編集を終えたばかりの場合を想定しているため、「キャンセル」という用語はユーザーを混乱させる可能性があります。 「保存」をクリックすると、「キャンセル」ボタンがあります。 「キャンセル」をクリックすると、すべての作業がキャンセルされて混乱する可能性があります。 「閉じる」を使用することをお勧めします。また、「閉じる」ボタンを押すと、ユーザーがどこから来たのかによって異なる画面に移動することをお勧めします。彼がリストビューから直接来た場合は、彼をリストに戻し、プロパティから来た場合は、プロパティに戻します。
それが何らかの形で役立つことを願っています...
したがって、ユーザーが[保存]ボタンをクリックすると、単に保存するだけでなく、履歴コピーも作成されますが、「保存」ボタンにラベルを付けても、そのことはわかりません。また、キャンセル機能、履歴コピー、および[元に戻す]ボタンは少し冗長であるように見えます。保持したくないと思われる一連の変更を行った場合は、ドキュメントの元の状態に戻るまで元に戻すことができます（ここではキーボードショートカットをサポートするとよいでしょう）、または以前に保存したバージョンに戻すことができます。なので、キャンセルボタンは不要です。ただし、「閉じる」の代わりに戻るボタンや矢印を使用することもできるため、ユーザーを以前の画面に戻していたことがわかります。エディタが前の画面の上にモーダルで表示される場合、閉じることは理にかなっていますが、そうではありません。
私にとっての簡単なアプローチは、ポップアップで通知を表示して、操作が完了し、情報が保存されていることをユーザーに知らせ、記事を表示するか、リストから次の記事に移動するかを尋ねることです（オプションは異なる場合があります）。とにかく、成功メッセージを表示するので、この余分なステップに時間がかかるとは思いません。