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.
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.
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.
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.
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.
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.
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.
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.