クライアントの1つのために、WindowsアプリケーションをWebアプリケーションに移植することを検討しています。 WindowsアプリケーションはMDIアプリ(複数のフォームを一度に開く)ですが、Webアプリはワークフローではるかに「線形」になります。つまり、一度に1つのウィンドウを開く(ほとんどの場合)部)。
私は二つのことを考えていると思います。
最初に、混乱を解消するための用語の問題:「マルチドキュメントインターフェース」(MDI)は、ユーザーが複数のドキュメントウィンドウ(それぞれがフォームである場合があります)を表示できる単一の「コンテナー」ウィンドウを持つアプリケーションの設計です。これは具体的には、Microsoft Officeの初期バージョンのようなさまざまな生産性アプリのためにMicrosoftが推進した設計に言及しています。 MDI=の代わりに、コンテナウィンドウがない単一のドキュメントインターフェース(SDI)を使用しました。各ドキュメントには独自のトップレベルウィンドウがあります。これは、各ドキュメントも個別のプロセスであり、したがって、複数のドキュメントのSDIはMDIよりも多くのコンピューターリソースを必要とします。ただし、SDIはそのシンプルさのおかげで使いやすさが向上しているため、今日の強力なコンピューターでは、MDIは廃止され、ほとんど放棄されています。MSOffice 2002年に部分的に撤退しました。
「MDI」のメリットについて話し合うつもりはないと思います。
あなたの質問に答えるために、私は「履歴ナビゲーション」と「ウィンドウナビゲーション」を区別することを好みます。ここで、前者はWebスタイルで、後者はデスクトップスタイル。 両方は、単一のアプリケーションで複数の「オープン」フォームをサポートします。違いは、ユーザーが開いているフォーム間を移動する方法です。履歴ナビゲーションには、フォーム(または他のページ)の暗黙的な履歴リストがあり、前後に「移動」できます。 Windowsナビゲーションでは、各フォームが個別のウィンドウに表示されるため、ユーザーは必要なフォームの開かれたウィンドウをクリックするだけで(ナビゲートしたい場合は)ナビゲートします。
どちらが良いですか?履歴ナビゲーションは、ユーザーが多くのページ/フォームで表面的に作業し、コンテンツをスキミングし、ほとんどを無視して、たまにしか提供しない場合に最適に機能しますナビゲーション以外の入力。ウィンドウナビゲーションは、ユーザーがいくつかのフォームで集中的に作業し、実質的な入力(30秒以上の作業など)を提供する場合に最適に機能します。履歴ナビゲーションでは、フォームは単に無視されるだけで効果的に閉じます。これは、表面的な作業では問題ありませんが、保存されていない多くの作業を追跡できない場合は、実際の抵抗になります。
フォームタイプの作業の場合、ウィンドウナビゲーションには履歴ナビゲーションに比べて次の利点があります。
最近使用したページの、よりシンプルで高速、そして視覚的なナビゲーション。必要なページを表示してクリックします。何回も戻るまたは進むことはありません。精神的な追跡履歴はありません。
「ページング」は、同じウィンドウに複数のデータベースレコードを表示するなど、他の目的に使用できます。
終了またはログアウトしても、明確にアクセスできるページがあります。履歴ナビゲーションでログアウトしても、ユーザーは履歴チェーンのページに戻ることができますが、これは少なくとも混乱を招きます。
ユーザーが別のページに移動しても、入力は保持されます。ユーザーが別のウィンドウをクリックしてからフォーカスを元のウィンドウに戻したからといって、1つのウィンドウのフォームをクリアすべきではないことは明らかです。履歴ナビゲーションは、ユーザーがフォームから離れて戻ったときにフォームをクリアします。これは通常、間違った方法ですが、正しい方法である場合もあります。実際には、フォームを適切に処理する方法はありません。
ウィンドウナビゲーションアプリが既にユーザーに対して十分に機能していると仮定して、履歴ナビゲーションアプリに切り替えようとしても、それを台無しにしないでください。主な課題は、ユーザーが新しいウィンドウのオープンをブロックまたはクローズする「ポップアップ」として扱わないようにすることです。もう1つの問題は、ユーザーのコンピューターの専門知識です。多くのローエンドユーザーは、複数のウィンドウを処理する方法を知りません。それらはすべてのウィンドウを最大化して実行し、タスクバーを認識していません。ただし、これらの同じユーザーは、ブラウザの戻るボタンの使用方法を知っています。
ページをめくる に、履歴ナビゲーションとウィンドウナビゲーションの詳細があります。また、WindowsナビゲーションWebアプリケーションの適切な設計の詳細も含まれています。
MDIはコンピュータリソースが不足していた時代に発明されたものであり、異なる実行可能ファイルを実行するのではなく、プログラムを異なるドキュメントを処理できるように適合させる方が有益でした。
これは 記事 が長所と短所、そしていくつかの歴史を上手にまとめたものです。
MDIプログラムでは、ほとんどの場合、一番上にあるのは1つのフォームだけです。したがって、実際には、ユーザーは一度に1つずつ作業しています。いくつかの追加機能があります。
これらの利点は、Webの状況でも簡単に処理できます。
要するに、私はMDI Webアプリケーションのインターフェースを模倣しようとはしません。
注:本当にMDIインターフェースを模倣したい場合は、たとえば ExtJS など、いくつかの優れたソリューションが存在しますが、個人的にはお勧めしません。
複数のドキュメントインターフェイスは、複数のドキュメントを同時に編集できるアプリケーションに適しています。ユーザーが一度に1つだけではなく、2つ以上のドキュメントを同時に表示/編集できるようにすると、多くの場合有益です。同時に複数の物件を閲覧したり、別の物件の詳細を閉じなくても物件を閲覧したりできる不動産業者を想像してみてください。これにより、机の上の紙での作業方法に似たドキュメント管理のアプローチが可能になります。
Webアプリケーションでは、すべてのコンテンツを1ページだけに保持したい場合は、ダイアログスタイルのドキュメントを提供できます。または、各ウィンドウにドキュメントを表示して新しいウィンドウを開くことができます。アプリケーションを開くと、それらのウィンドウの制御が失われます。別の方法として、アコーディオンコントロールのようなものを提供して、1ページですべてのドキュメントをすばやく開いたり閉じたりすることができます。テクニックの選択は、ドキュメントのサイズと、ドキュメントが表示または閉じられた(削除された)ときに必要なコントロールに大きく左右されると思います。
現在、同様の問題を検討しています。私たちのアプリケーションはシンクライアントアプリケーションです。ほとんどの場合、これは必ずしもユーザーの焦点とは限りません(主要なツールとして別のアプリケーションが使用されている間、ステータスと機能を提供します)。
ユーザーに2つのビューを提供できるように、アプリケーションの構築を検討しています。単一ウィンドウビューと複数ウィンドウビュー。後者の場合、ユーザーは、アプリケーションの各部分のサイズを調整して、必要に応じて配置できます。
より伝統的なWebアプリケーションでは、同じロジックが役立つ場合があります。参照テーブル/グラフまたはステータスペインは、画面の周りに構造化できる便利なポップアップである場合があります。これは、アプリケーションが非常に複雑で、ユーザーがビューを制御したい場合にも機能します。ただし、この場合は、ある程度のユーザー制御構成を持つ、より優れた、よりスマートな画面レイアウトを検討することを検討する傾向があります。複数のウィンドウは、複数のアプリケーションパラダイムに影響を与えるため、煩わしくなります。たとえば、ウィンドウの下で、アプリケーション間でalt-tabキーを押しても、アプリケーションである複数のストップポイントが生成されません。タスクバーにも同じ影響があります。