This is ThemeShaper, a WordPress-powered blog which helps for shaping WordPress Themes and home to the Automattic Theme Division. We shape beautiful and customizable themes that make the world a better place.
Last week, Allan Cole and I shared a new Gutenberg-powered theme called Music. In this follow up post, I’m going to take you through the design process for the theme. At its core, this felt a lot like a typical theme design process, but I did learn a lot about block-based design along the way.
When Allan and I decided to make this theme, we already had a homepage comp featuring a handful of blocks. That comp did a great job of setting the tone for the design aesthetic. To get things going, I decided to apply that aesthetic to the other default Gutenberg blocks. I worked through the Gutenberg Blocks Sketch document from my last post, updating styles as I went.
Working this way was great for a couple reasons. First, it helped me focus — I’d never designed a block-optimized theme before, and this kept my design explorations squarely on the blocks themselves. I thought, “Gutenberg is all about blocks, right? I’ll design some blocks.”
Second, the Sketch file allowed me to see every single block style in one place. In effect, I was creating a sort of pattern library as I went. I thought this was pretty cool, and figured it’d come in handy later on when we began development.
As I got further through these block designs, I realized the need to see all of these individual blocks in context; I’d design a wide-width cover image block, but I had no idea how it’d look in use. So I began dragging blocks around and stacking them up to get a sense of how they’d feel together.
This helped a little bit, but still wasn’t enough. At this point, I realized something that should’ve been obvious: blocks are not a theme. They’re just part of a theme. By designing blocks first, I’d been avoiding the big picture. Users will never see blocks all by themselves — they’ll exist within full pages. I needed to design more pages.
My initial homepage design comp introduced a rough idea of a header and an off-centered text column. I began by duplicating that initial page and clearing out all the blocks on it, then pulled together some sample content. Looking at the project through the lens of my imagined client (the band Superserious), I was able to think through examples of blocks and block combinations that might exist on a real site: the columns block to display album information, the table block to display tour dates. This felt much more effective than randomly placing blocks on a page.
Around this time, I hit my stride, design-wise. I’d lay out a page using my existing blocks and the sample content. Then I’d iterate and experiment with everything on that page. Once things looked right, I’d migrate any new block tweaks back to the global symbols and start fresh on the next page. After a little while, I ended up with a solid set of sample pages.
Backing up and thinking about page design helped me shift focus to other, more traditional components that needed to be designed too: archive pages, page footers, post headers, etc. Designing these wasn’t all that different than it would’ve been without Gutenberg. In a way, we’ve all been designing with blocks all along — we just hadn’t called them blocks. Take a look at this entry summary:
If I’d designed this theme pre-Gutenberg, I still would’ve designed each one of those pieces — they’re all fairly standard parts of a theme. But thanks to Gutenberg, each piece is part of a clear pattern library, to be reused throughout the design by me and by the user. That’s pretty cool.
I’d gone into this project thinking I’d spend most of my time styling individual blocks, but I ended up splitting my time pretty evenly between designing block variations and overall page elements. In that sense, this wasn’t as drastically different from a traditional theme design as I’d anticipated.
I’d been getting ongoing feedback from Allan throughout the process above, but once we were happy with the page designs above, we gathered with the rest of the Theme team to get broader design feedback. To help with that process, I pulled all my comps together into a prototype. This took just a few minutes to do, and really helped others get a sense of how the theme will work in practice.
I created two separate prototypes with Invision: one for desktop and one for mobile. If my transition from block design to full-page design was about looking at the bigger picture, these prototypes stepped back still further: they showed us the context around that big picture. We were all able to see the designs on-device and test some basic interactions.
The team’s feedback was (as usual) very helpful — we made some subtle revisions to text contrast, adjusted a number of margins, and kicked off a lot of iteration on the mobile menu treatment.
Allan had been focused on the build from the beginning, and had the majority of the framework in place at this point. After our design feedback session, I jumped into the code too.
From the development angle, we’d already determined a few things in the design that we..
A couple months ago, I created a Sketch document to assist with the design of block-driven themes. I posted about that here on Themeshaper, and provided a couple short examples of how it could be used in a theme design workflow.
Since then, Allan Cole and I have been working to make one of those examples — a site for an imagined band named Superserious — into a working example of a Gutenberg-powered WordPress theme. We named the theme “Music.”
Allan and I set out to experiment, learn, and create a resource for the community. We’ve documented our experience designing and building this theme, and will be publishing our notes in a series of posts here on Themeshaper.
To kick things off, we’re releasing Music on GitHub today. We’d love for you to give it a spin, tinker with it, and explore how it works with Gutenberg. Here are a few things to look out for:
Our design goal for the theme has been to show that it’s possible (and encouraged!) to make a Gutenberg theme that doesn’t necessarily look like Gutenberg. We wanted to create something bold and a little experimental; a theme with somewhat aggressive, non-standard styles.
Gutenberg gives users unprecedented control over their site design, opening the door for variety and experimentation. Our favorite example of this is our cover image blocks. They look great out of the gate, but users can adjust the image, alignment, and color to achieve a wide range of looks:
You’ll be happy to hear that the overall theme development process wasn’t all that different with Gutenberg. Common patterns like headers, footers, and loops work just as you’d expect in a Gutenberg-powered theme.
In many areas, Gutenberg makes things easier for both users and developers. For instance, full-width header images used to require a custom-built customizer or theme option solution, but now they’re essentially built in. This was important to keep in mind while building the theme, and was a very positive change for development.
Creating stylesheets for blocks was pretty straightforward. Expanding on the built-in stylesheets in _s, we added a blocks.scss file to the SASS directory and placed all of our block-specific styles and overrides there. This kept everything nice and organized and is likely to appear in _s in the future.
Since Gutenberg is output by the_content(), we learned to take special care with any wrapper divs that might clip or obstruct the expected behavior of Gutenberg blocks. We’ll talk more about that in a follow up post.
We’re truly excited about the custom editor styles that ship with Music. These styles are a breakthrough: they give users a much clearer sense of what their visitors will see on the front end.
Best of all (for theme developers at least), the editor styles were a breeze to integrate! We built all of these in over the course of just a few hours.
Like most of the work we do, the Music theme is open source. You can find it on GitHub:
In many ways, designing and building this theme was similar to the way we’ve made themes in the past — but we did carve out a few new practices along the way. Allan and I will be sharing them with you in upcoming posts. In the meantime, we encourage you to download, install, and experiment with Music yourself!
I sat with a potential WordPress themer, who wanted to know how to get started the right way with theme development. He’s a user experience professional by day, looking to up his coding skills.
He pointed to the WordPress editor, and said something like, “I understand HTML and CSS, but I’m not sure how to make something beyond putting it in there.”
We’ve all been there. Having that vision of what you want your site to look like, and not knowing how to get there. Gutenberg promises the vision you have takes shape in the editor, instead of some PHP file or a special plugin that isn’t truly native to WordPress. That’s powerful! It shifts much of the customization control from the themer to the person using the theme.
Today, if you’re trying to get into WordPress development, you might start by tweaking an existing theme. Then making a child theme. Then diving into a custom theme. My user-experience professional friend did just that. He’s already customized a theme and made a child theme. But the whole world of specialized WordPress theme knowledge can intimidate even professional web workers. Imagine how it feels to new users of WordPress who have never built a website before?
But with Gutenberg, people – professionals and beginners alike – can begin building what they want. Now, Gutenberg will no doubt need its own specialized knowledge. But at its heart, it will transform what a theme means to WordPress. They can become more about pure design, powered by the simplicity of CSS.
You might be saying, “But you can already use CSS now to change a theme’s design.” That’s true, but much of a theme’s structure gets determined by and locked away in template files. Hard to change unless you start learning how to “theme.” But with much of that structure and markup becoming blocks that can be added to a theme, it becomes easier for people who aren’t themers to see different possibilities.
Say goodbye to lots of custom widgets and theme options. Oh, and to limiting page templates. The future of WordPress themes can become more about empowering users to work on their vision instead of always having to learn how to “theme.” It starts in the editor and not with the theme.
On WordPress.com, one thing we’ve been focusing on is making themes that just work. It’s a bit of a balancing act; it’s very tempting to allow customers to control every aspect of their theme, because it seems like the simplest way to give them what they want.
That idea may sound great to customers, but having panels of options in the Customizer and an armload of documentation to figure them out is daunting. You can change things, but you’re also faced with making dozens of small, similar decisions about various aspects of your site, and deciphering the purpose of various controls.
It is true that in WordPress themes, some options are necessary. When designing and building a theme, it’s important to distinguish what options fit the actual intent of the design, and what options are being added for the sake of adding them.
You can often figure out which is which by tracking common pain points.
One way to do this is through support requests. On WordPress.com, we have a dedicated, talented team of Happiness Engineers who interact with customers every day. As Gary Murray wrote in a recent post, support teams are an important link between our work and our customers, and an invaluable wealth of information.
For themes, the support requests often involve how to set up a theme or use different options (which is why making themes that just work from the get-go is important). But other requests have to do with customizing a theme in specific ways. Some are unique to a customer’s specific goals; others come up again and again from different customers, either in the same theme or across several different themes.
In the Ixion theme, we recently added an option to control the opacity of the overlay used on front page photos, after several customers asked about changing or removing it.
Ixion with its two new options.
One purpose of the dark overlay is to ensure the text on top is legible against the photo. But if you’re starting with a photo that’s already pretty dark, the overlay isn’t needed and can make it hard to distinguish details in the photo. We were able to add this option while maintaining the original appearance, so customers who weren’t troubled by the opacity didn’t know the change happened.
Another feature that came from frequent customer requests was Content Options. A brainchild of Thomas Guillot, Content Options are a way for customers to make small visual changes on their site, like hiding the date, author name, or featured images. Rather than adding the options to individual themes, it’s a feature available in Jetpack and WordPress.com that themes can support. That way, the options are available in several themes and implemented exactly the same way.
Both additions were guided by the goal of keeping things simple, balanced with following actual customer requests.
When looking at adding options to a theme, there are a few things that can help to keep things simpler:
First, aim to make a theme that just works on activation. If the design’s not possible without multiple options, rethink it. If options are necessary to get the theme to work well with different kinds of content, find a way to make the theme more forgiving instead. Make the theme do as much work as it can by itself.
In a similar vein, make the theme make the decision. You could allow customers to switch a sidebar position, or make the header sticky, but unless it’s a very common request it’s best left out. Chances are, one option looks best and makes the most sense for the theme you’re building — use that one.
Use existing WordPress functionality rather than custom options. I don’t mean stretch the options beyond their original intent, just don’t reinvent the wheel. For example, look to use the custom header image or featured images in the theme before adding another image upload option to the Customizer.
When adding options, rethink your approach to customization. Alright, you’ve discovered your customers can’t live without being able to change their header’s layout. Rather than having separate controls to move each individual item — logo, header image, menu, social links, site title — is there another way to approach this? Aim for simpler, more opinionated controls to limit the decisions customers have to make. Basically, make your options smart.