Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor
  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. The Lounge
  3. UI guidelines for dialog boxes

UI guidelines for dialog boxes

Scheduled Pinned Locked Moved The Lounge
htmlcomdesignhostingbusiness
55 Posts 22 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N 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]

    M Offline
    M Offline
    Matt Gullett
    wrote on last edited by
    #27

    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.

    M N A 3 Replies Last reply
    0
    • M 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.

      M Offline
      M Offline
      Matt Gullett
      wrote on last edited by
      #28

      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.

      1 Reply Last reply
      0
      • C 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

        S Offline
        S Offline
        Shaun Wilde
        wrote on last edited by
        #29

        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

        C 1 Reply Last reply
        0
        • C 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

          S Offline
          S Offline
          Shaun Wilde
          wrote on last edited by
          #30

          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

          1 Reply Last reply
          0
          • P 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).

            A Offline
            A Offline
            Anna Jayne Metcalfe
            wrote on last edited by
            #31

            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

            1 Reply Last reply
            0
            • N 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]

              M Offline
              M Offline
              Michael P Butler
              wrote on last edited by
              #32

              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

              N J 2 Replies Last reply
              0
              • N 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]

                S Offline
                S Offline
                Shaun Wilde
                wrote on last edited by
                #33

                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

                1 Reply Last reply
                0
                • O 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:

                  M Offline
                  M Offline
                  Michael P Butler
                  wrote on last edited by
                  #34

                  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

                  1 Reply Last reply
                  0
                  • S 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

                    C Offline
                    C Offline
                    ColinDavies
                    wrote on last edited by
                    #35

                    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

                    1 Reply Last reply
                    0
                    • N 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]

                      A Offline
                      A Offline
                      Anna Jayne Metcalfe
                      wrote on last edited by
                      #36

                      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

                      1 Reply Last reply
                      0
                      • N 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]

                        N Offline
                        N Offline
                        NormDroid
                        wrote on last edited by
                        #37

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

                        J 1 Reply Last reply
                        0
                        • V 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.

                          N Offline
                          N Offline
                          Nish Nishant
                          wrote on last edited by
                          #38

                          Vimal Earnest wrote: We should be able to select various controls using ALT+key combinations Good suggestion Vimal. Thanks :-)

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

                          1 Reply Last reply
                          0
                          • M 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.

                            N Offline
                            N Offline
                            Nish Nishant
                            wrote on last edited by
                            #39

                            BRILLIANT Matt G absolutely awesome tips Nish :rolleyes:

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

                            1 Reply Last reply
                            0
                            • M 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

                              N Offline
                              N Offline
                              Nish Nishant
                              wrote on last edited by
                              #40

                              Michael P Butler wrote: What's wrong with the "offical" Microsoft User Interface Guidelines? Well, 90% of the application development here is targetted for X-Windows based systems :-( Nish

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

                              M 1 Reply Last reply
                              0
                              • N 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]

                                A Offline
                                A Offline
                                Anna Jayne Metcalfe
                                wrote on last edited by
                                #41

                                If you're working with MFC projects, Herbert Menke's CResizeCtrl may be of help to you here. Since it's a plug-in class, there's no need to write hand-crafted OnSize() handlers in each dialog...just add them to the resizer and tell it how they should be sized/positioned as the dialog is resized. :cool: 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

                                1 Reply Last reply
                                0
                                • M 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.

                                  A Offline
                                  A Offline
                                  Anna Jayne Metcalfe
                                  wrote on last edited by
                                  #42

                                  Matt Gullett wrote: 2. Also for dialogs with more than 2 or 3 lines place the help button (if any) in the lower left of the dialog. Surely you mean lower right? (Property Pages and Wizards follow this convention, unless you move the default buttons). 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

                                  M 1 Reply Last reply
                                  0
                                  • A Anna Jayne Metcalfe

                                    Matt Gullett wrote: 2. Also for dialogs with more than 2 or 3 lines place the help button (if any) in the lower left of the dialog. Surely you mean lower right? (Property Pages and Wizards follow this convention, unless you move the default buttons). 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

                                    M Offline
                                    M Offline
                                    Matt Gullett
                                    wrote on last edited by
                                    #43

                                    Oy yea! Lower right it is. BTW it was 4:30 AM when I posted the message so I am surprised it makes sense at all.

                                    1 Reply Last reply
                                    0
                                    • N Nish Nishant

                                      Michael P Butler wrote: What's wrong with the "offical" Microsoft User Interface Guidelines? Well, 90% of the application development here is targetted for X-Windows based systems :-( Nish

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

                                      M Offline
                                      M Offline
                                      Michael P Butler
                                      wrote on last edited by
                                      #44

                                      Well just cut and paste the MS ones, put your name on it and nobody'll know the difference. ;-) Michael :-) Look, try and use your intelligence, man, even if you are a politician. - The Doctor

                                      1 Reply Last reply
                                      0
                                      • C 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

                                        C Offline
                                        C Offline
                                        Christopher Duncan
                                        wrote on last edited by
                                        #45

                                        Chris Maunder wrote: 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. [OK] [Cancel] should be replaced with [Crash] [Burn] If I'm going to get choices, at least make them realistic. Chistopher Duncan Author - The Career Programmer: Guerilla Tactics for an Imperfect World (Apress)

                                        1 Reply Last reply
                                        0
                                        • O 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:

                                          P Offline
                                          P Offline
                                          Phil J Pearson
                                          wrote on last edited by
                                          #46

                                          Then you should upgrade to the latest version of customer. There's really no excuse for continuing to use the old, broken version. Phil

                                          O 1 Reply Last reply
                                          0
                                          Reply
                                          • Reply as topic
                                          Log in to reply
                                          • Oldest to Newest
                                          • Newest to Oldest
                                          • Most Votes

                                          • Login
                                          • Don't have an account? Register
                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • World
                                          • Users
                                          • Groups