Common File Dialogs
The common file dialogs used in Windows95 clearly demonstrate that programming efficiency was a far more important concern to Microsoft than usability. New users and experienced computer users alike are stumped when initially presented the common file dialogs. Even with considerable experience with the dialogs, they are notoriously inefficient to use, require considerable input of the user to find the necessary information, and offer the potential to lead the unwary user on a convoluted path through the operating system. The very design of the common dialogs makes it difficult to explain how they operate, consequently making it difficult to explain the problems the design present.
Last updated 17-April-1998
Where am I?
The main problem with the dialogs is that they hide the hierarchical information from the user. For example, consider a scenario in which you have created folders for each of several projects: Project A and Project B. Each folder contains several common subfolders, for example Contacts, Notes, and Reports. We could represent this as follows:
- ProjectA
- Contacts
- Notes
- Reports
- ProjectB
- Contacts
- Notes
- Reports
 A lowercase "i" is a lousy choice for the mnemonic character; why they didn't choose the "L" is beyond us. |
 |
The Windows 95 dialog provides no indication of which Notes folder you are in. The only way to verify that you are in the appropriate Notes folder is to click on the "Look in" combo box and scroll upwards.
In contrast, the Windows 3.1 common file dialogs explicitly displays the hierarchical directory, graphically in the directories control, and verbally, in the label above the directory control. The user is instantly aware of which Notes folder he or she is currently in. The extra information provided in the Windows 3.1 file dialog reduces uncertainty, makes it less likely that an incorrect file will be selected, and reduces the manipulations the user has to make to select the appropriate file.
Jack of all Trades...Master of None
Another problem with the Windows 95 common file dialogs is that, by using a single control to display folders and files, the user may have to perform several actions to determine if the folder contains the desired file, or if it contains any files at all. When a folder contains a large number of subfolders, the user may have to scroll to the right simply to determine if the folder contains any files at all.
The Windows 3.1 common file dialog, in stark contrast, explicitly separates files from folders. As you navigate among the directories in the directory control, the files contained in the selected directory are instantly displayed in the files list.
Hey, maybe they're on to something...
It would appear that, in time, Microsoft's designers realized the problems created by combining folders and files into a single control in the Win95 common file dialog design. This image was taken from the Office97 common file dialog, and illustrates a woefully bad attempt to minimize the problems. In the Office97 file dialogs, whenever the user opens a folder, the dialog skips over all the constituent folders and selects the first constituent file. Thus, the user can rapidly see the files contained in the folder.
Good idea? No. When the folder itself contains many folders, the rapid scrolling to the right is completely disconcerting. Moreover, the "solution" now creates a great deal of overhead for the user when he or she needs to drill-down through several folders. Each time a folder is opened, the user has to scroll back to the beginning of the list to open each subsequent folder. (In the above example, the user had to click on the paging area of the scrollbar 15 times to get back to the beginning of the list of folders in the InfoSys folder).
The only appropriate resolution to this problem is to have separate controls: one for the folders and one for the files.
A Lesson in Inefficiency
The dialogs’ handling of long filenames further reduces their efficiency. Windows95 makes the column widths in the dialogs wide enough to display the longest name of the files or folders contained in the current folder. This results in an amazing waste of screen space, especially when, for example, all of the files in the C:\ folder are in 8.3 format with the exception of "COPY (BEFORE NAV) OF AUTOEXEC.BAT" which some installation program has thoughtfully created for you. A single filename like this can result in the dialog displaying only 6 files at a time, meaning that you will have to make more scrolling inputs to get to the desired file.
Stunted Growth
Perhaps the most frequently mentioned complaint that we receive concerning the Windows95 common file dialogs is that they are not resizeable. Depending upon the length of a single file in the currently displayed folder, the dialog may be limited to displaying only 7 files in the default mode, and in Details mode, will never display more than 7 files. Unfortunately, someone at Microsoft felt that this wouldn't be an issue.
Memory Impaired
One characteristic of the common file dialogs that would earn them notable mention in the Interface Stupidity section of the Hall of Shame is that they are unable to recall the user's preferences from one instance of the dialog to the next. For example, if you decide to view the files in detail mode, sorted by Modification Date, the dialog will have forgotten these details the next time it is opened, reverting instead to the default mode, and requiring the user to re-specify his or her preferences.
Attention Deficit Disorder
An application uses the common Open File dialog simply to allow you to specify the file to be worked on. Why is it then, that the Open File dialog allows you to rename files, delete files, create new folders, send files to the printer, send a fax, save a file to a floppy disk, try to convert a bitmap file to an Excel spreadsheet, edit a file with a different application, create an e-mail message. and so on, all while the calling application is waiting for the name of the file you want it to work on? This is bizarre!
While you could do all these things and more from the Open File dialog, who would want to? The availability of these functions from this location could only be of extremely limited value to the most experienced of users, at the cost of easily confusing the new user. These functions are not mere distractions, they could lead the user on a convoluted path through the operating system, taking them further and further away from the initial task.
Fortunately, by violating their own standards, Microsoft has inadvertently protected some new users from the confusion these functions offer. The only way the user can access them is to right-click on a filename. By their own standards, the right-click menu is supposed to be an alternative method of accessing menu-based functions. Since the Open File dialog is a dialog box, it should not have menus; therefore it should not have a context (or right-click) menu.
Get Your Pointers Out
One particularly bad design feature of the common file dialogs is that they require the use of a pointing device to access certain functions. The common file dialogs utilize toolbar buttons for the Create New Folder function and to toggle between List and Detail display modes. The presence of toolbar buttons in a dialog box is itself enigmatic, since toolbar buttons were created to be used as an alternative means of accessing frequently-used menu commands. Since the dialogs do not have menus, and because toolbar buttons do not have captions, there is no means to access these functions from the keyboard. While the graphical buttons sure are pretty, they have no place in a dialog box.
Perhaps they were Mistaken After All
Since first criticizing the right-click context menu on the common file dialogs, we have received a few letters criticizing our position. It seems that a number of people, after having become used to the context menus, find that they are really quite useful. We agree, but then again, we have been using computers for a long time, as have the persons who find the context menus most useful. We've maintained our position based on our observations of new users, and recently, based on circumstantial evidence provided to us from Microsoft.
The Arrange Favorites dialog from Microsoft's Internet Explorer is pictured below. Notice that it is clearly based on the Windows95 common file dialogs, and most likely utilizes the same code. A cursory review of the image will demonstrate rather important differences between this dialog and the common file dialogs. Specifically, the most frequently used context menu commands have been explicitly located on the dialog. Furthermore, Microsoft added instructions for the functions on the dialog itself.
What we find most interesting is the timing of this change: Internet Explorer was released long after Windows95. Now we could be mistaken here, but we can only surmise that the change was the result of observed difficulties with the use of the context menus. We welcome all alternative explanations.
Cancel? - Not.
Of course, if a user selected one of these functions inadvertently, such as deleting a file, they could simply hit the Cancel button to undo the changes, right? Wrong. Unlike all other dialog boxes, the Cancel button on the standard file dialogs does not undo the changes that have been made, it merely closes the dialog. This is probably because standard file dialogs are not supposed to allow any changes to occur.
Roget's Syndrome
What does "Open" really mean anyhow? That depends on a number of things, most importantly, which 'Open' function you select. If you clicked on the button labeled Open, the current application would attempt to open the file for editing, which was the purpose of providing this dialog. If you selected the context menu item Open, however, several different things might happen, depending on the type of file you clicked on. If you "Opened" an executable file, Open would start, or Run the application. If you clicked on data file, Open would start a parent application for the file, then Open the data file with the parent application. The one thing the context menu Open does not do is open the file with the current application.
Standards are for Breaking
At about the same time that Microsoft released Windows95 with the new Common file dialogs, they also released Office95, the flagship of their software development efforts. Interestingly, the developers of Office95 decided against using the Common file dialogs of Windows95. Rather than allowing the user to take advantage of the benefits of Common dialogs, Microsoft decided to create unique dialogs for Office95. Does anyone at Microsoft talk to each other?
One particularly frustrating aspect of the Win95 common dialogs is that they ignore the requests of the user. As shown in the above image, the user attempted to save the file with the name 'test' and the extension '.bch'. The common dialog chose to ignore the user's extension and add one of its own, resulting in a file of the name 'test.bch.txt'.
Unbeknownst to Windows95, users may actually have a need to assign a file extension other than those that have already been registered. Perhaps the user is creating data files for a particular application, or is trying to manipulate the sort order of files displayed in Explorer.
The problem is not a question of ignorance: Windows95 is perfectly capable of determining if the user-specified extension is already registered (e.g., 'test.doc' would not be renamed 'test.doc.txt', nor would 'test.htm' be renamed as 'test.htm.txt'). It seems to be a question of arrogance: if the user adds an extension that has not been registered, Windows95 assumes that the user has screwed up, and therefore it appends an extension that it feels is appropriate.
© 1996-2000 Isys Information Architects Inc. All rights reserved.
Reproduction in whole or in part in any form or medium without express written permission is prohibited.
GP designpartners provide this mirror — for educational purposes only — as the interface hall of shame is no longer maintained or available at its original home, www.iarchitect.com [a domain apparently abandoned and taken over by a search spammer ...].
you can view this file in its original layout: file95.htm.
please drop us a line if you happen to know anything about the whereabouts of brian c hayes of isys information architects, the author of this »interface hall of shame« [and fame].
