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.
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.
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.
Plain menu items make your application look normal and less expressive.
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:
A message box automatically provides this functionality so there is no need to manually put a beep right before a message box pops up.
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:
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:
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.
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:
Sample Access database are named similarly:
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.
A product should not close without providing a warning. We use the following message box to warn the user before closing a program:
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.
Every application you build should have the same "Help | About" form. The form should always display the following information:
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.
A common oversight is applications don't check for invalid data. You should add "Tools | Validate Data" to your application.