9

As WPF has no built-in MDI support I was looking around for alternatives for a rather large graphical work oriented application. The application will have a lot of different widgets, and for a lot of those the usable area will be different in size: there will ba a widget showing a 512*512 image, but also a widget with 3 buttons, another one showing a listbox, etc. There will be multiple instances of those widgets, and for eg the image widget, it is preferrably that they are all visible at the same time to be usefull.

Looking at some alternatives, I couldn't really find anything that seems to give the same ease of use as a typical MDI app (think PhotoShop). This is what I tried so far:

  • only tabs, like today's browsers: impossible. 90% of the application is hidden.
  • docking layout: not bad, but wastes a lot of screen space (eg docking a small widget in the same area as a large widget, because they logically belong together) and might get unmanagable since the number of widgets that can be opened is basically unlimited
  • docking layout combined with tabs: same as above, but somewhat better as it makes it easier to organize everything
  • multiple floating toplevel windows on the desktop: not bad, but sometimes confusing because the desktop (or whatever windows are on there) is visible in between the windows

None of these was really convincing me (note that I did not talk to any users). So I was wondering: am I just so used to MDI (spending tons of time in VS2008/VS2010 with floating windows extension/PS/...) that I cannot enjoy alternatives, or are there no true alternatives and is MDI the only way for an app like this?

2
  • Are you asking for a User Experience/Usability perspective or are you asking from a code library/implementation perspective?
    – DA01
    Nov 9, 2011 at 23:50
  • @DA01 yes this would be purely from a UX perspective
    – stijn
    Nov 10, 2011 at 7:46

3 Answers 3

11

Of the options you give, I’d say your best bet is to pursue multiple top-level primary windows. I’m not aware of users being confused by an app being spread over multiple primary windows. MS Outlook seems to do okay with this approach where individual letters and appointments appear in a separate primary window from the “home” window. You can still have menu items that affect all windows (e.g., application exit, and a Window menu, which may include Iconify All), so you aren’t losing capability. MDI’s windows-in-a-window complexity has several serious usability disadvantages. Maybe it’s time to ditch it.

Instead of relying on a container window to comprise your primary windows, you can apply some graphic design to visually tie the windows together (e.g., give the window borders, menu bar and toolbars a non-theme non-standard background color). However, it may be sufficient to have a common icon and program name in the title bar. Also, there’s something to be said for the users not seeing all the windows as a single app, but instead just seeing “documents” on their screen regardless of their respective apps. This helps users to flow freely from window to window (mentally and spatially) as the task requires, including among windows of different apps.

In your case, one problem with multiple top-levels may be that it’s easy to lose the smaller windows in the clutter of the desktop. Also, if users typically have a lot of such windows open at a time (five or more), then the task bar can get awfully crowded. You may want to cut down on the number of small primary windows:

  • Combine small windows together. If several of your small windows are related to each other, you could put them in a single window. This could either be a large window with divisions between the content. That won’t get lost and the user has immediate access to all the content. Or it could be a small tabbed window so it doesn’t get in the way.

  • Use modeless dialog boxes. If there is a hierarchical relation among your windows, you can turn your small windows into modeless dialog boxes or utility windows. Dialog boxes and utility windows always float above their parent primary windows, so they are less likely to get lost. They lack an icon on the task bar, so it doesn’t get too cluttered.

  • Combine small windows with a large window as panes. Another approach for hierarchically related windows is to join small child windows to a large parent window. For example, a main content window can include adjacent panes for Layers and Properties of content in the window. Alternate views of the same content (e.g., a small “overview” map for the main content) can also be in the same window divided into panes. This is often better than separate small windows (including dialog boxes) because panes won’t occlude the main content like small windows can. The panes should be closeable and resizeable so users can adjust the space dedicated to the main content.

  • Docking panes/secondary windows. You can have both of the above options at once if you allow the users to dock/undock the window/panes to suit the current needs. This is common for palettes. You only have to decide whether the default should be a pane or dialog.

In other words, the real solution may be a combination of the options you list.

2
  • +1 even though Outlook is a dreadful example :-)
    – GUI Junkie
    Nov 10, 2011 at 14:22
  • +1 though I wish I could upvote more than once: this is really good advice actually, clearly structured as well. Thanks!
    – stijn
    Nov 10, 2011 at 15:41
1

Third party tools allow the feature of MDI in WPF. Have you considered this (I guess this is free):

http://wpfmdi.codeplex.com/

Edit

I suggest you use MDI since the window size can be customized (not necessarily with ease) to fit the varying content where as tabs for example can't be adjusted and lots of White space may be left unused, which sometimes look ugly.

2
  • yes I know about this; would need some modifications but it's not bad. Hence my question: sould I blindly follow what I like (MDI like this), or consider alternatives that I do cirrently not like because I don't use them?
    – stijn
    Nov 10, 2011 at 7:50
  • @sigin, thanks for your comment, I have edited the answer.
    – NoChance
    Nov 10, 2011 at 10:17
0

I know that this is an incredible old thread that I'm jumping in, but I'm in on my way experiencing with different UX GUIs, guided somewhat by the Head 1st C#, and it makes me do the same projects in thrice ways - WindowsForms, WPF and UWP.

Speaking of MDI WindowsForms, I definitely agree that have a lot of tabs is not so helpful as an alternative, and the Outlook way isn't easier to code and user (me) can get overwhelmed or lost; of course, all the advice and directions given by Michael Zuschlag's are very inspiriting.

But I stumbled in an easy and fast way to turn a MDI towards a better UX, by turning child forms into views that are added to a ToolStripContainer control; when we click on each child "form view", it appears maximized into the MDI parent form, in a very intuitive and fluid experience.

The solution is here; the project is from 2008, by Amer Gerzic - his site isn't updated for a long time; it was compiled with earlier than VS2010, but I could import into VS2019 without any problems, and it is very clever and I'm using it for some old projects that I not whiling to port to .Net Core 3.0 and XAML.

P.S.: You'll need a Crystal Reports for VS to run it if you simple download it's code, unless you edit ChildView2.

Edited after @Nash's request; I hope I gave due credits to it's author and his repository; anyway; if, by any means, the page is gone, let me know and I can reproduce it here.

After load: enter image description here

Click view: enter image description here

ChildView1: enter image description here

ChildView2: enter image description here

ChildView2 menu integrated with MDIForm: enter image description here

PS2: These screenshots are tuned to future SO's Dark theme ;)

1
  • Hi Marcelo, some screenshots would be nice to follow the UI controls you are proposing.
    – Nash
    Jul 13, 2020 at 7:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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