SSW Foursquare

Rules to Better Interfaces (Forms) - 26 Rules

For specific Windows Forms Application rules, go to Rules to Better Windows Forms Applications.

  1. Do you avoid having unnecessary labels?

    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.

    labels are a last resort bad
    Figure: Good example - Unnecessary labels

    labels are a last resort good
    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.

  2. Being Pedantic - Do you avoid ending labels text with a colon?

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

  3. Do you know how to align your form labels?

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

    Top aligned

    label 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

    label 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

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

    label material labeling

    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.
  4. Do you align your Add/Edit/Delete buttons horizontal and bottom right?

    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.

    BadButtonAlign
    Figure: Bad Example - This form places the Add and Delete buttons in the top right.

    BetterButtonAlign
    Figure: Buttons aligned vertically, however they cut off useful information in the datagrid (Better)

    GoodButtonAlign
    Figure: Good Example - Buttons align horizontally at the bottom right of the grid which provides plenty of room for then needed information

  5. Do you avoid "Data Junk" (data not manually entered by yourself)?

    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?

  6. Do you avoid combining different entities?

    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

  7. Do you avoid doing an embedded 'Add'?

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

    EmbeddedAdd
    Figure: The 'Add New' button changes from a view into a data entry form

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

    GoodEmbeddedAdd
    Figure: Good Example - the 'New' button in Outlook opens a new form for you to construct your email

    sharepoint add table
    Figure: Adding a table in SharePoint have a popup with dimmed background

  8. Do you avoid dynamically labeling your form buttons?

    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

  9. Do you avoid using menus for ComboBox maintenance?

    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

  10. Do you avoid using one form for data entry?

    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.

    Rule 2formbetter bad 1
    Figure: Bad Example - ListView with data entry fields in one form

    Rule 2formbetter good 1
    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.

    Rule 2formbetter good 2
    Figure: Good Example - Separate form with all the data entry fields

  11. Do you avoid using plain textboxes for notes?

    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.

    BadNotes
    Figure: Bad Example - use of a plain textbox limits the detail of the user's notes

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

  12. Do you create a popup form for editing details?

    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.

  13. Do you follow the control size and spacing standards?

    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:

    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.

    GoodStandardForm
    Figure: Good Example - The form follows Standards of good form design discussed below

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

    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

    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.

  14. Do you group related fields by using FieldSet?

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

    fieldset
    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

    fieldset browser
    Figure: How that code will look on the browser

    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.
  15. Do you use HTML "maxlength" attribute to limit number of characters on input fields?

    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)"
  16. Do you have a label tag for the fields associated with your input?

    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.

  17. Do you have consistent way to store a same field?

    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.

    GoodExample
    Figure: Street Address in Outlook.

    BadExample
    Figure: Street Address in CRM.

    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.

  18. Do you know how to label web-based form buttons consistently?

    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.

    BadButtonLabels
    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

    GoodFormButtonLabel
    Figure: Good example - This form uses the standard button naming standards (and has the Default buttons set!)

  19. Do you know the correct way to develop web-based data entry forms?

    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.

    bad form controls
    Figure: Bad example - Ambiguous controls

    Good form 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.

    Bad responsive
    Figure: Bad example - Design fails on smaller views

    Good responsive
    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.

    Bad Example Form Formating
    Figure: Bad example - This form has left alignment and non-decimal values

    Good Example Form Formating
    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.

    minimum defaults
    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.

    NoCreatedUpdatedField
    Figure: Bad example - This form does not contain Created by/Updated by fields

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

    Delete Button grid
    Figure: Bad example - Delete buttons shown

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

    AppropriateUseOfRemove
    Figure: Exception - This grid contains delete button because all of the required information can be seen from the main form

  20. Do you make text boxes show the whole query?

    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.

    textarea small bad
    Figure: Bad example - Can't see the whole query

    textarea big good
    Figure: Good example - Text area expands showing the entire message as it is typed

    More info:

  21. Do you provide hints for filling non-common fields?

    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.

    field hints
    Figure: Good example - Field hints can make the user more comfortable

  22. Do you provide red errors next to the field?

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

    red error
    Figure: Good example - Provide red errors next to the field

  23. Do you provide the user Drill-Downs and Drill-Arounds?

    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

    Figure: Use named buttons to navigate around the application (Preferred)

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

    Figure: Good Example - Use ellipses to navigate around the application

    1. Use hyperlinks

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

  24. Do you save the last user's 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.

    SampleSelect
    Figure: Bad Example - This is suitable for first view, but not for a return view

    SampleSelect2
    Figure: Good Example - Instead, save the users last selection

  25. Do you use the concept of drafts?

    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

  26. 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: 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.
We open source. Powered by GitHub