Skip navigation.

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:

Drag the icon to a directory viewer

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:

Saved in ~/Documents/Letters

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:

Uncompressing some files

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

RISC OS drag-and-drop

Time to call for *customizable* Save dialogs?


I certainly agree that the ROX/RISC OS saving system is much better than GNOME's. And it is a pity that GNOME developpers do not seem to want it...

An interesting point in the document you quote is uncertainty: there is a need for experimentation. And the best thing for this would be to give the user the ability to plug the kind of dialog box she/he wants.

Let us dream further: maybe one day all application on my desktop will have the same kind of Save dialog box. Newbies trying to install a KDE app on a GNOME desktop (or the converse) soon feel lost just because dialog boxes are different (I am not even speaking of other apps such as gv or (x)emacs...).

I do not pretend to impose my favorite kind of Save dialog box to everybody, but I would much welcome the ability to have the same kind of dialog box for all applications. And in my opinion the only sensible way to achieve this is to make people agree on a service (be it implemented as a program, library, or whatever) that all applications would use for their Open/Save dialog boxes. Then the choice of the implementation of the service and its configuration would just be an ordinary customization of the desktop: it would be chosen by the administrator or the user. If I remember correctly, pluging a new kind of Open/Save dialog in the system was already possible on Mac OS more than ten years ago...

So instead of pushing straight away for the ROX/RISC OS solution, it may be better to ask for that kind of pluggable/customizable Open/Save dialogs, which would help experimenting and would improve competition. Then, I guess a ROX/RISC OS plugin would soon appear, and I would happily choose it :-)

My 0.02€...

Pluggable saveboxes

Yes, this is the goal. The ROX-Lib saving interface allows support for the default GTK boxes without modifying applications (just ROX-Lib), although no-one's ever asked for it to be implemented before ;-)

The ability to swap may also be important for people with diabilities which prevent them from using drag-and-drop, for example.

Automatically replacing the GTK boxes with DnD ones is harder, because the GTK interface has a load of functions which don't do anything with drag-and-drop (e.g. gtk_file_chooser_add_shortcut_folder_uri) and the MIME type isn't given (this is needed to set the icon, and when dragging to other programs).

Also, it just returns a filename to the application, so dragging to other applications can't be supported. ROX-Lib asks the application to write to a stream.

However, given those limitations, it is still possible to make it save to a directory using drag-and-drop. Stephen Watson made a patch for the old GTK 1.2 version:

It's also possible to replace the GTK saving widget dynamically. Plash does this with its --powerbox option.

A final issue is applications that add extra widgets to the box. ROX boxes are very small (to allow DnD easily with other programs), while the GTK ones are very large, so a widget that looks good in one will be the wrong size for the other.

Syndicate content