,

A native and iterative approach to responsive control in WordPress

How our design looks on mobile devices is hugely important. For that reason, we need to talk about responsive design controls in WordPress and whether or not we need them.

One of the most powerful features of WordPress block themes is the ability to create a design system that shapes the aesthetic of your theme. This design system, powered by settings in the theme’s theme.json file, dictates the design language of blocks, patterns, templates, and how all of these elements interact with each other.

On top of that, users can customize these styles to make sweeping changes to their site within the WordPress UI. Contrary to classic WordPress themes, block themes aim to be a no-code (or very close to it) experience, empowering the user to design, build, customize, and launch their website with native controls.

This shift towards a no-code experience means that WordPress has to find creative ways of handling complex problems without overwhelming the user (many of whom are still having a tepid transition into the block era). Along the way, the WordPress UI has been growing and evolving to meet the many demands of building modern websites.

Great control, great responsibility

Now that users are diving deeper into block themes, one of the first hurdles they’re seeing is the lack of responsive controls in the WordPress UI. It’s a totally realistic expectation — virtually every other website builder has granular controls for adjusting styles for tablet and mobile views.

Now, lacking a core standard, many WordPress block solutions have started implementing their own responsive controls. Naturally, users are wondering when these controls are coming to WordPress core for a more uniform experience.

The response from WordPress core decision-makers has been varied. Some say it’s too complex to implement into the UI, some say it’s aspirational, some say fluid, or “intrinsic design” (more on that in a minute) should be enough and when you need anything more, just add CSS.

However, for creators, agencies, and freelancers who are still deciding whether or not to fully buy into the block theme paradigm, this response doesn’t really inspire confidence. For many, stopping short at responsive control feels contrary to the promise of a no-code theming future.

This sentiment totally resonates with me. I’ve spent the last year deeply embedded in block themes, learning everything I can and creating a WordPress theme that brings all of these powerful new features together. And in my experience, we’re like 90% there. That’s how good block themes are right now!

But there’s so much potential left in that last 10%, and today I’d like to dig into how we can get closer to 100%.

The future is flexible

If you’ve been following the conversations around WordPress block themes, you’ve probably seen the term “intrinsic design” being used in different contexts. Although not a particularly new concept, it’s important to do a quick refresher as it will help inform how we think about block themes.

As coined in 2018 by Jen Simmons in her talk “Everything You Know About Web Design Just Changed“, intrinsic design is an evolution of how we approach responsive design as we know it.

  • Contracting & Expanding – the way we consider how our design will adapt to a change in available space
  • Flexibility – using primarily Flexbox and Grid in combination with newer units and functions in a way that enables our layouts to adapt at various rates to the available space
  • Viewport – the ability to use all four sides of the viewport as well as take advantage of viewport units

Traditionally, we’ve thought of responsive design as how a design changes at certain viewport sizes (i.e. at 768px, I want the columns to collapse down to one column).

With this model, we’re essentially saying the content should transform to fit into arbitrary constraints, instead of letting the content decide when it should shift into a more appropriate layout based on its context. And with the thousands of device screen sizes to account for, aiming for breakpoints is largely a futile exercise.

Conversely, with powerful features like CSS Grid, Flexbox, container queries, clamp, min(), max(), and fit-content, we can design smarter layouts that adjust to the context in which they exist. We can and should break free from breakpoints, and start thinking of our entire design from a fluid-first approach. This is the foundation of intrinsic design.

How we’re doing so far

Realizing all of the benefits of intrinsic design will be a big effort, and will require widespread adoption of new building standards, but we’re off to a pretty good start!

Realistically, we’re in more of a fluid design phase than an intrinsic phase. (Maybe the distinction doesn’t matter?) With fluid typography, margin, padding, and spacing with CSS clamp(), we can achieve fluid and graceful scaling of common content elements, while also providing common-sense UI controls to the user. This is part of the promise of intrinsic design.

However, in order to reach that level of epic intrinsic web design, WordPress will have to lean even further into a large-scale CSS Grid and Flexbox implementation that is able to abstract away much of the complexity of grid-based layout building. On top of that, there will have to be a sustained educational effort to help theme builders start thinking and building with these principles in mind. It’s a whole vibe.

A fluid-first approach

