Which one is better in our case if MDI is considered bad?

Question

We are developing a financial reporting system, which is able to display many, I mean MANY, different reports from different angles. For example, the reports for position, deal, market risk, for individual financial instrument. And they can be static (like a paper report), or real-time refreshing, or user-configurable (for example, on top of the paper report there are some controls to specify the reporting parameters). All of these reports in my opinion, are loosely related with each other, which means our user might want to open many and look at them at the same time, and jump from one to another like randomly.

Our legacy software(more than 10 years old) is done in a Multiple Document Interface (MDI) layout, and now we want to develop a new client which is using WPF. When we explored the tools we have, we discovered that WPF doesn't support MDI in its own library. Furthermore, people keep saying that MDI is considered as bad-UI practice in modern software. But I really can't think of a good alternative to it (I have to admit that I am a software developer not an UI designer).

People suggest to use multiple Single Document Interface (SDI) windows, like what MS Word looks like. But I think it has some drawbacks to our application:

1) I think multiple-SDI layout suits better in the scenario where multiple documents have exactly the same layout and functionality (like Word). But in our software, the reports are so different that if we arrange them as many top-level windows, the user wouldn't even feel that they belong to the same application.

2) our user often open more than 10, sometimes even 20 reports at the same time in our old software. I personally don't like to see the a 20 items long list to be shown when I put my mouse onto the Word icon in the task bar. Plus, they are loosely, but still, related to each other. The user might want to jump from one report to another one.

Another often-mentioned layout is tab layout like Visual Studio. I like the idea of have some items/control in some specific maybe static places, like the output and break point windows in the bottom of visual studio, and properties windows on the side. I think we can move some of our reports into such areas. But the main area, the tab area in visual studio, is still not suitable for our main reports in my opinion:

1) in visual studio the user is more likely to work on one document, when it is finished or needed, move to another one. The user can't look at different documents at the same time as what our user sometimes do.

2) the navigation in Visual Studio is still weak in my opinion. I personally like to user our software in such way that I open multiple reports and put them into different areas inside the container. So I can easily switch between them.

3) one report taking the whole display area might not be no necessary for some reports. In another word, the sizes of reports vary. But there are only few of them which can take the whole display area.

If somebody could widen my horizon, enlighten me of some other layouts which might serve better in our scenario, it would be really appreciated.

Answer 1

I've pondered this issue a few times, I hope I can contribute. All the following is purely IMHO unless otherwise noted.

I work on an application that still uses an MDI interface to present a lot of different data in a user-customizable view. For moving away from MDI, I see exactly the same problems you mention.

---

Traditional MDI (i.e. freely arranging multiple child windows inside a parent window) still beats multiple-SDI and tabbed MDI when information is strongly related and needs to be seen side-by-side, where the choice which information to compare must be left to the user.

Usability issues with traditional MDI

Arranging windows burdens the user:

[edit] The user may have some goals for size, aspect ratio or relative position of the individual MDI child windows, but ultimately, pixel-correct positioning is not something the user wants to do. Users are forced to put up with too many degrees of freedom. To achieve a reasonable display, we are basically asking the user to approximate the packing problem repeatedly. [/edit]

Unfortunately, automatic tile isn't sufficient in most scenarios, manual arrangement is tedious and often triggers neatness obsession. Re-sizing the main window (to "see more" or to "see something else, too") does not translate well to the contained windows.

Overlapping windows lead to a permanent "where's my window?" interaction: draging and clicking just to find it.

Window decor is in the way.

When having a few windows tiled, there's a lot of controls visible (close, minimize, maximize, restore, resize chevron) for each window. This adds visual complexity, distracts, and steals a lot of screen space.

Furthermore, users tend to ignore window titles. So you usually have to repeat the title of the window within the document shown.

Completely sucks on multiple monitors.
You can stretch the MDI frame window across multiple desktops, but that exacerbates the window arrangement problems as windows overlapping screen edges are a massive no-go.

Stretching the frame limits access to other application or documents. Restricting the frame to a single window crams a lot of information on a single monitor, with another one standing idly by.

Solutions and workarounds

• improve auto-arrange to match application, allow auto-arranging subsets
• magnetic edges
• provide a reasonable default position for MDI windows
• remember MDI child positioning as user or even application state
• allow to reuse window positions (e.g. through layout templates)
• handle re-sizing the parent well.
  (For our application, re-sizing child windows with the frame is appropriate, YMMV)
• show window manipulation like drag, resize, maximize only when mouse is over or a specific hot key was pressed. Also consider getting rid of the window title bar

I have no convincing idea on how to deal with multiple monitors (yet).

Design Alternatives

