tables - When to save data?

When should I save data in an business application?

We have a lot of applications and currently they have not all the same behavior. I am not very experienced with UX and would like to know when I should use AutoSave behavior and when a Save-Button.

The main applications have all a tree-structure on the left hand side and on the right hand side you can edit some data for the selected item in the tree. The data is separated and displayed on different tabs.

The behaviors we have:

1. Tree is saved automatically; data saved on tab-changed or application closed and selected item of tree changed


2. Tree is not saved, only when save-button is clicked. No tabs on right side.


3. Tree is saved automatically; data is saved automatically, except there is some invalid data.

The data is often displayed in DataGrids (WPF).

Answer

You pretty much want to go for one or the other extreme, where the extremes are:

• 
  

  Explicit Save for Everything. Everything needs saving through an explicit command.

  
  
  


• 
  

  Autosave Everything. Everything is saved automatically and instantly.

  
  

You want the user to have as simple a mental model of the system’s behavior as possible. You don’t want to burden the user with trying to

• 
  

  Predict when they need to explicitly save and when they don’t .

  
  



• 
  

  Understand that the system won’t let them perform certain actions because they haven’t explicitly saved some edits.

  
  


• 
  

  Figure out what action triggers an autosave (e.g., changing a tab).

  
  


• 
  

  Deal with the need to close a window or pane to commit their changes (in many situations, users prefer to keep a few key windows constantly open so they can easily return to them periodically as their work dictates).

  
  

To achieve this, Explicit Save for Everything should work like this:

• 
  

  No edits in the window –neither the tree nor the tabs –are saved until the user explicitly selects a Save command.

  
  


• 
  

  A single Save control saves all changes in the window, both for the tree and the tabs.

  
  


• 
  

  The users can make an arbitrary number of changes to everything in the window before selecting Save. A user can change the tree, multiple fields in multiple tabs, and multiple database records in the window, and then a single click of Save saves all changes. The system never forces the user to choose to Save or not before doing something else, except when the user tries to close the window with unsaved changes.

  
  
  

Autosave Everything should work like this:

• 
  

  Everything in the window is autosaved, both changes in the tree and changes to the tab.

  
  


• 
  

  An exception can be made for input to dialog boxes, but these should appear as separate small windows (or lightboxes, if you insist) with the familiar OK and Cancel buttons. As always, dialog boxes should be limited to just a few fields –something the user can complete in 20-30 seconds.

  
  



• 
  

  Autosaves are performed immediately for each meaningful atomic user input. If the user clicks a radio button, that change is immediately saved. Edits to small text boxes are immediately saved when the text box loses focus or the user hits enter. While the user is editing the text box, it should preferably assume a “tentative” graphic appearance (you need to test what this may be).

  
  


• 
  

  Ideally autosave should be combined with auto-refresh, where objects a user is viewing are automatically and promptly updated with changes made by other users. The idea is to get the users away from this complicated mental model of them working on a copy of objects, and get them thinking they are working directly on the real objects -that the UI is a like a physical control panel.

  
  


• 
  

  Undo is necessary for any app, but it’s especially important to have sophisticated multi-level undo when you have autosave.

  
  

The choice between Explicit Save for Everything and Autosave Everything depends primarily on the performance capability of your system. Generally if your bandwidth can handle Autosave Everything, do it. The requirement to save remains a user error waiting to happen. It also adds work to the user. It’s about time autosave became standard for all apps.

However, precisely because requiring save is an error waiting to happen, just about every user has lost a tragic amount of work due to not saving, turning nearly all of them into compulsive savers. Autosave can thus make users anxious, and you may not want to use it unless you can through training and documentation repeatedly assure users that their work is automatically saved.