10 tips for creating dialog windows like the pros

2

At SAS, our Windows client products (such as SAS Enterprise Guide and SAS Add-In for Microsoft Office) feature hundreds of Windows forms, or dialog windows, implemented with Microsoft .NET. Because we encourage customers to extend our products with their own custom tasks, I wanted to share some tips on how to build task dialog windows that appear and behave professionally for your end users.

Most of the dialog windows that you see in SAS Enterprise Guide are modal; that is, while the dialog window is shown, no other part of the application can take focus. You are in the "mode" of completing the task on the dialog window, and that window keeps focus until you click OK or Cancel or otherwise close the window.
A picture helps, sometimes

The following tips are geared towards Windows Forms controls within Microsoft .NET (that is, controls that inherit from System.Windows.Forms.Form):

1. Ditch the minimize and maximize buttons.
These are the buttons in the top-right of the window that either maximize the window to the full screen size or minimize it down to the task bar. Very few dialog windows can benefit from either of these transformations, so it's best to set the MinimizeBox and MaximizeBox properties to False.

2. Set a minimum size.
It's handy to make your dialog window resizable, but be sure to set the MinimumSize property so that the end user does not shrink your window into oblivion. Try to determine the minimum size at which the window still remains usable.

3. Don't show your dialog window in the task bar.
The main application already occupies a spot in the Windows task bar. You don't need an additional item to show up when your dialog window is showing. Set ShowInTaskBar to False.

4. Place your window front and center.
The default location for a dialog window to show is set to WindowsDefaultLocation, which is usually someplace offset from the top-left corner of the main application. You want your modal dialog to command full attention from the end user, so set the StartPosition to CenterParent.

You might decide to get fancy and remember the window coordinates when the end user closes your window, and then restore the window to that location the next time that the user opens it. That's what we do with many of the tasks in SAS Enterprise Guide. It's tricky to get it to work correctly with multiple displays and a varying screen resolutions, but nothing is too good for our customers.

5. Change the default icon.
The default .NET icon in the top-left corner of your dialog is that multi-color blocky thing that means nothing to the end user. Nothing says "newbie" like leaving the default icon in place. Change the Icon property to include an appropriate icon for your task.

6. Get results from your buttons.
Most modal dialog windows feature at least two buttons: OK and Cancel. Be sure to set the DialogResult property for each of these buttons to OK and Cancel, respectively. These built-in properties simplify the logic you need when your dialog is closed. You probably won't need special "OnClick" handlers for these buttons if they are providing the correct DialogResult value.

7. Set proper Accept and Cancel roles.
Assuming that you have an OK and Cancel button on your form, set the form's AcceptButton property to the OK button, and the CancelButton property to the Cancel button. The AcceptButton will be highlighted as the "default button" when the dialog shows, and thus the Enter key will be mapped to it by default. Likewise, the CancelButton will be mapped to the Esc key. These roles are essential for consistent keyboard navigation.

8. Anchor your buttons.
When you place new buttons on a form, they are anchored by default to the top and left edges of the window. This means that as the end user resizes the window, the buttons remain fixed in a location relative to these edges. Usually the OK and Cancel buttons are positioned in the bottom-right, so remember to change the Anchor property for these buttons to "Bottom, Right". You should review the Anchor property for each of the controls on the window to ensure proper behavior when resizing the window.

9. Set the tab order.
The tab order contains the invisible ordinals that determine how the controls on your form are traversed when a user navigates them with the Tab key. Having the correct order is critical for proper keyboard accessibility. For our SAS products, accessibility is a big deal. In Microsoft Visual Studio, you set the tab order by selecting the form in design mode, and then go to View->Tab Order.

10. Don't forget the colons.
It's a common pattern on dialog windows: you have a text label that precedes another control that it describes, such as a text field. In addition to setting the correct tab order (see #9), it's important to include a colon at the end of your descriptive text label. A text label with a colon serves as an important cue to assistive technology software to ensure proper accessibility. Plus, it just looks better.

Thirsty for more? Check out the Microsoft User Interface guidelines.

Share

About Author

Chris Hemedinger

Senior Manager, SAS Online Communities

+Chris Hemedinger is the manager of SAS Online Communities. Since 1993, Chris has worked for SAS as an author, a software developer, an R&D manager and a consultant. Inexplicably, Chris is still coasting on the limited fame he earned as an author of SAS For Dummies.  He also hosts the SAS Tech Talk webcasts each year from SAS Global Forum, connecting viewers with smart people from SAS R&D and the impressive work that they do.

2 Comments

  1. Thanks Bob. It's "Bottom,Left" from the perspective of sitting inside the screen looking out, but I guess most of us don't work that way

    You and several others noticed the discrepency, and I've now fixed it in the image.

    Thanks for noticing.

Leave A Reply

Back to Top