Search the site
What we do
Little Springs Design is a mobile product, research, design, and usability testing consultancy. We help wireless operators, associations, manufacturers, and application & website providers with product and UI design, patterns, training, research and strategy.
Contact us today.
Downloads
Sign up to get a free copy of our Mobile Widgets Whitepaper or almost-monthly newsletter. Or buy mobile Java or web design guidelines.
Recent blog entries
Blog topics
Blog archives
yes/no, ok/cancel
This document may contain formatting or content that cannot be saved in the OpenOffice.org 1.0 Text Document file format. Do you want to save the document in this format anyway? - Click 'Yes' to save in OpenOffice.org 1.0 Text Document file format.
- Click 'No' to use the latest OpenDocument file format and be sure all formatting and content is saved correctly. Yes No
I want to save in the same format I've saved it in the last 45 times I've saved the file. Do I click 'Yes' or 'No'? This user's answer: "no idea; I make an error on this one on a regular basis."
There are several problems with a dialog box like this one (similar dialog boxes appear in mobile app, mobile web, fixed web, fixed app, and many many other platforms all the time).
First, the question shouldn't be there in the first place. I've answered the question for this file before. Why bother me with it again? I don't want to always answer this way, just always for this file.
Second, it doesn't check to see whether the current file would lose anything; it tells me this even if the file is pure text. A bit of logic to alert me only if formatting will be lost would be a good plan. (Especially since the file in question is in the older format!)
Third, and easiest to fix, are the yes/no buttons. The button labels should give cues to the action to be performed. In this case, "use .sxw" and "new .odt" would work fine. The user should be not have to read the dialog text, especially the second, third, or 45th time around. And no, OK/Cancel buttons are no better unless you are truly canceling an action.
From a developer perspective, yes/no buttons, like OK/Cancel buttons, are favorites because the tools have preset dialog boxes in which the developer just has to add the relevant error string, and bam! there's a dialog box. Fortunately, it really only takes 2 extra minutes to call a slightly different object and put useful labels on the buttons.
In the mobile space, I frequently see the button label problem with error messages and query messages. In many of these cases, "Retry" and "Cancel" make good labels (almost always better than either yes/no or ok/cancel). What's most important is giving the user a clue about the action in the button label itself.
I've made this into a draft UI design pattern; I'll refine it in a couple of weeks --- or you can!
No Comments »
No comments yet.
RSS feed for comments on this post.