Programming : Undo Adds Usability to our Frictionless Desktop

Everyone who has used a graphical computer interface has experienced modal popup dialogues. These are the small windows typically with “OK” and “Cancel” buttons which appear in front of the application. These modal dialogues are extremely popular with developers and are available in almost every user interface library.


JavaScript alert dialogue.

I believe there are two main reasons for the pervasiveness of modal popup dialogues in graphical interfaces. The first is their simplicity. Usually the programmer only has to think up a single phrase to display in the dialogue, and write a single line of code. For example, in JavaScript it requires only one function call:
alert('This is my message to the user.');

The second reason is because of their blocking behaviour. Usually launching a modal popup dialog will pause the application in the background and wait for the user to click “OK”. Once the dialog has been closed, the programmer can continue performing the action which the message related to. Ensuring that each step of the program is executed in order makes programming much easier as there are fewer things to worry about. This is similar to the current difficulties programmers are having with taking full advantage of multicore processors. If there are many actions happening at the same time, it is harder to keep track of them all.


GTK+ message dialogue.

While the ease of implementation makes modal popup dialogues attractive, they have several usability disadvantages. The most important for me is the annoyance of windows popping up and blocking access to my work. Another important issue is that fact that humans are prone to habit forming, and if they see a similar popup many times they will start to click “OK” as a habitual reaction. This is aggravated by the fact that many modal dialogues warn about dangerous action which cannot be undone.

The recommended solution for these disadvantage is to allow the user to undo an action instead of warning about it. Aza Raskin, a very smart usability guy from Mozilla has shown the usability benefits of undo in Gmail. Google’s implementation is one of the most popular examples of this pattern. Since they will frequently want to perform an action, but only infrequently want to undo it, this interface design is much less prone to habit forming, and requires fewer clicks to get the job done.

The GNOME desktop and its Human Interface Guidelines provide good instructions for the use of modal popup dialogues. In cases where it is not yet possible to avoid a modal dialogue GNOME applications do a much better job at making them usable. For example the GEdit dialogue which prompts the user to save a modified document lacks the standard “OK” and “Cancel” buttons. If the user neglects to read the text, which frankly she is likely to do, she can still understand the purpose of the dialog by reading the two words “Save As” in the bottom right.

GEdit's modal, but well designed, unsaved changes warning.

GEdit's modal, but well designed, unsaved changes warning.

Another one of my favourite usability developments in the GNOME desktop in the last few years has been the use the passive yellow message panes to show messages. Important information can be given to the user without distracting her from the task at hand. Additionally the message can remain in a yellow message pane indefinitely and kept for reference whereas a modal dialogue must be closed immediately.


This message pane can be found in popular GNOME applications such as GEdit, Brasero, Evince and, since our last release, Jokosher.

By reducing the number of popup dialogues, we can avoid distracting users from the task at hand, reduce the friction in our interfaces and create a better desktop. Many of these usability advantages can be implemented individually by each application. By sharing best practices we can create consistent and usable interfaces as the passive yellow messages demonstrate.

However for a more integrated desktop, we must cooperate even further and cannot rely on each application to work individually. While replacing undo with confirmation dialogues within applications is very important, we should also think about how the desktop itself can benefit from it. Instead of confirming when the user decides to close an application, the desktop should allow a window to be reopened with a simple undo button.

Many applications prompt the user to save the current document when exiting. However there are other applications which do not use documents but still store important information that can be accidentally destroyed. As a developer, the example most important to me is the terminal. Often times I have had many lines of important output from an application and accidentally closed the window. In recent releases, GNOME terminal will show a confirmation dialogue if there is a process still running in the terminal window which will be killed. However in a perfect world, I should be able to close without confirmation and reopen the window instantly regardless of whether there is another process running or just the output of an application that I need to take a look at.

GNOME Terminal will prompt the user if a process is still running.

GNOME Terminal will prompt the user if a process is still running.

In the case of GNOME terminal, it would be reasonable to make use of the UNIX process model. When a window is closed, the corresponding process could be suspended and resumed at a later time if the user wishes to undo the window close. For other applications such as those which deal mostly with documents, we must notify the application that the user wishes to close the window so that it can prompt the user to save the document and save any other data to disk.

The Jokosher window showing a loaded project.

The Jokosher window showing a loaded project.

