User Mental Models of Persistence in RIAs

First A Little History
Rich Internet Applications are widely believed to be the new paradigm for application development. This is the most exciting thing since all the desktop applications had to be ported over to the web 5 years ago. THAT was the most exciting thing since all the client server applications were ported to the desktop 10 years ago. The technology industry reverses its opinion about whether computing power should be centralized or distributed every five years or so, seemingly as regular as the tides or the seasons.

Of course, every computing platform has different features and drawbacks, so applications never make it through a transition without changing significantly. For example, when all the corporate business apps were ported to the web, drag and drop disappeared. HTML just didn't support it, and so a whole interaction paradigm disappeared.

Similarly, when applications were ported to the web, the way that user data was saved changed dramatically without anybody noticing. When the user navigated from one page to the next, their data went back to the server, and NOT saving it meant that it had to be stored somewhere on the server until it could be saved to the database at a later date. So web applications typically save a users work automagically, every time an act of navigation is performed.

This is the exact opposite of how desktop applications operate. In a typical desktop application, user data is saved every time the user selects File->save, (or control S). That model had been criticized by usability professionals for years (most famously by Alan Cooper). It relies on the user understanding the difference between RAM and hard disk, an implementation detail that is irrelevant to most users. This flawed model was fixed (by accident!) in the move to web applications.

RIA Persistance Models
How Rich Internet Applications will behave is up for grabs. This issue has not arisen until now because the early adopters of Flash-based UIs were either game developers (with no user data to save) or transactional sites like brokerages or e-commerce sites (where the data is sent to be saved at a particular time, when the user explicitly initiates a transaction). But now RIAs that allow users to "work on their data" are starting to emerge, raising the question of what their model for saving user data will be. Desktop accounting software would save user data on command. An accounting web application would save data automatically. What would an accounting RIA do?

The user expectations here are almost certainly that an RIA will behave like a web application (since it is running inside their browser). However, history shows that developers will implement the persistence model most convenient to them. As I will show, implementing the web application persistence model in an RIA presents significant technical and design challenges.

The first challenge is managing error handling for automatic saves. The saves would certainly be asynchronous (since avoiding latency during navigation is one central reason people are switching to RIAs in the first place). However, the internet is flaky technology, and background saves will fail with some regularity due to an internet connection going down. This is not a problem with web applications because when the internet connection goes down, the navigation breaks, so the user knows there is a connectivity issue. In an RIA, the user could work for hours without an internet connection, as long as they don't request any resources from the web. But if the system is saving without their knowledge, than it must let them know when the saving mechanism breaks (so that they don�t do an hour's worth of work that can�t be saved and is lost). The user will probably get information about a connectivity problem some time after the failed save, so communicating what has and what hasn�t been saved becomes a real design problem.

The second challenge is technology: saving constantly requires a way of making sure that save requests are saved in the order that they were emitted (if change 4 gets committed before change 3, and requires data that was input on change 3, an error condition will result). Of course you have to worry about what happens if change 3 never makes it at all: do you resend? That might be a good idea. Before you know it, you've basically redesigned http or a similar network protocol. These kinds of programming issues are hard, and frankly might not even be cost-effective to address within an individual application.

The Desktop Persistence Model: Most Likely to Succeed?
Given the design and technical issues above, I think that it's likely RIAs will follow the desktop / client-server model of saving on command, and informing the user at save time if there is a problem. Since that is the case, "save" buttons should be prominent, and extra care will need to be taken with labeling and workflow design in RIAs. Users are expecting RIAs to behave like a web site: not meeting this expectation brings up real usability issues that will have to be carefully managed. RIAs should use standard components that are evocative of desktop applications, and will have to explicitly communicate throught their design that unsaved work will be lost if the user leaves the site without saving it.

Subscribe to or Bookmark this site

Add to del.icio.us
Digg this
Post to Furl
Add to reddit
Add to myYahoo!