In my understanding the Dashboard metaphor captures this use case quite efficiently: allow the user to arrange a subset from a pool of information or gadgets.

However, it extends the dashboard metaphor by being the main work surface, rather than a gateway, and by the user defining and switching between multiple - often many - dashboards, rather than working with one.

Answer 2

Keep in mind that there is more than one way to implement a multiple document interface (MDI). First, there's the classic MFC implementation where each document was its own child window of the main frame. This was kinda clunky and window management could be a pain.

The newer form of MDI is tab based (like Visual Studio) with docking tool windows on the sides. This makes it much easier to deal with multiple documents than having a separate window for each one (Word/Excel).

Reading your description, it sounds like you could mimic Visual Studio 2012's interface and have it make a lot of sense.

A Visual Studio 2012 type interface would have the following features:

• Tabbed document area for having quick access to many reports
• User could drag reports and create multiple tabbed document areas inside the main frame (handy for viewing reports side by side)
• Tool windows that can be hidden or shown for additional functionality
• Ability to drag reports and/or tool windows outside of the main frame for viewing on multiple monitors
• Anything you drag out of the main frame can be docked together

Answer 3

DIY UIs like MDI put the burden of the layout design on the user, as @tete stated.
On the other hand, the users expect from us the IT people to provide them with well honed solutions for their needs.
IMO in this particular case there might be a host of use cases and repeated behaviors other than "anyone can do anything with any number of reports".
IT should take note of how the users use the reports and act accordingly. For example several small reports might be used together by almost anybody who used them so they can be displayed side by side in a single window (or whatever).
Also, in the 10 years since the application was developed till today, screens have changed a lot. Especially, now they are much wider and capable of displaying more data at once.
The change in the form factor is significant. It makes a tabbed UI more feasible, whera a tabs column (not a row!) can hold the reports descriptions, replacing the sub-window title bars.
Additionally, dynamically changing reports could display a changed flag in their tabs to avoid the user the burden of having to check them periodically.
If the tabs had shortcuts to select them quickly and directly, it would be even better, especially if the shortcuts are shown in tabs.
The user research I mentioned above can be done by logging in a file the usage patterns for a while, and then analyzing the data for patterns, namely which reports are watched maximized, and which sets of small reports are watched side by side, etc.
You need not be a UI designer to make an excellent UI, what you really need is to know the users. I'm a developer who made VB6 UIs that my users loved simply by watching them work.

Answer 4

If I was you, I will just make the application flexible enough to be able to support both MDI and TDI. And just let your uses decide what style they like. If you use the LinsUIWPF Suite, it will allow your app automatically support both. You can reference the following link Introduction to LinsUIWPF Suite.

Answer 5

A good example of an MDI application using web technologies is jsoncv.com (which I co-developed) - it gives a true MDI experience as you usually see in Windows applications. If your audience is used to MDI's from within a corporate environment then go for it, it's definitely worth while if you want such rich functionality rather than loosing it just because of the technology - there is no reason to these days. Even for a website like jsoncv.com, we found that we wanted to push the MDI experience to the greater community because it does provide a much nicer experience. btw, it falls back to SDI on some devices too (in case you choose to check it out on a tablet or low res monitor). Improved phone support will come in future.

Answer 6

Why your users suggested you to use SDI model? It is a sign of an un-investigated need.
MDI gets user very high ability to open documents/windows with low usability in my opinion!
It is here to cover unhandled complex app usage.
I suggest you to gather more info about current app usage by users and also double-check user needs and avoid getting user unnecessary ability to reducing complexity and improving usability.

Some notes:
User might needs a little part of a large information. User will not tries to open some large window with many waste information, if he/she gets sufficient information at right time and right place. (waste info: unnecessary information at current time/place/situation).
So try to discover real user needs at each situations (as many as you can) and think for alternate info presentation solutions.
For example, user may needs to comparing two charts. You can integrate two charts to simplify usability and reduce waste info.
User may open a doc/window and keep that open in background without need to it. It will affect usability and usage performance.
User might has multiple monitors. So MDI might not be a good option. You can let users to spread windows in other monitors.

Answer 7

I know this post is old, but the question remains relevant. My two cents would be to look at the data the user expects. From the financial world I would expect graphs and tables and not lengthy documents, except for rules and regulations.

for the first 2 I would suggest: cut uit the BS by using widgets. this way the user could organize the values that are related (current value vs historic value) side by side.

For the documents I would suggest not putting them on the dashbord but provide links to other windows that open separatly since usually users would consult them in a "question like" way (is this action allowed for this amount, if so what are the limitations and fees). This can be transformed from documents to a set of widgets later on (amount vs fees table) or even calculator controls. Or maybe even a searchable document or wiki page.