The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Universal save - Why use it

In the management studio for sql server there is a single save icon that is used to save pretty much anything that is modified. This approach is also used in MS Access, VS and a host of other applications.

I'm writing an app that pops up any number of screens where data can be modified but I have always used Save and Cancel button to manage the persistence side of things.

I am wondering, is there a strong case for forms in a windows app to only have a close/cancel button and with all save actions being managed by a universal save button.

Any insight into use would be interesting to hear.  For my part I find 'travel time' a bit too long each time I need to save - moving the cursor from one part of the screen to the other - but after a while, one gets used to it. Also  The save button on a form makes it immediately clear what options are available. Though just having a Close/Cancel button on the form will reduce visual clutter.

Thursday, January 04, 2007
Does your app use MDI and child windows, where multiple forms can be open at one time?  The only time that I have used the one button saves all is in VS.  For that it makes sense, since each tab shows an astericks for unsaved changes.  Also, each tab only has an X in the corner of the tab, no save button on the form, no close button on the form.

But they also have a save button on the toolbar that only saves changes on the tab that is open.
Thursday, January 04, 2007
A Save and Cancel button per form is only appropriate if users are working on simple discrete tasks on one form at a time, in which case the Save button also closes the form, like a dialog box. It sounds like your users will be dynamically switching and editing multiple forms at once and leaving a set of key forms open for multiple transactions. That implies having a single Save control to save users from tracking what’s been saved or swapping back and forth among the forms to post edits. A single Save control reduces time, clicks, and cognitive effort for your users, as well as reduces the clutter on your forms. This assumes you have a decent Undo feature so users are not force to use close-but-do-not-save as a work-around if they screw up a form and want to start over.

As for mouse travel time, you’ve a couple of options. First make the toolbar button for Save extra large to take advantage of Fitts law, which states that the travel time is inversely related to the size of the target. Use an icon _and_ a “Save” text label to make its function clear and just to take up space. Assuming other less important toolbar controls are a conventional 16x16 pixels, this has the added benefit of indicating that Save is important. Second, provide a Ctrl-S accelerator for Save for experienced users like yourself. I doubt even clicking a Save button is faster than Ctrl-S, especially if the user’s hands are already over the keyboard editing a form.

Because a save-every-form feature is not conventional, Michael is right that you have to be careful that users understand that Save saves everything, or else it defeats the whole purpose. Putting control in the container window of an MDI might help, but the most commonly used MDI apps like MS Excel do not save all open documents with Save. Using a text label like “Save All” for the control might be necessary. Grouping Save together all other controls that act on the app as a whole (e.g., Exit) may also help. Feedback like the asterisks Michael describes for VS will educate the user that Save affects all.

Finally, you mention Access, which of course has implicit save for record input –once focus leaves a record, for example, changes are automatically posted. I believe GMail has demonstrated that implicit save can be practical for web apps too. If you can make your save automatic then you’ve eliminated the entire concern.
Michael Zuschlag Send private email
Thursday, January 04, 2007
I think for the majority of apps, most users operate on one form at a time and therefore, a global Save All button would be confusing.
Greg Send private email
Thursday, January 04, 2007
Please don't use Access as an example of "Good" save behavior.  That program's approach is unique -- save on every mod -- and heaven help you if you need to undo something, or even revert to an earlier state.

Personally, I feel the "there's a version in Memory, and another version on Disk, and you Save to update the Disk version to match the Memory version" approach matches reality.

Sure, it takes a little training for complete newbies to get this idea -- but once they get this idea they're in pretty good shape.  "Hiding" this reality from newbies does no one any good -- they're likely to NEVER save, or the program will auto-save FOR them to some random location which then fills with files.

Using metaphors that match reality is one way we all develop a common understanding and vocabulary, which then allows us to act effectively.
Thursday, January 04, 2007
Having said that, the typical way this is handled is to have a 'dirty' or 'edited' bit to keep track of which 'windows' are modified.

If the user then closes the application with some windows still 'dirty', you prompt the user to save or discard changes for each of those windows.  Give him an option to Save All too, why not?

But the less 'mind reading' the program does, the better, usually.
Thursday, January 04, 2007
So, AllanL5, we can start implementing autosave when computers start shipping with solid state drives?  The users' perception of "reality" can evolve along with the technology?

I, for one, think that's completely bogus. 

Current technology doesn't make harddrive reads and writes fast enough, so we keep a copy in memory.  That certainly doesn't mean we can't push those changes onto the harddrive when the user won't notice.  OneNote does this and I think it's great.  Don't confuse what you're used to with the Right Thing To Do.

In any case, that's not what the OP asked.
Thursday, January 04, 2007
Ideally, the user creates work for the computer to do, but saving is an example of the computer creating work for the user to do. Anything like that is a candidate for automation. User interfaces are all about hiding such things from the user. For example, the location of a document in your folder hierarchy has no real relation to the physical location of the document on your hard disk platters; heck a single document may be divided among several physical locations, but users don’t see that. AllanL5 is right that automation has been misapplied in various apps resulting in faulty “mind reading,” but it’s hardly mind reading for an app to save by default anything the user inputs until the user explicitly indicates otherwise. However, I agree that you don’t want to use implicit save unless the technology is ready for it. Universal is describing a form interface so I assumed input of maybe a dozen fields will be stored in a database. At least in the desktop world, implicit save has been feasible for databases like that since at least the early 1990’s.

Right now, implicit save is so novel that in my experience its use has not resulted in users failing to save in other apps. On the contrary, the only problem I’ve had is assuring certain users the save really is automatic. This whole don’t-forget-to-save business generates a lot of anxiety in users that contributes to their fear of computers.

However your app saves, you should always support incremental undo/redo for some large number of transactions. The close-but-do-not-save technique is an ugly work-around we should never have had to teach users.
Michael Zuschlag Send private email
Friday, January 05, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz