SSW Rules to Better Interfaces

Do you realize that a good interface shouldn't require instructions?

The corner stone of good user interface design is that if your users need instructions, you haven't done a good job. Of course with particularly complex applications there will be exceptions to this rue, but all developers should aim to make your designs as self evident as possible.

Figure: You shouldn't need instructions!

Do you realize that when it comes to interface design 'less is more'?

How to make a user interface great:

• Less is more - keep your design as simple and uncluttered as possible
• Understand the importance of Defaults - Aim for 'Next', 'Next', 'Next'
• Hide advanced options, but make them easy to find!

Most developers think about user interface last. They spend their time worrying about class design, threading, and system architecture. All this is important, of course. But the user only experiences software on the surface level. It might be fantastic under the covers, but if the user interface is not intuitive the user will think the application is just hopeless. If the user interface doesn't afford an easy and simple understanding of how to operate the application, you'll get a lot of unhappy customers and unnecessary support calls. Do yourself a favour, take some time to think about UI first.

Figure: Bad Example - An example of a poor UI

Figure: Good Example - See the fly? (an example of excellent usability) Dutch manufacturers realized that a fly painted on the porcelain of a urinal nearly always became a "target" for men using the facility. And the fly is positioned in precisely the right place for minimal spillage or splashback. Clever people those Dutch!

Do you use a Wizard to help a user through a complicated set of steps?

Though all software should be intuitive there are still times when you will need some extra guidance. Wizards are ideal especially for guiding through more complicated steps or when an application isn't going to be used regularly. e.g. SSW Code Auditor may only run once a month, and in between times the user may forget what are all the steps were. You can see all the relevant steps Code Auditor User Guide.

Most importantly the first time a user tries out your program they should be able to step through the setting up process and a Wizard helps them see how your application flows, from beginning to end.

1. Page name. It is important for the user to know which page they are currently on.
2. Page description. You should provide a short description of the task to be performed on the page.
3. Instructions. Not required for every page, this is a short description requesting the user to perform a task, for example, entering some values into a text field.
4. Company logo. This helps promote branding, however it should be inconspicuous and should not move visual focus away from the body of your application.

Figure: Good Example - SSW Link Auditor Wizard's better flow of information

Technical Note: To ensure visual consistency across applications, create a base form then set the properties in that form (application icon, menu structure, button names etc.) Add any logic in for switching pages with the "Next" and "Back" buttons. Then for all projects, add a reference to that one and inherit the customised form.

In the forms in your application, instead of inheriting from System.Windows.Forms.Form (the Default), inherit from your new base form class.

public class MyForm : System.Windows.Form.Form

Figure: Default code in a Windows Form

public class MyForm : Company.Framework.BaseCustomForm

Figure: Change the form so that it inherits from your new base form class

The "finish" button denotes the end of the Wizard; by clicking on it, the user closes the Wizard.

For longer processes, the Wizard should implement "Start" and "Skip" features to guide the user through from start to finish.

Figure: Good Example - SSW Code Auditor Wizard featuring "Start" and "Skip" options

Here's some more information on the Microsoft Standard for Wizard Welcome and Completion Page art and Interior Page art .

Does the first form provide the user product information?

• If the application is wizard application :
  
  The first page of the utility should introduce the user to the application.

  Because the first two paragraphs of this screen and the first few paragraphs of the application's website often contain virtually identical information (i.e., describing the product) it may be a good idea to make both the same. The first two paragraphs of the screen can be copied from portions of the website.

  A "More" hyperlink can also be added at the bottom of the screen, which will direct the user to the website where they can read further information about the application.

  

  Figure: Good Example - This wizard has an information screen as the first screen

• If the application is not a wizard application
  
  The main menu of the application should have a Help - About... menu item. When clicked, a new form should open up containing similar information as the page in the wizard application described above.
  

  

  Figure: Good Example - Help - About... menu item opening the product information

Do you add an introduction screen prior to settings?

A brief introduction will give some idea about what will happen on this process and it may save user's time and effort. So, if you expect that not all users will be totally clear on what the settings do, add an introduction with a screen.

• Add screen shot with red circle at the top of the screen
• Put a description next to it

Figure: Bad Example - This screen has no product introduction

