MDIが悪いと見なされている場合、私たちのケースではどちらが良いですか？
私たちは、さまざまな角度から多くの、つまり多くのさまざまなレポートを表示できる財務報告システムを開発しています。たとえば、個々の金融商品のポジション、取引、市場リスクのレポート。また、静的（紙のレポートのように）、リアルタイムの更新、またはユーザーが構成可能（たとえば、紙のレポートの上に、レポートパラメーターを指定するためのいくつかのコントロールがあります）にすることができます。私の意見では、これらのレポートはすべて互いに緩やかに関連付けられています。つまり、ユーザーは多数のレポートを開いて同時にそれらを確認し、ランダムに別のレポートにジャンプする必要があるかもしれません。
私たちのレガシーソフトウェア（10年以上前）はマルチドキュメントインターフェイス（MDI）レイアウトで実行されており、WPFを使用する新しいクライアントを開発したいと考えています。私たちが持っているツールを調べたところ、WPFは独自のライブラリでMDIをサポートしていないことを発見しました。さらに、MDIは、現代のソフトウェアでの悪いUIの実践ですが、私はそれに対する良い代替案を本当に考えることはできません（私はUIデザイナーではなくソフトウェア開発者であることを認めざるを得ません）。
MS Wordのように、複数のシングルドキュメントインターフェイス（SDI）ウィンドウを使用することをお勧めします。しかし、アプリケーションにはいくつかの欠点があると思います。
1）複数のSDIレイアウトは、複数のドキュメントのレイアウトと機能（Wordなど）がまったく同じであるシナリオに適しています。しかし、私たちのソフトウェアでは、レポートが非常に異なるため、トップレベルのウィンドウと同じ数だけ配置すると、ユーザーは同じアプリケーションに属しているとさえ感じません。
2）私たちのユーザーは、多くの場合、古いソフトウェアで同時に10を超えるレポートを開くことがあります。個人的には、タスクバーのWordアイコンの上にマウスを置くと、20項目の長いリストが表示されるのが嫌です。さらに、それらは緩やかですが、互いに関連しています。ユーザーは、あるレポートから別のレポートにジャンプしたい場合があります。
よく言われるもう1つのレイアウトは、Visual Studioのようなタブレイアウトです。 Visual Studioの下部にある出力ウィンドウとブレークポイントウィンドウ、側面にあるプロパティウィンドウなど、特定の多分静的な場所にいくつかのアイテム/コントロールを配置するというアイデアが好きです。レポートのいくつかをそのような領域に移動できると思います。しかし、メインエリア（Visual Studioのタブエリア）は、私の考えでは、メインレポートにはまだ適していません。
1）ビジュアルスタジオでは、ユーザーは1つのドキュメントで作業する可能性が高く、ドキュメントが完成または必要になったときに、別のドキュメントに移動します。ユーザーは、ユーザーが時々行っていることと同時に、異なるドキュメントを見ることができません。
2）Visual Studioのナビゲーションはまだ私の意見では弱いです。私は個人的に、複数のレポートを開いてコンテナー内の異なる領域に配置するようにソフトウェアを使用したいと思っています。だから私はそれらを簡単に切り替えることができます。
3）一部のレポートでは、表示領域全体を使用する1つのレポートが不要な場合があります。別の言葉では、レポートのサイズは異なります。ただし、表示領域全体を占有できるのはごくわずかです。
もし誰かが私の視野を広げ、私たちのシナリオでよりよく機能するかもしれない他のいくつかのレイアウトを教えてくれれば、本当にありがたいです。
この問題について何度か考えましたが、貢献できることを願っています。特に明記しない限り、以下のすべてが純粋に私見です。
MDIインターフェースを使用して、ユーザーがカスタマイズ可能なビューにさまざまなデータを表示するアプリケーションを使用しています。MDIから離れた場合も、同じ問題が発生します。
従来のMDI（つまり、親ウィンドウ内に複数の子ウィンドウを自由に配置する）は、複数のSDIに勝っており、タブ付きMDI情報が強く関連しており、表示する必要がある場合並べて表示。比較する情報の選択はユーザーに任せる必要があります。
従来のMDIの使いやすさの問題
ウィンドウの配置はユーザーに負担をかけます：
[編集]ユーザーは、個々のサイズ、アスペクト比、または相対位置にいくつかの目標を設定している可能性がありますMDI子ウィンドウですが、最終的に、ピクセルの正しい配置はユーザーのものではありませんwantsを実行します。ユーザーは自由度が多すぎて我慢しなければなりません。合理的な表示を実現するために、基本的に packing problem を繰り返し近似するようユーザーに求めています。 [/編集]
残念ながら、ほとんどのシナリオでは自動タイルでは不十分で、手動での配置は面倒で、しばしばきちんとした執着を引き起こします。メインウィンドウのサイズを変更しても（「もっと見る」または「他のものも見る」ため）、含まれているウィンドウにうまく変換されません。
ウィンドウが重なると、「ウィンドウはどこですか？」相互作用：ドラッグしてクリックするだけで、それを見つけます。
ウィンドウの装飾が邪魔です。
いくつかのウィンドウを並べて表示すると、各ウィンドウに多数のコントロールが表示されます（閉じる、最小化、最大化、復元、サイズ変更）。これにより、視覚的な複雑さが増し、多くの画面スペースが邪魔され、盗まれます。
さらに、ユーザーはウィンドウタイトルを無視する傾向があります。したがって、通常は、表示されているドキュメント内でウィンドウのタイトルを繰り返す必要があります。
複数のモニターを完全に吸います。
MDIフレームウィンドウを複数のデスクトップにまたがって拡大することができますが、ウィンドウの画面の端と重なるウィンドウは大規模な移動ができないため、ウィンドウの配置の問題が悪化します。
フレームをストレッチすると、他のアプリケーションやドキュメントへのアクセスが制限されます。フレームを単一のウィンドウに制限すると、単一のモニターに多くの情報が詰め込まれ、別のモニターが待機します。
解決策と回避策
- アプリケーションに合わせて自動配置を改善し、サブセットを自動配置できるようにします
- 磁気エッジ
- MDIウィンドウに適切なデフォルト位置を提供する
- 覚えているMDIユーザーまたはアプリケーションの状態としての子の位置付け
- ウィンドウの位置を再利用できるようにする（例：レイアウトテンプレートを使用）
- 親のサイズ変更を適切に処理します。
（このアプリケーションでは、フレームを使用して子ウィンドウのサイズを変更するのが適切です、YMMV） - ドラッグ、サイズ変更、最大化などのウィンドウ操作を、マウスオーバー時または特定のホットキーが押されたときにのみ最大化するように表示します。ウィンドウのタイトルバーを取り除くことも検討してください
（まだ）複数のモニターをどのように扱うかについて、私には説得力のある考えがありません。
代替設計
私の理解では、Dashboardメタファーはこのユースケースを非常に効率的にキャプチャします。ユーザーが情報またはガジェットのプールからサブセットを配置できるようにします。
ただし、ゲートウェイではなくメインの作業面になり、ユーザーが1つで作業するのではなく、複数の（多くの場合は複数の）ダッシュボードを定義して切り替えることで、ダッシュボードのメタファーを拡張します。
マルチドキュメントインターフェイス（MDI）を実装する方法は複数あることに注意してください。まず、各ドキュメントがメインフレームの独自の子ウィンドウである、クラシックなMFC実装があります。これはちょっと不格好で、ウィンドウ管理が面倒なこともありました。
MDIの新しい形式は、（Visual Studioのような）タブベースであり、側面にドッキングツールウィンドウがあります。これにより、ドキュメントごとに個別のウィンドウ（Word/Excel）。
説明を読むと、Visual Studio 2012のインターフェイスを模倣して、それが非常に理にかなっているように思えます。
Visual Studio 2012タイプのインターフェイスには、次の機能があります。
- 多くのレポートにすばやくアクセスできるタブ付きドキュメント領域
- ユーザーはレポートをドラッグして、メインフレーム内に複数のタブ付きドキュメント領域を作成できます（レポートを並べて表示するのに便利です）
- 追加機能のために非表示または表示できるツールウィンドウ
- レポートやツールウィンドウをメインフレームの外にドラッグして、複数のモニターで表示する機能
- メインフレームからドラッグしたものはすべてドッキングできます
MDIのようなDIY UIは、@ teteが述べたように、レイアウト設計の負担をユーザーに課します。
一方、ユーザーは、IT担当者がニーズに合わせて磨かれたソリューションを提供することを期待しています。
この特定のケースでのIMOには、「誰でも任意の数のレポートで何でもできる」以外の多数のユースケースと繰り返しの動作がある場合があります。
ITは、ユーザーがレポートを使用する方法に注意し、それに応じて行動する必要があります。たとえば、いくつかの小さなレポートは、それらを使用したほとんどすべての人が一緒に使用して、1つのウィンドウ（またはその他）に並べて表示することができます。
また、アプリケーションの開発から今日までの10年間で、画面は大きく変化しました。特に、現在ははるかに広く、一度により多くのデータを表示できます。
フォームファクタの変更は重要です。これにより、タブ付きのUIがより実現可能になります。タブ列（行ではない！）がレポートの説明を保持できる場合、サブウィンドウのタイトルバーが置き換えられます。
さらに、動的に変化するレポートでは、タブにchangedフラグを表示して、ユーザーが定期的にチェックする必要がある負担を回避できます。
タブにショートカットを直接直接選択する場合、特にショートカットがタブに表示されている場合はさらに便利です。
上記のユーザー調査は、使用パターンをしばらくの間ファイルにログインし、パターンのデータを分析することで実行できます。そばなど.
優れたUIを作成するためにUIデザイナーである必要はありません。本当に必要なのは、ユーザーを知ることです。私は、ユーザーが好きなVB6 UIを作成して、その動作を見るだけで作成した開発者です。
私があなたなら、MDIとTDIの両方をサポートできるように、アプリケーションを十分に柔軟にします。そして、あなたの用途に彼らが好きなスタイルを決定させるだけです。LinsUIWPFスイートを使用する場合、アプリで両方を自動的にサポートできるようになります。次のリンクを参照してください LinsUIWPF Suiteの概要 。
MDIアプリケーションの良い例は、jsoncv.com（私が共同開発したもの）です。これは、通常のMDIエクスペリエンスを提供しますWindowsアプリケーションの場合。オーディエンスが企業環境内からMDIに慣れている場合は、それを試してみてください。テクノロジーだけでなく、そのような豊富な機能が必要な場合は、間違いなく価値があります。最近では理由がありません。 jsoncv.comのようなWebサイトの場合、MDIエクスペリエンスをより優れたエクスペリエンスを提供するため、より大きなコミュニティにプッシュしたいと考えました。ところで、一部のデバイスではSDIにフォールバックします（タブレットまたは低解像度モニターでチェックアウトすることを選択した場合に備えて）改良された電話サポートが将来提供される予定です。
ユーザーがSDIモデルの使用を提案したのはなぜですか？これは、調査されていないニーズの兆候です。
MDIはユーザーにドキュメント/ウィンドウを開く非常に高い能力を提供します使いやすさは低いです私の意見では！
ここでは、未処理の複雑なアプリの使用について説明します。
ユーザーによる現在のアプリの使用状況に関する詳細情報を収集し、ユーザーのニーズを再確認して、ユーザーの不必要な複雑さを軽減し、使いやすさを向上させることは避けてください。
いくつかのメモ：
ユーザーは大量の情報の一部を必要とする場合があります。ユーザーは、適切なタイミングで適切な場所で十分な情報を取得できれば、多数の無駄な情報がある大きなウィンドウを開こうとはしません。 （廃棄物情報：現在の時間/場所/状況での不要な情報）。
そのため、（できるだけ多くの）各状況で実際のユーザーのニーズを発見し、代替の情報プレゼンテーションソリューションを検討してください。
たとえば、ユーザーは2つのチャートを比較する必要がある場合があります。 2つのグラフを統合して、使いやすさを簡素化し、無駄な情報を減らすことができます。
ユーザーはドキュメント/ウィンドウを開いて、それを必要とせずにバックグラウンドで開いたままにすることができます。使いやすさと使用パフォーマンスに影響します。
ユーザーが複数のモニターを持っている可能性があります。したがって、MDIは適切なオプションではない可能性があります。ユーザーが他のモニターでウィンドウを広げることを許可できます。