Gall's Law says that any complex system that works is derived from a working simple system.  Complex working systems do not emerge de novo.  One consequence of Gall's Law is the presence of features in complex systems that really belong in simpler systems, and that now seem awkward and hard to use.  I think the most seriously screwball such vestigial feature of the Mac user interface (including its derivatives like OS X and Windows) is the Standard File Dialog (later called Navigational Services, and now called NSOpenPanel and NSSavePanel).

Simple Beginnings

    From the beginning of the Mac, it was possible to launch a program by double-clicking a document created by that program.  It was one of the most wondrous features of the Macintosh.  Programs put their signature on the documents they created, and the user could launch a program either by double-clicking on the program icon, or by double-clicking on a document.  Users immediately understood that the document method was most efficient and used that.  Once a program was running, a user who wanted to open another document had no access to the Finder.  In those days, before the Multifinder, the Finder was not available once another program was started.  The only choice would be to quit the program and open it again from the Finder using the new document, or to open it by selecting Open… from the File menu.  When you did the second of these, you opened the Standard File Dialog. 

    For the 128K and 512K machines (documented in Inside Macintosh Vols 1-3), the Standard File Dialog was very simple and easy to understand.  At the extreme right the name of an inserted disk was presented above two buttons, one labeled Eject, and one labeled Drive.  You could eject the named disk to make room in the disk drive for a different one.  If you had an external disk drive with a disk in it, you could click Drive, to direct the Standard File Dialog to look at the disk in that other drive.  The rest of the dialog (to the left of the vertical dotted line) contained a scrolling list of every file on the disk readable by the current program.  One and only one file in that list could  be selected. By default, the first file in the list was selected.  There was an Open button that would close the Dialog and open the file, and a Cancel button that would close the dialog box but not open any file.  Yes, the list had every file on the disk that could be read by the running program.  This made sense because disks at that time were small (400K) and couldn't hold enough files to make the list unmanageable. 

    It’s worth mentioning than none of this was inherited from the Lisa user interface.  There is no equivalent of New, Open or Save As  in the Lisa Office System.  The Lisa desktop never goes away, so new documents can always be opened from the desktop.  And new documents are created on the desktop too, by instantiation from a stationary document and opening it.  If a new document is to be made by editing an old one, that new document is made on the desktop, by duplicating the old file.  Lisa users never experienced the Standard File Dialog.

Then Things Got Complicated

    The advent of the hierarchical file system with the release of the Mac Plus in 1986 created problems for the Standard File Dialog.  There was still a need to change disks, so the Drive button had to stay, and there was a need to eject disks to make room for others in the disk drive, so the right hand side of the dialog could stay about the same.  However, now the scrolling list of files on a disk was inadequate.  Files were contained in real directories (not just cosmetic folders) so the path to a file could not be described simply by a volume number and a name, but by a volume number, a hierarchy of directories, and a file name.  To solve this, the Standard File Dialog file list became the thing that Apple user interface designers had warned programmers to avoid, a system of nested menus.

What's Wrong With Nested Menus?

    Nothing, if you can see the entire hierarchy at the same time.  For example, hierarchical menus in the menu bar are fine, so long as they don't get too deeply nested.  As you work your way through the hierarchy of menus, all the previous menus are visible, and you can always look back along the hierarchy and see the other choices you could have taken.  To design a set of menus like that, you have to know ahead of time how deep it will go and about how many items there will be in each menu, to keep it from getting out of hand.  With the hierarchical file system, there was no way of knowing that.  The user could put as many directories as he wanted on a disk, especially on one of the new SCSI external hard disks, and there could be an almost unlimited number of files in each directory.  Now the Standard File Dialog looked like this:

    You are looking at a long list of files, and you can see only a small proportion of them at one time.  They are inside a directory called CIncludes, which is inside a directory called Interfaces.  You can't see what other directories are in Interfaces.  The only directions you can go are up (to the enclosing directory) or down (to a subdirectory you can see in the list).  If the file you are looking for is in another directory within Interfaces (for example in AIncludes or RIncludes), you don't know that unless you just know it, or if you go exploring.  You can use this menu to go up to Includes, then back down to AIncludes, and search the (long) list of files that are in there.  Likewise with enclosing directory MPW and Programming.  If this sounds like the classic game Adventure but without the keys or shiny brass lamp or hatchet-wielding dwarfs or any of the other fun parts, you're pretty much right.  The only solution to this is a well-organized tree of directories and a good memory.  The Standard File Dialog could be even worse if you wanted to write a file.  What is the right directory for that file, and where is that directory in the tree?  If you didn't remember the structure of your directory tree very well, a search for the right directory using the single list and popup menu of the Standard File Dialog was going to be slow going.  And if you wanted to make a new directory to put your file in, well, you just can't get there from here.  You'll have to put it somewhere else temporarily and quit the program, go back to the Finder, make the directory, and move your file to the place it belongs.

