Revisiting Button Placement in PatternFly 4

Hey everyone,

I spoke with @mcoker about taking a look at how buttons are placed in PatternFly and I feel that there may be some space continue our discussion in the forum.

Since PatternFly currently is in the transition of introducing the button alignment in the modal, now may be a good time to revisit some of the initial findings and possibly open up an alternative to the original approach.

I want to reference the great work done by the VMware team in their Clarity Design system. They recognize that there are two primary ways people read webpages: The Z Pattern and F Pattern. We can go into further detail for each pattern in this thread, but I find it very clever that VMware recommends using both a left-aligned and right-aligned button placement, depending on which reading pattern is being used.

In the blog post related to PatternFly’s decision to always left-align buttons, I found the cited sources to be insufficient at communicating the justification behind the break in conventions. Universally updating the button placement puts a strain on other design patterns where an alternative button placement may actually work better. The primary action does not always need to be the first thing the user sees; it can actually create additional visual fixations when a user is moving through a lengthy workflow and increase cognitive load.

If additional studies and discussions are needed to validate this, I would be happy to set up discussions to coordinate them.

I am curious of other designers’ thoughts on this as well. Based on what you have seen in other design systems and in other applications you use everyday, your feedback and input to this discussion is crucial. I look forward to continuing this conversation!

Modal dialogs are read in a Z pattern which is why right aligned action buttons make sense for that context.

It seems unlikely to me that a technical solution to the DOM a11y ordering issue couldn’t be hashed out without breaking an intelligible visual ordering. No doubt the DOM ordering issue must be addressed.

Only anecdata here but we’ve had to override the button ordering in our app as it demoed poorly with the new default modal ordering.