UI guidelines for dialog boxes

Nish Nishant

Hey guys I am working on a set of UI guidelines for designing dialog boxes. I have a few tips ready already. But I am looking for several more. Your suggestions are welcome Dialog boxes 1. All dialog boxes will have a CANCEL button, and when the user clicks the CANCEL button the dialog will be dismissed without any changes being applied 2. Pressing ESCAPE when a dialog box is active will have the same effect as clicking the CANCEL button 3. On Windows based systems, the dialog will have a Close button [X} in the title bar which will duplicate the behaviour of the CANCEL button 4. All dialog boxes will have an OK button and when the user clicks the OK button, the dialog will be dismissed and all changes will be applied 5. Pressing ENTER on a dialog box will have the same effect as clicking on the OK button, except when the focus is on a multi-line edit box 6. The size of the dialog box will be such that it will fit within the screen on the lowest target resolution which by default is fixed as 640 x 480. Depending on the target requirements this default may be raised or lowered. 7. Dialog boxes that accept data entry should be modal. 8. Ideally there should not be more than 10 data entry fields on a dialog box, inclusive of edit boxes, combo boxes, list boxes, check boxes and radio buttons. Text fields are not counted. Under special situations where it is absolutely necessary that there will be more than 10 data entry fields in a dialog, they should be arranged in logical groups using group boxes. 9. The tab order should be sequential and logical. Random jumping of tabs is strictly not allowed. Nish

Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]

ColinDavies

Nishant S wrote: 7. Dialog boxes that accept data entry should be modal. Unless they are Find Dialog boxes in a Document, or have another reason for coexisting. Such as in rule 10. Nishant S wrote: Under special situations where it is absolutely necessary that there will be more than 10 data entry fields in a dialog, they should be arranged in logical groups using group boxes. Unless this is not practical and will make the UI look ugly. Nishant S wrote: 9. The tab order should be sequential and logical. Random jumping of tabs is strictly not allowed. Unless you have a valid reason for doing so such as the user is using a cracked version, and then you should try to do stuff like this for the sheer hell of it. As can be seen in rule 7 10. See rule 9. Regardz Colin J Davies

Sonork ID 100.9197:Colin

I am sick of fighting with Martin, I think I will ignore his posts from here on in, and spend the time working on articles instead. Christian Graus

Chris Maunder

11. Developers who provide dialogs with messages such as 'Your application is toast: Shutting down' with [OK] and [Cancel] buttons, and for which the Cancel button does not cancel the aforementioned toasting of said application, will be taken out back and shot. 12. Dialogs that have the message 'Lame: we need to restart Windows' and for which clicking the 'X' close button, hitting escape, or clicking 'Cancel' (if provided) goes ahead and restarts windows in defiance of the users choice will cause the developer who wrote the code to be staked over an ant's nest and covered in honey. cheers, Chris Maunder

Christian Graus

ROTFL - 12 has my vote for SURE !!!! Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002

Christian Graus

Nishant S wrote: 1. All dialog boxes will have a CANCEL button, and when the user clicks the CANCEL button the dialog will be dismissed without any changes being applied Nope. You're assuming there are changes to be applied, not always the case. Nishant S wrote: 2. Pressing ESCAPE when a dialog box is active will have the same effect as clicking the CANCEL button You get that for free. Nishant S wrote: 5. Pressing ENTER on a dialog box will have the same effect as clicking on the OK button, except when the focus is on a multi-line edit box I think this is something that needs to be judged case by case. How often do people post the 'enter closes my dialog' problem to the c++ forum ? Nishant S wrote: 6. The size of the dialog box will be such that it will fit within the screen on the lowest target resolution which by default is fixed as 640 x 480. Depending on the target requirements this default may be raised or lowered. Too true - I can't tell you how often when developing GrausPaint I realised a dialog was bigger than that. Nishant S wrote: 7. Dialog boxes that accept data entry should be modal. I disagree - rules like this are inflexible and can cause a GUI to suffer for the sake of complying to some arbitrary rule that does not consider every case. If I might say so, this is a combination of things I would disagree with and things I would consider so obvious that I would not allow anyone who needed to be told them near any project I was working on. What is it for ? Another article, or work ? Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002

Chris Maunder

Christian Graus wrote: GrausPaint How much more Aussie can you get than a program called 'GrousePaint' (I assume you merely got the spelling wrong, right? :P) cheers, Chris Maunder

