GNOME finds save usability problems

Prolific GNOME profiler Federico has been profiling GNOME usability. The results? Saving is a big usability problem. The list of problems sounds almost identical to the motivation for the ROX saving system, itself based on RISC OS. RISC OS users never save files without knowing where, because they have to drag them where they want them.

Imagine a new office worker who tries to file an important document by dropping it on the floor. Pretty quickly, someone will yell at them to learn the office filing system. ROX does the same. Here's what happens if you just enter a name for a new file and press Return in ROX:

The user must therefore open a directory in which to save the document, and drag it there. When the save is done, the user can now actually see their saved document in its new location:

They know how to get back to this directory, because they already had to open it to do the save. They can also see where in the directory the file is, making it easier to locate it later (the newly-saved file is shown in its final position, but with bold text). Notice too the visual similarity between the icon in the save box and in the filer window.

From the report:

• "A user types a document and hits File/Save. He simply changes the "Untitled" name to "Letter to mom", and hits the Save button. However, the user doesn't notice the actual folder where the file was saved. The next day, he has no idea where to look for that file. Is it in ~/Documents, in ~/, in ~/Desktop? Or did the program happen to pick a totally unrelated folder for the Save dialog?"

With drag-and-drop saving, the user picks the folder, not the program.

• "People spend too much time hunting down files which they just worked on. You receive a mail attachment, and you save it to a folder on your home directory. A few hours later, you need to open that file. Do you remember where you put it? The computer should be able to help you: since you were working with that file just a little while ago, it is likely that you'll need that file again soon. New user interfaces like Gimmie may be the right way to solve this problem: Gimmie is a replacement for the GNOME Panel which always shows you your most recently-used files. Programs need to be made to save this information as appropriate."

If you save by dragging to the filer, then your filer's recently visited feature can already tell you this.

• "Programs pick completely different default folders for their Open and Save dialogs. Some use the current working directory of the program; some always use ~/Documents; some use the last directory on which you worked within that program. The result is that file dialogs are completely unpredictable. One option is to make file dialogs automatically show the last folder on which you worked, regardless of program. However, this needs to be tested on users to see how well it works."

There are several different common patterns here:

• Using several programs to work on files in a single directory (quoted solution above works),
• Using a program to edit source files in one directory to processed files in another (e.g., shrinking a set of photos for an images directory on a web-site), and
• Using different programs for different tasks.

No matter how you pick the default directory, some of these tasks become hard. With drag-and-drop saving, the user can keep as many directories open as they are working on.

For example, to uncompress some files using the Archive application (working with two directories at once, the source and destination), we just click on each file to uncompress and drag to the destination:

To load an uncompressed file into Edit (sharing the 'Letters' directory between both applications) we just click on the uncompressed file (if the intermediate uncompressed file wasn't required we could just drag directly from Archive's savebox to Edit).

To perform several unrelated tasks, just keep the directories needed for each task open. There is no need for any special UI in each application to support this.

So, any GNOME hackers want to add support for this? We have Python code and C code, and there's a full drag-and-drop saving specification at freedeskop.org.