Fields are used to gather information and to set values. They are one of many elements in a form, and typically have an input area and label (except for Search fields). They can display help text, icons, menus or both.
There are two main field types: Input Fields and Select Fields. There are many variations of each field type including a combination of input and select, and combination of input field and button.
Users manually type content into an input field. Use this field when only one line of content is necessary.
Users can also manually type in the field or select from a pre-defined list of options in a select field, and the value of the field changes depending on the most current selection. They work in conjunction, but are still 2 separate actions.
When there are more than 7 options in the menu, it would be valuable to offer “type-ahead” in the text field to filter the menu options.
When multi-selection is appropriate, use check boxes for each menu option. All selections should appear as values in the field, separated by comas. This is one situation where field content could be truncated, but in general, the field should be large enough to accommodate multiple selections or a different pattern should be used.
In some rare situations, a button can be placed in the menu. Be sure to make it “stick” at the bottom so that it is always visible.
1. All fields have labels (except for Search fields) 2. Fieldlabelsshould be clear, concise and helpful 3. Fields have squared corners. Do not create buttons with rounded corners. 4. Do not wrap field labels to a second line 5. Do not truncate field labels, field content, or menu options 6. Avoid icons unless necessary (except where specified for field help) 7. Provide default values, when appropriate 8. Provide help content only when it is necessary and helpful
Type your input value.
Type your input value or select from a list of options.
Embedded Field Help
Field help can be inside the field to show how to populate the field (for example, 000.000.000 for an IP address) or what the field is for (for example a search field). Or it can be below the field (always visible) with an “information” icon inside the field, when a description is appropriate.
When a field does not pass a validation test, the help content can be placed below the field (always visible), with an “critical” icon inside the field.
For situations when showing a field passed validation is appropriate, the “success” icon is placed in the field. No description is necessary.
Sign In Field Help
For Sign In fields, it is best not to tell users whether it was the User ID field or the Password field that failed validation. In this case, display one message for both fields.
Required fields are denoted by an asterisk.
Horizontal check box lists can be used when vertical space is limited.
Multi-line Input Fields
Normal input fields only allow for one line of text. When multiple lines of content are appropriate, the field is taller. And when there is more content than is visible, this field can have a scroll-bar.
Combination Input & Select Fields
When users can type input and select from a menu, then this combination field is best. It allows users to type in the field and see a menu that is filtered based on that input. Or the user can see all menu options by just clicking on the menu icon.
Combination Fields & Buttons
A pattern that we want to use for Browse fields is to have the Browse button change to display progress after a file is selected. In the example below the animated progress indicator is displayed in the field and the textual progress description is displayed in the button.
Search fields are pretty standard, but break a lot of normal field conventions. Search fields do not use field labels; the Clear icon is placed directly in the field (not in a separate button); the field uses type-as-you-go to invoke a menu of options that mach the typed text, and the Search button can be activated by clicking the Enter key.
When appropriate, a Scoper select field can be combined with the Search input field to narrow the search criteria. A good example of this is the Amazon search field; in this case the scoper menu is used to narrow the search by the store’s departments.
When users can change a field without the entire page being in a modal edit state, then an inline edit pattern can be used. In this case, clicking on the edit button causes the Edit button to disappear and the Cancel and Save buttons to appear. The Edit button can appear as a primary, secondary or tertiary button type, but it should always be 40px (same height as the field).
Can’t find what you’re looking for?
Feel free to share any comments or concerns, and request any other elements you might need.