Too many developers never change the Title Bar. The Title Bar should reflect the current document in the same way that Microsoft Word, Notepad, etc do.

Imagine 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 Taskbar, they would all look the same.

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

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.

Note: Make sure the URL won't take other important information's place.

Note 2: 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 user hovers the mouse pointer over the form's button on the taskbar, the resulting tool tip looks somewhat distorted.

Plain menu items make your application look normal and less expressive.

While icons can make your application look good.

More information

You can use the MenuStrip control in .Net

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:

Out of the box, you'll get a sound with error messages. You'll still need to add your own for:

• 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.

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

string message = "You did not enter a server name. Cancel this operation?";
string caption = "No Server Name Specified";
MessageBoxButtons buttons = MessageBoxButtons.YesNo;
System.Media.SystemSounds.Beep.Play();
DialogResult result = MessageBox.Show(this, message, caption, buttons);

string message = "You did not enter a server name. Cancel this operation?";
string caption = "No Server Name Specified";
MessageBoxButtons buttons = MessageBoxButtons.YesNo;
DialogResult result = MessageBox.Show(this, message, caption, buttons);

Some processes might take a long time to be completed and this can frustrate the user. The best way to avoid this frustration is giving information and options.

The importance of having the status of progress bar on winform's title:

• Users can clearly see the progress status
• If the winform is minimized to taskbar, users still can see the progress status

The form title should take the form of "[XX]% Completed - [Task Description] - [Product Name]".

There is another relevant rule about the winform title.

Give users the chance to skip a lengthy process.

When your wizard has a lot of processing, do you allow the user to skip that processing when appropriate? It may be that the user simply wants to see the results of the last time the wizard was used, or is interested in seeing what comes after the processing step before deciding to run the process.

When stopping processes, you should use 'Cancel'... Not 'Stop'. The meaning of 'Cancel' is clearer to users, as opposed to 'Stop' which might also mean 'Pause'.

The last thing a user wants is to be stuck waiting around for a long-running process to finish that they accidentally started in the first place. This heightens frustration with the application because:

• They do not know how long the process will last (adds uncertainty to the user experience)
• They cannot stop the process (creates lack of control in the user experience)

Instead, keep users happy with your application by:

• Showing status description information above the progress bar
• Allowing the user to stop the process at any time by clicking "Cancel" (or as a minimum, prompt for confirmation before the long running process starts)

We have a product called SSW .NET Toolkit which includes these controls. SSW .NET Toolkit - Using Progress bars/Status forms.

If you are unable to show a progress bar, you should still indicate that it may take be a long process. For example, if installation takes more than 5 minutes, let your users know so they can get on with something else:

Whenever a long process is churning away (e.g. about 10 seconds) users will usually do something else, either make a coffee or switch to another window.

Your application should remind the user to go back and check on it by:

• Playing a sound
• Hiding the progress bar
• Showing a message box at the end of the long process

See rule on Do you know how to make long-running processes user-friendly?

When using Message Box to indicate user a process is done, always includes detailed summary of the process. Don't just say "Process completed."

This is just like standing at a set of traffic lights listening for the beep to know when to walk, rather than constantly looking at the red and green lights.

If you are shipping a product that makes use of a database backend, then you should also supply and option to automatically populate the database with some sample database. This is particularly important if you are offering your software as a trial license and need to have data in the database to show off your application's ground breaking functionality.

Tip: you can script your data in a sample database to a .sql file with a lot of INSERT statements and then use a product such as SSW SQL Deploy to manage the safe execution of your .sql file.

You should prefix your sample databases with your company and products. This is so your users can tell easily at a glance what it is for. Sample databases should be named in the following way:

• SSWSQLAuditorNorthwindSample
• SSWSQLTotalCompareNorthwindSamplePub
• SSWSQLTotalCompareNorthwindSampleSub

Sample Access database are named similarly:

• SSWLookOutNorthwindSample2000.mdb

If you have an SQL script that runs as part of your install you should always make sure that it does not drop the database first. When you typically auto-generate a script file from some of the SQL applications (such as Enterprise Manager) it will automatically attempt to drop a database if it already exists. This is bad practice as a company may already have a large investment in the data already in the database and dropping it may cause them to lose this investment.

If you know which machine the database is going to be installed from within your application you should first check that it doesn't already exist and prompt the user accordingly to let them know that they should first manually delete the database. For example the install of the SQL Reporting Services setup handles this problem in an appropriate and simple manner (although some additional help could be provided).

If you cannot be sure of the machine that the database is going to be installed on then you should make use of third party .sql script execution managers such as SSW SQL Deploy to ensure that when you attempt creation of databases where the database already exists then things will run smoothly.

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

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();
    }
}

We have an example of this in the SSW .NET Toolkit.

Training Videos provide a straightforward way to help the user look into your product and help them have a good understanding. It's better to have a "Training Videos" item in the help menu.

See our suggestion to Visual Studio to provide "Training Videos" menu item in the help menu.

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)

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" button can provide 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.

There are benefits of having your user guide online:

1. Easier to keep up-to-date and maintain
2. Stats on usage
3. Allows community commenting

A common oversight is applications don't check for invalid data. You should add "Tools | Validate Data" to your application.

So when you add business rules to the middle tier, consider scenarios such as importing data and any other areas that side step 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

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

1. Training Videos
2. Online User Guide
3. Knowledge Base
4. Make a Suggestion
5. Report a Bug

6. Check for Updates - [Product Name]

   • Check for Updates - All Programs
7. Run Unit Tests...
8. About [Product Name]...