Rules to Better Interfaces (Forms) - 26 Rules

Thinking about UI, the objective is to create clean interfaces by minimizing clutter. You do that by removing noise. One of the most common ways to avoid noise is the removal or de-emphasis of labels whenever possible.

Find more examples and information on the article "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.

There are different ways to align your form labels and each has its own pros and cons.

1. Left-aligned

When labels are left-aligned, the spacing between labels and input fields becomes inconsistent. The excessive visual distance between the labels and their corresponding input fields is a problem.

✅ 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

2. Right-aligned

Right-aligning labels ensures a consistent visual distance between the labels and their corresponding fields across the form. This strengthens the association between them, as objects placed closer together are perceived as related.

However, the inconsistent spacing on the left side of the forms makes it harder to scan the fields, leading to user discomfort and slower completion of lengthy forms.

✅ 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

3. Top-aligned

In addition to being more visually appealing, placing labels above the input fields minimizes the visual distance between the label and the input field, creating a stronger cognitive association and enabling faster user response.

The downside of this alignment is that it increases the overall height of the form.

✅ 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

4. Adaptive placeholders

Adaptive placeholders are form labels that become into placeholders and vice-versa, depending on which fields have been filled or not. The placeholder is placed inside the form and slides up on focus and after field is filled. It gives the form a great UX.

✅ Pros

• Best for readability
• Best for visual connectivity
• Best for completion rates
• Decent multilanguage support
• Decent responsive support

❌ Cons

• Time-consuming to implement. Need to consider the cost/benefit
• Not always available on 3rd party platforms, like Wufoo or Microsoft Forms

---

You can find more useful information and examples in this nice article: Form design best practices.

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.

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.

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:

A good example on that the checkbox on the search screen of 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.

For any case of 'Add New', choose to open a new window (popup) for entering data.

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.

The buttons that a user will typically use should not be dynamically labeled across your applications.

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.

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.

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.

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.

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.

Despite seeming trivial, the most subtle elements of your form can have the greatest impact on your users.

The form shown in this screenshot is an example of bad control placement:

1. The fonts used are non-standard

2. The controls have no consistency in terms of margins, spacing or even control alignment. See, for example:

   1. 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.
   2. The dimensions of all input controls and buttons do not follow standard convention (see below)
   3. The right side of the "Build..." button is not aligned with the right of the "Connection String" text box
   4. The left margins inside the two frames are inconsistent.
   5. 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.

The Rules

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

2. Single-line textboxes and most controls must be...

   • 21 pixels high (width depends on content)
   • Aligned correctly with any related controls

3. 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:

1. Consistency across wizard pages is very good
2. Spacing and sizing of buttons is precise
3. The logo has been positioned evenly

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

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

Things to remember:

1. Wrap logical control groups in a <fieldset>.
2. The first child of a <fieldset> should be a <legend>, so the user knows what to expect in that section.

Rule 1: Whenever you have a data entry page you should always use the HTML maxlength attribute to limit number of characters to the length of the field in the table (except for numbers).

Rule 2: Whenever you have a situation where you are using the HTML textarea (does not have the maxlength property).

Then you need to:

• Add the JavaScript function. E.g. ValidateLength(control)
• Add 2 properties to every data control. E.g. dataType="char" onkeyup="validateLength(this)"

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.

We consider Outlook is friendlier, because:

1. The wrong data is entered often when you have Street 1, Street 2, Street 3.
2. Often Street 2 and Street 3 is not needed so it is extra clutter for no reason.
3. What do you do when you have Street 4.
4. It is the same as http://local.live.com/

Of course, we might be wrong, because:

1. Basically, it's not worth the effort - because it goes across multiple places in CRM like Leads and Opportunity (see test results from Adrian).
2. 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.

• 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

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.

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.

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

<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'}}</p>
</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.

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.

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.

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.

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.

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.

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.

More info:

• http://blogs.sitepointstatic.com/examples/tech/textarea-expander/demo.html
• http://www.sitepoint.com/build-auto-expanding-textarea-1/

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.

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

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:

1. Preferred - Use buttons to navigate around the application

2. Double click the control
3. Use buttons with three dots - an ellipsis (...) character

4. Use hyperlinks

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.

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.

Border protection in action:

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.