The Principle of Least Profanity

Dianne Hackborn and I are in disagreement. This isn’t the first time, and it probably will not be the last. Usually, I do not blog about these, but this one seems important enough to discuss.

A StackOverflow question came in the other day, inquiring about the UX patterns for saving of data. The questioner points out that many of the built-in apps seem to automatically save on the BACK button, and that felt a bit wrong.

Ms. Hackborn indicates that, indeed, this is the recommended UX. If the user begins making a change, those changes should be deemed permanent if the user does not quickly revert them. BACK button, HOME button, incoming calls, etc. would all save the changes. The most likely implementation of this would be to save the data in onPause() or onStop() of the affected activity.

I agree that there are some scenarios where this may be appropriate. I disagree that it is a universal axiom. In fact, if too aggressively applied, it will cause people to fear their phones, which hardly seems to be in Android’s best interests.

For example, let’s consider a spreadsheet. While spreadsheets are probably not terribly popular in phone form factors, they will be more likely candidates in tablets. There are clear and expected patterns for persisting changes in a spreadsheet — notably, it does not happen unless the user positively requests the changes be saved. Excel does not save changes because the user minimizes the window, for example. Hence, users tend to be sloppy, testing out various things in the live real spreadsheet, with a plan to not save those changes. Should they be making a copy of the spreadsheet for experimentation? Sure. By the same token, they should be reading the manual, and we all know how well that works.

Saying that an Android spreadsheet application should automatically overwrite the old spreadsheet with a modified one, just because the user accidentally bumped the HOME button, seems ludicrous. More generally, if users feel they are no longer in control over when what they type in gets permanently applied, they will simply stop typing things in.

Designers refer to this as “the principle of least surprise”. I think of it as “the principle of least profanity” — your UX should minimize the number of curses hurled in your direction as a result of your UX.

In onPause() or onStop(), you should be taking steps to ensure that what the user has done in the current activity is not lost. What that means will vary by circumstance, to minimize surprise and profanity:

• A game may save the game state, overwriting the previous saved game. This is consistent with the UX in other games in other environments and therefore should not be surprising.

• A complex data model, such as a spreadsheet, should be persisted to some temporary spot, to be retrieved when the original spreadsheet is next opened or something. Not automatically overwriting a spreadsheet without explicit authorization is consistent with the UX in the leading spreadsheet apps (going back to VisiCalc) and therefore should not be surprising.

• Things that involve transmitting the data to third parties should be saved in some sort of draft as well. Bear in mind, though, that this not only includes things where you are directly sending stuff to third parties (e.g., tweets, emails) but where simply saving it “to the cloud” might trigger something to be sent to third parties. For example, saving a bookmark might not be considered “sending”, but if the bookmark Web service allows others to follow someone’s bookmarks, then “saving” is equivalent to “sending”, even if that is not obvious to all parties.

• Some things, particularly those with no “prior art” from a UX standpoint, may be able to create their own patterns, and therefore may elect to “edit in place”…so long as the changes can be reasonably easily reversed. For example, in the standard AOSP Contacts app, accidentally clicking on Add Contact results in a permanent modification of your contacts list — even if you back out of the contact editor activity, you wind up with a more-or-less empty contact in your contacts list. This is annoying, but it may be that this annoyance is worth it to avoid either the user losing edits to a contact because a phone call comes in or having to deal with some form of “draft” changes to the contact.

Again, I am not arguing that “edit in place” is intrinsically dangerous and should be avoided. Rather, it is a UX technique that will have its places. However, “edit in place” can be surprising in other places, resulting in profanity, and so the technique should not be blindly applied.

In other words, think before you save.