Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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 loosed 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 SW (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 SW. But I really can't think of a good alternative to it (I have to admit that I am a SW 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 SW, 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 SW. 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 breakpoint windows in the bottom of VS, 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 VS, is still not suitable for our main reports in my opinion:

1) in VS 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 VS is still weak in my opinion. I personally like to user our SW 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.

share|improve this question
3  
TALOIAAITQ (There Are Lots Of Initialisms And Acronyms In This Question) –  JonW Sep 23 '13 at 9:52
    
@JonW : sorry about that. I just searched some pages and they used them. MDI: = Multiple Document Interface. SDI = Single Document Interface. I don't see other ones which are hard to figure out for a software/ui developer –  tete Sep 23 '13 at 10:12
1  
Are you sure that "people" think dat MDI is bad? I mean: the browser is a very frequently used application, and all modern browsers are very much MDI applications... –  André Sep 23 '13 at 10:52
    
@André when I say MDI, I am talking about (like many others) the freely-docking-inside-a-container MDI layout, like Access and Word before Office2002. Like I mentioned the tab layout is indeed recommended by many people, but I feel that it has some limitations in our scenario. Mainly because we might want to see multiple reports at the same time and also single report taking up the whole area is unnecessary –  tete Sep 23 '13 at 11:05
    
@André: yes, it's common, and with reason, see my reply below. Googling for "MDI bad" leads to a lot of "can't be that bad" discussions. FWIW, I'd agree that most applications are better off not using MDI. –  peterchen Sep 23 '13 at 11:05
show 2 more comments

4 Answers 4

up vote 4 down vote accepted

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 acheive 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. Resizing 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 singel 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 resizing the parent well.
    (For our application, resizing 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.

share|improve this answer
    
Thanks for your answer. You definitely have more understandings on this issue than me. I'll read your answer carefully –  tete Sep 23 '13 at 11:26
    
I disagree with your point of "Arranging windows burdens the user". Arranging multiple Word windows is WAY more difficult than dealing with multiple tabs in Visual Studio. –  17 of 26 Sep 23 '13 at 14:26
    
@17of26 I think peterchen refers to the fact that in the freely-docking MDI, the user needs to arrange the windows arbitrarily by himself. In tab-layout since it is limited to only display one doc the burden is then alleviated. While in mulitple-SDI app, the user basically doesn't need to (and in fact can't) keep multiple-document working together in order. So basically one solution is simpler since it is limiting and the other one is simpler since we don't have the requirement. And I do agree with you that arranging multiple Word is difficult. –  tete Sep 23 '13 at 14:49
    
@17of26: Isn't that what I'm saying? Not sure if I understand you correctly - anyway, I elaborated that part a bit. –  peterchen Sep 23 '13 at 14:50
    
Nevermind, I didn't realize that you were using the term MDI to specifically refer to the child window within a window interface. I consider tab based document containers to be another form of multiple document interface (MDI). –  17 of 26 Sep 23 '13 at 17:04
show 1 more comment

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
share|improve this answer
    
It is exactly what I designed in the first place: a VS-like frame which has a side panel, which I think is good for e.g., report configurations and properties, a bottom panel which I designed for some real-time windows and messages/notifications, and a structured main frame (for example, 3 small ones vertically and 1 big one be their side). But still I feel a little bit uncomfortable with that because 1)the report sizes vary a lot it might be not easy to fit it to some fixed-size area. And on the other hand 2)some area might not contain anything so it is a waste of space –  tete Sep 23 '13 at 14:57
    
And the document-docking-outside-the-main-frame I didn't think of it, but I find this feature a little bit clumsy to understand and use in VS. I mean I often accidentally drag one doc out of the tab, and when I try to move them back, they get "embedded" in many unexpected places. Of course it could be that I didn't think it through. Your suggestion is definitely one that worth exploring. –  tete Sep 23 '13 at 15:02
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Welcome to the site! Can you summarize some of the information in the link? Is there any additional evidence you can give to support your assertion that supporting both is the best option? –  3nafish Jan 26 at 5:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.