Buttons on Forms

High-Level Recommendations

  • Align submit buttons to the left (Save, Cancel) on full page forms and to the right (Cancel, Save) on modals.

  • Buttons within forms should be placed immediately to the right of or below the item that they affect.

  • Disable submit buttons until all required form inputs have been satisfied.

Buttons are the primary means for invoking actions within forms. They may be placed at the bottom of a form, as in the case of submit buttons or inline with other form content.

Submit Buttons

Submit buttons are placed at the bottom of the page to optimize top to bottom flow. There should always be two buttons, a primary action button that will commit changes made by the user and a Cancel button that will abort those changes. By default, the primary action will be labeled Save unless there is use case specific naming that makes more sense. The Cancel button should always discard any changes and return the user to their prior state before opening this form (i.e., close the modal window or navigation back to the parent page.) See the PatternFly Terminology and Wording Guidelines for more guidance on button labeling.

Full Page Forms

For full page forms, submit buttons should be left aligned at the bottom of the page. Left align buttons with the left edge of the input fields with the primary action on the left.

Buttons on Forms

  1. Submit buttons are left aligned with input fields on a full page form.

On modal forms, the button are right aligned with the primary action as the right most button.

Buttons on Modal

  1. Primary submit button aligned with the right edge of input fields on a modal form.

Inline Actions

Buttons may also be used for inline actions within a form. In these cases, the button should be placed to the right of or below the item that they affect.

Buttons within Form

  1. Inline action button placed to the right of the field that it affects.

Enabling and Disabling Actions

  • For short forms (e.g. wizards or similar forms), the submit buttons should be disabled until all conditions required for completing a form are met. This will reduce the need to return validation errors because the user neglected to complete the form. However, in cases of long scrolling-page forms, we recommend against disabling the submit button as the missing field and the button may not be visible on the screen at the same time. When using disabled buttons, it should always be possible for the user to enable the button by inputting information onto the current page. For more guidance on handling form validation see Errors and Validation.
  • When a form is submitted, the submit button should be disabled to avoid duplicate submission. Also, feedback message and progress indicators (spinner or progress bars) should be used if the time to process the form submit action would exceed users’ expectations. For more information about progress indicators, see: spinner and/or progress.

Disable Submit Button

Styling Commonly Used Buttons

Close Button: Use “Close” to exit the current view. Close should not be used when the view is editable as its meaning may not be clear. In these cases Save and Cancel are recommended. Style Close as a secondary button.

Delete Button: “Delete” should be a secondary button unless you have a use case where the Delete action is a highly destructive action. In that case, use the destructive button style. Ideally, a delete button would be followed up with a confirmation modal for the user to confirm this action.

Cancel Button: “Cancel” should be styled as a secondary button unless you have a limited use case where the Cancel action is a highly destructive action. In that case, use the destructive button.

Save Button: “Save” should be styled as the primary button on all editable forms.

Buttons on Forms

Styling

  • Button language should be clear without the use of an icon. This will support accessibility and remove a dependency on creating an icon for every button.
  • Buttons should be of equal height. Varying button height can be distracting to the user and give inadvertent importance of one button over another. Do not combine differing sizes within the same row.
  • Three sizes of buttons are offered.
    1. Default.
    2. Large.
    3. Extra Small.

Button Sizing

Color

  • There are four different button colors with specific meanings:
    1. Primary Button: The primary button is blue, and should be used for the primary call to action on a page/modal. If present, there should only be one primary button (as each page should only have a single, clear call to action), and it should be triggered when the user hits the ENTER key.
    2. Secondary Button: Secondary buttons are gray. These will be the majority of the buttons used in an application. Any button that exists on a page that isn’t a primary call to action should use this color.
    3. Destructive Button: The destructive button is red. This color should be reserved for highly destructive actions only. Most simple “Delete” or “Cancel” functions are not highly destructive. Evaluation should be done to agree that a button meets the highly destructive criteria. One example of a highly destructive action would be allowing the user to delete all hosts that a system is dependent on to run.

Button Colors

State

  • There are a few state changes that each of the buttons could take on:
    1. Active State: Buttons will appear pressed when active.
    2. Disabled State: Buttons that could become enabled, but are currently not available will be disabled.