Types of Fields
Text fields allow members to input, edit and select text. They are differentiated by an underline affordance, and become highlighted when active. Use label text as hint text, as the hint text will transform to a label once the field is active.
Use a list item for most field entry options, with a label on the top and the field entry underneath. We can use this type of field with pickers, menus and multi-item select. If triggering an in-line menu, use a drop down arrow.
Use pickers when you have a finite set of options for the member to choose from. We recommend using keyboard entry if typing a response is easier than scrolling through a set of options. For example, typing in two letters for the state in an address is likely faster than scrolling through 50 states.
We also advise against using pickers with a long set of options (roughly greater than 20 options) with the exception of numbers, which members are likely familiar with scrolling through.
Dates can be chosen with a calendar picker. Surface the current year if a member should pick a nearby date.
If members need to see all options side by side to answer the field, use single-item select instead of a picker.
Single-item select allows members to select one option from a set. Use radio buttons if you think that the member needs to see all available options side-by-side, or if the options require a significant amount of explanation (which should be provided as description text)
Multi-item select allows the member to select multiple options from a set. Use checkmarks to indicate that a member can select more than one item.
We use full width fields in a small number of cases when the context provides enough explanation for a field, even when the field is completed.
Examples of this include the post description in Connect, adding a comment in Connect, any chat: 24/7 chat, messaging a coach, and instructions in recipes.
We use icons as radio buttons in a limited number of self explanatory fields. Actions must be discreet.
Use toggles for simple yes or no questions. If the label does not provide context for a member to make a choice, provide explanation in the detail entry.
Use menus for discreet options that can affect the app, view, or selected elements within a view. For example, when switching between folders while uploading a photo to connect.
Menus are also great for conditional statements, when the selected input affects other elements in view. Menus should have at least two options, with a maximum of 6 options visible at any time.
Use menus for discreet options within dialogs. Never display a dialog on top of a dialog.