The Human Factor: Mailbag Miscellany: Menus and MDIs

Tandy Trower
Director of User Interface Design

March 10, 1995

This month I thought I'd take a break from covering new topics and respond to some comments and questions from previous columns.

File menu

First, I received a letter challenging my statement that it is not necessary to include a File menu in all applications ("Menu, please," Developer Network News, September 1994). The reader insisted that every application for Windows should include a File menu, if for no other reason than to provide a logical location for an Exit command.

This reader is partially correct in emphasizing the importance of the File menu for a majority of applications. But I stand by my assertion that a File menu is not required in every application. The purpose of a File menu is to provide commands associated with handling files, typically for opening, saving, and printing files. Such applications as Calculator or Clock for Windows have no such functions.

Further, while many applications have an Exit command, this command is not a requirement either. In applications such as Notepad, for example, an Exit command on the File menu makes sense. However, for objects such as folders and printers in Windows 95, Exit does not apply.

Exit and Close commands are sometimes confused. Exit implies terminating an application process. Close means to remove a window. They apply to different aspects of the interface, although sometimes they may result in the same effect, such as when you close or exit the primary window of a data-editing application. For example, closing a printer window does not terminate the printing process.

As application design becomes more data-centered, applications will be less visible in the interface. As a result, application functions such as Exit will disappear from many menus as windows represent the data or document object rather than the application.

So a File menu is a good thing to have when file operations are supported in your interface. Similarly, Exit is a common command for many application designs. But there are definitely circumstances where neither may be appropriate.

MDI alternatives

The next two questions came in response to "It's Windows 95: Do you know where your child windows are?" (Developer Network News, November 1994), about multiple-document interface (MDI) applications and my suggestion of a few data-centered alternatives.

One reader asked how MDI and "workspaces" differ from a design standpoint. Assuming the reader means from the perspective of UI design rather than coding (the latter being Dr. GUI's specialty), the answer is "not much" and "a whole lot."

To clarify my apparent double-speak, let me first say that visually and operationally there isn't much difference. The child windows share the parent window's menu bar and other interface areas. The child windows are constrained to the parent. When the user closes the parent window, the child windows close as well.

However, the significant difference here is that a workspace is a container. The icons are not representations of minimized windows as you might see under Windows 3.1. Instead, the icons represent objects that are stored in the workspace.

For example, in a Microsoft Word document, you can create a Microsoft Excel embedding that is displayed as an icon. Icons that appear within a workspace represent objects that are embedded (wholly contained) within the workspace. That is, they are literally stored there.

In contrast, traditional MDI only provides visual organization. In other words, Word documents are not literally stored inside the MDI parent window. Another way to think about this: A workspace is like a folder that uses MDI conventions for managing objects opened from within it. In a workspace, there is a one-to-one mapping between storage and the windows that appear within the parent window.

Documents, not links

Another reader asked whether the "workbook" example assumed in-place editing of OLE-linked objects, something not supported in OLE 2.0. The answer is no. If you look at the illustration below, all the tabbed pages were intended to represent individual documents, not links.

Example of a workbook.

However, that does not mean that different tabbed pages could not represent some form of linked data. In Microsoft Excel 5.0, a user can create a chart (linked to data on a spreadsheet page) as a new "page" within the same book.

Possibilities, not specs

Let me reiterate that the examples in my MDI column are only possible designs, not fixed specifications. In addition, these designs are not limited to organizing and viewing documents or files. For example, a workbook's pages could represent different views of the same file.

Thanks for all those cards and letters. Now you know that I actually read them!

Tandy Trower is the director of UI design at Microsoft (or the Curmudgeon of Consistency or worse).