The idea is not force them to think, but just make the decision-making process easier. Often the users skip all text and go straight to the buttons; if the labels are clear, they can make the decision quickly. If they need to go back, change their state-of-mind, read AND understand the text to see if they should choose YES or NO, the GUI may be flawed.
Some links: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGWindows/chapter_17_section_6.html http://developer.kde.org/documentation/standards/kde/style/dialogs/simple.html 2005/9/5, Alain Michaud <[EMAIL PROTECTED]>: > Hi, > > I think that in general, you can not force people to read or even > think > if they do not want do it. Usually when the computer crashes two or > three times then they start worying... This is human nature. > > One idea would be to randomly change the position of the buttons or > the > question, size of the form, etc... > > Alain > > > > On Mon, 2005-09-05 at 17:04 +0200, Michael Van Canneyt wrote: > > > > On Mon, 5 Sep 2005, Alexsander Rosa wrote: > > > > > After years of development with this kind of dialog box (with a > > > caption, a message ending with a question and buttons labeled Yes, No, > > > Cancel etc), I've noticed than most non-tech users actually do not > > > READ the message, they just read the labels of the buttons and click > > > Yes or No (rarely Cancel), almost automatically - no thinking at all. > > > > > > I did some GUI and usability research and found that many experts > > > suggest that the labels of the buttons should state the action that > > > will be performed. IIRC, Open Office dot Org does that: when you try > > > to exit when the text has changed, instead of the classic "Save > > > changes?" (Yes, No, Cancel) it says something like: "There are > > > changes." (Save, Discard, Cancel). The experience shows that users > > > read the buttons, not the message. > > > > > > Of course it's simple to write such a dialog box, but it would be nice > > > to have it as a built-in feature, to educate new developers and create > > > a standard. This would also solve this language problem, as most text > > > would be provided - except, maybe, "Cancel", that could be defined > > > globally somewhere or at least have a default text. > > > > I think this can be easily implemented as an overloaded form of > > MessageDLG, where instead of [mbOK,mbCancel] you pass the captions of > > the buttons. > > > > MessageDLg('File has changed. Save Changes?',MB_WARNING,['&Save','&Don''t > > save','&Cancel'],0) > > > > The first button is the default button, and the function returns the index > > of > > the pushed button, or -1 if the dialog was closed by closing the window. > > > > Michael. > > > > _________________________________________________________________ > > To unsubscribe: mail [EMAIL PROTECTED] with > > "unsubscribe" as the Subject > > archives at http://www.lazarus.freepascal.org/mailarchives > > _________________________________________________________________ > To unsubscribe: mail [EMAIL PROTECTED] with > "unsubscribe" as the Subject > archives at http://www.lazarus.freepascal.org/mailarchives > -- Atenciosamente, Alexsander da Rosa _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
