Interaction design and usability for data persistence and transactions

Most applications deal with data that needs to be stored persistently — that is, saved — so that it can be accessed later. A “persistence concept” or “transaction concept” is an explanation, at the user-interface level, of how this works in your application.

To help us understand what’s involved in interaction design for persistence and transactions, let’s first look at how data is saved in two typical classes of applications: document-oriented desktop apps, and multi-user web and client-server apps.

Document-oriented desktop applications

For document-oriented desktop applications, like word processors and spreadsheets, documents are usually saved as individual files on a disk.

When a user is working with a such an application, there is a copy of the document stored in the working memory of the user’s computer. As the user edits the document, the copy in working memory is modified, and so it will no longer match the copy on disk. By saving the document, the copy on disk will be updated to match the copy in working memory. If the user makes changes to the document and then closes the document or closes the application without saving the document, then the changes will be lost.

Most people with computing experience are familiar with this model. You can indicate that your application uses this model by following standard conventions (which can vary between platforms). There should be “Save” and “Save As…” commands under the File menu, and (especially on Windows) there may be a “Save” icon in the toolbar. On Mac OS X, a black dot appears in the red “Close Window” button whenever unsaved changes are present, and this dot disappears after the document has been saved. On Windows, some applications place an asterisk next to the document title in the window’s title bar when unsaved changes are present.

The dot in the red "Close Window" button indicates unsaved changes are present

Some usability specialists argue that the need to know about the separation between working memory and persistent storage is a “leaky abstraction” — an underlying aspect of the technology that is exposed to the user, creating an unnecessary mental burden. The Canon Cat was a unique word processing system in the 1980’s that hid the distinction between working memory and persistent storage. No “Save” command was offered because the system automatically synchronized all changes with the copy on disk. The popular word processing application Scrivener similarly saves all changes automatically every few seconds, meaning that users never have to worry about explicitly saving their work. Diverting from the conventional way of doing things can initially cause users confusion, though, and so Scrivener still offers a “Save” command in the File menu for convenience, even though it’s never really necessary.

Web and client-server applications

For most web applications and client-server applications, data is usually stored in a database (which in turn stores the data in files on a disk). Database systems allow many different users to access the same data simultaenously.

In applications that are backed by a database, when a user creates, edits, or deletes data in the system, these changes can be accumulated in units called transactions. If other users of the system retrieve data from the database while the first user’s transaction is still in progress, the other users will not see these changes. But when the software issues a “commit” command for the first user’s transaction, the transaction is ended, and the user’s accumulated pending changes are saved “permanently” to the database so that other users of the system can see the user’s changes.

If instead a “rollback” command is issued, the transaction is also ended, but all of the pending changes for that user’s transaction are cancelled, and the database is not updated; other users see no changes in the data in the database.

Most applications hide the technical concepts of transactions, commits, and rollbacks from the user. This hiding is done by aligning the start and end of transactions with places in the user interface where various events or task flows start and end. Terminology is also used that is more familiar to the user.

For example, we can image that when a dialog box such as a Properties dialog is opened, a transaction will be started. If the user closes the dialog or presses the “Cancel” button, then the transaction will be rolled back and any changes the user had made in the dialog will be lost. If the user presses the “OK” button, the user’s changes in the dialog will be committed to the database.

For multi-user systems, you also need to think about what happens when two users try to edit the same information records simultaneously.

Imagine a situation where two users are attempting to make changes to the address information on file for a particular customer. The original address on file is “123 Main Street”. User A opens the address record and starts changing “123 Main Street” to “456 First Ave.”, while seconds later, User B opens the same address record and starts changing “123 Main Street” to “789 Second Ave.” If User A presses the “OK” button to save the changes, and then User B presses the “OK” button shortly afterwards, what happens to the data on file? There are a couple of possibilities:

• User A’s changes get saved, but then User B’s changes overwrite User A’s changes. So the address on file at the end is “789 Second Ave.”
• User A’s changes get saved, but User B’s changes are ignored because User A was first.

Neither of these is particularly satisfying, as both users will think that their changes have been saved, but one user will have had their changes overwritten or lost without their knowledge.

One solution to this issue is to use some form of record locking: When User A opens the customer record, the system locks that record, so that if User B attempts to open the same record, she receives a message that the record is locked and unavailable for editing. When User A commits or rolls back his changes, then the lock is removed and the other users can edit the record again. One problem with locks is that if User A leaves his terminal and goes home, or if User A’s application or operating system crashes, the lock might be “stuck” in place for a long time, requiring an administrator to intervene so that other users can edit the record again.

In many applications, it makes sense to want to allow multiple users to view the same record simultaneously, but only one user at a time should be able to edit the data. This raises the question of whether users who are viewing a record should be notified when the data they are viewing has been changed by another user. If there is no notification and if the display is not automatically refreshed, the user will be looking at “stale” data that was at one time correct, but no longer matches the current state of the database, and this may or may not be a problem depending on the nature of the application.

Collaborative web-based applications where users work together on editing the same document can present many challenges like these, and it can take some creative thinking to find usable and non-intrusive solutions to avoid or manage simultaenous editing conflicts.

Designing and documenting a transaction and persistence concept

We’ve seen that an application’s learnability and usability can be impacted by how it handles the persistence of data and manages multi-user editing conflicts, and how the persistence model is presented via the user interface and interaction design. Therefore, explicitly designing how these aspects will work from a user’s standpoint is a good idea for applications of significant complexity.

Questions you need to ask and eventually make decisions about include:

• What types of data validations take place, and when is the validation performed? How are errors and warnings presented?
• Can data or documents be saved when validation errors exist or when mandatory fields are empty?
• At what points in the application can data be saved? How and when can any changes be lost (intentionally or unintentionally)?
• If the system uses transactions, where do transactions begin and end?
• Does the application save data automatically, or does it rely on the user to use some form of “Save” or “Commit” command? Are controls such as “Save” menu options or toolbar buttons prominently visible, and is it clear to the user how and when to use them?
• How is the user interface structured to help user understand the persistence or transaction model? Is the state of the data (saved or unsaved) made clear?

You’ll often need to clarify some of these questions with the technical architects and developers in your project, as the technology framework being used can often dictate how some of these aspects will have work. At the same time, just because the technology requires things to be done in a certain way does not necessarily mean that you have to expose all of the details to the user; technical details can be hidden. Whenever possible, create the design that is clearest and easiest for the user, and then build the system to support that way of working.