Usability of desktop apps, or why file menus are not needed

Usability of desktop applications has been a concern for me for quite a long time. I’ve been thinking about it lately and came to some conclusions that I’d like to share. I have the feeling that modern desktops are mostly stuck in a dead end with usability, and M$ takes credit for most of it.

I’d like to explain one aspect of usability with an example, that is creating, editing and handling a text document. I’d like to start with how this is usually done on all desktops I know (Windows, KDE and GNOME) (sorry if I include details that seem obvious to anybody but the completely computer illiterate, I have my reasons):

  1. Start the text application (for example OpenOffice Writer). That includes knowledge of the existence of such an application and that this app is needed to edit texts, navigating something like a start menu to find the application.
  2. The application comes up with an ‘unnamed file’ and an empty edit area.
  3. You start to write something. At some point you need to save it (hmm. this includes you have to know that there are two states of your data, the copy in RAM and the copy on your harddisk.) So you navigate the thing that is called ‘file menu’ and choose the save option (urgs, there’s also ‘save as’). Now you’re presented with a dialog that is similar but not exactly the file manager you know from the desktop and are prompted to enter a filename, because so far the file has been ‘unnamed’.
  4. At some point you’re done and want to close the application. Navigate file menu to the exit menu entry (what’s this to do in the file menu anyway?). You’re prompted with the question if you want to save the file etc blah blah.

In an ideal word, the above steps are full of usability problems. At least from my point of view, things would be much more intuitive the following way (if people weren’t so much used to the above way that is):

  1. Navigate from the desktop to a folder where you want to create the file (maybe including creating new folders on the way).
  2. Choose option ‘New File’ in the file manager. This will ask you which type of file you want to create. You select ‘Text File’ from a list and enter a file name.
  3. The file is opened and you find yourself in an empty editor area. Note that there’s no need to distinct between the file you have open and the application that actually does all this. This is a detail that the user should not need to know about. The user should care about his files, not about applications.
  4. Edit away with the file. Actually, there’s no need to save the file, because the data in RAM is kept in sync with the data on the HD quite cleverly. And of course, the undo buffer is saved along with the actual file.
  5. If you’re done, choose the standard close option for each window (like the small cross in the upper right corner). The ‘application’ has no need to ask questions at this point because all the data is already in sync with the HD, see point #4.

Now, if you think this further, you will find that many concepts in the so called modern desktops are actually not needed and only hinder usability and simplicity of the desktop. There’s no need to have a start menu, there’s no need to have a distinction of (data) files and the application that are used to edit them, there’s no need for a file menu, etc etc.

So why was all this invented in the first place? Most of these concepts date back to the good (ok, they were actually pretty bad) DOS days, when there was no such thing like a graphical desktop, but applications like MS Word were already good enough to have menus and mouse support. At that time it made sense to have a distinction between apps and data files (because there was no file manager), it made sense to have a file menu (because there was no file manager and the computers at that time didn’t have enough resources to keep RAM data and HD data in sync in a useful way). That was actually pretty sophisticated at that time.

So, why do modern desktops still stick to these old concepts, which actually seem to be in the way of reasonable usability? Well, the answer is simple. One big rule in usability engineering is to take care of the user’s expectations and habits. People got used to these concepts so much that at one point it actually became impossible to change these concepts. I mean, imagine a desktop without a start menu, without the concept of applications even. Imagine applications without file menu, etc. Kindof hard, right? If M$ decided today to revamp Windows in such a radical way, they would probably loose millions of users. The same is true for KDE and GNOME. Remember the big debate about the spatial nautilus? A pretty radical change in a good direction, not perfectly implemented maybe (it’s much better now, because users can change it to their needs). But it certainly turned away many ‘power’ users (which infact only had pretty strong habits and didn’t want to let loose). This is why we will most likely see file menus in 10 or 20 years still, although they are not strictly necessary.


About Roman Kennke
JVM Hacker, Principal Software Engineer at Red Hat's OpenJDK team, Shenandoah GC project lead, Java Champion

6 Responses to Usability of desktop apps, or why file menus are not needed

  1. alex says:

    Your proposed solution exists in Windows; applications can register “template” files which get added to the “new…” option in Explorer; you can create them, name them and then open and edit.

    However, nobody does this.

    Is this because of force of habit? Because it is not the best solution? I don’t know, really…

  2. Have you seen the Archy Project? It is built around this and other similar ideas…

  3. Well, actually, your proposed workflow, points 1 to 3 already work exactly the way you describe in KDE. And there are major usability problems with 4 and 5, even though people like Alan Cooper have been advocating that approach for ages.

  4. roman says:

    @alex: I suppose it’s appealing to fire up the empty document quickly, hack away and care about the saving location later. See below for an idea how to avoid this nasty location problem.
    @Marcel: No, but thanks. This looks very interesting.
    @Boudewijn: I’m interested about details of these usability problems.

    I’d like to add that I think the idea of having something like a filesystem with folders might be inferior. The user shouldn’t need to care about the actual location. A good search facility like is present in modern OSes does the job much better. Infact, this is what people often do: save the file in a rather flat location (their home, or their desktop) and search for the document, rather than navigate to it. This could also make the begin of the workflow much easier. Rather than navigating to the destination location of the file and creating a new file, we let loose of the file concept altogether. Simply choose to create a new file of type text document, give it a name and let the application choose a location for the data. Be it in the filesystem or a DB or something else doesn’t really matter. A search engine and maybe the last-opened-file history would be much easier and more efficient for finding files than hopping through folders.

  5. I read an article recently about the OLPC Sugar interface not having a file menu. When I saw your title I thought you might be referring to that.

    Personally I often have the need for temporarily gathering or formatting some data. I don’t want to bother with a filename because I don’t really ever want the data saved to a file.

    As to saving the undo buffer with a file, that can be a risk when the user thinks he’s removed something from the file but it’s actually included when he sends it to someone. MS-Word documents, for example, have had a problem with this. (although I’m not sure the un-removed data could be accessed from the undo button)

    The bigger question, though, is why should each file type have only one editor? The beauty of software is the flexibility it gives the user. The flexibility even to have multiple applications that do essentially the same job. But the price for that is the need to be able to name and distinguish the application.



  6. Thomas Zander says:

    as boudewijn said; the second workflow has been available in KDE for many years. Its surprising you didn’t find it 🙂

    Point 4 (in that solution) requires a versioning filesystem as you can’t expect all apps to do the undo themselves.
    It also has major problems in usability like not being able to open the same document in two apps and that you take away freedom to ‘clone’ a document. The last one probably needs a usecase to be explained;
    I have a letter that I wrote to an insurance company. It says I’m moving. I want to open that document, change the names and address and save it as a letter to another company. Also notifying them I’m moving. Note that if I do a ‘save-as’ _after_ I change the address I still have lost my data.
    In other words; not saving means you created a leaky abstraction. And there are corner cases where it breaks down.

    The ‘locationless filesystem’ is something that KDE4 aims to do in its search infrastructure. When the infrastructure is in place in 4.0 I bet that it won’t take long before people start building on top of that to do stuff like you suggest.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: