Rules to Better Interfaces (Forms) - 25 Rules
For specific Windows Forms Application rules, go to Rules to Better Windows Forms Applications.
Thinking about UI, we want to make them as clean as possible... you do that by removing noise. One of the most common ways to remove noise is to remove or de-emphasise labels.
Figure: Good example - Unnecessary labels 
Figure: Good example - Users know what things are without all the unnecessary labels Find these and more examples and information on labels are a last resort.
Labels provide an easy way to show text in a form. It is recommended to consistently keep labels as clean as possible, without having them ending a colon [ : ], which is a common thing to do in Windows Forms.
Figure: Bad Example - Labels with ":" at the end 
Figure: Good Example - Clean labels without ":" There are different ways to align your form labels and each has its own pros and cons.
Top aligned
Pros:
- Easiest to process
- Fastest completion times
- Good for multiple languages
Cons:
- Takes up a lot of vertical space!
- Makes a long-form look even longer!
Left aligned
Pros
- Easy to scan labels, especially if you have a lot of optional labels
- Takes a little more attention to fill in, so useful for complicated forms that require accuracy
Cons
- Horizontal space, unlike vertical space, is not limitless, and an unintended horizontal scrollbar is the first sin of web development.
- Slowest completion times
- Poor multilanguage support
- Not even very good responsive support
Right aligned
Pros
- Best at linking label and form
- Good completion rates on small, common forms (i.e. Login, Sign up)
Cons
- Hardest to read and scan
- Poor multilanguage support
- Poor responsive support
Material labeling
Alternatively, we can use Material labeling which places them inside the form and slides up on focus.
Pros
- Best for readability
- Best for visual connectivity
- Best for completion rates
- Decent multilanguage support
- Decent responsive support
Cons
- Extremely time-consuming to implement. Need to consider the cost/benefit.
- Not necessarily available on 3rd party platforms, like Wufoo or Microsoft Forms.
Usually there are problems fitting buttons next to datagrids or listboxes when trying to imply that those buttons add functionality to the datagrid or listbox.
Figure: Bad Example - This form places the Add and Delete buttons in the top right. 
Figure: Buttons aligned vertically, however they cut off useful information in the datagrid (Better) 
Figure: Good Example - Buttons align horizontally at the bottom right of the grid which provides plenty of room for then needed information When there are too many choices always Default to the most common ones. Then add a checkbox to allow the advanced users to turn off the common choices.
[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)
A good example on that the checkbox on the search screen of TimePRO.NET:
Figure: Default search tick box in TimePRO.NET Read our rule on Validation - Do you avoid capturing incorrect data?
If the form controls are different entities, they usually have different data and different validation, thus they should not be combined.Having the controls separated also make the form easier to read.
Figure: Bad Example - Different entities are combined 
Figure: Good Example - Different entities are separated For any case of 'Add New', choose to open a new window (popup) for entering data.
Figure: The 'Add New' button changes from a view into a data entry form 
Figure: Bad Example - The 'Add New' button, shown in Figure 1, opened the page in the same window It is better to open in a new form, reasons being:
- It is better for the user in terms of clarity. The change of view to data entry form can be a surprise
- It is better to code e.g. if you are using this control in a couple of places you may need to show or hide 'Save' buttons etc. Otherwise, it is a pain to make it behave differently in different contexts.
However, you do need to call back on save and requery it.Use a modal form and requery it (DON'T use JavaScript, instead use the Modal Popup Form Example)An example of this is in Outlook with the 'New' button.
Figure: Good Example - the 'New' button in Outlook opens a new form for you to construct your email 
Figure: Adding a table in SharePoint have a popup with dimmed background The buttons that a user will typically use should not be dynamically labeled across your applications.
Figure: Bad Example - Buttons are dynamically labeled "Build ..." and "Edit ..." depending on text in the text box 
Figure: Good Example - Buttons are not dynamically labelled Using a separate menu to maintain ComboBoxes is never a good idea. A better solution is to use an ellipses button to drill down into the menu.
Figure: Bad Example - Menu driven ComboBox maintenance form 
Figure: Good Example - Use ellipses to drill down into a ComboBox maintenance form Combining data entry and find navigation is a mistake. I think 2 forms are better than one. I prefer a list box on one form with "Add", "Edit" and "Delete" buttons to a popup form. Rather than a listbox and the data entry fields on one form.
Figure: Bad Example - ListView with data entry fields in one form 
Figure: Good Example - ListView with only 'Add' 'Edit' 'Delete' buttons When you want to create a new entry or edit one, just click the buttons and open a new form with all the data entry fields.
Figure: Good Example - Separate form with all the data entry fields Instead of using plain textboxes for notes, use rich textboxes. It allows you to use links to URLs, formatting (including bold, underline, italics, font type and font size, etc.), bullet points and numbering.
Figure: Bad Example - use of a plain textbox limits the detail of the user's notes 
Figure: Good Example - with use of a rich textbox, you can use features such as bold, underline, highlighting and hyperlinks. See our page on The Best 3rd Party Web Development Tools and you will find the FreeTextBox Demo.
If you want to edit a single item in your form we suggest you use a popup form. This gives each form a definite function and neat UI design.
Figure: Bad Example - Edit controls and main UI are messed up. 
Figure: Good Example - Use a popup form to do edit. Despite seeming trivial, the most subtle elements of your form can have the greatest impact on your users.
Figure: Bad Example - See below what is wrong with this form The form shown in this screenshot is an example of bad control placement:
- The fonts used are non-standard
-
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: Good Example - The form follows Standards of good form design discussed below 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...
- Margins must be consistent (see Microsoft's diagram illustrating this)
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 you 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: Good Example - Microsoft have defined to exacting measures what spacing should be used in their Microsoft Outlook wizards Read more about control size on the Rules to Better Windows Forms page.
FieldSet element allows you to group thematically related controls and labels. Grouping controls makes forms more accessible and easier for users to understand the purpose of filling the forms.
See the example below using "Your Details" and "Event Details".
Figure: Good example - Use FieldSet for grouping Here's an example of how FieldSet works:
<fieldset> <legend>Your Details</legend> <p> <label for="FirstName">First Name: </label> <input id="FirstName" type="text" /><br /> <label for="LastName">Last Name: </label> <input id="LastName" type="text" /><br /> <label for="EmailAddress">Email Address: </label> <input id="EmailAddress" type="text" /> </p> </fieldset>Figure: Example code of FieldSet
Figure: How that code will look on the browser Things to remember:
- Wrap logical control groups in a <fieldset>.
- The first child of a <fieldset> should be a <legend>, so the user knows what to expect in that section.
When adding input boxes to collect data, please always have a <label> tag associated with your <input> tag to link the labels with their respective edit controls. This improves accessibility and gives nice focusing stuff (when you click the label).
<p> <label for="EmailAddress">Email Address</label> <input id="EmailAddress" type="text"/> </p>Tip: To do this in ASP.NET use the AssociatedControlID parameter on your <asp:Label />; controls.
<p> <asp:Label ID="EmailLabel" runat="server" Text="Email Address" AssociatedControlID="EmailAddress"/> <asp:TextBox ID="EmailAddress" runat="server"/> </p>Tip: For a nicer user experience, consider using adaptive labels and inputs with a UI Library like Material UI.
In Outlook the Street Address is stored as 1 Multi-Line field (with an intelligent Address Checker - nice but not essential), yet in Microsoft CRM the Street Address is split out across 3 separate single line text fields, they should be consistent.
Figure: Street Address in Outlook. 
Figure: Street Address in CRM. We consider Outlook is friendlier, because:
- The wrong data is entered often when you have Street 1, Street 2, Street 3.
- Often Street 2 and Street 3 is not needed so it is extra clutter for no reason.
- What do you do when you have Street 4.
- It is the same as http://local.live.com/
Of course, we might be wrong, because:
- Basically, it's not worth the effort - because it goes across multiple places in CRM like Leads and Opportunity (see test results from Adrian).
- Printing labels might be simpler - sizes would be fixed.
We have a suggestion for CRM about this at CRM and Outlook should be consistent with regards to Addresses.
Consistency is a key factor of software development, designing applications that minimise the learning curve through consistent use of componentry and functionality. If buttons with similar functionality are named inconsistently across a web application, it can cause a confusing experience for its users. For example, the buttons used to close a form should be named consistently across your application.
Additionally, buttons should have clear names so the user knows what to expect. For example, it is unclear if a button named Close will save (or not save) when closing, so Cancel would be clearer.
Figure: Bad example - Unclear labels on the buttons - Save button alone is not explicit about the following action for the form (It could close or remain open)
- Close could save the fields, then close the form, when the Cancel button may be more appropriate
We recommend the web standards of:
- Save - Save data without closing the form
- Save and Close - Close the form and save any changed data
- Cancel - Close the form without saving
Figure: Good example - This form uses the standard button naming standards (and has the Default buttons set!) Regular users or data entry personnel should be able to use your data entry form with ease. The form should follow a logical sequence of steps that matches the expectations they have based on their past experiences. This user experience will help to maximise their efficiency and satisfaction.
Video: Mastering Web-Based Data Entry: A UX Handbook | Toby Churches | SSW Rules (6 min)
Use descriptive button labels
Forms should clearly indicate how a button will affect the page's state. For instance, a "close" button alone can be ambiguous; it's unclear whether it will apply or discard changes.
To avoid confusion, provide buttons for every possible state change and make "cancel" less obvious. For example, include 3 buttons:
- "Save" - Saves the form without closing it
- "Save and close" - Saves and closes the form
- "Cancel" - Closes the form without saving
Furthermore, ensure state-based actions are labelled consistently across the application so that users always know what to expect.
Figure: Bad example - Ambiguous controls 
Figure: Good example - Well defined controls and associated actions Test UI Responsiveness
With the diversity of modern devices used to access web-based applications, responsive design is an essential part of form development, ensuring that the fields can be accessed. Generally, the size of the form field should also be indicative of the amount of data it should possess.
Consider the following Questions:
- Is the form resizable?
- What happens if the user resizes and/or maximizes the form?
- What if the user is using their mobile phone or tablet?
For more information, read about making webpages work on mobiles and tablets and providing alternate sizings for Bootstrap columns.
Figure: Bad example - Design fails on smaller views 
Figure: Good example - Responsive design for smaller views Field formatting
Field formatting is essential for a good UX. Ensure that the data is displayed in a logical manner based on the datatype of the input. always consider the usecase of the data being conveyed, but here are some guidelines to get you started:
- The size of the field should be similar to the expected size of the data
-
Numerical values contain the least amount of decimal places to convey the information required
- For example: On an invoice you need to provide very precise figures, so you would need to use 2 decimal places. However, on a sales report you may not use any decimal places as it is just to convey the general trend of dollars to management.
- The frontend converts the database format into a human readable format e.g. 2 decimal places
- Numerical values have right-alignment
- Currency and Percentage fields contain relevant numerical symbols i.e. '$' or '%'
Note: This format conversion can be difficult for data-bound fields. Luckily, many frameworks such as Angular provide convenient methods for handling such situations. In the following code extract, an example of Angular pipes can be seen to format the currency and percentage fields.
<div> <!-- When amount = 10 , output = '$ 10.00' --> <p>Currency: {{ amount | currency}}</p> <!-- When percentage = 0.1 , output = '10.00 %' --> <p>Percentage: {{ percentage | percent: '1.2-5'}} </div>Figure: Code - Angular Pipes for formatting data
Alternatively, this could be done by triggering a transformation method in the TypeScript file with event binding. This would ensure that the input field would be reformatted when modified.
See more on arranging forms and aligning form labels.
Figure: Bad example - This form has left alignment and non-decimal values 
Figure: Good example - These fields have appropriate width for the data Use auto-populated fields when possible
Populating fields with default values, such as pulling data from system time, enhances data entry efficiency and user satisfaction by reducing trivial and repetitive data entry. However, when opening a new form, only prepopulate fields unlikely to change, such as sales tax. If you want the user to consider a field, don't prepopulate it by default.
Figure: Good example - This form contains the date as that can be safely prepopulated Use Validation
Validation is essential for any form development, with the majority of fields requiring validation of some description. The 3 main categories of validation include:
- Required - The field should be filled in
- Formatting - The field must be in the correct format. e.g. currency or date
- Logical - The field needs to pass some validation tests in the business layer
Tip for long forms: the desired behaviour for when a validation error occurs is to take the user back to the improper field via a scrolling motion. This is particularly important for mobile devices where the responsive layout may cause the form to be extended, requiring further effort to identify the issue.
Figure: Good example - A scrolling effect added to the validation Show "created by" and "updated by" fields
For the purposes of logging and change history, it is highly recommended that the following information is maintained:
- Date Created - The date on which the record was created
- Employee Created - The employee responsible for its creation
- Date Updated - The date on which the record was last updated
- Employee Updated - The employee that last updated the record
This will assist with accountability, allowing users to quickly see information about recent changes.
Additionally, these fields of the form should remain "Read only" ensuring that the data is accurate and reliable.
Figure: Bad example - This form does not contain Created by/Updated by fields 
Figure: Good example - This form contains Created by/Updated by fields Avoid "Delete" button for item lists
For a list of items that is used for searching for individual records, the user shouldn't be given the option to delete from the grid. Instead, they should have to open the individual record to be presented with the option to "Delete" the data. This forces the user to examine all of the information before deleting.
Figure: Bad example - Delete buttons shown 
Figure: Good example - This grid contains no delete button, requiring the user to examine the entire record via "Edit" before deletion However, this rule is contextual. For instances where the importance of the data is trivial or all of the necessary information is immediately presented within the grid, it would be acceptable to include a "Delete" button on the grid.
Figure: Exception - This grid contains delete button because all of the required information can be seen from the main form Text boxes are often limited in size. When the user have a large ammount of text, the field should grow bigger to show the whole query.
Figure: Bad example - Can't see the whole query 
Figure: Good example - Text area expands showing the entire message as it is typed More info:
If you have form fields that require some further information, you can provide a hints column next to the fields so users know what the purpose of the data is.
Figure: Good example - Field hints can make the user more comfortable Too often error messages are a summary at the top or the bottom of the page. Instead please provide an error message per validation error, next to the field (and in red!).
Figure: Good example - Provide red errors next to the field Users should be able to navigate around your application without having to return to the main menu to open a related form.
Think about a summary report - users should always be able to "drill-down" to track a transaction to its original source.Think about a data entry form - users should always be able to "drill-down" to the look up table
There are four ways to provide drill-downs:
- Preferred - Use buttons to navigate around the application
Figure: Use named buttons to navigate around the application (Preferred) - Double click the control
- Use buttons with three dots - an ellipsis (...) character
Figure: Good Example - Use ellipses to navigate around the application - Use hyperlinks
Figure: Drill-downs implemented as links (an interesting alternative but a bit too much of a visual impact) Another handy thing to add for users is "drill-around". This is implemented by using a right mouse-click to activate context-sensitive links between related screens.
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: Bad Example - This is suitable for first view, but not for a return view 
Figure: Good Example - Instead, save the users last selection Your form should prompt to save the record when the user leaves a page that has been modified. Alternatively, you can prompt the user when they log back on that they have drafts. E.g. mail.google.com
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: Good example - Good border protection on a form at run time. The only problem is you would have to imagine these blue lines to get consistency Border protection in action:
Figure: Bad example - Controls placed very near to the border and not aligned correctly 
Figure: Good example - All controls are in the border protection area and aligned correctly 
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&A
Why don't we put a panel on the form and set the form DockPadding property which does a similar thing?
- 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.