The Design Team provides user experience, user interface, and visual design expertise for the WordPress project.
Want to get involved?
Welcome! This all-volunteer team needs designers of various kinds. See our handbook and drop into #design once signed up for volunteer opportunities.
Our vision is to be the go-to resource for design for other teams across the WordPress open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project.
A few weeks ago, we introduced the new Openverse identity as the beginning of a redesign journey, where we placed the search engine within the WordPress ecosystem. Since then, we have been working on a new interface that consolidates the new brand and puts consistency with WordPress at the forefront.
You may have heard about Openverse during State of the Word 2021, which is perfect timing to dive into what’s coming next for Openverse.
Audio. The new content type
The goal of Openverse is to catalog all openly-licensed content, not just images. To start this journey, we decided to include audio results as a new content type that many creators use for various purposes. This integration demanded designing an interactive audio player component with multiple variants and accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) as a primary concern. Even when Openverse spans a simple flow, the audio browsing experience is completely different from searching for an image.
We wanted to keep the interface as clean as possible, but the vibrance of the brand colors also excited us. For this reason, we used our brand yellow for the active, ‘playing’ state. Its boldness really shines when interacting with the component.
At the same time, we wanted to highlight the artwork that creators added to their audio, whether album artwork, a podcast logo, or an image taken during a field recording, for example. For audio tracks without artwork, we plan to design a default image that uses the spectral data of the audio file to add randomness.
We will post about that in the following weeks.
A gallery for all content
Audio and images were mentioned as relevant content types by our users during the interviews we ran. For that reason, we explored the idea of having a gallery showing all content results to exhibit the strength and flexibility of Openverse. There aren’t many search engines, to our knowledge, that integrate results from different media types, and we’re excited by future possibilities like multimedia user collections.
Imagine a biology teacher making a collection of images of crows; audio files of crow calls; and 3D models of the skeletal structure of a crow’s wing!
The resulting gallery challenged us to make a simple yet interactive page to preview audio and dig into the content details.
Browsing results without leaving
Since time ago, we have been hesitant about the idea of seeing the content details as a modal. The page view provides a straightforward navigation and interaction experience when opening the source site and copying the attribution info. However, it felt as leaving the search results page and splitting the browsing experience into separated moments.
The new modal looks clean, and the main content is even more predominant. On images, the showcase space is modest, whereas audio fills the modal width to allow a seamless experience. The result details are clustered in sections, and the vertical lecture is flexible to varying heights.
Next steps
I would love to dive into other changes like the new headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., the symbol animation when loading content, and all the accessibility challenges when designing the audio states. But for now, this snap summarizes the essence of the new Openverse.
We are looking forward to putting this redesign online and seeing what people come with. This step, after the brand work, is a solid one towards a future where Openverse offers a space for creators to use openly-licensed content.
In the meantime, see the Releases file for the audio integration mockups and the Design Library for the components used.
It’s about that time again: time to start creating the About page for WordPress 5.9.
I took a first pass on the About page using some preliminary copy that’s loosely based on the script for the recent Introducing WordPress 5.9 video. Here’s a link to this draft as a Google doc — all are welcome to view, edit, or comment there directly!
In addition to the page content, I’ve also mocked up a couple of different visual directions for the headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. artwork.
Direction 1 is inspired by jazz album covers and classic movie posters (particularly by this movie poster design by Saul Bass):
The next steps from a design POV would be to create new header artwork in whichever style we choose for the other section pages (Credits, Freedoms, and Privacy). I’d also like to look into how the chosen look & feel could potentially be utilized for the Dashboard page to help create visual consistency between the two sections.
The featured content is still TBD but hopefully this first draft can help get the conversation going! Design feedback is very much welcome at this stage — please comment on the Trac ticket with your thoughts and ideas. 🙂
The sibling inserter, the plus button, the quick inserter button, the in-between add button; Whatever you call it, this button often gets in the way. Do we need still need it? Lets chat about it.
This months discussion will focus on the [ + ] button that appears throughout the WordPress blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. There are many names for it: the sibling inserter, the plus button, the quick inserter button, the in-between add button, and more. Last year I wrote a GitHub issue that describes some of the confusion around this button, and much of it is still relevant. I’d like to focus our discussion around:
Validating the problems outlined in the GitHubGitHubGitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue.
Reviewing some of the suggested solutions.
Updating the issue with a way forward.
We’ll also have time for anyone to share their work or ask questions to the design team. Just drop a comment below, or show up and raise your hand. I hope to see you on Zoom tomorrow.
Recent Happenings
There’s so much design work happening every day across SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., TracTracTrac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/., GitHub and more. For good measure, here’s a few highlights from the past few weeks…
A series of animatics shown when first visiting the site editor in WordPress 5.9.
A new “Explore” button in the block inserter sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. opens a large modal to browse block patterns.
This post presents an analysis that Channing Ritter and I have made of the Cover and Image blocks and offers some ideas to improve the user workflow and streamline some of the basic operations, like cropping, image placements, and rotation.
We’ll also offer an idea to integrate Fill modes into Cover blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. settings. The designs, prototypes, and an analysis of the current functionalities are available on this Figma file.
Our intention with this exploration is twofold. We’d like to:
Simplify the way Image and Cover blocks work.
Offer image editing functionalities so that users don’t need to resort to outside tools.
Before we present our designs, let’s see some of the current problems with the cropping tool.
The first one we encounter when using this tool appears right after the user clicks the crop icon. We go from this toolbar:
To this one:
We think this change is quite disorienting because the toolbar gets reorganized, adding new icons and removing the cropping and link icons in a very abrupt way. We’ll show a possible solution to this problem in a minute.
But there are some other problems with the cropping functionality. Let’s see a video of the cropping tool in action:
As you can see in the previous video:
It’s impossible to revert a change made inside the cropping mode. Clicking “apply” inside this mode essentially creates a new image and replaces the original one. This means that every time users make a change and go back to the cropping mode, they can only edit the new cropped image.
The rotation option is limited to just 90º increments.
The zoom only allows zooming in, and it only goes from 100% to 300%.
In order to zoom in, the user needs to click the crop icon.
But the main problem is that the cropping mode works in a convoluted way: instead of selecting a rectangle and extracting the content inside, the cropping tool defines a viewport (using the set “Aspect ratio”) that will be used for the crop. Users can move the image inside, but this movement is restricted to one direction and limited by the outer bounding box of the block.
Once the user applies a crop to the image, the image then expands to fill up the entire space of the block using the selected aspect ratio. This is confusing since the user sometimes interacts with a small image that suddenly grows and fills the whole block.
Secondary toolbars
A solution to the problem we mentioned above about the confusing toolbar could be to use dedicated toolbars for certain groups of actions.
These new toolbars would present a title indicating that the user is now inside a different mode, the set of options for the functionality, and links to apply and discard the changes.
It could look like this:
And here’s a list of explorations we did for the placement of the elements:
Walkthroughs
We’ve created three walkthroughs that explain several aspects of our proposal:
How to integrate the cropping tool and other editing background functionalities inside the Cover block.
How different Fill Modes could work.
How could we add the cropping tool inside the Image Block.
These prototypes are self-guided, just open each of them and advance to the next slide clicking each screen. A series of notes will explain each concept.
Cover Block
A question we haven’t addressed on this exploration is what happens with the focal point functionality this block offers.
On the one hand, it could make sense to keep this feature, because it allows centering an image that is larger than its container. On the other hand, however, this block’s new background editing capabilities would make it very easy to enter inside the Edit background mode, reposition the image or crop it, and apply the changes.
Fill modes
Image Block
Thanks!
We hope you like these explorations and help us with comments and suggestions.
A while ago, myself and @kellychoffman started working on the redesign of the Gutenberg landing page on WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. The current page is slightly outdated, both its visuals and content.
Now that GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ has been a part of WordPress for a few years, it makes sense to update it, shifting the message from what used to be the new post editor to the editor that can power all parts of your site.
In these iterations, we grabbed many ideas from patterns in the Pattern Directory, ending up with an interesting collection of different blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. patterns. We kept copy and visual elements rather minimal, exploring three typographic alternatives: two sans-serif fonts, Inter and SF, and an elegant serif font, EB Garamond.
It is intentional that the page looks more like a landing page rather than an open canvas “playground” page. While it can still be interactive, allowing people to click around and explore, it shows what is possible to achieve with the editor, remaining ultimately informative.
Structurally, there are a few proposed changes:
Highlighting Blocks and Patterns separately
Adding accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) info and improvements to the “Gutenberg loves everyone” section
Adding a section for new users, linking to Learn WordPress and highlighting a few key courses
Creating a section with some more helpful content and links to dig deeper about Gutenberg
You can see proposed links highlighted in pink in this prototype.
What’s next?
This is a proposal, which means there’s space for iterating! I’d like to open this up for feedback through November 5th, at which point I’ll return to work on refining the content and details. All feedback is welcome, either here or in the Trac ticket, where previous iterations have been shared.
Last Week @kellychoffman and I shared some concepts that explored how we might introduce some of the powerful site editing features in the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
To briefly recap, the first concept brought template, style, and content editing together under a single “Editor” menu item in the Appearance section of the main navigation. The second concept kept these features separate, and leaned more on existing wp-admin views to access some of them.
In this post I am sharing a stress-test that I’ve performed on both concepts, to see how they handle complex plugins that add custom post types. For this test I used WooCommerce and focussed on it’s product post type. The aim here is to further distill each approach and hopefully find consensus around which one to pursue for 5.9.
Since styles are a feature that transcends content and template, I’ll be focussing on editing the latter. I’ll demonstrate the hypothetical flows to edit individual products, and to edit the template that is used to display those products.
For the purpose of this test we’ll assume that WooCommerce fully supports blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. templates and the block editor.
TLDR: Due to the “Separate” concept leaning more on existing wp-admin list views it will require less work to implement, and less effort for plugin developers to adopt. It will also be less disruptive to existing user flows when working with custom post types.
“Combined” concept
In this concept clicking “Editor” in the Appearance menu takes you to a view where you’re able to edit the homepage of your site. From here clicking the W menu will open the navigation where you will see a new “Products” section has been added. Clicking this takes you to a product list view inside the Editor:
Clicking a product will take you to the editor view for that product, where you are able to modify the product data, the product template, and elements like the site headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. and footer all at the same time.
Editing a product
To then go and edit the product template on its own, you once again open the W menu, navigate to templates and find the two new templates that WooCommerce added: “Single Product” and “Product Archive”. Clicking “Single Product” takes you to a view where you’re able to edit that template.
“Separate” concept
In this concept product management is accessed in the same way it always has been – at the top level of the wp-admin navigation. Even the list view behaves the same. However, opening a product takes you to an editor view where you’re able to toggle the visibility of the entire layout in order to visually edit other product data, or even elements of the underlying template.
Of course in an example like this – where the post type in question is so visually reliant on the template – it may make sense for WooCommerce to make the layout visible as a default for product editing. Or perhaps even force it to be permanently visible by removing the option to toggle the layout visibility. This is a detail we should consider making available to plugin authors during implementation if we choose this concept.
On that note, there’s a balance to be struck around where we draw the lines between content and template editing, so we should explore contextually locking certain blocks. For example: here it should be trivial to change the featured imageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. source, but moving it around or changing the dimensions should be either one step removed, or alert the user that they are making a template-level change.
To explicitly edit the product template you exit the edit-product view and navigate to Appearance > Templates. Just like in the last concept, here you’d find the two new templates added by the WooCommerce plugin, and you are able to go and edit one by clicking on it. As in the current post editing experience, clicking the W button simply takes you back to the Template list.
Observations
The thing that stands out most to me is the duplication that occurs in the “Combined” concept. There are effectively two places for users to manage post types – either via the existing top level “Posts” and “Products” menus they’re familiar with, or via the new Editor menu. This increases the workload on plugin authors as they need to consider both potential workflows and it also places additional cognitive load on the end user since they will need to actively choose an interface each time they want to manage things like posts and products.
Any flows accessed from list views such as trashTrashTrash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days. management and bulk editing may also end up being duplicated.
All of this will be compounded when you add more plugins/post types, and given that different plugin authors would adopt these new features at different paces, the user experience could grow increasingly inconsistent.
Another consideration is the many plugins that currently extend the existing list views. With the duplication of those views in the “Combined” approach, many of those plugins would need to be updated to support both versions. APIs can probably do much of the heavy lifting here, but ultimately this would slow down adoption of these new features as it will take plugin authors time to adapt. Users may also prefer to stick to their “tried and true” methods. Those that choose to embrace the new views could find themselves in an awkward spot if the one plugin they rely on doesn’t support them yet.
The “Separate” concept addresses each of these shortfalls by simply relying on the existing post type list views in wp-admin. The flows in which users manage all post types remain the same, and whether they get a richer block-based editing experience is solely down to whether or not the plugin has chosen to adopt these new technologies. It gives us the time to concentrate on updating the list views in isolation at a later date. Due to this, I tend to lean more towards this approach as it feels like a much smaller step with arguably equal impact, but I’m keen to hear more thoughts and feedback from y’all.
What’s next
After digesting feedback we’ll hopefully agree on how to move forwards for 5.9. From there we can open a tracking issue on githubGitHubGitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ to work through the necessary outstanding issues and explore finer design details.
Our monthly show and tell takes place on Zoom tomorrow at 18:00 UTC. This monthly call is a chance for designers to share work, ask for feedback, and answer questions. All are welcome to join; A Zoom link will be shared in the #design channel on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. (Not sure how to join Slack? We have instructions available just for you!)
We’re open to anyone sharing their work, but here’s a few things we’ll likely discuss:
We are at a point in the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ development where we have many new features to help people visually create, edit, and manage their site. These include, but are not limited to:
Pages & posts: Add and edit with blocks and patterns.
Template editing: the ability to customise theme templates, and create new templates ad hoc.
Styles: change the color, fonts, and layout across your site.
Template parts: Create and edit headers, footers, and other areas.
More features continue to be added and @jameskoster and I have been iterating on how we can surface these new features in a way that is both intuitive for new users and familiar to existing users. To keep the scope focused, we looked at the features in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. today along with the ones that are being worked on to be considered for the 5.9 version of WP, according to this post while keeping the near future in mind as well.
To set some context
If you are already using the Gutenberg pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, you may be familiar with the Site Editor menu item. This is where most of these new features can be found during development. While this works for the purpose of development, “Site Editing” is a broad expression that essentially spans the entirety of site management activities in WordPress. Do we want to begin down this path towards a single page app-like experience, or would it be better to keep things separate for now? It’s time to explore and design the IA (information architecture) so that we can begin to paint a picture of how we might merge this exciting functionality in to core.
Click on Appearance and you see Editor (beta) menu item. This keeps the concept of updating your look and feel of your site within the Appearance menu item, where current users are used to going to Customize. It is also intuitive for new users and matches the iterative approach product development has taken.
From there, you are brought to the homepage of your site, where you can immediately start to edit it – whether its a static page or your latest posts. Example of the latter:
From here, if you click on the W menu in the upper left corner, it opens a menu where you would be able to access Styles and Templates. And if you have any – other template parts. This navigation menuNavigation MenuA theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. feels light right now but as more functionality gets added, this navigation could scale and grow along side it. For example, you can imagine that you’d have direct access to editing your posts and pages within here as well.
Click on Styles to update the colors, typography, and layout of your site. This also shows what a welcome guide could look like, which could be useful for big new features.
If you open the W menu again and click on Templates, you’ll view a list of all the templates you can now edit visually:
An alternative concept would be to keep template and content editing separate for now, but still bring some of the most compelling template editing functionality (like direct manipulation of headers and footers) to the post editor.
With this approach you’d edit posts and pages the way you always have, but when you open the editor there would a new option to view the full layout:
With the layout visible it becomes possible to customize the site headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., footer, and any other blocks that make up the underlying template. You would also be able to invoke the Styles panel to further refine the look and feel of your site.
Theme editing has always lived in the Appearance section of the navigation, so in this concept that is where you’d go to customise and create new templates.
Template editing can be a complex exercise, so to help narrow the scope this concept keeps content and template editing separate. So instead of being populated by actual content, blocks like Post Title and Post Content display simple placeholders to help you identify them.
Editing the theme’s Page template
In the future it would be interesting to explore options that enable users to load compatible content in to the template while editing to help with testing, but it’s not essential at this stage.
One trade-off with this approach is that in order to allow users to visually edit their home page when it is set to display latest posts, we’d need to introduce a placeholder “page” in the pages list:
This somewhat breaks the idea of keeping content and template editing separate, since visiting the latest posts “page” (and the “Posts page” for that matter) on the frontend will resolve to display the home or indextemplate. Whether this trade-off is worth making may require further technical investigation and perhaps a round of usability testing, but it’s worth noting that a similar placeholder is already utilised when you create a “Posts page” in partnership with a static home page.
Curious to hear your thoughts on these ideas and alternative proposals!
FSE Outreach Program coordinator Anne McCarthy facilitated a recent call for responses (a slight change in format from the recurring FSE calls for testing) on the topic of blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. theme switching, which officially kicked off the process of “thinking long term about what folks would want to be able to have across themes.” According to Anne’s follow up summary:
When it came to ideas for how to best manage the switching process, it quickly became clear that there’s a balance to strike between not adding too much friction to the process while also offering users options to pick and choose what can come with them when they switch.
The call for replies resulted in some imaginative descriptions of how this all could work. The responses also raise some important questions: what role should themes play in the world of block themes, especially when users may want to mix & match styles and layouts from different themes? What does switching themes mean in this context, when you might be able to use aspects from several different themes?
I used some of the responses to Anne’s post as a starting point for a blue-sky exploration around what theme switching might look like in a world of highly flexible themes that — in the true spirit of WordPress — can be hacked and cobbled together to your heart’s content.
Approach
The flows shown below stem from on an ongoing series of posts by Javier Arce and I that explore the possibility of introducing a GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/-style mosaic interface across WordPress screens — including, for example, on the Appearance/Themes page. This is a thought experiment that we are excited to share more widely — please feel free to leave comments on the blog posts or message us directly in the Making WordPress Slack!
Idea 1
Redesign the current Live Preview theme switching flow to incorporate a process similar to multi-entity saving
Entry point: Appearance/Themes
First, I explored the most literal translation of the current theme switching flow as it exists today while incorporating the top bar and other familiar Gutenberg components.
Just like the Live Preview functionality works now, we could utilize a CustomizerCustomizerTool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings.-like preview that would allow users to preview and navigate the site before activating the changes. Selections regarding which styles and layouts to activate could be made in a sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. panel, similar to the one used for multi-entity saving.
Like the current flow, the default behavior is a one-click activation that would switch styles and layouts to the new theme’s defaults (or to the user’s prior customizations of that theme’s templates, where applicable). This is based on the assumption that the majority of users will want to switch everything to the new theme’s look — but the activation panel also provides an opportunity to offer more granular selections.
We could utilize the thumbnail preview that appears within the Global Styles panel, and there could be a toggle allowing you to switch between the theme being previewed and the active theme on your site.
From there, it would be possible to drill down into more nuanced selections. For example, you might want to keep certain aspects of your active styles (e.g., just the color or typography) and have those be activated rather than the new theme’s defaults. Similar selections could be made for the layout by picking and choosing which Templates and Template parts to keep active on your site when switching.
A fun variation on this idea is to utilize a slider for comparing the before and after layouts (similar to an Image Compare block):
Idea 2
Make Theme management accessible directly from the Site Editor
Entry point: Global Styles panel
This approach utilizes a “design dashboard” focused on theme management. This idea was originally explored as part of an Appearance menu overview screen.
What if block theme switching could be integrated directly within the site editing flow? For example, a modal containing the Appearance/Themes page could be directly accessible from the Global Styles sidebar. This would allow theme switching to happen more seamlessly without ever leaving the site editor, and hopefully turn the sometimes stressful moment of theme switching into something more akin to changing settings — it’s a low effort modal to close, reopen, and keep tinkering with.
Idea 3
Reconceptualize themes to emphasize styles (with optional or de-emphasized Templates)
Entry point: Global Styles panel
The last idea takes inspiration from a super interesting alternate range of color schemes shipping with the upcoming Twenty Twenty-Two theme. What if changing themes was about swapping styles, withtemplate changes becoming something more seamlessly intertwined with existing editing flows? For example, maybe you could browse Template parts from other themes via the inserter or an in-canvas selector.
In this case, navigation between theme styles could happen directly from within the Global Styles panel. Utilizing the current Global Styles navigation pattern, perhaps you could drill down further to adjust and fine-tune after selecting a theme style.
What’s next?
While there’s a lot left unexplored in these flows, I hope these sketches can help serve as a starting point for design discussions around things we would like to see in the future of block theme switching! A great next step would be to start narrowing in on an iterative pathway towards enabling the mixing-and-matching of block themes — at the moment of the theme switch and potentially beyond.
You must be logged in to post a comment.