What are the advantages and disadvantages of multi-window functionality vs single-window functionality?

Question

I am considering porting a windows application to a web application for one of my clients. The windows application is an MDI app (multiple forms open at once), but obviously the web app would be much more "linear" in the workflow, i.e. one window open at once (for the most part).

I guess I wonder two things.

• What are the advantages and disadvantages of multiple window (one per form) vs single window (using Back and Forward for multiple forms) UI?
• Is it possible/common/acceptable to have a web app that is designed to have multiple browser windows open at the same time for the same application?

Answer 1

First a terminology issue to try to eliminate confusion: "multiple document interface" (MDI) is a design where an application has a single “container” window within which the user can view multiple document windows (which each may be a form). This specifically refers to a design promoted by Microsoft for various productivity apps like early versions of MS Office. The alternative to MDI was a single document interface (SDI), where there is no container window -each document has it own top-level window. This implies that each document was also a separate process and thus SDI for multiple documents requires greater computer resources than MDI. However SDIs have better usability owing to their greater simplicity, so, with today’s powerful computers, MDI is obsolete and has been largely abandoned. MS Office partially moved away from it in 2002.

I don't think you mean to discuss the merits of "MDI."

To get at your question, I prefer to distinguish between “history navigation” versus “window navigation,” where the former is web-style and the latter is desktop style. Both support multiple “open” forms in a single application. The difference is how users navigate among the opened forms. History navigation has an implicit historic list of forms (or other pages) you can “move” back and forth through. Windows navigation has each form in a separate window so users “navigate” (if you want to call it that) by simply clicking on the opened window for the form they want.

Which is better? History navigation works best when users work superficially on many pages/forms, skimming for content, ignoring most of it, and only occasionally providing any input other than navigation. Window navigation works best when users work intensively on a few forms, providing substantial input (e.g., more than 30 seconds of work). In history navigation, forms effectively close themselves by simply being neglected, which is fine for superficial work, but a real drag if it means losing track of a lot of unsaved work.

For form-type work, window navigation has the following advantages over history navigation:

• Simpler, faster, and more visual navigation for recently used pages. See the page you want and click on it. No going back or forward multiple times. No mentally tracking history.

• “Paging” can be used for other purposes, such as showing multiple database records in the same window.

• Exiting or logging out leaves no ambiguous pages apparently available for access. Log out with history navigation and the user can still back into the pages in the history chain, which is confusing at the least.

• Input is preserved when the user navigates to another page. It obvious that a form in one window should not be cleared simply because the user has clicked on another window then returned focus to the original window. History navigation traditionally clears the form when the user navigates away from it and then returns, which is usually the wrong thing to do, but sometimes the right thing –there really isn’t a good way of dealing with it.

Assuming your window-navigation app is already performing well with users, don’t mess it up by trying to switch it into a history-navigation app. The main challenge will be getting users to not treat the opening of new windows as “pop-ups” to be blocked or closed. Another issue is the computer expertise of your users. Many low-end users don’t know how to handle multiple windows. They run every window maximized and seem unaware of the task bar. However these same users know how to use the back button on the browser.

I’ve more details of history navigation versus window navigation at Turn the Page. It also includes details of properly designing a windows-navigation web application.

Answer 2

I believe that MDI was invented in the days where computer resources were scarce, and it was more beneficient to adapt your program to be able to handle different documents, instead of running different executables.

This article nicely sums up advantages and disadvantages and some history.

I think most of the time in a MDI program, only one form is on top. So actually the user is working on one thing at a time. It does offer some extras:

• you can view information side by side
• sometimes it gives a visual history of the things you have done (e.g. first opened a person, clicked on his accounts, opened an account, and all these windows are on top of each other).

These advantages can be handled easily in web situations though:

• it is very easy to open different pages side by side (use different browsers or browsertabs), allowing users to compare or verify information, cross-check, whatever.
• using a good breadcrumb mechanism allows a user to have a good vision of her history

So in short: I would not try to mimic a MDI interface in a web-application.

Note: if you really want to mimic a MDI interface, some good solutions do exist, e.g. ExtJS. But personally I would not recommend it.

Answer 3

Multiple document interfaces are suitable for applications where more than one document can be edited at the same time. It is often beneficial to allow a user to view/edit two or more documents at the same time than just one at a time. Imagine an estate agent who can view more than one property at the same time, or viewing one without having to close the details of another. This allows an approach to document management more akin to how they might work with paper on a desk.

In a web application you might be able to provide dialog-styled documents if you wish to keep all the content in just one page, or you can open new windows with a document in each - though the latter will require discipline on the users part because your application loses control of those windows once they're opened. As an alternative, you could offer something like an accordion control to quickly open/close documents with them all in the one page. I think the choice of technique will be largely down to the size of your documents and the control you want over when they are visible and or closed (removed).

Answer 4

I'm looking at a similar problem at the moment. Our application is a thin client application. It isn't necessarily the user's focus most of the time (we provide status and function while another application is being used as the primary tool).

We are considering building our application so we can offer the user two views. A single window view and a multiple window view. In the latter, the user can size and position the pieces of our application as they see fit.

In a more traditional web application, you may find the same logic to be useful. Reference tables/graphs or status panes could be useful pop-ups that could be structured around the screen. This might also work if your application is very complicated and users might want to control their view. However, in this case, I'd be more prone to consider looking at a better, smarter screen layout that has some amount of user controlled configuration. Multiple windows, can become annoying as they impact the multiple application paradigm. For example, under windows, alt-tabbing between applications not yields multiple stop points that are your application. Same affect on the taskbar.