One of the interesting things I learned at the last Ubuntu Developer Summit was the widespread use of implicit save in the GNOME environment.
Implicit Save (or can also be called instant apply or instant editing) is when changes made by the user are automatically saved by the system without the need of the user confirming the changes by performing a Save or Apply action (implied to be so by the action of the user making the change). Explicit Save is when the user explicitly confirms the change by performing a Save or Apply action.
In many cases, implicit save makes a lot of sense and makes the configuration and interaction with options much more natural. For example, consider (Ubuntu) GNOME’s Appearance Preferences dialogs. The widget theme selected is the current theme. Select a different theme and it is changed immediately and automatically:
The immediate apply is pretty neat, but there are a few things that have me worried. There is no obvious “out” for the user. If you are trying out themes and want to go back to your original one, you have to remember which theme was selected. Otherwise you’re stuck. (I’ve been told that clicking the X button in the window decorations instead of Close will reset your options, but this doesn’t work in the Appearance Preferences nor the Internet Proxy dialogs).
This safety net may not matter so much for changing window decorations or fonts, but it matters a lot when you are configuring more important system-level settings such as Internet proxies. Say a user is exploring network options and comes across the Internet Proxy configuration dialog. They click on a few options to configure a proxy but change their mind. The Close button in the dialog is a bit ambiguous and doesn’t give a hint as to if it will save the new options or not, so the user clicks the X close button on the window decoration thinking it is the same thing as Cancel. Now their network settings are messed up. When the user begins having network trouble, it is unlikely they will remember they reconfigured their proxy information because they think they cancelled the changes.
Look at how KDE handles changes in System Settings. Although the dialogs aren’t as well designed (we’re working on that), guessing the result of a user’s actions is much more clear, and an “out” option is provided to users who may have forgotten they made changes while they were browsing the dialog:
The problem with the current GNOME implementation is that it doesn’t support users who make errors. There are many reasons why a user could make an error when configuring a dialog, but the types of errors which would result directly from the dialog design (i.e. not user knowledge errors) would be attention-based: forgetfulness, interruptions, multi-tasking, etc. Also, users tend to “start over” when a task becomes too complicated or they think they’ve made a mistake. You can’t do that with these dialogs. Also, almost all of the dialogs use implicit save instead of selectively where it makes sense.
Although many long-term GNOME users may have adjusted they way they work with dialogs because of this behavior, your KDE and Windows users are going to suffer. OS X is selective about when it uses implicit save — when it makes sense, and provides revert/apply options for particularly sensitive options.
However, there are a two easy fixes alleviate some of these problems:
- Change Close to OK. Close is neutral and wont help the user when they’re not sure what will happen. In GNOME, Close has a bit of a negative twist to it because of the orange X icon associated with the button. OK is positive and when you click it, is like saying “I am OK with the information in this dialog”.
- Add a Revert or Undo button so users can get back to the original state of the dialog information if they need to start over
- Optionally, I would also change the window close button (X) to be a Cancel function instead of the current Close (OK) function. Users resort to controlling the window instead of the dialog when they are in doubt and don’t want to save their work.
As I’ve been discussing, implicit save isn’t something we really do in KDE, but it does get used in a few places. Here are two good applications of implicit save in KDE:
KNotes. When you create a new KNote, new notes are saved automatically as well as any text changes so if you close the note and reopen it, all of your changes are there. There is no need to explicitly save every text edit and since the information is very ephemeral, there is no need for a history of changes. Undo is supported.
Konqueror. The bookmark editor is updated automatically and there is no need to explicitly save your changes. Although the interface does not confirm destructive actions such as deleting a bookmark, it does support Undo and Redo actions so you can recover a bookmark you might have accidentally selected.
In summary, here are some pros and cons I can think of involving the use of implicit save.
- Makes sense in certain information contexts, especially when dealing with ephemeral data
- Supports tasked-based workflows more naturally without the need for supportive interaction procedures
- Easy to adapt to or relearn in cases where explicit save was previously used
- Isn’t appropriate for many types of information tasks which makes creating guidelines for use and implementation difficult
- Difficult to manage and easily abused since good guidelines would be difficult to write
- Can be destructive and hard to recover from; in many cases and will increase the number of user errors (lost data or unstable system)
I’m interested to hear what the KDE community’s thoughts are on this. Is implicit save something we should be investigating? I think it’s use in Plasma could be valuable, but this is not something I would recommend for configuration dialogs.