UX best practices in applying persistency

Question

I am looking for UX best practices in applying persistency. I'm referring to an application's ability to "remember" the user's previous actions and preferences to make it easier for them to use the system. This can include things like table filters, sorting, selected options on a menu, or chart view preferences.
Are there guidelines for which preferences should be kept and when? Are there relevant articles or research papers on this topic?

Answer 1

Definitions

There are various levels of persistency:

• Primary persistent: The settings (including any settings in a dialog or other secondary window) persists as long as the primary window (a non-dialog) remains open. However if the user opens another primary window in the same program, its settings are default.

• Session persistent: The setting persists for the session with the app, so once the user sets something in one primary window, any other primary window they open will also have that setting. However, if the user closes all windows and exits the program, the next time the user opens the program, the settings are default.

• Object persistent: The settings used with a particular object(s), content, or file that is current presented persists for a given user across windows and sessions. However, when the user opens a different object (even to repopulate the current primary window), the settings are default, or whatever they were the last time the user opened the object.

• User persistent: The settings persist for a given user across all objects and sessions for a program. Basically, they function as user options or preferences.

Depending on your app, some of these levels become synonymous. For example, if your app can only show one primary window at a time, and it only shows one thing (the user can only change how that thing is viewed), then primary, session, and object persistence are one in the same. If your program has no secondary windows, “primary persistent” is really “not persistent.”

The Guidelines

Looking through general guidelines, like those for Windows, you’ll see that if and what level something should persist depends on the kind of setting and context, so there’s too many to list here. For example, in Windows and OSX, the object (e.g., file) is generally not persistent. When the user re-opens a program, they’re presented with a blank document or a list of documents to select, rather than the last document the user worked on. In contrast, mobile apps persist the object and its appearance right down to scroll position to the point that there is no functional difference between “closing” an app and “changing focus” to another app. Generally, dialog settings are primary or session persistent, but Window 7 UX guidelines recommends not persisting number of copies or page range in the printer dialog. On the other hand, the guidelines recommend object-persisting the current tab of a properties box.

There is a tendency towards recommending higher levels of persistence than you often see in programs. I suspect that’s because higher persistence often means more programming work, so developers don’t bother. For example, it’s relatively easy for things to be primary- or session-persistent since the necessary information can be held in the session, but object- and user-persistence requires explicitly saving to and retrieving from the disk somewhere.

General Principle

Perhaps more useful for your purposes is to decide on the persistence level you should have case by case for each setting of your application by following this principle:

Make it persist if the current setting is more likely to be wanted later by the user than the default setting.

Where “later” means later in the window, later in the session, later when looking at the same thing in different session, or later looking at something different in another session.

What this principle often means is that, if the user is continuing on the same task as last time, make it persist. Your user research tells you if this is the case or not.

For example:

• Dialog box settings (e.g., Find criteria, Save folder, Print paper size) generally should be at least primary persistent and could be object persistent because if the user has done it once in a given primary window (or on a given object), they’re likely to want the same or similar thing the next time they do it in the same window (or on the same object). However, if they open another primary window to work on something else, chances are they working on a different task, so don’t be session persistent –don’t carry over the dialog settings between different primary windows.

• The “presentation” in the primary window (window position, size, zoom level, sort order, filtering, even scroll position) are candidates for object persistent if in the next session that the user works on the same objects, the user is likely to be continuing where they left off (e.g., continue reading a .pdf or watching a movie). However, there may be some issues in some apps if objects appear like they were presented long ago. For example, if the user forgot about a document (e.g., had only skimmed it briefly), they may not realize they’re not at the beginning if it opens scrolled to their last position. Also, as mentioned above, object-persistence is harder to implement and sometimes hard to even define (e.g., when presenting, not one object, but a variable set of multiple objects, like the results of a search or query).

Case-by-case Analysis

Ultimately, though, it comes down to applying the principle to each kind of setting in your application, and different kinds of things will have different levels of persistence. For example, imagine a map viewing program that supports multiple primary windows, and thus multiple simultaneous views of the world. When launching a new primary window, should it show a default starting view (e.g., zoomed in on the user’s current location with the usual layers and filters), or a duplicate of the view of the current window (which may be panned, zoomed, filtered, and layered to show something far different than the default)? Well, why are users launching a new window? If usually they starting a new separate task to look at something unrelated to the current window, show the default. On the other hand, if they’re launching a new window to preserve the current settings while they try modifications of it to compare, then at least session-persist the settings in the new window.

Mitigations

If there are gray areas between default and current setting being desired later, or if persistence is technically difficult (true for a lot of web apps), there are some other design features you can include to have a similar effect of various levels of persistence.

• If the settings are not user-persistent, but occasionally they should be, you can have a “Save as Default” feature that overwrites the default with the current settings. Alternatively, if settings are user- or object- persistent, you can have a “Reset to Default” feature to re-apply the designer-selected settings. In the case of our map example above, it might be a “Show My Location” feature. Reset to Default is especially helpful to rescue users who really screw up their settings (“where am I?”) and just want it all back to normal.

• As an alternative to object-persistence, you can have a Recent menu of objects to work on, where various settings, including the previous presentation for the object, are re-applied when retrieving the object in this manner. Or, more broadly, you can have “resume last session” feature, maybe as a checkbox on the Login window, to re-display the entire workspace as the user left it in the last session.

• You can allow the user to save the current settings, perhaps to a named configuration, to be easily retrieved and applied later. This may be necessary if there are multiple complex combinations of settings each for a different recurring task. That gives more flexibility than just “persist current” or “use default” options.