While we work towards that bright future of native intrinsic web design, we still have a responsibility to the reality of WordPress site building today. We still have scores of veteran and novice users wondering about responsive design controls, and whether we can compete with other modern site building solutions.

In the short term, we can and should promote the adoption of fluid design as the go-to way of building block themes. By sharing fluid styles across typography, margin, padding, and block spacing, your design system can handle most of your responsive needs while keeping a beautifully-cohesive design intact across your whole site.

But, even with a comprehensive fluid design system like I’ve built into Ollie, you’re still going to have circumstances where you need to make fine-tuned adjustments (just ask anyone with a roster of clients), and media queries still have a utility here. We’re just not at that point where we can simply brush them off.

In the short term, we can and should promote the adoption of fluid design as the go-to way of building block themes

So, what do we do about that last 10%? How do we approach responsive control without being inundated with responsive controls? Can we do better than telling folks to use custom CSS? I think so, and I have a few ideas!

Exploring native responsive controls

Over the past few weeks, I’ve been contemplating how we might implement common sense responsive controls to address the gaps that fluid design can introduce.

When thinking about adding anything to WordPress, it should always be considered with a great deal of restraint. Big features are difficult to get approval on and costly to implement, so we have to keep our approach super simple, intuitive, and use as much of the current offerings as possible.

With that in mind, here are some baseline requirements that I approached this proof of concept with.

  • Responsive styles should only be needed as an exception
  • Responsive settings should only be shown in context
  • Responsive settings should be limited to specific style settings

Only show controls in context

For starters, we have to avoid cluttering the WordPress UI at all costs. Adding persistent responsive controls that only some users need sometimes is not the right approach.

Instead, we should only show these controls in contexts where they are most needed. For this, we can tap into the Tablet and Mobile view already built into the WordPress editor.

Right now, this view just functions as a simple preview of your content at various viewports defined by WordPress. What if we took this view a little further? What if you could not only view your styles in this responsive context, but you could also contextually modify them here?

Introducing style overrides

Next, we need a mechanism for adjusting styles in this responsive view. Let’s just reuse the same UI we already have, but change its context.

In this proposal, a new menu item appears on select style settings when you are in the editor’s responsive view. Clicking Enable Style Override would turn the respective style into an override that would take precedent at that viewport size.

In this example, changing the padding slider would only affect screens below 780px (or whatever breakpoint is defined in the theme). Ideally, we default to the tablet and mobile breakpoints defined by WordPress, but allow these to be customized via theme.json.

Other than an indicator that a style override is active, we don’t really have to modify the native settings UI any further. The override can be enabled and disabled just like any other style setting via the kebab menu.

For some inline education, we could utilize the guide modal the first time the user interacts with the feature. This would be a good opportunity to set some realistic expectations and encourage the user to consider their fluid design system before adding style overrides.

All together, the flow for style overrides could look something like this. In this demo, we’ll add a style override for padding on tablet, and then remove it before returning to the desktop view.

Scaling down the scope

Returning to the idea of restraint, we have to decide what block style settings should receive a style override setting. To start, we can safely scope this down to only support settings panels that supports fluid styling, such as Typography and Dimensions (margin, padding, and block spacing).

There’s also a good case to be made about the Columns block, which currently tries to handle responsive stacking automatically. In fact, the Columns block is usually the first block where users realize the lack of responsive controls.

Iterative and intentional

What I like about this concept is that it’s iterative and intentional. It breaks away from superfluous use of breakpoint styles, and doesn’t inundate the user with new UI. Instead, style overrides are responsibly tucked away in a context where they makes sense, providing restraint to a feature that could otherwise could balloon in scope.

Wrapping up

So, what do you think of this concept? Surely, I haven’t covered every circumstance here, so I’d love to hear your thoughts. If anything, maybe this is a good fire starter to a bigger conversation.

Would a native iterative approach like this be a good place to start? What kind of needs do you have for responsive styles within your work? And have you maxed out the capabilities of your theme’s fluid design system via theme.json before considering the need for responsive controls?

This is a big conversation, so let’s hear some diverse commentary! Feel free to comment below, or start a conversation with me on Twitter.

