How and when to gently prompt user to save between pages

Question

I am working on a complete rewrite of a complex, multi-step and enterprise-/internal-facing web application. The existing application's UI was literally based upon Excel spreadsheets that had been previously used to fulfill the business need. The users loved Excel, which they found to be quick and flexible. However, they hate the 1998-ish web forms that replaced them a few years ago.

For the new application, we conducted detailed workflow analyses and user research, from which we identified four major steps within the end-to-end business process. We adopted a tab metaphor to create "swim lanes" in which multiple sub-tasks could be completed while maintaining the context of a primary step (read: tab).

To create a fluid and seamless "Excel-like" experience, I wrote the original UI spec to support auto-save, undo, and re-do across multiple tabs. However, our technical architect objects to the amount of coding and maintenance required to do any of this. So, we've compromised on prompting users to save changes when navigating between each major step. However, within a major step, a user might interact with up to a dozen forms contained within sub-tabs. Users need to be able to quickly move back and forth between these secondary tabs (which maps well to the task analyses). Sticking with the Excel metaphor, I therefore want to permit users to dynamically navigate back and forth between these sub-tabs without a barrage of save reminders and field validation interruptions. This is where we've reached a stalemate.

So, I'm reaching out to the UX universe to solicit best practices for gently prompting users to save changes with minimal disruption to the users' thought processes. I also want to avoid modal or javascript popups wherever possible, but so far, I haven't come up with an alternative to the dialogue approach. Because this is complex and data-intensive business process, I want to reduce users' cognitive load and minimize the frustration that constant save reminders would likely impose.

Answer 1

One of the ways I have seen unobtrusive messages appear (usually with attached action buttons) are the flash messages appearing at the top of a page. This is the type of bar that appears in Firefox when you first start it informing you about your rights

I have seen this pattern being used on multiple websites and seems to be catching up. An overlay message that blends in with the current UI yet still able to get the attention of the user. The user is then able to decide whether to take action or complete their current task and attend to it at a later time.

When to prompt the user would possibly depend on the average amount of information that gets processed by a single user at a given time before considering to save. You could have the message appear in general after a certain time has passed, or after counting how many sub-forms have yet to be saved.

In general, grouping the sub-tasks and attaching each group to a prompted unobtrusive save would be the simplest approach.

Answer 2

One method that I've used in the past is to be explicit about how much time there has been since the last save. Just have something like '7m since last save' in a bit of the screen where the user will scan. We put it in a bar under the main nav on the left. We basically had three states:

1. If it had been less than 5m we didn't show anything
2. >=5m and < 10m we showed the time since last save
3. >10m we showed the time since last save in bold and red

Seemed to work okay - but we didn't test alternatives. This was in the context of having under/redo and 'save' being the equivalent of 'commit the changes so everybody can see them'.

---

On the undo/redo front I'd be interested whether you could dig a little deeper into the reasons why the technical architect thinks that this mechanism would be difficult to implement. There are pretty well established patterns for doing this in code (e.g. http://en.wikipedia.org/wiki/Command_pattern), so I suspect that there are some interesting reasons why they can't do this.

Digging into the detail of the reasons why undo/redo can't work may provide some information that will allow folk to figure out more appropriate alternatives.

For example - the 'save' operation might have the effect of publishing data that other people can immediately start using and affecting future decisions. So 'undo' is impossible because third-parties may already be using the data. Or having extended editing sessions without a save might be hard since it involves having an extended lock on the data so only that individual can edit it, which causes roll on consequences elsewhere.

I can think of lots of ways for this not to be a 'bad' decision on the part of the technical architect given the constraints of the project - but by understanding more of the details of why it's hard we might be able to come up with better options.