The first time I went through the exercise of writing a GUI design guide was in the early 1980’s (very much pre-Windows). In the years between I have written a moderate number of GUI applications, but most of my work has been non-GUI, so I often spend years not thinking (much) about GUI design.

My most recent task was to add a customized “File” “Save As” dialog to a desktop application. Not too big a deal, but once running I had this nagging mental itch … I knew there was something wrong, but could not first at figure out what was bugging me. Pulled up and compared the File Open and File Save dialogs as used on Windows, Macintosh, and Gnome (Linux). Finally it clicked - they are all wrong.

Take the File Open dialog. Choosing a file to open is a selection task - the file to open must already exist.

  1. What is the first most-likely task? Choose a file from a (short) list. The list could be most-recently-used names of saved files. The list may be files in a particular directory. Probably a bit of both.
  2. What is the second most-likely task? Choose a location from a (short) list. This is not a generic browse-anywhere-on-disk gadget. This is an application-dependent list of a small number of places where you might have files to open.
  3. Less likely is the need to browse to an arbitrary location on disk. This is where “progressive disclosure” kicks in, with the expectation that most users will never need or want to see this part of the user interface.

This is entirely different organization than the usual File Open dialog, and the usual dialog is wrong. The first task should be the first thing in the dialog, not buried amid a bunch of controls you are mostly not going to use.

The interesting bit here is that of all the platforms, the Gnome File Open dialog is - not perfect by any means, but the closest to fitting the task. Guess I need to pay more attention to the Gnome folks. :)

This is not about “dumbing down” the user interface for average users. This is about “smarting up” the work done by the programmer. Think about this … if your application has ever saved files, shouldn’t that list of saved files show up in the File Open dialog? Of course, the standard File Open dialogs do not fit this usage. Seems pretty silly that the list of “recently used” files (when supported) are not available as an immediate choice when opening a file.

The File Save dialog is for an entirely different task.

  1. What is the first most-likely task? Entering an name for the new file to be saved.
  2. What is the second most-likely task? Changing the location where the file is to be stored. Again, this is a short list, not anywhere on disk.
  3. Less likely is the need to browse to an arbitrary location on disk. Again, this is the point to apply “progressive disclosure”.

Again, note this is different from the usual File Save dialog, and the usual dialog is wrong.

Again, the Gnome File Save dialog is a notch above pretty much everyone else.

Looking at the new dialogs in Windows Vista, without doubt I find the visual appearance “cool” … but not well designed for the task. Bit disturbing that - as I Microsoft with all their money can afford to hire good user interface design folk. What has gone wrong?

Update: Two added notes.

First, I do not have access to a Macintosh (last Mac I used regularly was a Lisa) so I have to go off screenshots on the web (seem to remember looking at a design guide on Apple’s site). Not ideal - so the OS/X behavior is only a guess. Sure wish Apple had OS/X in a VM for developers, so I could test web applications and web-launched applications to insure compatibility.

Second, the recently-used-files list (when present) is both finite and distinct from the File Open dialog - both of which are silly as default behavior. The history of recently opened files should be accessible from the File Open dialog. Using the same notion, the File Save dialog should “remember” the recently used directories for saved files. You want a single locus of attention in either case.