Posted by & filed under PatternFly.

After careful research and consideration, the latest version of PatternFly is introducing a new standard for buttons, recommending left-alignment for button groups in forms, with primary buttons always appearing as the first button in the button group. This approach is being applied across components like form, wizard, and modal, and the updates will be rolled out to the community in the coming weeks.

A form embedded in a page, showing that the form submit buttons are left-aligned with the form, with the primary action first.
Form embedded in a page
A form in a modal, showing that the form submit buttons are left-aligned in the modal footer with the primary action first.
Form in a modal
A form in a wizard, showing that the form submit buttons are left-aligned in the modal footer with the primary action labelled "Next" first.
Form as a wizard

Members of the PatternFly community have questioned this decision for a few different reasons, but most commonly it’s because this alignment isn’t the convention users are most familiar with. So, why is PatternFly challenging designers and developers to move away from a familiar standard? Very simply, it’s not compatible with universal design, and it doesn’t align with our PatternFly principles.

The PatternFly principles ensure that, even as we evolve, we’re always staying true to the original goals we set out for the design system.

By following the principles of modularity, accessibility, and responsive design, we made several key decisions:

  • To maintain consistency, the order and position of form submit buttons shouldn’t change based on context. Alignment should be the same whether we present a form on a page, a form in a modal, or a form in a wizard.
  • To prioritize the user’s primary task, the primary action button should be presented first.
    • This approach reinforces a natural, conversational style where affirmative choices are generally presented first.
    • Accessibility standards require that actions be presented visually to users in the same order they are defined in the DOM. As a result of responsive design, interfaces can be laid out differently depending on screen size, meaning actions could be displayed to users horizontally or vertically. If the first action in a vertical stack of actions should be the primary action, then the first action in a row of actions should also be the primary action.
    • An observation made by a low vision student who participated in a UX design and research workshop confirmed that it would be beneficial to have primary actions presented first. [1]
  • To make it easier for users to complete a form, submit buttons should be presented in the same scan line as the form inputs.
    • This approach benefits users displaying the webpage in full screen mode on a large monitor. Based on previous feedback, we realized a large spatial gap between form content, like input fields, and buttons caused users to miss critical parts of their workflow.
    • This approach also benefits low vision users who use screen magnification devices to view the contents of a web page and rely on related information, like form inputs and form submit buttons, being in close proximity. The straw test is a great way to test the accessibility of a layout for these users.
    • Finally, this approach is consistent with a finding provided by Luke Wroblewski in his book Web Form Design. [2]

If you’re interested in learning more about how the PatternFly principles helped guide this decision, we go into further detail in the following sections.

Modularity and flexibility

Modular design systems enable you to take very isolated interaction patterns and combine them to build complex designs that can support different user tasks. Modularity helps ensure consistency, since isolated patterns shouldn’t change much between different contexts. With this in mind, we felt it critical for PatternFly that form submit buttons remain consistent in order and position as they are moved between various contexts.

When deciding on button placement, we considered every possible context: forms on pages, in wizards, in small modals, in large modals, forms with a single input, forms with numerous inputs. Because considering all possible scenarios—and not just your basic use case—is important when creating a design system.

After reviewing every possible variation, one approach—to align form submit buttons to the left with the primary action appearing first— emerged as the pattern that could be successfully applied to any context with consistency and without concern of creating any pain points for users.

Button placement remains consistent whether a form is placed in a page or a modal.
Button placement remains consistent whether a form is placed in a page or a modal.

Accessibility

Accessibility adds a new level of challenges and forces you to consider all the possible ways that a user can experience a web page. Are users sighted? Are they using magnification? Is the page full screen on a huge monitor, or on a screen the size of a phone? Are they using a keyboard to interact with the form? Are they using a screen reader?

When you start to consider all the ways that a user can interact with a web page, you realize that small things like alignment, proximity, and order can have a huge impact on their experience. Using spatial concepts to reinforce the progression of a workflow aren’t applicable to all users, specifically low vision, no vision, and also mobile users. Low vision users benefit from having the form submit buttons in the same scan line as the form fields. No vision users benefit from having the order of form submit buttons be consistent across any context. As designers, we should be willing to recognize that the spatial concepts we applied in the past to the placement and order of buttons were optimized to the needs of sighted users with good vision. Sometimes being inclusive means letting go of the standards we have been following for so long when we realize they no longer satisfy the needs of all users.

Left aligning the primary action facilitates scanning and ensures that it will come first in the tab order for keyboard users.
Left aligning the primary action facilitates scanning and ensures that it will come first in the tab order for keyboard users.

Responsive design

Standards that exist for desktop applications aren’t always applicable to the design of web applications. Designers of desktop applications have a lot control over the presentation and layout of UI elements, whereas users of web applications access the interface on a variety of devices and screens. Web designers have to consider every possible viewport size. This means the order of elements have to be considered sequentially, where the most important elements come first and least important elements come last. This way, when elements need to be stacked vertically, the most important things are encountered first. This also means that when elements are presented in a row, the most important items (e.g. the Next button) should be presented on the left.