Multifinder

    Some relief came with Switcher.  It allowed the user to keep the Finder in memory and quickly switch back there to search around the file system and remember where things were, or make a new directory to put things in.  Then, you could switch back to your still-running program and find the file or directory you were looking for using the Standard File Dialog.  An even better solution for opening files was Multifinder. It became available with System 5 in 1987, more than a year out from the release of the hierarchical file system.  That was about the time that lots of mac users had acquired hard disks and had started to notice that there was a problem.  The Multifinder made opening a file with Standard File Dialog obsolete.  Now you could just click on a Finder window, thereby bringing the Finder to the front, find the file you want to open and double-click it.  Your already running program could come to the front, open your file, and off you go.  Use of the Standard File Dialog to open files became a second, crummier way to do something that was better done in the Finder.  Most Mac users never went back.  Occasionally even now I show a Mac user that you can open a document from the File menu of a program, rather than by double-clicking  its icon in the Finder.  Most are surprised that this exists, express some (probably feigned) interest in having learned that, and never use it again.  The Standard File Dialogs used in Systems 7, 8, 9 were basically the same as in System 5 (despite a name change and a slightly updated look introduced in System 8).  They were a violation of Apple's own user interface philosophy, and nearly useless, but nobody much cared because nobody ever saw them.  That is, until you went to save a file to disk.  And then there was no avoiding it. 

Misplaced Files

    It has never been my job to provide technical support to casual (I mean non-professional) Mac users, but I have helped friends and family members.  Their most common complaint is that after saving a file, they look for it in the Finder, and can't find it.  Sometimes they repeat that 3 or 4 times, thinking they must have done it wrong the first time.  Of course the problem is that they saved it to a different directory than the one in which they are looking.  Because I am not a trained tech support person, I ask a stupid question.  What directory -- er, uh, I mean what folder, did you put it in?  Quizzical look, no answer.  Here is what happened.  She selected Save from the file menu.  This was a new document, so the program put up the Standard File Dialog.  She sees the field for the file name, and focuses on that.  She’s thinking, I have to type a new name for that file. I have to give the file a unique and memorable name that I will recognize later as this document.  That's pretty hard, actually, especially because the name has to be pretty short so it can't be very descriptive.  Think hard and solve that problem, then click Save.  The dialog disappears, and she is done.  Whew.  Of course, there is that little problem of the entire remainder of the dialog.  The part that determines where in the directory tree the file will be written.  Some will say this was fixed by the addition of the NeXT-style columnar directory view in the Dialog box.  I like that view, and I agree that in principle it solves the problem of nested menus.  But the fact that it so nicely reveals the complexity of the directory tree does not necessarily make everything ok.  Most users don't like that view, precisely because it reveals the complexity of their directory tree.  And OS X offers the simple version of the dialog, that is just a popup menu of some favorites and recent places.  Many users don't even know that by clicking the little button to the right of the file name they could reveal the ugly truth about their disorganized files.  Files get written to disk almost at random, and the users file system gets increasingly messed up.  My solution these days is to show them how to use Spotlight or Recent Items to find their files. 

The Solution

    What's done is done, and it's too late to worry about all this now.  In the future, nobody will directly organize files in a directory tree.  Files will be organized automatically and you will interact with them using a database, as you already do with your photos using iPhoto, and your music using iTunes.  You won't need to name your files, you will pick them by looking at them.  A form of this is already partly there in the Finder now using Smart Folders, Preview and Quicklook.  Probably the best use of the time of Apple programmers is to work toward this future rather than fixing the crusty old Standard File Package.  If we could all go back and do it over again, though, I'd be for offering users a solution for saving files that was like the one they found on their own for opening them.  When they want to save a file, don't put up a dialog box.  Take them to the Finder with an icon that represents the file they are going to save, and let them just put it away in the place that they want it to go.

-- BG (basalgangster@macGUI.com)