| Date: | March 8, 2006 / year-entry #85 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060308-09/?p=32013 |
| Comments: | 12 |
| Summary: | Some people have noticed that there is no message that lets you disable the Cancel button on a wizard. This is on purpose. Usability studies reveal that users find it extremely frustrating when they get partway through a wizard and then decide they don't want to perform the operation after all, but find that the... |
Some people have noticed that there is no message that lets you disable the Cancel button on a wizard. This is on purpose. Usability studies reveal that users find it extremely frustrating when they get partway through a wizard and then decide they don't want to perform the operation after all, but find that the wizard doesn't give them a way to cancel. Now the user feels trapped. They can't back out of the operation; they're being forced to finish something against their will. Imagine if you went to an e-commerce site and started going through the checkout procedure, then decide that you didn't want to buy the item after all, yet the web page disabled the Back button and didn't have a Cancel, and when you clicked the "X" button to close the web browser, the page put up a message box saying, "You cannot cancel this operation once it has begun." Not a very pleasant experience, and I suspect you would avoid this web site in the future. The same principle applies to wizards. Users should always be given a way to cancel out of a wizard. Wizards should, generally speaking, collect information in stages, and apply them at the point the user clicks Finish. This is not always practical, and wizards may have need to commit partially-made decisions along the way, but that's the general idea. Under such circumstances, the wizard author should make it clear to the user whether cancelling the operation will undo the previously-committed decisions or leave them intact. If you are clever, you can do this without an annoying confirmation dialog. Instead, you can indicate this by the flow of the wizard itself. For example, you might have a wizard that goes like this:
With this wizard flow, clicking "Next" to go from page 2 to page 3 commits the initial XYZ setup, as indicated by the text "Your XYZ is now ready to use." If the user decides to cancel out of the customization, you've made it clear that the XYZ has nevertheless been set up and cancelling will not undo it. |
Comments (12)
Comments are closed. |
(Yeah, this is nearly a dup of a posting from last month. Sorry. Didn’t realize it when I wrote it.)
Clippy said: "It looks like you’re trying to write a duplicate post. Do you want help?"
:-)
Well at least this time through I have some design guidance.
It would be nice to be able to disable the Cancel button at least on the final "conclusion" page of the wizard. For example, many Setup programs use wizards; after the "Progress" page (which does the actual install) you see the "Conclusion" page saying something like "Program XYZ has been successfully installed." And here you’ll see a Finish and Cancel buttons. It would be nice to be able to disable the Cancel button here, since the process has already been completely finished.
You’re assuming that people actually read the wizard pages. That assumption is frequently unwarranted :)
Who disabled your Cancel button? Time to report to the debugger room RCH3N and get fixed.
You can disable the cancel button using the PSM_CANCELTOCLOSE message because a wizard has no OK button. Maybe this isn’t supposed to work?
As an example… http://www.mutexed.com/code/JoinExt/wizard-iv.png
PSM_CANCELTOCLOSE is legal only for property sheets. Using it for wizards results in undefined behavior.
8: On the Office/Windows Installer issue, that’s because Word is trying to dereference several different WI-controlled GUIDs, and none of them are installed. So every single time it tries to dereference one of them, WI pops up the dialog, which you have to cancel.
Then, eventually, you’ve made it through all the GUID-dereferencing code in Word, and it comes up.
(WI uses GUIDs because that makes it possible to set components to "install on first use", where they’re present according to the app, but not taking up disk space until they’re needed. Apparently many Office programs abuse this feature, because even if I install Office XP Pro in "full" mode, with nothing set to "install on first use", I still get the WI dialog the first time I open each Office program. Which means each Office program is trying to use something that isn’t installed. Sigh.)
Thanks for the explanation. Install-on-demand can actually be useful. A shame though that we get to face it so often. So this begs the question, why can’t WI and Word better work together so WI can install the missing components in 1 run instead of several?