Dealing with multi-window interfaces for desktop applications?

Question

In the case where a single desktop application has many different screens, and a user may (or may not depending on the task) need to see more than one screen at a time, which approach is best for handling multiple screens?

For example, think of a business/ERP type application that has screens for listing items, editing items, viewing customers, entering orders, entering payroll, updating inventory, and so on. There could easily be thousands of available screens, although only certain combinations of screens might be used at a time.

I can think of two ways of dealing with this problem:

Option 1

Use the Operating System window manager to manage the windows. The user launches the main application window, and the main application window launches new windows in the desktop environment. The new windows appear on the taskbar/dock and the OS Alt+tab/Expose can be used for window switching.

Advantages:

• The application uses the GUI the user is already accustomed to. ie. mac users who like Expose don't have to use a Windows style GUI inside the application.
• Users with multiple monitors can move the various windows to different screens.
• We don't have to develop our own window manager. The OS does this for us.

Disadvantages:

• Having many windows of our application windows open at once can make a giant mess of the taskbar. It may be hard to find a specific window we need.

• What is the point of the main application window then? It's just a window with a menu bar. Whenever you open a new window, you switch to it. When you need to open another, you have to find the window-launching window down on the taskbar, which can create a bad UI experience.

• No way to minimize/restore all windows at once.

Option 2

Create only one main application window that appears at the OS level. Create your own window manager that lives inside the main application window, to manage the various sub-windows. Windows can be opened, moved, and minimized within the main application, but they do not appear on the main application task bar and can't be alt-tabbed, etc.

Advantages:

• Less Clutter. When you minimize the application, the whole thing minimizes to one slot on the taskbar. Clicking it again restores the application.

Disadvantages:

• Creating your own window manger is a lot of work to create and maintain.

• Windows that you can drag around, close, and minimize just like real windows can be very frustrating when you can't drag the windows outside of parent window.

• Will not work with multiple monitors.

• These types of interfaces always feel clunky to me, compared to the native desktop.

• May force the user to use a different metaphor for window management. ie. they are used to Expose but are forced to use a taskbar within the application.

I would consider option #1 to be a lesser of evils, but I'm not satisfied with it as a solution because it still has many disadvantages such as lots of clutter on the OS taskbar with many open windows, and having a main window with nothing more than a menu bar/launcher that you have to keep flipping back to.

Certainly someone has come up with a better way of managing windows in a multi-window application?

Answer 1

I think that both of your options grant too much liberty for the user. I believe that when users cannot grasp a clear and simple workflow they feel lost. When an app allows you to do the same thing in many different ways, I feel this way. When an apps allows you to position its controls in many different ways, I feel the same.

What I would do is to approach this problem in a specific case-by-case basis. No general solution will work well with any kind of program. The content should be the guiding principle. Once you know the kind of app that you need to make, decide a nice information flow for the user. Don't allow every master-detail-subdetail combination just because you can. Reorganize the subviews to where they make sense.

Decide on what is the most important view of your app. What is the most important piece of content the users will be working with? Made this the main window, and nothing else. I'd forget about developing a window manager within you app.

For subviews you have other options.

You can use what I call weak-modal popups (Apple calls them popovers). This are modal popups which immediately update the data model when you modify any field (you don't effectively need apply/close/accept buttons). They can be easily dismissed just by clicking outside them. They feel less intrusive and interrupting than traditional modal popups, because they don't obscure the rest of the view, and you can perform an additional action when you click to close them (say, close a weak-modal popup by clicking some control which at the same time opens a new weak-modal popup).

Another kind of control that I believe may be useful for your goals is the modern in-app drawer that has a fixed location within the main app window. The user can hide or show them at will, at the main view scales accordingly, showing more or less content. Xcode 4 shows a very good implementation of this with their debug, navigation and utilities areas. An advantage of this kind of drawers is that it makes full use of the spatial memory of the user: the appropriate drawer will always show in the same position relative to the full window. One less thing to keep in mind: where did I put this little window that I need now?

Answer 2

It sounds like what you're looking for is a docking window framework. A docking window framework lets users dock, detach, and combine windows in any way that they see fit. The windows can be moved to other monitors and the entire application appears as one entity on the taskbar. Visual Studio 2012 is one example of an application that uses this model.

If you have a bunch of equally important views that can be available at any given time, this can be an elegant solution.

You wouldn't necessarily have to roll your own. This is a solved problem with commercially available packages. For the product that I work on, we use a third party library called SandDock.

Answer 3

I still find this to be an unsolved problem. Nevertheless, I came to understand there are some circumstances where decisions can be made.

Your MDI vs. OS windows comparison is a false dichotomy. There are many more choices, notably:

• detachable and dockable panels (Visual Studio),
• splitters inside one big workspace (Windows 8),
• workflow-specific subviews inside the same window (every other app),
• workflow-specific second monitor views (Photoshop),
• miniature "launcher" window and lots of data windows (Bloomberg Terminal),
• and certainly many more.

You should ask yourself a few questions about the app:

• How much is known about user's workflow? Is it possible to distill a set of workflows that lend themselves well to workflow-specific UI design?
• Is there a single main piece of UI that's always present and never duplicated? If not, can it be introduced? If it is duplicated, can it be reduced to single split-view?
• Can you train your users? If not, what prior experience does the target audience bring over from other apps they are likely to know?

If multi-window capability is central to the app (rather than some expert feature), extra care must be taken. This is the kind of feature where you cannot afford users failing to understand the feature. Whatever design you choose, make sure that users are extremely unlikely to misunderstand it. If you aren't sure, discard the design.

In any case, I wouldn't recommend MDI. It's old-fashioned, confusing, and annoying. My priority list when choosing multi-window design is like this:

1. If you can train the users or offer them design they already know, then go for the most productive design.
2. If the app accomplishes specific task or supports specific workflow, create custom navigation that matches the workflow.
3. If there's single main window, then make this one default and allow users to open helper windows. Allow users to place them freely around the desktop. Docking should be optional. Closing main window automatically closes all the others. Desktop layout can be saved.
4. If every window carries content independent of all the other windows, consider splitting your app into multiple separate apps. Users can then open/close windows however they wish.
5. If the windows are independent, but you wish to manage them as a group, then provide session management. This can be accessed from miniature main window or it can be provided on every window that comprises the app.

Personally, I believe most apps should be simple. All the advanced techniques are for professional apps.

Answer 4

Option 1 may be tempting, however it reminds me GIMP with all its windows and toolbars. After a lot of critique (more-less similar to the disadvantages you mentioned), the GIMP developers have implemented also an option for Single Document Interface, which is basically a single main window with docked toolbars.