Left aligning the primary action will ensure that it comes first whether buttons are inline or stacked.
Left aligning the primary action will ensure that it comes first whether buttons are inline or stacked.

We hope the research and rationale outlined in this post helps shine some light on the updated approach we’re taking to button alignment on forms. As always, we welcome and encourage feedback from the community. For additional questions or concerns, feel free to reach out to us on the PatternFly forum.


Footnotes

  1. Presenting the primary task first was something noted by one of the low vision students in a user research workshop we had with students at Governor Morehead School in Raleigh. When presented with a card that stated “Previous & Next Page” she stated, “Next should be first because it’s the action I most likely want.”
  2. Luke Wroblewski makes the following statements in his book Web Form Design:
    • In chapter 3, Path to Completion, he provides two examples and states: “One has a clear scan line that starts at the first information point, ends at the primary action, and allows people to take in all the information they need to review quickly. The other has a number of different visual treatments that break up the path to completion into a series of zigzagging eye movements. A single path makes it easier to process the questions a form is asking through a consistent layout.”
    • In chapter 6, Actions, when talking about the style and placement of form submit buttons, he states: “According to the data we collected, the most effective designs of the six we tested all shared a common characteristic: they presented their Submit and Cancel options left-aligned with the input fields and labels above them.”

8 Responses to “Button placement on forms”

  1. Should we apply this same reasoning when considering how pagination should be laid out? As that student noted, going to the next page is “the action I most likely want”. Switching pagination controls around seems like pretty radical idea. While it makes some logical sense to do so, that logic ignores a deeply engrained idea that (at least for native readers of English) time flows from left to right. The past is to the left; the future is to the right. This left to right bias is not universal, (apparently Arabic readers have the opposite bias), but it accepted as a standard in UIs (viz. pagination).

    I think one could make the case that buttons in wizards are navigation. They are how users move from one step to the next (not unlike pagination). This new button order puts the idea that “the thing I most likely want should be first” in conflict with the idea that “the next page is to the right”. I’d be very curious to know how the rearranged wizard buttons perform with users, and understand which which bias is stronger for them.

    Reply
  2. Well researched and well written! In light of these findings, how would you recommend handling Back/Next scenarios? e.g. When a user can go back to a previous step or continue to the next one, there is arguably some value in spatial placement (Back on the left, Forward on the right). Does primary action placement consistency still apply?

    Reply
      • I read through your recommendations summarized in this GitHub issue and was pleased to see that you guys came to much the same conclusion. This was a difficult decision for us that involved weighing long standard conventions against the needs to optimize of reuse and accessibility. Wizards do present the biggest challenge, but I think as you are noting, contrast is perhaps more important than placement in driving rapid visual recognition.

        Reply
  3. Thanks for reading the post and sharing your comments and questions! I agree, there are certainly parallels between the actions in a wizard component and the actions in a pagination component. But I would not suggest applying what I suggest in this post to other patterns, like Pagination. What makes these components different is much more significant than similar text strings and similar conceptual models of flipping between pages.

    In the case of Pagination, the user is browsing through contents. The user may or may not consume contents using pagination.

    In the case of the wizard, the user is completing a task. When a user is completing a task, it’s important to have guardrails that highlight the path to completion, like making primary actions look prominent and easy to access. Sure, other actions exist, in case the user needs to take an alternate path, but they should be less prominent to make the most common path easy to follow.

    As I mention in the post, I’m suggesting we abandon the conceptual model where “the next page is to the right” and you get to it by going to the right for the Wizard component. I skimmed through Luke Wroblewski’s book on whether he had any findings on wizards. I didn’t see anything that tested specifically the actions in wizards, but he does make a really interesting point when talking about primary vs secondary actions:

    “Perhaps the most common example involves multiple page form wizards where people can move forward and backward through Web pages. Though it may be tempting to treat Previous and Next as equal actions in these circumstances, keeping people moving forward with a primary Continue action and a secondary Back action is likely to be more productive. After all, we want people to complete these forms, right?”

    With regard to user bias, it is important to consider, but I don’t rank that as high as user performance or accessibility. I would only consider user bias or preference between two options when the options are equal in user performance and accessibility.

    Reply
    • I agree with you that a wizard is about completing a task. Perhaps changing how we label the buttons could help clarify this distinction between task and navigation. What about “Continue” and “Go back” as opposed to “Next” and “Back”? “Continue” is, in fact, an action/verb while “Next” is not. Interesting to note that in that Luke W quote you cite he mentions “Continue” as a primary action.

      Reply
      • +1 I had a similar thought when I was reading that quote that I shared. :-) You also make a great point that “Continue” is a better fit because it’s more of an action/verb than “Next”. I definitely think that approach is something worth considering for this.

        Reply
  4. I think that the challenge is that the long-established conventions were based on how information is perceived by sighted users. What swayed the argument for me was the consideration of sight-impaired users’ needs. As for the wizard, this left to right idea is just a construction based on the horizontal arrangement of steps in most wizards. I could argue that we’ve already broken that by arranging out steps from top to bottom, and not left to right. This all may be initially surprising to sighted users, but my opinion is that they will adapt.

    Reply

Leave a Reply

(will not be published)