Forms

Forms wrap several types of inputs such as text inputs, text areas, radio buttons, checkboxes, etc.

The Constellation design system provides default form layouts of up to two columns. The types of form controls being used determine the layout. Simpler controls, such as a text input or combo-box, use the dual-column layout, whereas rich text editors, text areas, radio groups, and checkboxes use a single-column layout. Forms should not exceed more than two columns to support users with low vision. On smaller device sizes, all forms are single-column layouts.

Forms should contain a set of actions to help the user either navigate through, leave, or submit the form.

For additional best practices for designing forms in Constellation, visit Pega Academy.

A basic form is a one-column layout with labels on top. Strongly related fields are grouped together on one line. Fields are an appropriate width for the content. To optimize for speed, we recommend starting with a one-column layout.

In some cases, a one-column layout is not the best way to present the form.

Use two-column layouts when:

• There are many fields (>=6) on a single screen, and real estate is at a premium
• Specific fields have strong associations
• Speed is not a primary need

Depending on the controls being used, a two-column layout may display as a one-column layout to optimize available real estate.

Do not use a two-column layout to display one line of fields.

While three-column layouts are available for extreme edge cases within Constellation, they are not recommended for regular use. Three-column layouts are not always accessible— it may be unclear to low-vision users that a third column of fields exists within the form. To prevent users from missing fields, it is recommended to use a one or two-column layout instead.

Required fields should be shown before non-required fields. Having required fields at the beginning of the process ensures that users do not miss them. Avoid mixing a required field among many non-required fields. If a field is strongly recommended (but not "required"), it should be as near to the beginning of the form as possible. This reduces the chance of a user skipping it.

Use read-only fields alongside editable fields, when doing so gives the user context, or completes the layout for a set of fields. For example, in a set of address input fields, the “state” field may be read-only, while the “address”, “city”, and “zip code” fields may be editable.

Finally, a read-only field can indicate that a user does not have permission to edit a field either due to their role or due to conditions that prevent them from editing.

To display non-editable information that users will reference to complete a form or review to verify form details, use a field-value list instead.

When reasonable, put long and wide fields under short ones. If long and wide fields are at the top of a form, they can hide other fields by pushing them below the visible area of a webpage. When possible, put these at the end of your form.

Examples of long and wide fields include:

• Text areas
• Rich text editors
• Maps
• Any custom control taller than 60px

The actions content will be rendered at the bottom of the form. It is important to structure the buttons so that the primary action is towards the right, and any secondary actions are towards the left.

Reference Constellation content guidelines for best practices on UX writing for forms.

To learn how to configure this component in your Constellation application, visit Pega Documentation.

All components shown on this site are supported by the Constellation design system. To learn how to configure Theme Cosmos, visit Pega Documentation.

• Button

• Checkbox

• Field group

• Form progress

• Text area

• Text input