James R Twine

1. All dialog boxes will have a CANCEL button, and when the user clicks the CANCEL button the dialog will be dismissed without any changes being applied Not all modal dialog boxes are used for input. For example, your application may perform some action, and want to show the results of that action. The normal MessageBox(...) may not be enough, and you will want to use your own dialog box. In that case, having both [OK] and [Cancel] would really have no meaning. Having just a single [OK] or [Close] button would do. 3. On Windows based systems, the dialog will have a Close button [X} in the title bar which will duplicate the behaviour of the CANCEL button This is default behavior. The same goes for <ENTER> (see below). 5. Pressing ENTER on a dialog box will have the same effect as clicking on the OK button, except when the focus is on a multi-line edit box The "Want Return" style may modify this behavior. Also note that using <CTRL-ENTER> forces a line break, even if the dialog would normally process the <ENTER> itself (often forgotten by GUI designers). Also, <ENTER> should activate [OK] only if no other "<ENTER>-processing" control (like a button, ListView, or a dropped combobox) (1) is focused, or (2) has the "default button" style. (This is pretty standard dialog behavior.) 6. The size of the dialog box will be such that it will fit within the screen on the lowest target [...] In practice, this is difficult, because settings like font size, and border widths can have a major effect on the size of dialogs and their controls. It is easier to make the interface as small as possible (within reason), rather than try to make a dialog that will take up exactly 640x480 when shown. 7. Dialog boxes that accept data entry should be modal. There are cases where non-modal windows are very useful for data entry. The Properties window in DevStudio is a perfect example: image having to manually dismiss a dialog each time you changed a control's text, ID, or style in the resource editor... 9. The tab order should be sequential and logical. Random jumping of tabs is strictly not allowed. This must also apply to static controls, especially ones that are being used as labels, or groupboxes.

Christian Graus

No, everyone ELSE spells it wrong.... Christian come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002

Nish Nishant

Christian Graus wrote: Nishant S wrote: 2. Pressing ESCAPE when a dialog box is active will have the same effect as clicking the CANCEL button You get that for free. Only on windows. Even on windows VB developed dialogs dont work this way! My guidelines are for multiple OSs. Java written programs also don't default to dimissing on CANCEL Christian Graus wrote: What is it for ? Another article, or work ? Gosh!!!!!!!!!!!! Not for an article!!! Dis you really think I'd write a theoretical article :eek: I am a member of my company's User Experience and Usability group and I have been assigned the task of preparing a set of guidelines for app development on multiple operating system!!! :zzz:

Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]

Nish Nishant

Hello James Twine. First of all, thanks for the reply! James R. Twine wrote: 3. On Windows based systems, the dialog will have a Close button [X} in the title bar which will duplicate the behaviour of the CANCEL button This is default behavior. The same goes for (see below). Not for Java and VB developed applications!!! James R. Twine wrote: There are cases where non-modal windows are very useful for data entry. The Properties window in DevStudio is a perfect example: image having to manually dismiss a dialog each time you changed a control's text, ID, or style in the resource editor... Hmmm. I guess I'll have to add a special case clause for that!!! :-( Regards, Nish

Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]

ColinDavies

Yes I love using

AfxMessageBox("Your computer is toast");

But it is always best ro random seed the appearance of this. Regardz Colin J Davies

Sonork ID 100.9197:Colin

I am sick of fighting with Martin, I think I will ignore his posts from here on in, and spend the time working on articles instead. Christian Graus

Roger Wright

I would add that dialog boxes which request permission to perform a function must clearly, in plain language (not meaningless technobabble), explain what will happen when OK is clicked. Additionally, any dialog box presented in response to an exception must include a clear explanation of what application, process, & function caused the error, and provide an understandable description of the nature of the problem encountered. I'm a Frisbeeterian. We believe that when you die your soul is thrown up on the roof, and you can't get it down.

paulb

how about this... 10). Modal dialogs should never be nested more than 2 deep. Any more than this just creates confusion (and a mess of nested windows).

Olli

Nishant S wrote: 5. Pressing ENTER on a dialog box will have the same effect as clicking on the OK button, except when the focus is on a multi-line edit box Hi Nish, I disagree in that coz I like it more logical, sometimes it's better to behave like the TAB-key.... but I think it depends on the logical situation... Greetings from a strange world....