Figure: Good Example - This screen has production information before the settings

Do you visually indicate to the users the step where they are up to in the wizard?

In a wizard, a visual indication about the progress should be provided so users know that where they are up to.

Figure: Good Example - Microsoft FrontPage uses a progress bar to indicate where users are up to

Do you visually let the user know when they are finished?

When a user reaches the last page of a wizard, a visual indication should be provided so that they know that the process has finished. We use a finish flag to do this.

Figure: Bad Example - This is the last page of the wizard but it is not obvious because the finish flag is small and the "Next" button still enabled

Figure: Good Example - Good quality Finish flag on the last page of a wizard.

Do you avoid doing an embedded add?

You need to open a new form for any case of 'Add New'.
For Example:

Figure 1: The 'Add New' button changes from a view into a data entry form

Figure 2: Bad Example - the 'Add New' button, shown in Figure 1, openned the page in the same window.

You are better to open in a new form, reasons being:

• It is better for user in terms of clarity the change of view to data entry form can be a surprise
• It is better to code e.g. if you are using this control in a couple of places you may need to show or hide 'Save' buttons etc. Otherwise, it is a pain to make it behave differently in different contexts.

However, you do need to call back on save and requery it.
Use a modal form and requery it (DON'T user javascript instead use the Modal Popup Form Example)
An example of this is in Outlook with the 'New' button.

Figure: Good Example - the 'New' button in Outlook opens a new form for you to construct your email

Do you avoid using plain textboxes for notes?

Instead of using plain textboxes for notes, use rich textboxes. The main reasons for this is that it allows you to use links to URLs, have variations in formatting (including bold, underline, italics, font type and font size, etc.), use bullet points and numbering, as well as other features of rich textboxes that plain text boxes do not provide.

Figure: Bad Example - use of a plain textbox limits the detail of the user's notes

Figure: Good Example - with use of the rich texbox, the user is able to use added features such as bold, underline, highlighting and hyperlinks.

See our page on The Best 3rd Party Web Development Tools and you will find the FreeTextBox Demo

Do you use bold text and indentation, instead of dividing lines?

Many applications have a lot of content on each form. If this is the case there needs to be some way to separate certain sections. To achieve this separation Microsoft (and therefore most developers) use separating lines, but this UI is not perfect because:

• It creates additional visual clutter
• It is hard to maintain

Note: This rule is a rare one which is different from Microsoft.
Did they get it wrong? Well I think so?
Are they consistent with the separation lines? Nope so maybe they aren’t so sure about it.

We recommend using bold instead of dividing lines because:

1. Bold stands out
2. Indentation is more important
3. Developers are not good at keeping the lines aligned - you could create a .NET custom control to do this - but Microsoft do not provide one
   • The diving lines create additional visual clutter (ever so slight)
   • Each line creates additional performance implications (ever so slight)

Figure: Bad Example - This is the Tools - Options from Internet Explorer and it groups each section in a groupbox - busy UI.

Figure: Bad Example - This is the Tools - Options from Outlook and it uses dividing lines for each section.

Figure: Bad Example - This is an old screen from Code Auditor - the dividing lines are not required.

Figure: Good Example - This is the new screen from Code Auditor - the bold title and indenting are the best way to show the sections.

Do you make graphs easy to digest?

Graphs are a great way to display data in an easy to follow visual format. Some graphs, however, are easier to read than others. We recommend staying away from 3-D Graphs and keeping it simple! If you have complex data, it's also a good idea to display 2 or 3 simpler graphs rather than one complex one - the aim of the game is to make digesting the information as simple as possible for your audience.

Figure: Are your graphs simple to understand?

Do you remember the user's last settings?

The user's last settings should be saved and should be selected as the Default the next time a form is opened in many instances. For example:

• Login forms - the last login name should be the Default selected and the cursor should be in the password box.

  

  Figure: Bad Example - Last Username is not saved

  

  Figure: Good Example - Last Username is saved

• Report criteria forms - e.g. date start and date end fields should be automatically populated

Use the Configuration Block to store the settings.

Do you label your form buttons consistently?

The buttons that a user will typically use to close a form should be named consistently across your applications.

Figure: Bad Example - Unclear labels on the buttons

• Save button could possibly update the fields but keep the form open.
• Close could save the fields, then close the form, when the Cancel button may be more appropriate.

We recommend the age-old standards of:

• OK. Close the form and save any changed data. This should be referenced by the form's AcceptButton property.
• Cancel. Close the form without saving. This should be referenced by the form's CancelButton property.
• Close. This should only be displayed if no data has or will be changed in the form's current lifetime.
• Apply. Save data without closing the form.

Figure: Good Example - This form uses the standard button naming standards (and has the Default buttons set!)

Do you keep Time formats consistent across your application?

Time formats should be consistent across your application, to give the application a very professional and consistent look.

Figure: Bad Example - Three screens with inconsistent time formats

Figure: Good Example - Three screens with consistent formats

Do you keep Date formats consistent across your application?

Date formats should also be kept consistent across your application, to keep give the application a proffesional and consistent look.

Figure: Bad Example - Two screens with inconsistent date formats

Figure: Good Example - Two screens with consistent date formats

Don't use OK button if it does one clear action

Don't use "OK" if the button does one clear action. The button name must reflect the action that is going to happen by clicking the button. Examples of button names that are better than "OK" are:

• Save
• Move
• Rename
• Open
• Select
• Insert
• Print
• Process
• Login

Figure: Save button in action

However, there is an exception when there are multiple settings being changed. Typical examples are Properties and the Tools - Options dialog. There are often many tabs with many options. It would make no sense to have "Save Settings" or "Save". This is where the "OK" "Apply" "Cancel" convention really applies.

Do you avoid dynamically labelling your form buttons?

The buttons that a user will typically use should not have data driven across your applications.

Figure: Bad Example - Buttons are dynamically labelled "Build ..." and "Edit ..." depending on text in the text box

Figure: Good Example - Buttons are not dynamically labelled

Do you know how to make message boxes user friendly?

Message boxes should have consistent and informative titles and descriptions, and icons should be used appropriately.

Title
The title should contain the application name, so the user knows what application generated the warning/error. This is especially important when developing add-ins (e.g. Outlook add-ins or Smart Tags) as it can be difficult to know what caused the message box to pop up. Application.ProductName and Application.ProductVersion should be used to retrieve the data from AssemblyInfo. There is no need for the title to contain a brief description of the error because that information is readily available in the message box itself.

Figure: Bad Example - Title contains brief description of error, which is already contained in the message box

Figure: Good Example - Title contains Product Name ("SSW eXtreme Emails!") and Product Version ("12.56")

The description should explain what the error was, followed by the why it occurred. Information that is useful for debugging should be included with errors where possible be in a "Details" section. You should also avoid making the text unnecessarily wide. e.g.

Figure: Bad Example - A message box that does not intuitively alert the user

• This is confusing, because it uses different terminology to the title ("estimate" instead of "quote")
• There is no punctuation
• The word "Error" is meaningless
• Line breaks are not present, so the message box is too wide and the text may wrap in the wrong spot

Figure: Good Example - A message box that is clear, consistent and intuitive

• Terminology is consistent
• Punctuation is present
• "Details" indicates that this information is useful for debugging
• The text is split across three lines, and the technical information after Details is separated from the description of the error.

Icon
Including an icon is important because not only does it give the user a visual indication of the type of message, but without it only the Default beep sound is used. The icon should reflect the type of information being presented:

Icon	Name	When to use
	MessageBoxIcon.Information	Non-error information, e.g. Database connection test completed successfully.
	MessageBoxIcon.Warning	A non-critical error, e.g. The input was invalid.
	MessageBoxIcon.Error	Critical error in the program, e.g. Program file was not found
	MessageBoxIcon.Question	NEVER use this.  According to Microsoft, the Question mark is being phased out, as any of the other three: Error, Warning or Information can easily be reworded into a Question, and Question does not show the user the severity of the issue that has just occurred. E.g.  If you want to ask the user whether they want to save a file before closing, you should use the Warning Icon.

Do you avoid giving an Error" message for validation purposes?

If you do a search on the Australian White Pages www.whitepages.com.au and the search result is ?? it gives an Error" message. In actual fact, no error occurred; its just that zero results were returned.

However, a user thinks that either:

1. They have done something wrong (i.e. they are incompetent) OR
2. The software is broken (i.e. your application is incompetent)

Forcing the user into this opinion is a good way to make them avoid using your software in the future.

Instead, use the term Information" when validation is required.

Figure: Only use "Error" when appropriate

Do you use messages that are concise and informative?

It is important to use terminology that your users will understand. Do not to use technical terms that may confuse your users. Use consistent words and phrasing for similar situations. For example, the following phrases have the same meaning which is the best one?

• Not enough memory.
• There is not enough memory.
• There is not enough free memory.
• Insufficient memory.
• No memory was available.
• Your computer does not have sufficient memory.
• Memory resource is not enough.
• Ran out of memory.
• You may be out of memory.

Microsoft use this one:

Figure: Good Example - Microsoft error message is concise

Some other message types that Microsoft use are:

Consider using or adapting them in your application in similar scenarios. Only include the information that the user needs and will understand.

Do you follow the control size and spacing standards?

Introduction

Despite seeming trivial to some developers, the most subtle elements of your form design can have the greatest impact on your users.

Figure: Bad Example - What's wrong with this form?

The form shown in this screenshot is an example of bad control placement:

1. The fonts used are non-standard (see: Do you use Microsoft's Recommended Font in your Application?)
2. The controls have no consistency in terms of margins, spacing or even control alignment. See, for example:
   1. The navigation buttons at the bottom of the screen having uneven margin space on the right and bottom sides. They're also the wrong size.
   2. The dimensions of all input controls and buttons do not follow standard convention (see below)
   3. The right side of the Build... button is not aligned with the right of the Connection String text box
   4. The left margins inside the two frames are inconsistent.
   5. The space surrounding the logo in the top right corner is uneven

This detracts from the visual appeal of the user interface, and results in an uneven user experience. After looking at all of this you may be thinking "do I really need to work out exactly what spacing and dimensions I want to use for every detail of a form I make?"

The good news is that you don't need to: Microsoft have gone to a great deal of effort to define standards for exactly how your form controls should be laid out, and these standards are worth taking into consideration. By all means, if you have disagreements with anything listed here then please discuss it with us and we'll consider changing our own standards (Microsoft have changed theirs over the years, after all), but we recommend using the following as a guide.

These examples assume that you are using the standard system font as defined in the rule mentioned above. Please note that although Dialog Units (DLUs) are better suited for generic (font independent) use, they are not available in the Visual Studio designer.

Figure: Good Example - The form follows Standards of good form design discussed below

The Rules

1. Buttons must be...
   • Spaced apart by 6 pixels from other buttons except in the case of wizards where the < Back and Next > buttons may be closer together
   • Spaced 6 pixels from the inside border of a form on the sides closest to it
   • usually 75 pixels wide
   • 23 pixels high
2. Single-line textboxes and most controls must be...
   • 21 pixels high (width depends on content)
   • Aligned correctly with any related controls
3. In a form...
   • Margins must be consistent (see Microsoft's diagram illustrating this)

These are some of the more common examples. Please read Microsoft's Visual Design Guidelines for more information and greater detail.

Ultimately the goal of all of this is to ensure consistency. Keeping these ideas in mind at all times while doing user interface design will give users a better overall experience and will boost the professionalism of your products.

One From The Good Guys

Here's a good example for y'all to take inspiration from. This dialog is from Microsoft Outlook. Let's check out some points:

1. Consistency across wizard pages is very good
2. Spacing and sizing of buttons is precise
3. The logo has been positioned evenly

Figure: Good Example - Microsoft have defined to exacting measures what spacing should be used in their Microsoft Outlook wizards

Read more about control size on the Rules to Better Interfaces page

Do you strike-through completed items?

When you're giving an update on progress on a task list or a schedule, STRIKE OUT the items that have been completed. Not only does it visually explain where you are, it also gives you a great sense of satisfaction...

Figure: Good Example - Completed items are struck-through

Windows Form should have a minimum size to avoid unexpected UI behavior

If windows form does not setup a minimum size, user could have unpredictable form behaviour as below image shown:

Figure: Bad Example - Unexpected window form

Therefore, a standard has been built to ensure windows form have a minimum size. This will always keep application to have user friendly windows form(see below):

Figure: Good Example - User friendly window form

Do you clearly show a pass, fail or warning?

When a user looks at a test result, they want to be quickly informed. Therefore, you must make it clear weather the test has passed or failed, or is there any warning.

• For a pass, the message should be green in colour, and a tick next to the message
• For a fail, the message should be red in colour, and a cross next to the message.
• For a warning, the message should be yellow/orange in colour, and an exclamation mark next to the message.

Figure: Bad Example - Pass and fail are not clear

Figure: Green text and tick for pass, red text and cross for fail (Better)

Figure: Good Example - Status on windows forms

Figure: Good Example - Microsoft Update uses 3 icons to indicate different status, and good quality of Images too

Does your application's interface fit in the screen under any resolutions?

Each user prefers to have their own resolution. You must check if your controls will fit on the user's screen. Think about on which computers your application will run, and what devices will display it. To be on the safe side, it is advisable to fit your controls on an 800 by 600 screen. Our projector has that resolution and it may well be used for presenting your application to the client.

Figure: Bad Example - Form is too large to fit inside 800x600 resolution

Figure : Good Example - Form fits inside 800x600 resolution

The Potential Solutions are:

1. Reorder and move the controls around on the form.
2. Implement Tab pages.
3. Use a wizard type interface, with Next, Back and Finish.
4. Create multiple forms each containing a subset of the controls.
5. Create a menu based form where the items are categories that some form controls fall under.
   Similar to VS. Net's Tools -> Options .

Do you indicate when fields are Read Only or calculated?

When you are not able to edit a field the field should be greyed out. This visually indicates to the user that the field cannot be changed. If you are using Word or Excel, actually locking cells or tables may not be what you require, but you still want to prevent people from directly editing calculations. So make the cells grey and the visual indication should prompt the users what to do.

Figure: Good Example - Read only fields should be greyed out

Figure: Good Example - Calculated Fields in Excel should be in Grey

Of course you should follow the converse, which requires making all editable fields white.

Do you avoid capturing incorrect data?

When asking for an opinion do you give people the option of having no opinion at all? If you only provide "Yes" or "No" as answers to the question "Do you like apples?" then you force people to make a decision which may not be correct.

Maybe they only like cooked apples not raw ones. When asking any question in which "Don't know." or "Don't care." is a valid response, always include an option to opt out of answering. 

Additionally, were the user not to answer the question at all, the response you would get would be determined by the browser the user was using. Give them an answer they can agree with and you'll reduce the chance of bogus responses.

Do you put the company URL in the title bar?

When advertising and promoting your application using screenshots, you will want to have the URL for your company website displayed. This makes for good, free publicity.

If you want the URL to be shown as often as possible, you can place it in the title-bar of your form. That way, your URL will be visible in all screenshots that show the title-bar.

Figure: Good Example - The company URL appearing in SSW SQL Auditor

Note: Through certain coding tricks, it is possible to have the URL on the title-bar right aligned. This isn't a good idea, however, as it can produce undesirable results under certain conditions. For example, when the use hovers the mouse pointer over the form's button on the taskbar, the resulting tool tip looks somewhat distorted.

Figure: Bad Example - Bad caption in SSW SQL Deploy

Do you know the first word of your Title Bar should be the current document (or selected project)?

Too many developers never change the Title Bar. The Title Bar for should reflect the current document in the same way that Microsoft Word, Notepad etc work. Imagine for a second, if every email that Microsoft Outlook opened didn't change the title bar. When you were to open a few emails and then take a look in the Task Bar, they would all look the same.

Therefore change the Title Bar to reflect the current document/customer/job/project/product that the user is working on. It should be in the format "Document - Program Name", i.e. 'Northwind - SSW Data Renovator'

Figure: Good Example - Application with a standard title bar caption

Menu - Do you have a link to your application's user guide?

Users who are finding your application a little hard to use will always look for a user guide. The first thing they would do is to reach for the help menu. The About form provides a link to the product website, but this is not very handy and obvious for a user who needs quick help. A link to the user guide must be in the help menu.

Figure: Good Example - User Guide link in the Help menu

Menu - Do you have a standard 'Help About' form?

Every application you build should have the same Help About form. The form should always display the following information:

1. Version number
   
2. URL
   
3. Description of the product and what it does.
   Tip: This should be consistent with your standard description on the product box, website homepage, product page etc
   
4. Contact details (especially a phone number)
   
5. Branding (logo)

Figure: Bad Example - This About dialog does not provide enough information about the product and/or company

Figure: The old SSW Standard Help >About form across all our products (Better)

Figure: Good Example - The new SSW Standard Help > About form across all our products

Menu - Do you know the seven items every Help menu needs?

A good help menu should have these seven items in it:

1. Online User Guide
2. SSW Knowledge Base
3. Make a Suggestion
4. Report a Bug
5. Check for Updates ?[Product Name]
6. Check for Updates - All Programs
7. Run Unit Tests...
8. About [Product Name]...

Figure: Bad Example - Example of a Help menu with only About

Figure: Good Example - Example of a Help menu with all seven items

Menu - Do you have a standard 'Tools' menu that includes a way to Validate data?

We always add a "Tools > Validate Data" to our apps.

When we add business rules to the middle tier, we are always worried about developers importing data and side stepping the business rules. Therefore we always make validate queries that if they return records, they must be fixed. Examples are:

• For SQL Server we use vwValidateClient_MustHaveACategoryID, or procValidateClient_MustHaveACategoryID
• For Access we use qryValidateClient_MustHaveACategoryID

We then have a procedure that runs all these. The user should keep this list to 0.

Sound - Did you know that a message box automatically plays a beep?

There is no need to manually put a beep right before a message box pops up. A message box automatically provides this functionality.

        Dim Message As String = "You did not enter a server name. Cancel this operation?"
        Dim Caption As String = "No Server Name Specified"
        Dim Buttons As Integer = MessageBoxButtons.YesNo
        Beep()
        result = MessageBox.Show( Me, Message, Caption, Buttons)

Figure: The sound on the button is hardcode in this code snippet

        Dim Message As String = "You did not enter a server name. Cancel this operation?"
        Dim Caption As String = "No Server Name Specified"
        Dim Buttons As Integer = MessageBoxButtons.YesNo
        result = MessageBox.Show( Me, Message, Caption, Buttons)

Figure: The code is not present in this example as it is automatically done

Sound - Do you realise the importance of sounds to User Interface?

Sounds are important to an interface. Sounds provide an extra level of feedback to the user. For example, in Outlook, you can enable sounds, which notify the user when text is copied or pasted, or mail items are received, moved or deleted. Important situations where sounds should be used include:

• Message boxes - every message box should be accompanied with a sound, depending on the type of message box
  Error Warning Information (I'd still like to give the apps their own personality)
• Long process - there should be a sound at the end of every long process to notify the user that it has finished
• Deleting records
• Application opening / closing
• Copying and pasting text

However, not everyone likes sounds, so we think it is also important to have an option to disable sounds in your application.

Figure: Good Example - Turning on Feedback with sound in Outlook

Do you provide a warning before the program exits?

A product should not exit without providing a warning. We use the following message box to warn the user before closing a program:

Figure: Good Example - Standard warning before a program exits

        private void OnExit(object sender) 
             { 
                EventHandler handler = ExitRequest; 
                if (handler!= null ) 
                { 
                   handler(sender, EventArgs.Empty);
                   return;
                } 
                string closeTitle = string.Format("Exiting{0}", Application.ProductName);
                string closeMessage = string.Format("Are you sure you want to exit {0}", Application.ProductName);
                DialogResult result = MessageBox.Show(closeMessage,closeTitle, MessageBoxButtons.YesNo,MessageBoxIcon.Warning);
                if (result == DialogResult.Yes)
                { 
                   Application.Exit();
                } 
             }

What's the difference between Close and Cancel?

When it comes to wizards, there are basically two types of application you are likely to design:

• An application with its own user interface, which allows you to optionally begin and end a wizard from within that interface
• An application that is entirely composed of a wizard interface, where ending the wizard also means ending the application

This is where the difference between using Close and using Cancel buttons within the wizard comes into play. The term 'cancel' is OK to use when the result will simply be closing the wizard, without the rest of the application being shut down.

Figure: Bad Example - Cancel button for a wizard as part of a process

The term 'close' is more appropriate when we are dealing with a wizard that, when closed, ends the entire application.

Example:

Figure: Good Example - Close button indicates the application will exit

Do you use a UDL when getting database settings?

Why do people always invent ways of getting the same old server name and a database name? Look at this image from Speed Ferret - one of my favourite SQL Server utilities

Figure: Bad Example - Custom database connection screen in Speed Ferret.

While a nice form, it would have taken quite some developer time to get it right. Not only that it is a little bit different than what a user has seen before. Now look at this UDL from one of our utilities SSW SQL Auditor:

Figure: Good Example - Standard Microsoft UDL dialog

Every developer has seen this before - so use it. Better still, it is only a few lines of code: B-Open UDL Dialog-DH.txt

Figure: Coming in Visual Studio .NET 2005 Microsoft are yet to release an API to do this

Need extra information?

Do you use an ellipsis (...) to indicate an action requiring more user input?

In menus (including context menus) or buttons, there are generally two types of actions: ones that carry out an action without any further user intervention upon clicking; and those that require further user input before the action is carried out.

Microsoft developed applications uses this technique to indicate whether or not the action will be carried out without any further user intervention. Your application should also follow this well-established standard, so users will not be caught off guard when an action carried out immediately after they click the menu item.

Figure: Good Example - Options menu in Outlook, with ellipsis

Figure: Good Example - Ellipsis on buttons that require further input

Do you use Calendar controls effectively?

In Outlook, the Calendar control has a number of important features:

• Saturday and Sunday are displayed at the end.
• Days that have data associated with them are bold
• The current day is highlighted with a box

Users are familiar with the Outlook calendar control. When the calendar control is used it should incorporate all of these features of the Outlook calendar control.

Figure: Bad Example - Calendar Control - Sunday is at the front, today's date is not highlighted, items with data are not bolded

Figure: Good Example - Calendar Control - Monday is at the front, today's date is highlighted, items with data are bolded

Do you know that popup/modal forms should never have ShowInTaskbar=True

Question: What is wrong with this Picture?

Figure: What is wrong with this Picture?

Answer: The 2 SSW SQL Auditor windows are bad, because one is just a modal form.

Note: We don't check for this in Code Auditor because making a form display as popup, is done at runtime via the ShowDialog method.

Dim frm as new frmCustomer frm.ShowDialog

Figure: Bad Code

If your form is designed to be used modally (and thus be called using ShowDialog) then ShowInTaskbar should be set to false in the form designer.

Dim frm as new frmCustomer frm.ShowInTaskBar = False frm.ShowDialog

Figure: Bad Code (because this should be set in the form designer)

Dim frm as new frmCustomer frm.ShowDialog

Figure: Good Code (ShowInTaskbar is set in the form's InitializeComponents method instead)

Do you avoid "Data Junk"?

When there are too many choices always Default to the most common ones. Then add a check box to allow the advanced users to turn off the common choices. e.g.

[x] Only include common choices

[x] Only include customers that have been updated by employees (not directly entered from the web)

A good example on that the checkbox on the search screen of TimePRO.NET and the fact that when you search google they default to remove PORN.

Figure: Default search tick box in TimePRO.NET

Do you include the number of results in ComboBoxes?

When designing your form, it's a good idea to help your user whenever it's possible. So it's a good idea to include the number of results in ComboBoxes.

Figure: Bad Example - You can't tell the number of results and there is a scroll bar

Figure: Good Example - The number of results is clearly displayed But about long text boxes > 30 entires, this is another approach - puts the common ones at the top

Figure: Bad Example - because it is manual and what about the 4th,5th etc most common used countries

Figure: Good Example - We prefer a combination of the sorting and counting above

We believe all combos should be able to be sorted asc/desc and by popularity asc/desc.

Do you have '-All-' option in your ComboBoxes?

ComboBox is used for filtering data normally, it will be useful to have '-All-' option to give your user chances to select all data.

Figure: Bad Example - No '-All-' option, user cannot select all data

Figure: Good Example - Having '-All-' option, user gets chance to select all data

Do you extend the size of your ComboBoxes to show as many results as possible?

When designing your form, it's a good idea to help your user whenever it's possible. So it's a good idea to extend your ComboBoxes to show as many results as possible to save your user from scrolling. Also, you should extend the width of the dropdown in order to show the longest items.

However, yo