10 responses to “A native and iterative approach to responsive control in WordPress”

  1. Marius Avatar
    Marius

    Thanks for the great article and insights!

    The *Block Enhancements* plugin already uses native responsive controls and it’s great for text alignment.

  2. Ren Avatar
    Ren

    Great idea! It’s something I do with CSS for now but having convenient UI controls for this is better.

    I wish the side panels in the editor would be larger or slide out for less menu diving, maybe even mobile first.

    I always liked the mobile first approach when doing sites with Tailwind CSS. Why isn’t it a thing in WP?

  3. Carsten Bach Avatar

    I love your idea and hope you have already filed a PR!

    What I really enjoyed is the fact, that it works progressively within the current UI, without – like you said – the need for new bloat. Great.

  4. Marcio Avatar

    Hi Mike,

    Responsive design is such a foundational topic in the field. I just don’t understand how it wasn’t sorted out right from the beginning.

    The question of cluttering the UI is a real one, though, and your suggestions are a good compromise between the need for responsive controls and minimizing friction while using the editor, which is increasingly becoming an issue.

    Regarding the viewport selection: wouldn’t it be preferable to activate the override option right after selecting the desired viewport? I understand that if a user made the effort to select it, it is mainly because they are checking to see if the layout is working as intended and, if that’s not the case, to correct it.

    Probably this would require some user testing, but considering that this is true, activating the override automatically would save some mouse travel and a click, which is always good UX, right?

    Anyways, thanks a lot for publishing these articles, they’re always thoughtful

  5. Sally G. Avatar
    Sally G.

    This looks good to me! Easy to understand and use.

  6. Trevor R Avatar
    Trevor R

    Fascinating article and I like your thinking on this solution for light touch responsive style overrides. I’m really inspired to up my game to use intrinsic design as my starting point.

    Right now because I’m doing traditional responsive design, to get around the lacks of responsive controls in core blocks I use GenerateBlocks Pro. It too use the core “Preview” functionality for changing styles at different viewport sizes, so that’s handy. While it works nicely and gives you much of the power you need, it can get really confusing for clients (and myself as a dev sometimes) really quickly. I often wish I’d just used CSS and some custom classes. 🙂

    So that’s why I love the idea of intrinsic design to simplify things. Then if you could have this core functionality you outlined that would be perfect for just those minor tweaks when you have to make things “just right” with some small changes.

  7. Michel Avatar
    Michel

    Great reflexion, thank you very much to bring to the discussion the strong importance of the responsive/intrinsic fine tune settings.

    We saw on WordPress.org so many Gutenberg layout courses always done on the desktop side but NEVER on the tablet/mobile side. This is a very big problem because now majority of people look at web sites on their mobile. “Mobile first” says the motto.

    Personaly I have some additional interrogations:
    – what about responsive menu features? This is a big part of the missing features right now.
    – how to manage the reordering display of blocks?
    – when you have Flexbox (and soon CSS grids) is the column block still need to exist?
    -conditional display is also a part of the needs

    And finaly when you deal with responsive (intrinsic) settings, it can become rapidly a daughting task to manage a remember all the granular changes. So it would be be to have a central place showing all the change done. (could be within Appearance>Editor at the same level of “Styles”)

  8. Lars Ejaas Avatar

    Would it make sense to wait a bit and let the block styling be handled by container-queries (we need full browser support)?
    It would be super to have every blocks styling adapted to its own size and not the size of the viewport. Would make the design process a lot more intuitive…

    1. Mike McAlister Avatar

      I love container queries, but I’m not sure if that’s part of the roadmap for core. That would require a slightly different approach than what we have now. Not impossible though!

      That said, there are always going to be circumstances where an element just doesn’t sit right or the context calls for it to be modified. That’s just the nature of web design/dev where we want to push boundaries and clients have specific requests.

  9. Pierre Tilston Avatar
    Pierre Tilston

    I hope responsive design controls won’t be considered as only ‘fine tuning’.

    Sometimes something appears on mobile in a way that completely destroys the intent of the content creator.

    For example, if the creator puts two book cover images side by side because they want them to appear like thumb buttons among the other content.
    Then on mobile the low res image takes over the whole screen. The user has no idea why they are suddenly looking at a giant low res image. It’s a total WTF moment for the user.

    No developer can ever predict the *intent* of a creator.

    In addition, a huge value of FSE is in being able to ‘fix’ odd behaviours in a theme. So relying on the developers to get it all right is not ok. All too often it will leave the creator just stuck.

Leave a Reply

Your email address will not be published. Required fields are marked *