The whole point of a good GUI (Graphical User Interface) is being able to understand
what is going on without reading every single detail. That is why we prefer big red
crosses to say "Don't do that you oaf!" instead of a line of text that says "I think
you may want to reconsider your options."
Do you agree with them all? Are we missing some? Email me your tips, thoughts
or arguments. Fs Let
me know what you think.
-
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 rule, 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: An example of a poor UI (Bad)
Figure: 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.
To ensure a consistent user experience, make sure to include these visual elements:
- Page name. It is important for the user to know which page they
are currently on.
- Page description. You should provide a short description of the
task to be performed on the page.
- 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.
- 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: SSW Link Auditor Wizard's better flow of information (Good)
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 customized 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: SSW Code Auditor Wizard featuring "Start" and "Skip" options good
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?
How you present the product information depends on the sort of application you
are developing.
-
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: This wizard has an information screen as the first screen (Good)
- 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: Help - About... menu item opening the product information (Good)
-
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: This screen has no product introduction (Bad)
Figure: This screen has production information before the settings (Good)
-
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: Microsoft FrontPage uses a progress bar to indicate where users are
up to. (Good)
-
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: 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 (Bad)
Figure: Good quality Finish flag on the last page of a wizard. (Good)
-
Do you use bold text or dividing lines appropriately?
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. However at times developer
use separations such as dividing lines inappropriately.
We recommend use bold instead of dividing lines because:
- Bold stands out.
- Developers are not good at keeping the lines aligned.
Figure: Dividing lines in front of "Email" and "Schedule" checkboxes are
not required. (Bad)
Figure: Indenting within the sections signifies the separations. (Good)
-
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:
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: Unclear labels on the buttons (Bad)
- 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 and will
been changed in the form's current lifetime.
- Apply. Save data without closing the form.
Figure: This form uses the standard button naming standards (and have the
Default buttons set!) (Good)
-
Time formats should be consistent across your application, to give the application a very
professional and consistent look.
Figure: Three screens with inconsistent time formats (Bad)
Figure: Three screens with consistent formats (Good)
-
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: Buttons are dynamically labelled "Build ..." and "Edit ..." depending
on text in the text box (Bad)
Figure: Buttons are not dynamically labelled (Good)
-
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: Title contains brief description of error, which is
already contained in the message box. (Bad).
Figure: Title contains Product Name ("SSW eXtreme Emails!") and
Product Version ("12.56"). (Good).
We have a program called SSW Code Auditor
to check for this rule.
Note: The
Version Number in the title should only contain the Major and the Minor
version numbers (e.g. 11.28) and not the complete Major.Minor.Revision.Build
Numbers (e.g. 11.28.92.1198) |
Description
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: A message box that does not intuitively alert the user (Bad)
- 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: A message box that is clear, consistent and intuitive (Good)
- 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 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: Microsoft error message is concise. (Good)
Some other message types that Microsoft use are:
| Message type |
Sample message |
| Not enough disk space |
There is not enough disk space to complete the operation. Delete
some unneeded files on your hard disk, and then try again. |
| File not found |
The program cannot find the file filename. |
| Re-running setup |
The filename file is missing. Run Setup again to reinstall the missing
file. For more information about running Setup, press F1. |
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: What's wrong with this form? (Bad)
The form shown in this screenshot is an example of bad control placement:
- The fonts used are non-standard (see: Do you use Microsoft's
Recommended Font in your Application?)
- The controls have no consistency in terms of margins, spacing
or even control alignment. See, for example:
- 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.
- The dimensions of all input controls and buttons do not
follow standard convention (see below)
- The right side of the Build... button is not aligned
with the right of the Connection String text box
- The left margins inside the two frames are inconsistent.
- 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: The form follows Standards of good form design discussed below (Good)
The Rules
- 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
- Single-line textboxes and most controls must be...
- 21 pixels high (width depends on content)
- Aligned correctly with any related controls
- In a form...
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:
- Consistency across wizard pages is very good
- Spacing and sizing of buttons is precise
- The logo has been positioned evenly
Figure: Microsoft have defined to exacting measures what spacing should be
used in their Microsoft Outlook wizards. (Good)
-
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: Completed items are struck-through (Good)
-
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: 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: 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: Pass and fail are not clear. (Bad)
Figure: Green text and tick for pass, red text and cross for fail. (Better)
Figure: Status on windows forms (Good)
Figure: Microsoft Update uses 3 icons to indicate different status, and good
quality of Images too. (Good)
-
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 : Form is too large to fit inside 800x600 resolution (Bad)
Figure : Form fits inside 800x600 resolution (Good)
The Potential Solutions are:
- Reorder and move the controls around on the form.
- Implement Tab pages.
- Use a wizard type interface, with Next, Back and Finish.
- Create multiple forms each containing a subset of the controls.
- 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: Read only fields should be greyed out (Good)
Figure: Calculated Fields in Excel should be in Grey (Good)
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: 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 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 Taskbar, 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: Application with a standard title bar caption (Good)
-
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 : User Guide link in the Help menu (Good)
-
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:
- Version number
- URL
- 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
- Contact details (especially a phone number)
- Branding (logo)
Figure: This About dialog does not provide enough information about the
product and/or company (Bad)
Figure: The old SSW Standard Help >About form across all our products (Better)
Figure: The new SSW Standard Help > About form across all our products (Good)
-
Menu - Do you know the seven items every Help menu
needs?
A good help menu should have these seven items in it:
- Online User Guide
- SSW Knowledge Base
- Make a Suggestion
- Report a Bug
- Check for Updates
- Run Unit Tests...
- About [Product Name]...
Figure: Example of a Help menu with only About. (Bad)
Figure: Example of a Help menu with all seven items. (Good)
-
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.
Bad Example:
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 (Bad)
Good Example:
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
(Good)
-
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
How to use a sound file in VS 2005:
You must save the .wav file you wish to use to your computer and then add it to your Solution.
Once the file has been added to your solution, you then need
private void playSoundFromResource()
{
using (SoundPlayer player = new SoundPlayer(Resources.SoundResource.finish))
{
player.Play();
}
}
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
(Good)
However, not everyone likes sounds, so we think it is also important to have
an option to disable sounds in your application.
Figure: Turning on Feedback with sound in Outlook (Good)
-
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: Standard warning before a program exits (Good)
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: Cancel button for a wizard as part of a process (Bad)
The term 'close' is more appropriate when we are dealing with a wizard that,
when closed, ends the entire application.
Example:
Figure: Close button indicates the application will exit (Good)
-
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: Custom database connection screen in Speed Ferret (Bad)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: Standard Microsoft UDL dialog (Good)
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 (include 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: Options menu in Outlook, with ellipsis (Good)
Figure: Ellipsis on buttons that require further input (Good)
-
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: Calendar Control - Sunday is at the front, today's date is not highlighted,
items with data are not bolded (Bad)
Figure: Calendar Control - Monday is at the front, today's date is highlighted,
items with data are bolded (Good)
-
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 provide 'Continue anyway' functionality for when installation conditions
are not met?
I think too many times the 'continue anyway' approach is not taken, and the
developers add their validation but with no flexibility to continue. Example
of this can be installation package that requires a user to have certain version
of SQL Server, or SQL Server Reporting Services, or Exchange Server, or .NET
Framework on his computer. The reason to allow user to continue installation
is the user might know he has it on a server or something.
Figure: 'Continue Anyway' checkbox allows user to continue even conditions
are not met (Good)
-
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
Likewise in a contacts database where you have entries from all around the world
it is good to add a check box on the search screen similar to the following:
[x] Only include customers that have been updated by employees (not directly
entered from the web)
-
Do you include the number of results in
combo-boxes? 
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 combo-boxes.
Figure: You can't tell the number of results and there is a scroll bar (Bad)
Figure: The number of results is clearly displayed (Good)
But about long text boxes > 30 entires, this is another approach - puts the
common ones at the top
Figure: Bad - because it is manual and what about the 4th,5th etc most
common used countries
Figure: Good - 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 combo-boxes?
Combo-box is used for filtering data normally, it will be useful to have
'-All-' option to give your user chances to select all data.
Figure: No '-All-' option, user cannot select all data (Bad)
Figure: Having '-All-' option, user gets chance to select all data (Good)
-
Do you extend the size of your combo-boxes
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 combo-boxes 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, you shouldn't extend your combo-box without limit, normally the
maximum number of items should be under 10 and the maximum width of the drop-down
should be smaller than your hosting form.
Figure: You have to scroll to see all the result, and the long results are
cut off (Bad)
Figure: The size of the drop down has been extended to allow user to see
as much as possible (Good)
Changing the maximum items is easy, just include the following code in your
form:
| cbxOUList.MaxDropDownItems = cbxOUList.Items.Count; |
Changing the drop down size is a bit of tricky
Graphics g = Graphics.FromHwnd(this.Handle);
SizeF stringSize = new SizeF();
stringSize = g.MeasureString(longString, cbx.Font, 600);
int adjustedSize = cbx.DropDownWidth;
if ( adjustedSize<(int)stringSize.Width )
{
adjustedSize = (int)stringSize.Width;
}
cbx.DropDownWidth = adjustedSize; |
-
Do you save the last users selections ?
Below is a report screen that is fairly common that developers create, they
will make it so every time the page is loaded the user will have to reselect
their options. To make it simpler the options should be stored in a cookie or
database and be already pre-selected once the page is reloaded, as it is likely
they will want to use the same or slightly modified query. If they don't then
they can simply select what they are after anyway.
|
| Figure: This is suitable for first view, but not for a return
view (Bad) |
|
| Figure: Instead, save the users last selection (Good) |
-
Do your Windows Forms have border protection?
Border protection helps us design Windows Forms properly without placing
controls too near to the border. Maintain a consistent alignment makes the Windows
Forms look better, especially on designing wizard forms where all forms have
the same size.
Figure: An example of good border protection on a form at run time. The only
problem is you would have to imagine these blue lines to get consistency. (Good)
Border protection in action:
Figure: Controls placed very near to the border and not aligned correctly.
(Bad)
Figure: Fixed - All controls are in the border protection area and aligned
correctly. (Good)
Figure: Design mode
The way to implement border protection (the 2 vertical red lines) is implement
it in the base form or base user control, and all other forms and user controls
inherit the base class to get consistent border protection lines.
private void BaseForm_Paint(object sender, PaintEventArgs e)
{
// Draw border protection lines
if (this.DesignMode)
{
Pen pen = new Pen(Color.Red);
e.Graphics.DrawLine(pen, 23, 0, 23, this.Height);
e.Graphics.DrawLine(pen, this.Width - 23, 0, this.Width - 23, this.Height);
}
}
|
Q:\
|
Why dont we put a panel on the form and set the form DockPadding
property which does a similar thing?
|
|
A:\
|
- Adding more panels docking to a form reduces the performance
significantly because of the extra SuspendLayout and ResumeLayout
calls.
- In certain cases we might really want a control to stick at
the border, if we use DockPadding Property, we can't make any exceptions.
And still, these red lines actually just act like a ruler to help
us easily see whether the controls are aligned nicely.
|
-
Do you have a top CheckBox for users to perform
a "select all"?
Do you have top checkbox that lets users select or unselect all checkboxes
underneath it? If there were a lot of checkboxes, users might get frustrated
checking all the checkboxes if you didnt provide an easy way to select all.
A checkbox at the top is a good way to let user easily select all and it is
clear.
Figure: Hotmail - A CheckBox at the top that lets you select all CheckBoxes
underneath it. (Good)
Figure: Google have done it a different way to provide multiple methods (All, All Read, All Unread, All Starred, and All Unstarred)
Figure: SQL Auditor - No CheckBox for users to perform a "select all". (Bad)
Figure: SQL Auditor - CheckBox at the top of the column. (Good) More details for the CheckBox
Figure: Checked state - select all.
Figure: Unchecked state - select none.
Figure: Indeterminate check state - customized selection.
-
Long Process - Do you know how to make
long-running processes user-friendly?
- 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: Options for skipping a long process in SSW Diagnostics (Good)
- 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
is started)
Figure: Progress Bar with Description and Cancel Button (Good)
- Provide a detailed summary and play a sound at the end
Whenever a long process is churning away (e.g. about 10 seconds) users
will usually tune out and do something else, either make a coffee or switch
to another window. By playing a sound and showing a message box at the end
of the long process it will alert the user and flash the Taskbar, reminding
the user to go back and check on it.When using Message Box to indicate
user a process is done, always includes detailed summary of the process.
Don't just say "Process completed."
- Bad:
Process completed.
- Good:
Manual extraction process completed.
Mailboxes scanned: 8
Mailboxes skipped: 2
Total mailboxes: 10
Time Taken: 10 minutes, 15 seconds
This is just like standing at a set of traffic lights listening for the
beep to speed up to know when to walk, rather than constantly looking at
the red and green men.
Figure: A completed progress form (Good)
-
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: The winform's title does not contain the progress status. (Bad)
Figure: The winform's title contains the status of progress bar. (Good)
Figure: You can clearly see the progress status from taskbar when you have
the windows minimized. (Good)
-
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.
We typically script the data in our sample database into an .sql file with a
lot of INSERT statements and then use a product such as
SSW SQL Deploy to manage the safe execution of
our .sql file.
-
Sample - Do your sample databases have
good Naming Conventions?
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.
-
Reports - Do you have a standard Report
footer?
When designing custom applications you want to include branding on reports.
There are two ways to design a standard footer. As a minimum, you can have a
line "Generated from [e.g.] SSW SQL Deploy - www.ssw.com.au".
Or, even better, you can include your company logo:
-
Reports - Do you keep Reporting criteria simple?
- Have Selection for filters e.g. Date Ranges
- Have Selection for chart options e.g. Show Legend
- Don't have selection for chart groupings e.g. By Month or By Product
- Crystal and Access these are built into the report and it is very
complex to have a generic solution.
- Also it is disorientating for the user to have this as a selection
More Options
for Reporting
-
Control - Do your buttons have a mnemonic?
A mnemonic for a button is the letter which has an underscore, and the user
can press the button using Alt-<char>.
Figure: All buttons without Mnemonic (Bad)
Figure: All buttons with Mnemonic - user can easily choose which button they
want without a click. (Good)
In Windows Applications, it is quite easy to assign a mnemonic to a button with
the & character.
So for the case above, the text would be
btnAbout.Text = "&About"
Tip: In Windows XP the mnemonic display effects can be hidden by Default and
then shown every time the user presses the Alt key.
-
Controls - Do you disable buttons that are unavailable?
If a button is unavailable, or clicking it will generate an error message
or will have no effect, then the button should be disabled. However, buttons
should not be hidden simply because they are unavailable as it confuses the
user.
Figure: The Start button is disabled in SSW Link Auditor after the scan has
started (Good)
-
Controls - Do you make Option Groups
and Check Boxes simple to understand?
There are two aspects to this rule:
- Arrange Vertically
If your user must choose from a variety of responses, or select from
a number of items, using either radio buttons or check boxes, arrange the
items vertically rather than horizontally as it makes the association much
clearer. NOTE: You might want to disregard this rule if screen real estate
is at a crucial premium.
Do you like apples? Yes
No
Cannot say
- Text on the Right
The Option Group or Check Box should always be on the left, with the
text following on the right. Once again, this makes it easy for the User
to work out what is going on.
Figure: Action on the left, text on the right (Good)
-
Controls - Do you use a ToolTip to show the
full text of hidden ListView data?
When you can't see all the text for an item in a ListView you need to expose
the full text via a ToolTip.
Figure: Users can't see all the text and the ListView doesn't use a Tooltip.
(Bad)
Figure: Users can't see all the text, but the ListView shows all the text
via a Tooltip. (Good)
The code to do this is...
private ListViewItem hoveredItem;
private void listView1_MouseMove(object sender, MouseEventArgs e)
{
ListView lv = (ListView) sender;
ListViewItem item = lv.GetItemAt(e.X, e.Y);
int columnIndex = 1;
if (item != hoveredItem)
{
hoveredItem = item;
if (item == null)
{
toolTip1.SetToolTip(lv, "");
}
else
{
// Make sure the mouse hovered row has the subitem
if (item.SubItems.Count > columnIndex)
{
toolTip1.SetToolTip(lv, item.SubItems[columnIndex].Text);
}
else
{
toolTip1.SetToolTip(lv, "");
}
}
}
}
-
Controls - Do you use Microsoft Recommended Font in your
Application?
Some font are easier to read then others, at SSW we follow Microsoft's
Visual Design Guidelines.
This means we use Tahoma 8pt as our font of choice.
At SSW, we use Code Auditor to ensure all fonts on our forms are set to Tahoma
but we allow controls to use a different font. This is because certain information
is better displayed in a different font. For example a Textbox to show code
should use Courier instead of Tahoma.
Figure: This form uses a non-standard font, and it is hard to read. (Bad)
Figure: This form uses Tahoma, and it is easy to read. (Good)
Figure: This form uses Tahoma, and the RichTextBox displays source code using
Courier New. (Good)
-
Control Choice - Do you use ListView and DataGrid appropriately?
Yes a ListView looks nicer than a DataGrid, but a Datagrid is better because
it has more functionality (out of the box that is). With a ListView you cannot:
- Copy and paste - although you can select a row of data in both controls,
you can't copy and paste a whole row from the ListView
- Sort data - always useful when there are more than about 20 rows
- DataBind - always saves heaps of code
So our old rule was to always use the ugly DataGrid (although we were never
happy about that).
Figure: The DataGrid is ugly (Bad)
Figure: A beautiful ListView - a nicer look over the datagrid (Good)
So the listview looks nicer? If you are not convinced here is another one
Figure: The appearance of DataGrid and ListView
But another issue is how much code to write... For ListView you will need
to write a bit of code to fill the list view...
this.listView1.Items.Clear();
// stops drawing to speed up the process, draw right at the end.
this.listView1.BeginUpdate();
foreach(DataRow dr in this.dataSet11.Tables[0].Rows)
{
ListViewItem lvi = new ListViewItem(new string[]
{dr[0].ToString(),dr[1].ToString(),dr[2].ToString()});
lvi.Tag = dr;
this.listView1.Items.Add(lvi);
}
this.listView1.EndUpdate();
Figure: 8 lines of code to fill a ListView (Bad)
But the datagrid is nicer to code... this is because it comes with data binding
ability.
// bind it in the designer first.
this.oleDbDataAdapter1.Fill(this.dataSet11);
Figure: One line of code to fill a DataGrid (Bad)
But the SSW ListView (included in the .NET Toolkit)
is nicer to code with as it comes with data binding ability.
// bind it in the designer first.
this.oleDbDataAdapter1.Fill(this.dataSet11);
Figure: One line of code to fill the SSW ListView (Good)
So what is this SSW ListView.
It is an inherited control that how we implemented the ListView to give us what
MS left out.:
So now the rules are:
Always use the SSW ListView.
Exception: Use the DataGrid when:
- When not read only - i.e.. users will be editing data directly from
the cells.
- You need more than 1 column with checkboxes, or the column with checkboxes
cant be the first column.
Eg:
Figure: One place when you choose a DataGrid over a ListView is when
you have 2 checkbox fields.
So in summary, if you dont want users to edit the data directly from the cell,
and only the first column need checkboxes, then the ListView is always the better
choice.
-
Control Choice - Do you know when to use CheckBox?
If the option only contains 2 choices, and the answer is a Boolean type value
where the opposite value is clear (eg: Enabled/Disabled, True/False, Yes/No,
On/Off), it should always be a checkbox.
Figure: Boolean options not using CheckBox. (Bad)
Figure: A CheckBox is used for Boolean type value. (Good)
Only 1 CheckBox is used as the opposite value is clear, such controls are
often CheckBoxes in a ListView too.
Eg:
Figure: CheckBoxes in a ListView. (Good)
CheckBoxes are also suitable to use for enable or disable sections and to
tell the user that these sections do not need configuring for the
application to run.
Figure: CheckBoxes are used (although no opposite values), because they are
clear when the CheckBoxes arent ticked, the sections are disabled. (Good)
Figure: This screen implies that Configuring Credentials is required (Bad)
Figure: This screen uses a CheckBox to signify that Configure Credentials is optional (Good)
-
Control Choice - Do you use Combo Boxes instead of single-select List Boxes?
Combo Boxes are better than List Boxes for data entry because:
Figure: Using list boxes (Bad)
Figure: Using combo boxes - takes up less screen space and the required field
indication is easy to see. (Good)
Note: When are single-select list boxes OK?
As mentioned before, there are exceptions to this rule. It would be hard
to imagine the Include/Exclude boxes in the SQL Server Enterprise Manager's
Server Registration Wizard being handled with Combo Boxes, for example.
Figure: Include/Exclude Listboxes are an example of a valid use for List
Boxes
-
Control Choice - Do you use Checked List Boxes instead of multi-select List Boxes?
Multi-select listboxes are the bane of a graphical user interface, they have
a number of behavioural quirks that make it difficult for users to get used
to them:
- They require users to know that you select more than one entry by holding
down the Ctrl key
- They lose all selections if you click in the wrong place.
- You can't tell if a Listbox is single-select or multi-select at first
glace.
Figure: List Boxes are impractical - try it and see (Bad)
Checked Listboxes are the ideal alternative. They're much more pleasant
to use and are a good deal more intuitive - compare to the list above. Checked
Listboxes tell users immediately that they have the ability choose multiple
options.
- In ASP.NET, use System.Web.UI.WebControls.CheckBoxList. If you're
having problems with there being too many items in the list, use a scrolling
DIV
- In Windows Forms, use System.Windows.Forms.CheckedListBox
Figure: The beauty of the CheckListBox in ASP.NET (Good)
-
Question: What is wrong with this Picture?
 |
| Figure: What is wrong? |
| Answer: There are three different types of buttons in
the Application: |
| Next > |
- Default Window Style |
| Preview |
- .NET Flat Style |
| Cancel |
- Window XP Style |
Figure: Even labels need to use FlatStyle.System. Can you spot the wrong
label?
See our Rules to Better
Windows Forms to implement XP Themes in .NET.
-
Control Choice - Do you avoid using "Group Box" and use a line
to organize your form?
Group box should only be used when you want to notify the user the controls
within it are really related, such as radio buttons.
Figure: Inappropriate use of 'Group Box', there is nothing to be grouped
(Bad)
Figure: Use a line to organize different sections (Good)
Figure: VS.NET 2003 Options form, appropriate use of 'Group Box', the radio
buttons are related to each other (Good)
In other cases, you should avoid using group box and replace it with a simple
line, this will save you some space on the form and help you organize your form
more easily.
-
Control Choice - Do you use bold on the main options to make them
clearer?
Make the options clearer by using bold.
Figure: Main options text not in bold. (Bad)
Figure: Main options text in bold. (Good)
-
Control Choice - Do you know when to use options group (Radio
Buttons) instead of ComboBox?
When the options are static items (not database driven) and they can fit
on the screen (about 2-5 items), they should be radio buttons.
For a ComboBox, user needs 2 clicks to change the value
1) Click the little "v" button to see the available options.
2) Then click the option to select.
For an options group, user can see all the available options without clicking,
and select the option with just a click.
Figure: ComboBox is used for "Job Type" where it contains only 2 options.
(Bad)
Figure: Radio Buttons are used and aligned vertically. (Good)
-
Data Entry Forms - The way to develop Data
Entry Forms.
Data Entrees should be able to use your data entry form with ease. It will
follow the flow that they are familiar with. This is a standard we adhere to
when developing in SSW.
Figure - New button should open another form, and Delete button will be
on that new form (Bad)
- Multiple Form Instances
Imagine, while the Sally is entering a Quote on the Quote Form, they
receive a Phone call from a client needing a new Quote. The user will not
want to close the current Quote, because they are 1/2 way through it.
As we saw in the example above, Sally needs to open multiple instances
of the same form. A reputable example for this Microsoft's Outlook. When
you are 1/2 way through an email, and you chose to start writing another,
Outlook makes it convenient by placing every email you open in the task
bar. The figure below illustrates this.
Figure: Outlook opens multiple instances of the data entry form (email
message). (Good)
Figure: Each form instance is shown in the Taskbar, and easily opened
again. (Good)
A method of implementing this is through New and Delete buttons on the form
New and Delete buttons should appear, in a toolbar for example, docked to
the top.
The figure in Data Entry Forms - Drill Downs
below illustrates this.
Figure: New and Delete buttons docked in the Toolbar providing easy data
entry for new Timesheets (Good)
The Delete button resides there to make sure that sally has seen the record
before she deletes it. The New button should instantiate a new data entry
form in add mode (as compared to edit), leaving the current one in
the background.
It can be argued that navigation is required in a data entry form. As an
option, a good navigation system will navigate through a subset of records
(ideally records which are search results). The idea of navigating through
all records can be tedious, and most of the time useless.
However there is a problem
Do you open the same record with two different instances of the form. For
example, if attempt to open a form instance for editing a Quote from the
database, then while editing you open up another form instance for the same
Quote. Besides the fact that there will be loss of data, and dirty reading,
this is a very confusing interface.
A possible solution for this issue is to implement a form manager.
The form manager will keep track of every instance opened. So
in our example, the second time we try to open the same Quote for editing,
the form manager will recognize that there is a form currently being
edited that Quote, and would select that form.
- Form states and how to respond to them
The form is to be aware
of the data state. If the data is dirty:
- The Apply button would be enabled until the record is saved.
- The OK button would simply save the record and close the Form.
- The Cancel button would pop up a dialog (shown in the figure below)
asking to save changes;
If the user decides to save, it should save the record and close the
form.
If No, then close the form without saving.
If Cancel, then return back to the dirty form.
Figure: Save Changes Dialog must appear when form is dirty (Good)
Do not add buttons for searching on the data entry form, create a new form
for search, through which you can open new instances of the form. The convenience
of the search capability on the form will be overlooked as it makes the
form more crowded. Another issue which can arise is if Sally searches for
a criteria which returns multiple records, she cannot look at all those
records. She can only open one at a time, navigating through them. The solution
to the search dilemma is to create a new search form, which is shown in
the figure below. The search form will allow multiple criteria, will not
over crowd the data entry form, and will show you all the results that your
search has retrieved.
Figure: This implementation of a search utility is on the same form (Bad)
Figure: This implementation of Search feature is on a separate form (Good)
- No Delete Button for sub forms
When including a sub form in your main form (as shown in figure below),
the only options the user should have are "New" and "Edit".
When "Edit" is clicked, another data entry form is opened to edit selected
record. In this data entry form, you will have a "Delete" button on the
toolbar. This saves the user from making mistakes and forcing them to see
the record before deleting.
Figure: No Delete button for Sub forms. (Good)
- Validation
Most fields required validation. There are three types of validations:
- Required Field - the field should be filled in.
- Formatting - the field must be in a correct format. e.g. currency
or date.
- Logical - the field needs to pass some validation tests in the business
layer.
To show an error, display an error provider icon next to the field on the
right. An example of this is show in the figure below.
Validation must not be done on TextChanged, this may chew the processor
if it is a logical validation. It can also give unpleasant results, e.g.
when entering -6.00, as soon as the '-' is entered the validation control
would turn on.
Validation for Required fields must be done in the validating event.
Validation for format should be done in parse/format methods.
Validation for Logic should be done in Validated, since it must be entered
if required, and in correct format.
The reason for these placement of validations is because these events handled
run in the following order:
- Validating
- Parse/Format
- Validated
Figure: Error Provider Icon next to a required field (Good)
Do not show a message box after every error in validation. You may
show a message box as an error summary when an OK or Apply is clicked. Make
sure you warn the user that there is an error on the form when they attempt
to save.
- Relevant Menus
Make sure that the menu items are relevant to the current form. The
main idea is that we don't want to show the user any dummy menu items. However,
This may become complex when a base form (containing the menu) is inherited.
Access to menus in the base form must be granted (maybe through properties),
so that each menu can be customized according to each child form.
|
|
| Figure: Action and Tools are irrelevant on this form (Bad) |
Figure: Menus are relevant (Good) |
In the above example, there are a couple of unused menus that have been
inherited from the base form and not set to invisible.
- Field Formatting
Ensure that the data is displayed in correct format. For example, when presenting
a percentage data in a field, make sure it is displayed as '% xx.xx'.
To accompany formatting, you must also create a parse function for putting
the correct value back in the database.
Note: This can be difficult for data bound fields, and in that case you
will have to handle the parse and format event of the Field's Binding object.
An example of handling these events is shown below.
Dim controlBinding As Binding = New System.Windows.Forms.Binding(propertyName,
dataSource, dataMember)
AddHandler controlBinding.Format, AddressOf DecimalToCurrencyString
AddHandler controlBinding.Parse, AddressOf CurrencyStringToDecimal
controlToBeBound.DataBindings.Add(controlBinding)
Private Sub DecimalToCurrencyString(sender As Object, cevent As
ConvertEventArgs)
' The method converts only to string type. Test this using
the DesiredType.
If Not cevent.DesiredType Is GetType(String) Then
Exit Sub
End If
' Use the ToString method to format the value as currency
("c").
cevent.Value = CType(cevent.Value, Decimal).ToString("c")
End Sub
Private Sub CurrencyStringToDecimal(sender As Object, cevent As
ConvertEventArgs)
' The method converts back to decimal type only.
If Not cevent.DesiredType Is GetType(Decimal) Then
Exit Sub
End If
' Converts the string back to decimal using the static ToDecimal
method.
cevent.Value = Decimal.Parse(cevent.Value.ToString, NumberStyles.Currency,
nothing)
End Sub
Code: Code for Handling Parse and Format Events for Data bound Controls
When using the visual designer in VS.Net, the Binding is created and added
to the Data-Bindings of the Control all in one line. Do not use the visual
designer to data-bind if you will be handling the Parse and Format events.
You will have to create the handlers yourself
- Created/Last Updated By Fields
With all database entries, there is always some fields that are used over
and over again. For example, these fields may be created date, created by,
last updated date, updated by, etc.
A common UI to use for these fields can be seen in the example below. What
we do is create a user control that is identical across all projects/UI.
Figure: This form has no information to indicate who created this entry
and who last modified it. (Bad)
Figure: This form contains Created by/Updated by fields used in a standard
control which is put into all forms (Good)
An example of how to set the values for this user control is shown below.
updatedBy.CreatedDate = .DateCreated
updatedBy.CreatedBy = .EmpCreated
updatedBy.UpdatedDate = .DateUpdated
updatedBy.UpdatedBy = .EmpUpdated
Code: Code for Setting values for User Control
Databinding is also available to be used with this user control.
Figure: Data Binding using the Designer
- Minimum Defaults
In many situations, there is a need for field Defaults. These Defaults can
be extracted from the Database for example. When a new form is opened ensure
that only necessary Defaults are loaded. By Default some decimal fields
will become 0.0, but make sure they are set to blank because they may be
required fields.
- Resizing
Is the form resizable? What happens if the user resizes and/or maximizes
the form?
Data entry forms, and forms containing List View controls, should be resizable.
Use either anchoring or docking, or a combination, to handle window resizing.
Restricting the user from resizing or maximizing the form is not recommended.