The essence of a WordPress theme is: layout (templates) + style = presentation.
The template and global style editing features of the site editor are soon going to provide users with tools to create and manage these elements visually in their WordPress back-end. Community initiatives like the pattern directory present opportunities to enrich these features exponentially.
So the question emerges: If I have the power to tailor the individual components that make up a “theme”, supplemented by curated suggestions from the community while doing so, then what purpose does a single bundle of predefined layouts and styles serve?
I imagine a world where the idea of themes being discrete entities that you install and switch between goes away. Instead, the “default theme” in WordPress is nothing more than a generic version of the templates and styles necessary for the most basic site to operate.
On top of this, flows exist in the UI that enable users to perform bespoke activities, like creating a different layout for a specific post category archive.
In such a flow the user would be presented with contextual layout options that are pulled in directly from the pattern directory. Oh, you want to create a new 404 template? Here are dozens of neat options to choose from, ordered by popularity, rating, you name it. This feels much more powerful than having to accept whatever your theme supplies – especially as it’s unlikely that you chose your theme because of it’s 404 template!
Styles can work in a similar way. Imagine selecting an appealing color palette from a community driven library, directly in the Styles panel of the Editor, and having that cascade across your entire site. Ditto for typography. These tools can all combine in flexible ways to get you 90% of the way toward your desired design destination.
Naturally you can fine tune everything on a per-block basis as required, and even choose to contribute your creations back to the color, type, or layout directories, further enriching those libraries.
On that note, maybe new economies begin to emerge – imagine paying a small tip to install a comprehensive type scheme devised by some A-list design studio. An App Store for style?
No doubt it would still be possible to export your templates and color / type styles as a single theme bundle. But in a world where folks have freedom of expression on a much more granular level, I wonder about the utility of such a package.
When you’re able to easily apply different aspects of design to a single post, a single template, a site header, or even a single block, the concept of a “theme” starts to feel much less monolithic. I’m excited to watch these features interact as they grow and evolve.
Design Tools and their associated UI are an exciting development both in terms of the power and flexibility they will afford users, but also how they will replace chaos with consistency in the block editor UX.
I think the design does a really good job of tidying complex features / interfaces away until the user actually needs them. Not all blocks need padding, but it should be easy to add it as desired. The overall experience feels much less cluttered.
This got me thinking about one of the most complex block we have – the base Query Loop. Could we use this same design pattern to make an intuitive UI for query building? I couldn’t resist putting a quick prototype together…
The idea here is simple, when you insert a Query Loop it will display everything from a single post type (multiple post types doesn’t make much sense to me). You then add and combine filters using the familiar Design Tools UI until you’re satisfied with the output. I think this does a good job of avoiding the currently overwhelming experience when interacting with the vast multitude of options this block offers.
This pattern could not only be used to toggle filters on the Query block… maybe it’s also possible to toggle panels like Typography, Dimensions, and Border on all blocks.
With the advent of the site editor and all of its associated blocks – not to mention the burgeoning catalog of core blocks – the Inserter is starting to feel a little disorganised.
We have block categories for “Theme” and “Design” which feel conceptually at-odds with one another (in case you’re wondering “Theme” blocks are mostly template blocks like Post Title but also include unrelated things like Query variations. The “Design” category has unfortunately become a bit of a dumping ground that contains a number of unrelated blocks like Site Title, Post Tags, Columns, and Buttons).
The “Widgets” category is where block-based versions of legacy widgets live. Since “widgets” is a paradigm that will phase out over time (widgets are really just blocks like any other) this category doesn’t make much sense except as an interim. Especially as the blocks themselves can be quite varied, E.G: Search, Posts List, Shortcode, RSS.
Finally there is a large “Embeds” category which is where blocks that enable you to display third party media live.
Card sorting
The first thing I wanted to do in this exploration was identify which blocks belong only in the post editor, those which belong only in the template editor, and those which are truly global. Once I’d identified this I was able to begin thinking about potential categories within those contexts.
To do this I embarked on a card sorting exercise in FigJam:
Here’s a summary of my observations and organisational changes:
A surprising number of blocks were consolidated in to several categories within the template editing context.
There are way more template-only blocks than post-only blocks.
Embeds and Media have essentially been combined.
Several widgets moved to an “Internal links” category. I’m not sure what the best name for this is, but most of these blocks focussed on linking to other areas of the site e.g. tag clouds, category links, recent comments, etc.
The “Design” category was split into more contextual compartments; “Layout”, “Internal post navigation” (more link, page break), and Feeds.
A number of sections could potentially be de-emphasised in the UI. All the meat exists in Text, Media, and Layout.
Design Prototype
Although I only added one category overall (in the post editing context) one thing that struck me was how broad the block library really is. And this is just when you observe core blocks, an established site may have many more blocks installed via plugins and the block directory.
This got me wondering whether presenting a wall-of-blocks in the Inserter is really the best approach, or whether it might be better to encourage searching, and only list frequently used blocks for quick insertion.
“Frequently used” blocks are front-and-center
A quick design mockup piqued my interest. I figured we could allow folks to customise how many “Frequently used” blocks to display, and provide access to each of the block categories using the same drilldown pattern as the latest Global Styles designs.
Drilling in to a category gives the blocks within room to breathe
My hope is that this would make the Inserter less overwhelming, and feel more intuitive to use for common tasks.
To try this idea out I made a CodePen prototype and quickly noticed that the drilldown pattern could even be used to expose patterns relating to specific blocks upon insertion.
There’s still some work to be done here. For example I’m not sure how the tabs might interact with this design… the “Reusable” tab feels like it could just be a category within the inserter. And if we’re exposing contextual patterns upon insertion, maybe that tab is superfluous as well?
Where the heck should the Buttons block live?
Scalability is also top of mind, do these categories provide a framework that block authors can intuitively plug into without having to create their own sections?
Finally I need to mockup a version of this for the template editor, which will include a significantly larger catalog of blocks. Maybe the sky falls down in that context.
These are all explorations for another day. For now, feel free to mess around with the prototype here, and as always, do not look at the code 🙂
Until now, most explorations around navigation in the site editor have been a bottom-up endeavor. We’ve identified and designed solutions such as the mosaic view of templates and the drilldown navigation sidebar to connect disparate screens. But connecting these solutions and integrating them with the menus that already exist in wp-admin has been quite a design challenge.
In this post I’m in the clouds exploring this problem with a top-down perspective, and sharing some concepts that can theoretically serve us not only in the short term, but also the long term as we seek to elegantly deprecate wp-admin (😱) entirely.
It goes without saying that the chrome in these visuals is rough.
A single entry point
Currently the site editor is accessed through a menu item in the wp-admin navigation:
I am increasingly of the opinion that this is a sensible route on which to continue because it not only provides a designated area for experimentation in the site editor, but also avoids unnecessary interference with the broader wp-admin navigation structure, and consequently disrupting any existing user flows.
As an added benefit, when the site editor has 1:1 feature parity with wp-admin, then phasing out the wp-admin interface altogether becomes technically trivial (not accounting for plugins – one step at a time).
Up until now, most of the work done in the site editor has been focussed on template editing. This is a technical pre-requisite to more exciting enhancements simply due to the way that WordPress renders content. But now that we have most of the template editing fundamentals in place, perhaps it’s time to shift focus?
I’d like to concentrate on a more content-centric site editing experience. At the moment, when folks open the site editor we present whichever template is used to render the homepage. This can be confusing if you’re not familiar with the mechanics of WordPress’ template system (and let’s face it, the average user is not). It’s all too easy to conflate templates with content, and that’s before we even consider more nuanced features like template parts.
Content and Appearance overviews
Instead of dropping users directly in to a single template editing view, it might be better to display overview screens that can serve as navigational dashboards – not too dissimilar from what you’d find on a smartphone home screen.
Such screens could create intuitive compartments in which to present novel features that have a lot of perceived conceptual overlap, such as reusable blocks, template parts, and block patterns.
Here’s a (very) rough outline of what such a content management overview / home screen / dashboard might look like:
Opening the Site Editor reveals a dedicated content management home screen
From this screen users are able to quickly access any recently-touched content in a single click. Shortcuts also also exist to draft new content, or to access environments in which you’re able perform less common tasks like bulk editing and trash management.
This view could be customisable in a number of ways:
A scale slider could change the thumbnail size
The number of items in each content row could be personalised, and the rows themselves re-ordered to suit
Or perhaps even toggled row-by-row, based on user role or preference
Content overview on mobile
As blocks enable authors to compose richer content layouts, a visual navigation experience like this increases in value and usability.
The video below demonstrates the three primary views a user would see as they open the site editor and drill down into editing a single item of content.
The three pillars of content management: Overview, Edit, Bulk manage
Appearance overview
While I believe the site editing experience should ultimately be content-centric for the majority of users, tasks relating to general appearance (like editing a template) still play a very important role.
In order to help clarify the lines that exist between content and template editing (something that is not always obvious), a dedicated appearance overview could be utilised. This screen would re-use components from the content overview to present entities that relate strictly to appearance, IE the active theme, templates, template parts, and perhaps block patterns too.
Once these views are implemented in the Site Editor, we’d have the flexibility to consider removing their wp-admin counterparts to drive adoption, if that was desirable.
Navigating between overview screens
If these overview screens serve as compartments for contextually relevant functionality, there must be a way to navigate between them. Perhaps the (W) button in the editor could provide access to such navigation.
In the video below I navigate from editing a page, to the appearance overview, then the content overview, and finally back in to the original page.
You’ll notice the navigation panel also includes links to manage things like settings and users. This illustrates of how we might eventually migrate all site management tasks to the site editor, and create an opportunity to sunset the entire wp-admin interface over time.
This is where exciting possibilities present themselves, for example allowing users to configure exactly what screen they see when they log in:
Log in to content overview
Log in to edit home page
Then I get carried away with other ideas like custom overviews for things like analytics. Or even apps like WooCommerce Admin that deliver their own suite of overview screens.
If there’s one thing I’ve learned during the last year or so working on WordPress core it’s this: it is very difficult for fast-moving open source community projects that live almost entirely on code-centric platforms to be led by design.
I kind of knew this from when I was more focussed on WooCommerce. But the difference with WordPress is that we do not own the project, so it’s not possible to make decisions unilaterally – the community must be involved every step along the way.
Workflows mostly revolve around reported issues on github, so solutions are reactive, and tend to be narrowly focussed and technically motivated. This feels like an inevitable progression because reviewing and benchmarking code is generally easier than judging design. It is clear whether a code submission is an enhancement or not, so the community is able to find consensus relatively quickly. Design is less binary, and more subjective. (This is a little hyperbolic, but hopefully you get the point).
My colleague David Levin has a funny metaphor for describing how it feels to work in this environment as a designer:
“Sometimes it feels like you’re trying to design the plane while it’s already in flight”.
As someone who often finds himself drawn to macro UX design, I like to find solutions that can be applied canonically to several related issues… basically the DRY principle applied to design. Consequently, I will end up sharing the same principle across multiple siloed conversations, which can be exhausting.
But without that exhausting repetition we risk implementing different UI patterns that all accomplish roughly the same thing, to the detriment of the overall end user experience. Not to mention the bloat added to the design system.
Continuing the plane metaphor – an aircraft with jets on one wing and propellors on the other may still fly, but it won’t as easy to pilot as an all-jet or all-prop configuration.
To the annoyance of Shaun Andrews who coined the term, our team affectionately refers to this challenge of high-level thinking and low-level acting as “clouds and mud”. It sounds cliché, but it summarises the mental exercises designers working in this space have to do.
Innovate in the clouds
“If I had asked people what they wanted, they would have said faster horses.”
The alleged Henry Ford quote is extreme, but there is a grain of wisdom there, I think. It can be difficult to truly innovate when the status quo is reactive, microscopic problem solving. It’s all too easy to get distracted by the worms and the weeds.
Perhaps we can entertain something between these two extremes? A “first principles thinking” process whereby related issues are grouped and examined together in order to explore holistic design solutions for the root problem, thereby solving the group through extrapolation.
Stepping even further back perhaps new features should not be built at all, until there is consensus around a documented design vision? These visions should be explored in the clouds, where we have a bigger field of view and more freedom of movement and expression.
Reflecting on the last year, this has been the biggest challenge for me. This week I begin a three month Sabbatical and I hope that time out of the trenches will enable me to find some actionable ideas around topic.
