Data entry components within create view are grouped by their data type.
A. Nav Bar
Nav Bar contains the screen title and actions for user to save the data and create the item or opt out the modal without saving.
B. Key information
In order to create a new object or object detail, the user is required to enter at least one data point (such as the title of a new task) into the key information section, which should appear at the top of the window. In some cases, key information is pre-populated, and the user may or may not be able to edit these details. The type of information that appears in the key information section will differ depending on the use case; for example, if a user creates a new note, the key information section may display a text view.
Property details appear next in the create window. Any cells that contain a label and user-selectable value are considered property cells (e.g., a due date). The order of cells and cell groups within this section is based on their information hierarchy.
The accessory area is found at the bottom of the create view window. It includes elements such as switches, notes, and attachments, each of which is typically placed in its own group.
A text field allow users to enter a small amount of information into a single, fixed-height container. If multiple lines of text are required, use a text view instead (see below for more details).
Before user content has been entered into a text field, it should display clear and concise placeholder text to communicate its purpose (e.g., “Title” or “Description”). Vague directions should be avoided (e.g., “Tap to Write” does not explain the purpose of the text field). If necessary, the content in text fields can be pre-populated.
Please note that text fields should not have separate labels to indicate their purpose.
Text Field with Label
When a create modal contains a large number of text entries, such as a form used to generate a new customer profile, the Text Field with Label is recommended. This component gives users a better understanding of the purpose of each text entry.
The Label should describe the purpose of the text field, and there should be placeholder content in the field itself before the user has entered data. This placeholder can be used to indicate whether the field is required or optional to ensure users don’t miss any required entries.
The Text Field with Label component can be grouped with other cell types in create view to provide a strong sense of information hierarchy.
Picker / Date or Time
Pickers allow users to select date or time entries within create view. The date picker can be used to specify a date, a time of day, or a combination of both.
The default value of a date picker is usually the current date and time.
Drill down value lists allows for the selection of one option among values within a defined category—for example, to choose a specific project when creating a new issue entry.
Reasonable default values should be provided in value lists. In some use cases, these default values should not be editable by the user. For example, if the user triggers a create modal from a task detail screen to generate a new issue related to the current task, the value of “task” should be pre-populated and should not be editable by the user.
Value List / Long text value
When the body text in a property cell is long, the cell body should be placed on a second line below the cell title. If the body content is still too long, it should then be truncated.
The search function can be included within a value list when there is a large number of items. Values in the list can also be grouped if this would help users in more quickly making their selection.
Value List / Multiple selections
When a property cell accepts multiple values, the selected values should be displayed on a separate line below the cell title. If this second line cannot display all the selected values, its text should be truncated and it should indicate how many hidden values there are (e.g., “Value A, Value B, Value C, and 3 more…”).
Value Buttons Cell
Buttons are used within value buttons cell to allow users to quickly select from a small value set. They are generally single-selection, can only contain short text strings, and should not exceed three buttons in one cell.
Switches are used when a property has only two mutually-exclusive states—either on or off.
In some use cases, when a switch is set to ‘on,’ additional data can be entered (for example, using a date picker).
Text view cells provide space for multi-line text entry, for use cases such as entering notes. A text view cell’s height should usually be larger than a single cell to indicate its multiline functionality.
If there are additional accessories below the text view section (such as Attachments), the height of text view cell should be fixed, and a scroll bar will allow users to see the entire cell.
If the text view cell is the bottom-most section of a create view modal, the height of the cell can grow continuously downwards as the user types content into the cell.
The attachments section lets users upload items such as photos and audio files. The “+” button always remains in the first position at the top-left, with all uploaded files displayed as thumbnails after it in the order they were uploaded (with the most recent at the upper-left).
Users can tap on a thumbnail to preview the attachment; from the preview screen, they can then take the “Delete” action.
If an attachment can be previewed (e.g., a pdf or Word document), the preview should be presented using a drill-down screen. If an attachment cannot be previewed, the user should be informed and given the ability to open the item using another app.
The create view modal is usually triggered by tapping the “+” button on the nav bar, which presents the user with the option of adding a new item to the current screen.
If only a portion of the on-screen content requires the ‘add new item’ action, the add button can be placed within the relevant screen section. Tapping the add button would bring up a create view modal.
For create modals that include only text-based content areas, when the modal window appears on screen, the keyboard should appear at the same time. However, if this would cause any content areas in the modal to become hidden, the keyboard should not automatically appear, but only become present once the user taps into an editable text field.
Edit view generally looks the same as create view, with all data entry fields available in create view likewise available in edit view. However, when certain fields cannot be edited by the user, this should be clearly indicated in edit view. In this example, the Project field is unavailable for editing, and therefore lacks a chevron for drilling down.
Unlike create view, in edit view the user may have the option to perform a destructive action (such as delete) on the current object/item, and the buttons to trigger this action typically sits at the bottom of the window.
When a create view window becomes long, vertical dividers should be placed between the different input sections to make them visually distinct.
When a create view window is short, these dividers are not necessary.
In compact view, create view is always displayed as a full screen modal.
In regular view, create view is displayed as an in-place popover when there is no list of options under the “+” action button in the nav bar. (This usually happens in a list report or in a work list in compact view.) When there are multiple options triggered by tapping the “+” action button, or when the create button is a line item on the screen, the form sheet modal should instead be used.
Further details can be found in Modals.