SSW Foursquare

Rules to Better Interfaces (Windows Applications) - 21 Rules

Since 1990, SSW has supported the developer community by publishing all our best practices and rules for everyone to see.

If you still need help, visit Website Design and User Experience and book in a consultant.

  1. Title Bar - Do you put the current document/project name as the first word of your title bar?

    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'

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

  2. Title Bar - Do you put your 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: 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.

    Figure: Bad Example - Bad caption in SSW SQL Deploy

  3. Menu - Do you use icons in menu?

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

    Figure: Bad Example - Plain menu

    While icons can make your application look good.

    Figure: Good Example - Menu with icons

    More information

    You can use the MenuStrip control in .Net

    Figure: the Menuitem has a simple image property

  4. Sound - Do you realize 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:

    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
    • iconAudio Application opening / iconAudio 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

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

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

    Figure: Good example - Windows message boxes plays a sound... which cannot be captured in screenshot form.

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

    Figure: Bad example - The sound on the button is hardcoded in this code snippet

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

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

  6. Long Process - Do you know how to make long-running processes user-friendly?

    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.

    Figure: Bad example – this progress bar looks like it is stuck at 99%. Ideally the progress bar should be hidden when completed and replaced by a green tick

  7. Long Process - Do you show the status of progress bar on winform's title?

    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.

    Figure: Bad Example - The winform's title does not contain the progress status

    Figure: Good Example - The winform's title contains the status of progress bar

    Figure: Good Example - You can clearly see the progress status from taskbar when you have the windows minimized

    Figure: Good Example - Windows 7 shows the progress in the taskbar (which is visible even when the application is minimized)

  8. Long Process - Do you know that long-running processes should allow to 'Skip' the processing (when appropriate)?

    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.

    Figure: Good Example - Here the user can skip a long process and see the last results (from SSW Diagnostics)

  9. Long Process - Do you use the word 'Cancel' (instead of 'Stop') to halt processes?

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

    cancel long process bad
    Figure: Bad Example - Stop is an ambiguous term and can be momentarily confusing

    cancel long process good
    Figure: Good Example - Cancel leaves little room for miscommunication

  10. Long Process - Do you know that you should show a progress bar and allow users to cancel?

    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)

    Figure: Good Example - Progress Bar with description and Cancel Button

    Figure: Good Example - Progress Bar with description and status, and Cancel Button

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

  11. Very Long Process - Do you know that long-running processes should show a coffee cup?

    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:

    Figure: Bad example - An unknown length of time. So let them know

    Figure: Good example – The coffee cup tells the user that they will be here a while

  12. Long Process - Do you know that you should provide a detailed summary, play a sound and hide the progress bar at the end?

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

    Process completed.

    Figure: Bad example – No detailed information

    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.

    Process completed.
    Time Taken: 15 seconds

    Figure: OK Example - A completed progress form

    Manual extraction process completed.

    Mailboxes scanned: 8
    Mailboxes skipped: 2
    Total mailboxes: 10
    Time Taken: 10 minutes, 15 seconds

    Figure: Good example – The user can see what has been processed

  13. Sample - Do you supply a sample database?

    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.

  14. Sample - Do your sample databases have good Naming Conventions?

    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
  15. Sample - Do you avoid dropping a user's database when you attempt to create a database?

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

    Good example – an application should never automatically delete a database, not even a sample database

    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.

  16. Do you provide a warning before the program exits?

    A product should not close 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);
        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)

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

  17. Menu - Do you have a "Help | Training Videos" item?

    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.

    Figure: It's better to provide such a "Training Videos..." menu item

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

  18. 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: This "Help | About" form contains all 5 elements, but has room for aesthetic improvements (old SSW design)

    Figure: Good Example - This "Help | About" has the 5 elements presented better,

  19. Menu - Do you have your "Help | User Guide" online?

    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

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

    Figure: Good Example - Telerik keeps their "User Guide" online

  20. Menu - Do you include a "Tools | Validate Data"?

    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

    Figure: Good Example - This application, while not the prettiest, has a handy validation tool to check for incorrect data

  21. Menu - Do you know the 8 items every "Help" menu needs?

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

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

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

We open source. Powered by GitHub