UI guidelines for dialog boxes

[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:

[Rutger Ellen]

Nishant S 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 Maybe you should add that then a wizard like next next finish set of dialogs should be used ?

[Nnamdi Onyeyiri]

Colin Davies wrote: 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 how could u do something like that?

---

:suss: Email: theeclypse@hotmail.com   URL: http://www.onyeyiri.co.uk
:suss:"All programmers are playwrights and all computers are lousy actors."

[Vimal Earnest]

Good points.I like to add a few more Dialogs should support keyboard shortcuts. 1.This means that we can move within a group by using arrow keys. 2.We should be able to select various controls using ALT+key combinations.For this we have to underscore the 'key' letter of the text associated with the control.

[ColinDavies]

1. Only do it randomly 2. Catch the Tab-key message (Pretranslatemessage will do ) 3. Send it to another control at random with SetFocus() Most things are solved simply :-) If you want I'll help you write an App and you can publish it :-) 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

[KaRl]

I suppose you had a look to MS' "Official Guidelines for User Interface Developers and Designers" (msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/welcome.asp). Even if not perfect, these rules have the advantage to standardize your app with MS ones. For the rule 6, I would also add a parameter about available colour number, like: A dialog box should be fully displayed with a configuration of 640x480 pixels and 16 colors. I agree with all the others. We do not inherit the Earth from our ancestors. We borrow it from our children. Antoine de Saint Exupéry (1900-1944)

[Jeremy Pullicino]

Need to add this one: Dialogs need to fit in a 640x480 screen resolution. "Hey man, Taliban, Tali me Banana."

[Matt Gullett]

Here are some of my general rules. (Note: no rule is totally inflexible.) 1. For dialogs with more than 2 or 3 lines of text or controls, place the control buttons in the lower right of the dialog. (I place them in the lower right for all dialogs now but my data indicates upper right makes no difference for small dialogs.) 2. Also for dialogs with more than 2 or 3 lines place the help button (if any) in the lower left of the dialog. 3. Generally, all text should be left justified for US english display. 4. Button text should be in Upper lower case (ie. Cancel instead of CANCEL). 5. The dialogs title should be in Upper lower case (ie. Warning instead of WARNING) 6. IF the button text or title is in upper case, the other should be also. 7. If possible use Bold. underline and/or italic to emphasise text instead of CAPS. 8. Text in CAPS should be reserved to keu words and phrases only, and never more than 3 words at a time. 9. The group frame is your friend when used wisely. 10. Labels should all have an ending colon or not have the ending colon. Be consistent. 11. If needed, Bold any labels for required fields. If Bold is not avaiable use a leading asterick. 12. Place labels above or to the left of controls they identify, but never below (at least for US English.) 13. For numeric entry fields right justify is best. 14. Avoid the Masked edit control for dates unless changing the date in the control is a rare occurence in which case it should be a picket anyway. 15. Splitters and dialogs don't mix. 16. The tree control is generally evil unless you're software is for other developers especially on dialogs. 17. For dialogs containing lists it is best if the dialog is sizeable. 18. If your dialog is sizable, show the bottom-right chevron so the user knows it's sizable. 19. Edit controls should have a max length specified unless there really is no max length. 20. Multi-line edit control should allow the user to press ENTER to get a new line. Just a few I can think of at 4:30 in the morning.

[Matt Gullett]

Oh yea. 21. Check box text found be to the right of the check box. (At least for US english.) 22. The list box portion of combo boxes should be suffeciently large for the average size list or about 1/3-1/2 the height of the screen for longer lists.

[Shaun Wilde]

hmmm - now I wonder where I've seen 12 before - ponder ponder...... ;)

Stupidity dies. The end of future offspring. Evolution wins. - A Darwin Awards Haiku

[Shaun Wilde]

Christian Graus wrote: You get that for free. I wish you did - I have seen code where a developer handled the CANCEL button and the escape key as different functionality - arrrghhhhhhhhh

Stupidity dies. The end of future offspring. Evolution wins. - A Darwin Awards Haiku

[Anna Jayne Metcalfe]

Definately. That's one of my pet hates too! Andy Metcalfe - Sonardyne International Ltd

Trouble with resource IDs? Try the Resource ID Organiser Add-In for Visual C++
"I would be careful in separating your wierdness, a good quirky weirdness, from the disturbed wierdness of people who take pleasure from PVC sheep with fruit repositories." - Paul Watson

[Michael P Butler]

What's wrong with the "offical" Microsoft User Interface Guidelines? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch09d.asp Michael :-) Look, try and use your intelligence, man, even if you are a politician. - The Doctor

[Shaun Wilde]

Nishant S wrote: 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 now I still get requirements for UI to behave like that eg press return on an edit moves to next field - we deal with people who do a lot of data inputting - and they do not use the mouse much but like to use the keyboard

Stupidity dies. The end of future offspring. Evolution wins. - A Darwin Awards Haiku

[Michael P Butler]

I still on ocassion hit enter when I should hit tab. Too many DOS app's in my past. ;-) Michael :-) Look, try and use your intelligence, man, even if you are a politician. - The Doctor

[ColinDavies]

Shaun Wilde wrote: hmmm - now I wonder where I've seen 12 before - ponder ponder..... I BET. There is an unpublished API in windows for doing 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

[Anna Jayne Metcalfe]

Dismissing on ENTER can be a real pain. We tend to trap ENTER and use it to fire off a default action on the currently focused control instead. Although non-standard in Windows terms, this does allow the user to explicitly tell the system they've finished entering data in an edit box WITHOUT having to use the TAB key to force a focus change to the next control (which in our case is rarely the next one they'll be interested in anyway). :) Andy Metcalfe - Sonardyne International Ltd

Trouble with resource IDs? Try the Resource ID Organiser Add-In for Visual C++
"I would be careful in separating your wierdness, a good quirky weirdness, from the disturbed wierdness of people who take pleasure from PVC sheep with fruit repositories." - Paul Watson

[NormDroid]

Have you checked the Windows User Interface Guidlines. Normski. - Professional Windows Programmer