Dialog asking to save changes when doing a selection change?

Question

In our desktop application we have a viewer which shows the content of a selected item (both, viewer and list, are located in the same window). When the user selects a different item, its content will be shown. The user needs to invoke a different command to get a full-blown editor (in a separate window) for the item's content. Now the users request to be able to edit the content directly in the viewer (turning the viewer into an editor). They suggest to show a dialog asking to save if a different item is shown, if the user cancels the dialog, the selection change should not be possible. IMHO this would be a GUI blooper. I tend to leave it as is or, if the user starts to edit something, it does not change any more on selection change until the user has saved or discarded the content. Saving would be simple by providing a save menu item/toolbar button, but how about discarding (so the viewer will react on selection change events again) - does anybody ever saw a discard menu item/toolbar button? What do you think?

Answer 1

Very good question actually.

I think there are two ways to deal with this:

1. The editor is a dialog box or a separate window.
2. The editor is not a dialog box or separate window. E.g. it's a properties pane on the main window.

In the first case it is simple: the user can do all the changes he wants, the changes take effect after he presses OK or Apply. (The changes are saved when he saves his document.)

In the second case I believe the changes should always take effect immediately. (The changes are saved when he saves his document.)

I believe it is best to keep a clear distinction between these 2 options, and not try to make a mixture of both.

I understand the concern that certain people may have with approach nr 2: what if you accidentally change something? There are 2 answers to this question:

• You could foresee an undo/redo function in your application. By experience I know this is technically hard to implement because as soon as you introduce an undo function, users expect it can undo any change.
• Users can always revert to their last saved version of the document.

I know this is a very debatable answer, but the point I do believe is that you must keep the clear distinction between the 2 options. Trying to add "apply" or "revert" buttons is in my opinion not a good solution as it breaks up the distinction. The solution with the popup message asking the user to apply the changes or not is also very awkward. As a user I expect changes to take immediate effect except in dialog boxes that have an OK and Cancel button.

Answer 2

Yes, it’s is a blooper

Sounds like a case study of why users typically make poor designers. But while users may not be great solution-finders, they tend to be good problem-identifiers. The first thing you need to do is understand why they want to edit item content in the detail pane of the main window rather than in a separate window. Maybe you can solve the problem another way without introducing new ones.

Or maybe the users are on the right track to allow content editing in the main window. Maybe users need to do a lot of small changes to many items in the list. Maybe they often find themselves needing to make a quick edit to one item based on what they saw in another item in the same list. Those are good reasons for making the detail pane editable –it improves the UIs efficiency, saving users the hassle of a lot of opening and closing of windows.

But then your users blow it by specifying an intrusive Save/Don’t Save message box for merely changing the focus in the window, precisely what you don’t want if users need to make a lot of quick edits and compare items.

Yes, saving should be simple

The solution is to make saving work like it does for any other desktop app. Users are never forced or prompted to save, except maybe when closing the window. The Save command should save all changes in the window. That’s all changes within and between items. Build a capability to buffer multiple edited item contents and save them all at once when the user selects save.

An even simpler Save command is no Save command. Instead, automatically implicitly save all edits –not just to the item content but to the items in the list and to anything else in the app (for consistency). Alan Cooper has been calling for implicit save for years, and some web apps are doing it. Desktop apps can do it even better.

Meanwhile, Undo (you do have Undo, don’t you?) undoes each incremental edit whether it be within or between items, allowing users to undo no more than necessary –rather than have to make an all-or-nothing decision at a time when maybe they don’t know the answer.