How should I handle multi-tasking in a WPF application?

Question

In most of the multi-tasking CRM applications I've seen, MdiWindow is used to allow users to open multiple windows at the same time.

But MdiWindow doesn't seem to be commonly used in WPF. Looking through Codeplex, I only found one abandoned MdiWindow project.

In some of the WPF-based CRM applications I've seen, they create a dashboard and only let users work on one thing at a time.

What's the best way to handle multi-tasking in a WPF application? Is there a better alternative to MdiWindow in WPF?

Answer 1

Usually the design I use works like a TabControl: there is a navigation area and a Content area

I think it's because I don't like cluttering my workspace with many windows for the same application. I would rather have a single application instance containing everything I am working on.

I also find it makes managing Views and Dialogs much easier with the MVVM design pattern. I'll usually have a ShellViewModel containing the currently opened views, a list of available views, and the currently active view.

Answer 2

Your question, as I understand it, seems to be about GUI Design in general rather than WPF in particular.

For presenting secondary information, you have the options of:

0 - MDI Windows (allows the presentation and automatic organization of several windows simultaneously)

1 - Docked windows as in VS2010 (allows user to organize the workspace so that he/she can focus on the specific desired windows)

2 - Tabs as suggested by Rachel (this shows only part of the information and hides the rest)

3 - Wizards

4 - Accordion displays (somewhat rare but allows you expand only bands of interest)

There are 3rd party tools that provide all the above functions in slick ways.

Some of the key points to consider when selecting which interface is to think of this:

A - Does the user really need to see/interact with all this information together or at once? Remember that no one can type or look (actively) at 2 windows simultaneously. Your ystem should display necessary information for taking a business decision together in one display when possible. Other (secondary) information could be obtained via navigation to modal windows. Most people will not be able to look at 40 different fields on the screen to make a decision or take an action. You will usually find that in business applications, a process is composed of steps, and each step has its own data. You should be able to complete a business process without having to display many windows at the same time. You should evaluate navigation between windows as an alternative (as in (3)).

B - Is the information presented in each window independent of other open windows? If not, you will be heading for somewhat complex programming. To make all windows respond to a change in one window may be tricky. Be careful.

To summarize, your business process, required data volume, ease of use and ease of implementation should all be elements in your choice. For example, if changing information in 1 window causes other windows (or tabs) to change, your program could be complex and you probably want to avoid doing this.

Answer 3

Rather than re-inventing the wheel, you may want to look into using an MVVM framework, like Caliburn.Micro, that takes care of a lot of plumbing when creating a shell (or dashboard) style application:

http://caliburnmicro.com/documentation/composition