Justin Tadlock
Unlike routine testing rounds for the FSE Outreach Program, Anne McCarthy threw a bit of a twist on the Make WordPress Test blog earlier today. The announcement asks users to think about what they would like to see when switching between block themes. The test is open to anyone who wants to participate through September 29.
The steps are loose and not required. The goal is to get people thinking and discussing what the theme-switching flow will look like over time. McCarthy asked several questions, but they are merely a starting point for a more open-ended discussion.
While I sometimes need structure, I tend to break the rules anyway. The format of this test suited me well today.
I am not one for switching themes. Since I learned how to design for WordPress well over a decade ago, I have never moved from one theme to the next. At least not in the same way that the average user would. Instead, every time I have added a new coat of paint on my websites, I have simply switched over the foundation to whatever I had been working on at the given moment. WordPress themes, for me, were always just an iteration upon the last project.
One of the cornerstones of programming is to reuse your code, and it is a principle that I have taken to heart. Even now, as I continue to explore block theme design, I am doing so from a gutted version of the last WordPress theme I built.
When I think about switching themes, it is not an experience that I am accustomed to. Even when I started working for WP Tavern, the site already used one of my themes with some customizations. It feels like I have missed out. Throughout my entire journey with WordPress since version 1.5, in which the platform first introduced themes, I have never truly experienced the theme-switching process in the most fundamental way. I will soon, but we will talk about that on another day.
When I have “switched” themes, I have done so in test environments for writing about them or running tech support for end-users.
The call for exploration mainly focused on global design-related features. However, in my experience, these tend to matter far less than what a user’s content will look like. The first thing I do when testing any theme is to load a demo post. Lately, this has been the “Welcome to the Gutenberg Editor” test post. The primary question: Can I read the content comfortably? If I do not get past this stage, I simply deactivate the theme.
For this experiment, I chose three themes:
I started with that foundation of testing how easy it was to read a simple blog post.
Overall, each theme performed admirably. However, Quadrat’s use of the featured image on a single post view felt out of place.
One question that keeps me up at night is how cross-theme compatibility will work on the content level. Default block output should translate from one theme to the next with little or no issues. However, custom block styles, font sizes, colors, and the full range of presets are already a problem area.
This is not a new conversation. There is an ongoing discussion on standardizing some features. But the cat is already out of the bag and running loose through the house.
Global styles and templates are features that themers have been dealing with for years in some form or another. The new systems are just different ways of doing the same thing.
However, when design elements merge with content, switching themes becomes more complex without an underlying, standardized system. To illustrate this point, I checked all three of my test themes against a post that used custom block styles, gradient colors, and font sizes. I wanted to push the boundaries beyond a simple blog post.
The content was built with my custom theme and an “open canvas” template. Quadrat had a similar template for hiding the post title, but TT1 Blocks did not.
The result was, ahem, rough:
Of course, my custom theme looks as it should. This is not to say that TT1 Blocks and Quadrat are poorly designed. They are actually two of the best block themes available at the moment. The problem is that they do not share the same block styles and presets. WordPress and Gutenberg are also missing some fundamental layout tools that could make it easier to carry this design from one theme to the next.
The most complex piece of the design is with the opening Cover block pattern:
Technically, this is a Cover block within another. The bottom layer has a background image with a duotone filter and sets the inner content to 90% width of its parent. The second layer has a theme-defined gradient background and sets its inside container to the left at 50% width. Plus, it has a sprinkling of custom font sizes.
These layout controls are only possible through custom block styles or some hacky uses of the Columns block. I chose the former because it was easier, but it also means they are broken when used with any other theme.
While I called this the most complex piece of the design, it is actually a simple thing to do with most page builders or with a few lines of CSS. Until WordPress has some type of grid container block, theme authors will rely on custom techniques to make such layouts possible. It can and will get even uglier than this the longer we wait.
The open discussions on standardizing presets like font sizes and color names may bear fruit that could help with the more trivial parts. However, I have not seen gradient names pop up in this discussion.
I do have at least one ulterior motive for this test. I have long wanted to try more experimental post designs and layouts here at WP Tavern. However, I know that we will eventually switch themes. That voice in the back of my mind always reminds me that those custom-designed post layouts will likely break when that day comes. The tools are not advanced enough for me to take the plunge. Not yet anyway.
At this point, I am sure that I am no longer following the intended direction of the call for exploration. However, I am just letting the journey take me where I am meant to go. My destination is an addition to my wish list: more robust layout tools that work from theme to theme.
While I sometimes need structure, I tend to break the rules anyway. The format of this test suited me well today.
😀 Love that there was finally an initiative with the program that gave you ample room to roam and to take advantage of that ability of yours. I dig how you approached this comparing across a few themes rather than just one switch. I didn’t want to ask for too much in the test but it’s a great way to wrap your head around the current state of things, including important topics like this:
One question that keeps me up at night is how cross-theme compatibility will work on the content level. Default block output should translate from one theme to the next with little or no issues. However, custom block styles, font sizes, colors, and the full range of presets are already a problem area.
This too is a great call out:
While I called this the most complex piece of the design, it is actually a simple thing to do with most page builders or with a few lines of CSS.
I’m going to follow up on this latter point to see if I might need to open an issue or if this is being thought about in a larger overview issue:
However, I have not seen gradient names pop up in this discussion.
If you don’t mind, I have a few questions I can’t help but ask:
– Does being able to take different parts of different themes to create what you want feel enticing to you?
– What prevented you from switching themes previously? Curious about this in general, especially in light of folks eventually hopefully switching to block themes in time.
– Are there any tools outside of WordPress that you use that create a delightful experience when switching between something comparable to themes?
No pressure to respond but had to ask 🙂
Just running through these off the top of my head:
– Does being able to take different parts of different themes to create what you want feel enticing to you?
What might be interesting to me is pulling patterns from specific themes into others. When I think about patterns, though, I’m particularly interested in the layout of the blocks more so than the stylistic pieces. Those are easy to change. The more that we can have this sort of shared layout experience from theme to theme, the more mixing and matching we can do.
It could also be awesome to pull a color palette and drop it into an existing theme. Sort of like having a Colour Lovers directory to pick color schemes from but keep all the other bits. This could be fun for people who can recognize a palette that they like but would never be able to handpick all those colors. I’ve often seen color schemes that I’d love to use from other themes but didn’t like other things about them.
– What prevented you from switching themes previously? Curious about this in general, especially in light of folks eventually hopefully switching to block themes in time.
Mostly just like to build my own thing.
– Are there any tools outside of WordPress that you use that create a delightful experience when switching between something comparable to themes?
Probably the closest things might be “skins” for various applications. For example, it is simple to load up a new color scheme for my text/code editor without changing anything else. That experience feels more like changing a WP admin color scheme than the front-end of a site.
Outside of that, I can’t think of anything.
The open discussions on standardizing presets like font sizes and color names may bear fruit that could help with the more trivial parts. However, I have not seen gradient names pop up in this discussion.
Of course as soon as I hit “Post Comment”, I remember this issue referenced by Rich in both posts you linked:
https://github.com/WordPress/gutenberg/issues/29568
To me, gradients are well covered in this issue! Hopefully you agree but, if not, would love to hear more and open an issue if needed.
They did come up in that issue, which I can see now that I’m re-reading it. However, I do not see what I might call “deep discussion” (for lack of a better phrase) specifically about them. Colors and font-sizes are lower hanging fruit, so it makes sense that most of the discussion centers on them. Plus, building a gradient CSS class and slug system is hard.
Tailwind probably has the best class-based gradient solution I’ve seen (background image + color stop classes). I’m not sure if that’s a direction we could or even should go. Even if we did, we would need standardized color slugs first.
Even the solution I’m currently using in my custom theme is something I’m unhappy with.
I don’t think a separate issue is warranted yet. What comes out of that ticket may be just what we need or the starting point for the next step.
“While I called this the most complex piece of the design, it is actually a simple thing to do with most page builders or with a few lines of CSS.”
Has anyone ever given a good explanation for why Gutenberg didn’t offer the option to adjust most CSS values of a box like other page editors and instead often opted for custom solutions to adjusments? At least as an option? I mean, it’s basically what editor plus does (which you celebrated a lot) within the constraints of Gutenberg, and that was, I think, largely a one man show, compared to the team developing Gutenberg. So doing it the way it was done cannot have been due to the amount of work required, it should have/must have been a design choice (albeit one I can’t see a clear rationale for).
Somehow this keeps feeling a little in-between, like the Admin interface experiments between 2.3 and 2.7. To me, Gutenberg still feels 2.5ish from a user as well as developer point of view.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable