Home Updates Messages SandBox

File Open and Save Dialogs

What's wrong with the File menu?

Recently I stumbled upon an interesting project, Haiku Operating System, a continuation of the BeOs spirit. Apart from other intersting things, they have Glass Elevator with some pretty nice ramblings about user interface, among other things. Especially one of the articles, Drag and Drop Save made me think. I realized the "File" menu in applications is "evil".

What am I complaining about? Isn't it, like, uh, standard? Doesn't practically every application have it? Well, exaclty – if it's in every application, if we are so used to it, then maybe we don't see some obvious things?

Miniature file managers

ui-file-open.png

Make an experiment. It should work no matter what operating system you are using, as long as it has a graphical file manager and the "File" dialogs. Open one of each, place them on your screen one next to the other. I have done so on my system, you can see the screen shot on the right. But do try it on your system too.

Then compare them:

I am sure you will find a lot of similarities. After all, the file open/save dialog is commonly used to:

While the file manager is commonly used to:

No wonder they are similar. But how come the file manager window can be so simple when the file chooser window must be so packed with options and widgets, and use these tiny little icons without any thumbnails? Honestly, I have no idea why. I have no idea why there is a need for two separate dialogs at all.

Open/Save alternatives

We grew so used to these dialogs, that it may be hard to think of alternatives at first. But there are, and they are actually pretty neat. What's more, the advances in the technology and introduced standards slowly permit us to finally use them in real applications!

Continuous save

This idea is old, but I started to encounter it in wild only recently. Jeff Raskin described it in his Humane Interface: always save. Make the application open the file at startup, and save every change the user makes immediately. Well, at least make it look so – for technical reasons you may choose to use some cache or to actually only save when the application loses focus – but these are implementation details. This is not as crazy as it sounds – you only have to get used to it. Actually, many applications already have various substitutes for this – like timed autosaving.

Why should the file in memory be any different from the file on disk? It's just an artifact of how the computer storage is organized – and it's not even universally used.

Drag and drop

This idea makes use of your file manager. To save a file, just click on some icon or other control in your application window, and drag it into an opened file manager window (or just on the desktop). You probably need to title the docuemnt somehow before doing this, of course.

This seems simple and actually very smart and cool, but really has a number of problems – in particular, all the problems of drag and drop, plus some more of its own.

I haven't actually encountered this approach in the wild yet, there are no working mock ups as far as I can tell – so it's hard to actually judge how well such a system works. Chances are it's unusable.

Call the file manager

Drag and drop is just one possible way different applications can communicate. There are many more – recently Linux desktop develops really nicely because of introduction of dbus protocol. Other systems also have equivalent technologies. Why not use them?

The scenario is simple: your favorite file manager registers as the standard file manager with dbus or whatever your system uses. Whenever an application needs to do anything with files, it calls the file manager to do it. You get your familiar, favorite interface for dealing with files this way.

Obviously, this is not so simple – the file manager needs to support the additional operations – they are performed from a different point of view. You see, normally graphical file managers operate in the "noun-verb" mode: first you select the object(s) you want to act on, then you specify what you want to do. The file selection dialogs operate in "verb-noun" mode: you have already selected the action, now you have to select the object. So, in order to make them do the work of the other, you end up with "verb-noun-verb": this is how creating directories works in file selection dialogs, and also how selecting a file with a file manager works. Obviously, it's suboptimal.

Others

I'm sure there are many, many more possible solution. I suspect the future lies in one of them – maybe a hybrid of what I described, maybe an entirely new approach. Do you have your own idea of how this could be handled?

What else?

The "File" menu is often much more elaborate than just "Open" and "Save" (or "Save as…"). There is often "Print", sometimes with a separate print preview, print options and page properties entries to accompany it – easily handled by "Saving" the file to the printer. There are sometimes separate "Import" and "Export" entries where the "Open" and "Save" are not enough. There are "New window" and "Close window" (and sometimes a separate "Quit") that belong to the operating system actually. There are "Open recent…" and "File properties" that belong to the file manager. Some applications even have their own user database, complete with logins and passwords! Such is Human Pervesity.