Like many GNOME applications, Jokosher will prompt the user to save the project and provide three choices.

Like many GNOME applications, Jokosher will prompt the user to save the project and provide three choices.

If you forgot to save your document, or just want to continue working on it, you can undo the closing of Jokosher.

If you forgot to save your document, or just want to continue working on it, you can undo the closing of Jokosher.

I have constructed a working mockup of an application which allows the user to undo the closure of the window. When the window is closed, the user is prompted to save, data is stored on the disk and resources are released, but the process does not terminate. For example an application such as Rhythmbox would pause playback and any background tasks such as importing songs. From the user’s perspective the application is no longer visible and appears to have quit even though the process has not terminated. The application then waits in the background for the user to click the provided undo button. If ten seconds pass, the application is automatically terminated. Ideally we would keep the process in an idle state indefinitely, however while the application can release most resources, it is still occupying memory.

The Gmail developers have encountered a similar problem with their labs features allowing the user to undo sending of an email. Since it is not technically feasible to revoke an email which has already been sent, this feature instead gives the user a ten second window to undo the action before the email is actually sent. More accurately this is cancel with a timeout disguised as the undo pattern, however in some cases it is necessary to do.

Gmail Labs' undo send feature.

Gmail Labs' undo send feature.

While I agree on not having undo available indefinitely in the interest of having more RAM available, I do not agree with the current Gmail Labs user feedback. After a message is sent, an undo button will appear. Ten seconds later the undo button will disappear. This gives the user no indication that this action is limited. If they hesitate too long before undoing the action, they will wonder why the undo button has disappeared with no explanation. My mockup includes a countdown to provide feedback similar to the countdown on Ubuntu’s shutdown dialog.

My mockup implements all of the undo functionality and user interface in a single process. However having each applications place small popup dialogs on the desktop is not an effective solution, in the same way that having each application create a popup dialog is not an effective replacement for libnotify. To make undoable applications successful we need cooperation between processes — between the desktop and applications.

One strategy may be to create an extension to the X server protocol and allow the window manager to provide an undo option for any window which implements this extension. Another solution might be to use a daemon and client library similar to the architecture of libnotify. A simple standardized DBus API provided by the window manager may even suffice.

However it is implemented, it is still probably too big of a change to make it into any of the current and legacy desktop environments or window managers. I would like to see this idea explored further in experimental desktops environments such as GNOME Shell which are encouraging rethinking of the desktop. Even for a project such as GNOME Shell this idea might take a lot of work because it requires cooperation from application developers. However it may be necessary to make these large changes in many applications to allow us to break from the past even just a little and make a large change as the Ubuntu developers recently did with the notification system for Jaunty.

The code for the working mockup I created for Jokosher is available in a branch on Launchpad. The code is very simple and requires fewer than one hundred lines of Python code. Feel free to try it out and let me know what you think.

  1. Well I think it’s a brilliant idea!
    In fact I want to integrate your patch into Epidermis!
    Could you release this into the public domain, or under the MIT license? I know it’s only a hundred lines but still.

    • I have taken the relevant parts out of my Jokosher mockup and put them in a small Python library which is released into the public domain. Please download it at the following URL:

      I am providing this code for demonstration only. I would much rather see the undo button available in window managers such as GNOME Shell instead of having each application create their own popup window. However you can use this code however you like.

      Hopefully this works for you, let me know if it does not.

    • Hans
    • June 13th, 2009

    Personally I hope the new GtkInfoBar will replace most dialog boxes (like Firefox does it, few to no annoying dialog windows that pop up in my face there)

  2. This is how applications on Android work. Instead of closing, their state is serialized to disk, and it’s cpu and ram resources released. Then they can be restored when the app reopens. It works very seamlessly, and is fast.

    I would love it if someone made a Vala library for doing this for Gnome 3.0.

    • Milan Bouchet-Valat
    • June 15th, 2009

    No need for a new library. Apps should simply restore their state when starting, just like Firefox does with tabs. They should avoid any loss of data when closing, e.g. the undo history should be saved (for latest 50 entries) to the disk, and the last edited document opened again. Or for the terminal, save the log output (suspending processes is a little trickier).

    Quite basic to do for many apps. Better IMHO than the approach of suspending programs: the problem with not actually restarting apps is that all of them lean memory, which becomes a nightmare after some time…

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 )

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: