ThinkFlood Blog

“Primum non nocere” — first do no harm. Doctors consider this advice when planning for the care of a patient. The idea is to pause a moment before embarking on a course of treatment in order to ensure that the remedy is not worse than the illness.

In keeping with the spirit of minimalism, perhaps usability design should also adopt such a slogan. Let’s call it “preservation.” It is absurd to think that all the tools we might make would leave the in-process object or data completely unmodified – most of these tools would be useless if they could not make some changes. Instead, the idea of preservation is to eliminate (or at least to minimize) irreversible modifications.

On page 68 of his book The Inmates are Running the Asylum, usability champion Alan Cooper makes a compelling case for the practice of allowing action reversal:

Humans generally don’t make decisions in the same way that computers do, and it is quite normal and typical for a person to change his mind or to want to undo a decision he made earlier. In the real world outside of computers, most actions can be deferred, changed, or reversed. There is no reason that this can’t also be true for software-based products, except that the programmers who create them don’t think that way.

In fact, I will go one step further than Cooper. Not only do we change our minds, but we are much more comfortable using a product when we know we have the ability to make a mistake without worrying that the whole thing will come crashing down around us.

Let’s think about the consequences of preservation for a moment. If I can change my mind later, then I feel free to experiment, to poke and to prod, to explore the limits of the tool I am using. If something does not turn out the way I wanted, I can always go back and try a different path. In this manner, when I have control over final outcome I am the master and the tool is just a tool. By contrast, if the tool does not offer preservation then I become a slave – trying to figure out how the tool wants me to act, encountering frustration when I make a mistake, and generally withdrawing for fear of making a bad situation worse.

In fact, the principle of preservation is quite common in design today, though perhaps not as prevalent as it should be. Here are a few examples:

1. Backwards and forwards navigation. The fact that you are reading this posting means that you are familiar with web browsing and the back and forward buttons. Especially when navigating a poorly designed website, most of us rely upon the back button to find our way on the Internet. Unfortunately, some of the slicker approaches to web design (Flash, AJAX) make the back button meaningless.
2. Undo/redo. Undo is an old standby that harks back to the original Macintosh. Newer improvements include virtually unlimited levels of undo, undo past save points, and even non-linear undo (i.e., undoing a particular action while leaving the rest of the action chain intact).
3. File backup and recovery. File backup is nearly as old as modern computing, but somehow most of us do not bother with it. Online backup services seem like a great idea, since we can store additional copies of our data in remote locations for a higher level of security.
4. Versioning. When paired with a good file backup and recovery system, versioning is a powerful tool that allows us to recover different snapshots of a file or database, potentially rolling forward or backward to find the instance that we want. There are also application specific versioning implementations (for example, Microsoft Word can store multiple versions of a document in a single file).
5. Non-destructive editing. This is a relatively new addition to the preservation bag of tricks, but it is one of my favorites. Some of the more robust photo and video editors allow us to store modifications to the media separate from the media itself. Thus, we can apply filters, adjust colors, and make many other changes without messing with the original image. In this way, we can come back to the file at any time in the future and immediately get back to the original image without any quality loss. Or we can create multiple different versions for different effects or uses.
6. Data consistency. We commonly use checksums and cyclic redundancy codes in networking protocols and data storage devices to ensure that data input and output operations have integrity. Databases also implement locking mechanisms to ensure transaction atomicity.

There are also other areas where we do not see enough preservation in design. For example, I consider software security under the umbrella of preservation. If I enter a transaction online, I want the privacy of my financial information preserved from identity theft. Any security expert will attest that it is easier to design a secure system than to add a layer of security to a system that is fundamentally insecure.

The real issue with preservation is that it can be difficult to implement. For example, non-linear undo can be a nightmare, because there may be dependencies among different actions taken. A great example of a mediocre implementation of preservation is the trashcan/recycle bin metaphor. Rather than implement a real file backup and recovery system (which would require external backup devices and additional management), we throw files away in the trashcan and then can retrieve them later if we realize that we made a mistake. However, personally I rarely undelete a file, and often when I do need to undelete something, I find that I have long since emptied the trash. Annoyingly, Windows XP insists on confirming with me every time that I try to delete something, and then again when I empty the trash. On the Macintosh I do not get these prompts, but I am not sure that I am happy with that, either, since there is no protection against my own stupidity.

Traditionally, arguments against preservation were that it required extra storage capacity or more intensive calculations. However, as storage costs plummet and computing power skyrockets, it is hard to find against things like file backup and non-destructive editing. I believe that the real reason we do not see more preservation designs is laziness on the part of the implementers.

While it may be harder to include preservation in our designs, the payback is real. Preservation does make life better for the people that use the tools we provide, and they are more likely to have a satisfying experience as a result. Moreover, they may be more willing to overlook other design flaws if we can guarantee that no harm will come to their data or possessions. Minimalism helps us to decide whether to include a feature. But once we have decided to do something, we are always better off if we can provide preservation as part of the implementation.