Pixelcentric IHS: Document Windows

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 Multi Document Interface (MDI) conventions seen in Windows and some Unix desktop managers are usually painful attempts at escaping key problems caused by a poor window management system, resulting in only more window management problems. 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 and destroys the user's ability to work simultaneously in multiple programs. Mac OS X, which does not feature MDI, allows the user to freely interleave windows, even if they are from different programs. 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 IE 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 makes document handling in Excel much harder than Word. Internet Explorer 6 doesn't use MDI, either. 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.

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. Dropping an item in a certain place often results in a shortcut being created, when the desired result would be the relocation of the item. Dragging and dropping from one document to the other should result in a copy operation; in Windows, a Cut operation often occurs. An intra-document drag should move the dragged content to the specified target location without further user action.

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.

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. Encourage Dragging and dropping

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 most 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.

The designers of FirstClass (pictured above) made the commonly used formatting tools so difficult to use that they had to create an alternative method of accessing the tools (i.e. the toolbar at the bottom of the picture). Avoid using submenus if you can, especially with important tools such as the ones pictured here. If you do need to use submenus, try to stick to submenus that are one level deep.

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. See the image for an example.

Site contents copyright © 2002-2003 Pixelcentric. Software products, brand names and logos are Copyright their respective owners.