Olli I feel like I'm diagonally parked in a parallel universe.....
:suss: :rolleyes: :suss:

Daniel Ferguson

Nishant S wrote: 6. The size of the dialog box will be such that it will fit within the screen on the lowest target resolution which by default is fixed as 640 x 480. My resultion is 1600x1200 and tiny dialogs with huge (especially multiple-column) lists that must be scrolled to view the entire contents are annoying as hell. All dialogs that would be easier to use if they were resizeable should be. Resizeable dialogs should really be a standard part of the operating system. Another thing is to design dialogs from the point of view of using them, by that I mean they should be designed based on the user's view of the data rather than the programmers view of the data. If I have to spend time to figure out what the programmer who made the dialog was thinking rather than what I want to do, then there is a problem. "You don't have to be a political scientist or a history major to see the 'bigger dick foreign policy' at work. It goes something like this: 'What?! They have bigger dicks? Bomb them!' And of course the bombs and the bullets and the rockets are all shaped like dicks. I don't understand that part of it, but it is part of the equation." -George Carlin

Nish Nishant

paulb wrote: 10). Modal dialogs should never be nested more than 2 deep. Any more than this just creates confusion (and a mess of nested windows). Yeah, this is already there in my updated set of guidelines. Strange that we both picked 2 as the maximum depth :-) Nish

Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]

Nish Nishant

Olli wrote: I disagree in that coz I like it more logical, sometimes it's better to behave like the TAB-key.... but I think it depends on the logical situation... That's a hangover from the DOS days when apps did that. Today only COBOL apps behave that way. The default windows behaviour is to tab on TAB and dismiss on ENTER Nish

Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]

Nish Nishant

Though there are various implementations of resizable dialogs, none of them are anywhere near perfect. Otherwise the developer must develop separate dialogs, one for each kind of resolution or resolutions. But that'd be a big ask :-( Nish

Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]

Nish Nishant

Dialog boxes - guidelines • All dialog boxes will have a CANCEL button, and when the user clicks the CANCEL button the dialog will be dismissed without any changes being applied • Pressing ESCAPE when a dialog box is active will have the same effect as clicking the CANCEL button • On Windows based systems, the dialog will have a Close button [X} in the title bar which will duplicate the behaviour of the CANCEL button • All dialog boxes will have an OK button and when the user clicks the OK button, the dialog will be dismissed and all changes will be applied • The user must be made aware of exactly what changes will be applied on clicking OK. This can be done by providing a static text field that explains this bevaviour. • Pressing ENTER on a dialog box will have the same effect as clicking on the OK button, except when the focus is on a multi-line edit box • The size of the dialog box will be such that it will fit within the screen on the lowest target resolution which by default is fixed as 640 x 480. Depending on the target requirements this default may be raised or lowered. • Dialog boxes that accept data entry should be modal. • Where it is required to have a modeless dialog box, only one instance of the dialog box is allowed to be activated at any one time. • Ideally there should not be more than 10 data entry fields on a dialog box, inclusive of edit boxes, combo boxes, list boxes, check boxes and radio buttons. Text fields are not counted. Under special situations where it is absolutely necessary that there will be more than 10 data entry fields in a dialog, they should be arranged in logical groups using group boxes. • The tab order should be sequential and logical. Random jumping of tabs is strictly not allowed. • Dialog controls will always have proper labels. For edit controls that don’t have labels by default, a coherent static text control will be placed to its left. • Dialog boxes should have proper instructions in them, perhaps on the top or the bottom. The user should not have to refer help or documentation to fill in a simple data entry dialog box. • Edit fields should line up on the same vertical line • Static text fields should be left aligned. • Control spacing will be consistent across a dialog box • For dialog boxes that are intended for message showing purposes, and that have no data entry fields, there will be just an OK button. The CANCEL button will be unnecessary in this case and is not to be used. • Dialog box titles will be logical and make clear what the dialog bo

Olli

Nishant S wrote: The default windows behaviour is to tab on TAB and dismiss on ENTER I know, you know... but my customers do not really now... When you see them work, they click from edit to edit for example, and not so many are using the keyboard navigation (coz they don't know...)

Olli I feel like I'm diagonally parked in a parallel universe.....
:suss: :rolleyes: :suss: