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.

Dilemma: When to commit changes when lots of sub-popups?

Say a dialog has your typical Ok / Apply / Cancel functions, but also some stuff that triggers a secondary popup dialog that does some complicated interaction with the user, and it too has Ok / Apply / Cancel.

If you "Ok" the sub-popup, closing it, and then "Cancel" the original dialog...what should happen? Often, in Windows, whatever changes you make to the sub-popup are committed when you OK them, and they cannot be cancelled by hitting "Cancel" from the calling dialog.

This always struck me as a little counter-intuitive...but then so does the alternative! What's a good rule of thumb here?
Teller Send private email
Thursday, September 23, 2004
A design goal of the Be operating system was to avoid modal windows altogether.  It takes some thinking outside the box, but more often than not it is possible to redesign to avoid the dialog.

Personally, I'm not sure I would go to the extreme of no modal dialogs ever.  However, I have to think that modal windows on top of modal windows is a situation to stay away from.  It presents a frustrating user experience.
Ryan Send private email
Thursday, September 23, 2004
++Often, in Windows, whatever changes you make to the sub-popup are committed when you OK them, and they cannot be cancelled by hitting "Cancel" from the calling dialog.

this seems intuitive to me... maybe the first popup should have a "cancel all changes" button?
Kenny Send private email
Thursday, September 23, 2004
Often this is addressed by changing the word "Cancel" to "Close" which signals that the dialog will be closed, but if you thought it was going to cancel... too late!

Not sure how many users pick up on this.
Joel Spolsky Send private email
Thursday, September 23, 2004
In one of our apps, we spent a great deal of time making sure that Cancel really does cancel every single change, and that the user cannot close a panel without Applying (committing) changes that they've made.

In our case, any change to the panel enables the apply/cancel buttons, and disables the close button.
Nigel Send private email
Thursday, September 23, 2004
"What's a good rule of thumb here?"

My assumption is always that if you cancel a dialog then the changes are undone.  If you need a sub-dialog to do your work, that is also cancelled out when you cancel the main dialog.
Almost Anonymous Send private email
Thursday, September 23, 2004
Think transactionally:

- ok/apply = commit
- cancel = rollback and sometimes undo

When you start a dialog from a dialog you have a subtransaction. Theoretically a subtransaction commits/rollbacks within its parent transaction but not too many go the extra mile and implement things this way (the overhead is large and it is technically difficult to implement the nested rollbacks)

As an alternative to the dialog from dialog, add extra tabs within your "parent" dialog. This way you can getaway without committing to any changes until you hit ok/apply/cancel.
Friday, September 24, 2004
I fear that this is an area where armchair opinions aren't worth much. So...

Code is both ways. Come up with a script where the difference matters. Grab the next six people that wander down the hall, and subject 3 of them to each version. Watch what happens.

After this, you'll have an opinion. (Your opinion may very well be to redesign to avoid the situation.)
Jim Lyon Send private email
Saturday, September 25, 2004
I'll go with the last answer. A single opinion will probably end up being the minority.

One consideration is whether the sub-popup is a separate, supporting action, or is a refinement of the current action. For example, from the Print dialog box, defining a new printer so you can print is a separate action; it makes sense for an OK to this to make it permanent.
However, clicking Advanced Printer Options on the Print dialog is clearly just refining the Print operation, and should go away if you cancel the Print dialog.

This is similar to the Save As dialog box, where you can move, rename and delete existing files which are permanent actions. However, setting any options for the same is lost if you then Cancel the Save.
Dave Lathrop Send private email
Monday, September 27, 2004
Interestingly enough, I remember that the MFC property pages had a call to change the cancel button to a close button (CancelToClose) for this type of problem.  It was for modal property sheets, since non-modal sheets supposedly didn't have a cancel button.

I think if the 2nd dialog is really a part of the first, but separated to simplify or make room, cancel should still be an option.  Otherwise, it really takes thought to try to figure out what the user would expect.  I personally think if there is a cancel button, it should cancel everything.
Marty Fried Send private email
Thursday, September 30, 2004

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

Other recent topics Other recent topics
Powered by FogBugz