Interface: Document Interfaces

All major operating environments are used for one common purpose, and that is the handling of data, ie. documents. Typically document windows have a distinct appearance and work differently from for example status windows or alert windows. This page outlines some things you should keep in mind when creating interfaces for document handling.

1. Don't Do MDI

The Multiple Document Interface (MDI) conventions seen in various windowing systems — most notably Windows, as well as many Java applications and some *NIX desktop managers — present the user with a workspace window that contain all of a given application's document windows. This is generally done so the user is not exposed to some of the problems rising from having to manage multiple layers of windows shared between applications.

This limits the ways in which the user can interact with multiple documents at once. One of the key problems with MDI is that the system limits screen real-estate. MDI also makes it hard to manage windows within an application since windows can only be moved within the MDI parent window belonging to that program. The parent window hides all other programs underneath it, destroying the user's ability to work simultaneously in multiple programs.

Many windowing systems have instead opted for either document interleaving or application level window layering, doing away with MDI parent windows entirely. This is the case for many applications across the Windows, Linux and Mac OS platforms. Mac OS only supports MDI for purposes of Java applications that implement MDI for their cross-platform interface, but even this practice should be frowned upon.

Application layering means that clicking a document window to bring it to the front also brings the rest of that program's document windows to the front, behind the selected window — thus resulting in a stack of programs. Stacking windows on an application basis generally relies on the assumption that programs further provide the user with a way of reliably selecting the desired window. The most rudimentary method of implementing this would be an application specific Window menu, listing all of the open windows.

Meanwhile an interleaved system (such as the one used by Mac OS X and all Windows applications that adopt SDI) places every open document into a shared stack of windows regardless of which program spawned them. This means you could have an Internet Explorer window at the bottom of your window stack, partially covered by a Word file, which in turn could be partially covered by another Internet Explorer window. The user can easily see data in another program without switching to that program. This is especially handy if you want to drag and drop text from a web page into a text file, for example.

Also interesting to note is that Microsoft applications make inconsistent use of MDI. The latest version of Excel makes use of MDI, while the latest version of Word does not — this has been the case for a number of Office revisions now. More about the inconsistent behavior and other aspects of MDI, SDI and tabs in Office 2007 on Rich Newman's blog (2007-10-26).

Due to the MDI approach to documents, handling cross-application data in Excel is much harder than it is in Word, because you can more easily drop data such as text or images into a Word file from an external program. By default you will also see each Word document represented by its own button in the taskbar, facilitating easier cross-application window management.

Internet Explorer doesn't use MDI, either, and has instead recently adopted a tab-based document interface á la Firefox. This seems to be fire and motion from Microsoft's part: it persuaded thid party developers to use MDI, but the company is now steadily moving away from MDI. The revised MSDN Interface Guidelines now have this to say (via MSDN Blogs):

Note MDI is an application-oriented model. Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, many applications are switching to a document-oriented model. Therefore, you may want to consider other models for your user interface. However, you can use MDI for applications which do not easily fit into an existing model until a more suitable model is introduced.

2. Encourage Dragging and dropping

Dragging and dropping items is physically a relatively simple operation and a natural way to carry out various tasks, such as relocating text or files. It is important to allow cross-document and cross-application dropping.

Windows fails in many respects in this field, the most glaring example of which is the Taskbar. The Windows Taskbar is programmed to expect file drop events for the sole reason of presenting the user with an error stating that such an operation is not allowed.

It's obvious that the Taskbar engineers expected users to try to drop data onto the Taskbar buttons, and the resulting error message is in fact quite descriptive and informative. As the error message explains, although Taskbar buttons are proxies for the associated program windows, the buttons themselves don't accept file or data drag & drop. However, dragging an object onto a Taskbar button and holding it there will "spring-load" the program to the front, at which point the dragged item can be dropped into a program window.

The problem of course is that telling the user that they can't do that is not the way to solve a problem, nor does it build user trust. A more user friendly approach would be to have the Taskbar buttons accept most kinds of dropped objects, recognize their type and content, and act accordingly. For example if the user drops a picture or a snippet of text onto a Word Taskbar button, the expected action in almost all cases is to append the text to that document while bringing the document to the front.

Raymond Chen explains (2004-11-24) that the Taskbar can't forward item drops to the associated windows because the necessary functions aren't implemented, but he appears mystified as to why that's the case. The most common theory is that a Taskbar button doesn't always correspond to just one possible drop target — for example, due to MDI behavior (see section 1) an Excel Taskbar button could be a proxy for several Excel worksheets instead of one. However, this problem is easily circumvented by allowing an application to specify default behaviors for dropped data. Excel might opt to append dropped data into the frontmost worksheet, for example.

It is important to provide indication of what will happen when the mouse button is released. A good way of doing this is displaying status icons next to the mouse cursor, since the mouse is what the user will be looking at while dragging. Also be sure to display a phantom image of what is being dragged. For the Taskbar example above, the cursor could turn into a "Prohibited" sign while hovering over a Taskbar button like it does in other areas of Windows where dragging and dropping is disallowed.

If the user does drop an item into a location that isn't meant to accept dragging and dropping, a good way of informing the user that the operation failed is to simply use a brief animation — have the dropped content speed back to its original position. Displaying an error window is needlessly alarming and disruptive.

Don't allow the dragging and dropping of standard controls that aren't meant to be dragged. Also don't allow dropping data onto controls that aren't meant to accept file or data drop.

3. Use Standard Commands and Controls

The user is used to how their operating system works, so it is generally a bad idea to invent new controls or to change the way existing ones work. Don't reinvent the wheel. If you think you need a custom control for an operation, think about how to make the operation fit into the existing user interface. It's not very probable that the interface element toolkit at your disposal is not diverse enough. It's more likely the operation is too complex.

4. Avoid Nested Dropdown Menus

Dropdown submenus are possibly the only interface element that are physically hard to use, and therefore should be avoided in UI design at all times, if at all possible. Multiple levels of nested submenus are particularly problematic, since a tiny slip of the mouse can cause the whole menu structure to close and force the user to restart their balancing act through the menu structure.

5. Don't Hijack The Computer

No application-specific operation should cause a document-centric program to hog the whole computer; and no document-specific operation should ever take over an application. These are two standards set forth in Mac OS X, and should be followed in other operating environments as well. Users dislike an operating environment that keeps interrupting their work. Things such as document-specific warnings, info windows and save prompts should be displayed attached to the document, without hijacking the whole application or the whole system.

For example, since the word count information in a word processor or text editor only applies to one document, the window displaying the word count should be displayed attached to that document, leaving the user free to work in another document window or application.

6. Encourage Exploration

Don't make the user afraid to use the commands and features in your program. Try to provide multiple levels of Undo and Redo, and make sure the user knows the commands are there (place Undo & Redo in your application's toolbar if it has a toolbar, and have both commands visible in the Edit menu). Make your application forgiving to the user.

If an action cannot be undone, indicate this before executing the command. Allow the user to back out of the command.