Flex Article

Designing for Flex – Part 8: Making your application safe

Never lose data

This is the first rule of application safety. Nothing frustrates users and destroys their productivity and their morale more than losing hours of work because of some stupid software mistake. It hardly matters whether the mistake was due to a technical glitch in the system's intended functionality or because the application intentionally failed to take proper precautions. Lost data is lost data, and it should never, ever happen.

Unlike traditional desktop applications, Flex applications are usually connected to the network. This has significant implications for one standard software idiom—the Save operation. "Save" has never made much sense from the user's perspective; the distinction between working memory and permanent storage was an implementation detail that never should have been exposed. But the web environment introduces new complexities. First, documents might need to be saved to the server, an environment the user is unfamiliar with. Second, the fickleness of network connections may cause the client/server communication to get cut off unexpectedly; users need to feel assured that they won't lose their work if this happens.

Fortunately, there is a simple solution that sidesteps these problems. Instead of requiring users to explicitly save their work, always implement continuous save.

Figure 1. Gmail continuously auto-saves drafts of the user's e-mail messages as he or she types. If the user's browser crashes or session times out, the user loses very little of his/her work. Note the "Draft autosaved" message next to the Send/Saved/Discard buttons.

Continuous save eliminates the notion of a user-initiated "save" operation that commits the contents of working memory to disk. Instead, the application manages the permanent storage medium for the user, whether that medium is the hard disk or some server location. From the user's perspective, he is just working, and if he leaves the application and returns, his work is still there in the state he left it in. This is how things work in the physical world, which doesn't have a concept of working memory and permanent storage mediums for such creative tasks as carpentry, automotive repair, and ink-and-paper writing.

The most common objection to continuous save is "What if the user doesn't want to save his changes? What if he is just fooling around and doesn't want his changes to affect the file?" This is easy to solve. When the user opens a document for editing, make a backup copy on the permanent storage medium. Then provide a "Revert" operation that returns the file to its pre-opened state. Which do you do more often: save files or close them without saving? If you're like most people, you almost always want your work to be saved and only occasionally wish to discard it. Thus, it makes much more sense to have an explicit operation for discarding rather than saving.  (More details on replacing the "save" operation are available in About Face 2, listed in Appendix B: For further reading.)

Continuous save has two huge benefits. First, it prevents the user from accidentally forgetting to press the save button and losing his work. This can be a particularly insidious problem with systems that log the user out after a certain amount of inactivity, which isn't uncommon among Flex applications. Second, it minimizes loss of work when the application crashes. Applications should never crash, but they do, so you must plan for this contingency. If a crash occurs, a Flex application should restore itself to the exact location the user was at before the crash, with as much of the user's data pre-loaded into the screen as is available.

Crashes could occur at any time and the Internet is notoriously unreliable. Moreover, due to bandwidth concerns, it may be impractical to constantly stream data to the server every time the user presses a key. Continuous save shouldn't fully rely on network connection availability. Instead, your application should store data in Flash Player's Local Shared Objects or in disk files if targeting the Adobe AIR client between network operations. This behavior must be invisible to the user; from his perspective, he should simply be working on his data, secure in the knowledge that your Flex application is carefully guarding everything he sends its way.

Page 2 of 5

Previous Page

Next Page