Site editing IA concepts: How to surface and access new features

Co-wrote (and designed) with @jameskoster.

We are at a point in the GutenbergGutenberg The 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 coreCore Core 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 pluginPlugin A 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.

Idea: Appearance Menu

Try the prototype out here or scroll through a description of it below:

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 Menu A 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: 

Idea: Separate

Try the prototype here or scroll through a description of it below:

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 headerHeader The 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 index template. 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!

Show and Tell Oct 2021 Agenda

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 SlackSlack Slack 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:

If you have anything you’d like to add to this list let us know in the comments, and we’ll bring it up on the call.

#meeting-agenda

Adventures in Block Theme Switching

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 blockBlock Block 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 GutenbergGutenberg The 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 CustomizerCustomizer Tool 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 sidebarSidebar A 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.

A close-up view of the upper right hand corner of a live preview screen. It shows a sidebar panel containing a toggle for switching between the preview and current theme, as well as activation options.

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

Editing "Index" template in the site editor. Image shows the Global Styles panel with options for three different theme styles. The options are a yellow, white, or black background color palette with various type styles.

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, with template 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.

#design, #site-editor, #theme-switcher

Design welcomes Shaun Andrews as team rep

Today we closed the call for new team nominations and we only had one entry.

I would like to welcome @shaunandrews as the new design team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts.. Shaun is a designer who has focused on the new editor and has been collaborating with the design team for a few years now.

He has new ideas as to how the team will work better and be more succesfull in the future. Check the blog for ideas and new workflows that we will bring to the team.

Welcome to the team @shaunandrews!

#team-rep

Call for design team rep nominations

The time has come to open up nominations for one rep as I am rotating out. This is an opportunity to bring new ideas and create a new dynamic in the design team.

I have been on this role for about a year and a half and it has been a pleasure to support the team. It is the right time for me to step aside and continue growing as a contributor to WordPress in other areas.

The past few months have been very challening for both, Ahmed and myself, with illenss in our families. And we are both thankful that we always found someone to help with our duties as team reps. This is why is very important to mantain an open communication within the team.

This is a great opportunity for an existing team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. to onboard someone and gives someone the chance to grow into this role and work alongside Ahmed. Yet, I will be around to help with the onboarding until Ahmed returns.

So, let’s get on with the exciting possibility and explain a little about the role.

What does a team rep do?

In the WordPress open sourceOpen Source Open 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, each team has one or two (or more!) representatives, abbreviated to reps. The role goes way back to 2012 and is an established one across teams. You can learn more about the team rep role here.

A little note, it’s not called team lead for a reason. This section from the updates page explains team reps well:

“Team Rep is a leadership role that is mostly administrative in nature; it is not a Lead role. Letting go of the Team Rep title is not a loss of status, just a handing off of responsibilities. Someone who is a leader in a team can lead whether they are doing the team rep job or not.”

Here are the main tasks:

  • Ensuring a meeting agenda happens along with notes. We have note-takers who are not team reps and post agendas, so this is coordination. The team rep adds agenda items to a shared document.
  • Run the weekly design team meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
  • Co-ordinate the weekly triage meetings.
  • Write a biweekly update post for make.wordpress.org/updates?
  • Give quarterly updates on the team when asked.
  • Call for new team reps when the time comes at the end of year tenure.

As a team rep, other tasks might fall to you in order to keep the team running, but in general, it’s a support and coordination role. On average the estimated time you would need for this role would be a few hours a week. With another team rep though, that time is shared.

This role is open to contributors of any level, not just full-time contributors. Like many good open-source processes, this work is done openly and can be shared. Also, because WordPress is a globally-minded project, if the team rep that is selected can’t make the current time, we can always discuss changing the meeting time.

The process

Taking inspiration from teams that have done this before the suggested process would be:

  • A call for nominations in the comments on this post. Self-nominations are welcome. These will close in on September 22nd.
  • After the closing date, another post will highlight those nominated votes will be made on those nominations for a week. Currently, there is one team rep role available and the incoming rep will be working with Ahmed (and Estela in his absence.)
  • The votes will be tallied, the chosen team rep asked to confirm they want to do this process and then announced during the Show and Tell at the end of the month.
  • If there is only one nomination, we will skip the the voting week and still announce the new team rep during Show & Tell.

If you want to nominate someone in private, please reach out to me  (@estelaris or @chaion07) on Slack.

Disclaimer: if you get nominated, please don’t feel like you have to say yes! We will add to the polls only the names of the people that are responding positively to a nomination. So feel free to reply with a “Thank you, but no thank you”.

#team-rep

Document Status and Visibility

If you’ve ever used WordPress to create a blog post, web page, or any other type of document, then you are likely familiar with the Inspector SidebarSidebar A 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.. The sidebar shows you information and controls related to the either the selected blockBlock Block 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., or the document itself.

The sidebar hasn’t changed very much over the years, and in many ways still resembles the pre-GutenbergGutenberg The 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/ (Classic) WordPress editor. Here’s a side-by-side of the sidebar in the classic and block editors:

Over on GithubGitHub GitHub 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/, there’s an overview of design updates to the sidebar. The designs focus on block controls, specifically typography, color, and dimensions. The issue does propose a component system of controls for things like inputs, dropdowns, and sliders, but doesn’t explore how this system could apply to the document controls shown above.

Since we’re talking about sidebar controls, I think it’s helpful to also include the design of the so-called “Global Styles” project outlined on Github. This design uses a multi-level, nested interface to group controls into Color, Typography, and Layout sections.

With all this in mind, I’ve been looking at the document sidebar and how it could be improved. For this first pass, I’m focused on the “Status & visibility” and “Permalink” sections. Here’s a look at the current design alongside my proposed changes:

There’s quite a few changes. The first, and maybe most obvious is the lack of an accordion interface containing all the controls. Instead, controls are shown and hidden using the ellipses menu; Open the menu and you can choose what controls are hidden or shown. This reduces the overall footprint of the controls, but also allows people to customize the sidebar to their specific needs.

This menu is also a convenient place to find features and functions like viewing the document’s history, renaming the document, reverting publish documents to draft, and moving the document to trashTrash Trash 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..

At the top of the section is the current document’s title. Here’s how that could look with a few different titles.

The title itself could also be interactive, and allow for renaming the document directly from the sidebar. This is helpful as the editor’s canvas may not always include the document title. You could initiate renaming from the ellipses menu, or double-click on the title itself.

Each control within the list would be clickable, opening a popover with more information and controls to change the value.

Here’s how each control’s popover would look:

There’s a lot more to do with the remainder of the document controls, like improving categories, tags, and the featured imageFeatured image A 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. controls. But for now, I think this is a good start and can hopefully lead towards improvements across the rest of the document sidebar.

Republished from my personal site.

#design, #document-sidebar, #status-and-visibility

Initial Patterns for the Patterns Directory: Launched!

As reported over on the Meta blog, the 85 patterns the community designed for launch with the Pattern Directory are now live! 🎉

A few examples of our new community-designed blockBlock Block 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.

Thank you to everyone who submitted, refined, and helped launch this set. I’m thrilled that users have such a broad set of high-quality patterns to choose from at launch, and I look forward to iterating and growing the collection over time. 

Now that we’re post-launch, we’re going to close submission of general patterns to this initial collection. The next phase of development for the directory will allow anyone to submit their own patterns directly, so please hold onto your ideas for then!

In the meantime, the design team may add a few more patterns from time to time (similar to how default patterns were occasionally added to GutenbergGutenberg The 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/ before). You can keep an eye on the Pattern Directory’s GitHub repository for any activity there. Also, if you notice a bug with one of the existing WordPress.orgWordPress.org The 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/ patterns, please file an issue and let folks know! 

Thanks again to the contributors who made these patterns happen: @anariel-design, @beafialho, @bgardner, @cavalierlife, @chrislema, @circlecube, @critterverse, @greenshady, @jameskoster, @jcasabona, @karmatosed, @kellychoffman, @kjellr, @laxmariappan, @mahvash-fatima, @melchoyce, @richtabor, @schutzsmith, @tajim, @webmandesign, @wetah

Redesign of WordPress.org/News

Jazz should be recognised as music of the people, based in a lot of accents and melodies. What is jazz but music that people danced to? Jazz has the dynamic thing.

Al Jarreau

The blog page of WordPress.orgWordPress.org The 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/ has stayed the same for a very long time and it could benefit from a careful rethinking and visual attention to detail. There are things we can do to improve the reader’s experience, to make it less visually constrained, and introduce an improved design language. After a request from Matt Mullenweg, I’ve spent some time thinking through a possible redesign, and I’d like to share some directional ideas below.

Making It Jazzy

Some of WordPress’s visual materials have been influenced by jazz aesthetics, which immediately translated into a clear visual direction. Although subtly, I’d like to express the playfulness of jazz, as in the album artworks you can see above.

Imagery in the blog is often sparse, so I explored elements such as stroke shapes, typography, layout and colors, to achieve a timeless result.

Leaving Space for Content

The current layout and typographic styles lack space. Opening up the canvas, rethinking spacings, placements and line heights could make it feel less boxed and improve readability.

I have also explored variations between categories, while maintaining coherence within the same section of the website, taking content in consideration and playing with it.

Rethinking Typefaces

Open Sans is widely used in the current site, and while there’s nothing wrong with it, its quirkiness wasn’t propelling improvement or helping readability, so I suggest we replace it with Inter, an open sourceOpen Source Open 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. font, which I’m using for paragraphs and functional text. It works well for screens and reading and it has a timeless feel that fits universally with any type of content it’s used with.

EB Garamond, equally open source, is used in headings, bringing elegance and delicacy to the blog.

Continuously Iterating

Certain pieces are still in progress of refinement, such as the blog’s “home” page, text styles and the balance in the usage of paint strokes (some of the ones used here aren’t as polished). Colors are still being iterated on, but the vibrant blue seems to associate well with the evolving GutenbergGutenberg The 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/ language.

Higher Level Concept

I’ve also spent some time thinking about simplifying the nav bar and footer for the site, which ultimately contribute to its visual consistency. Beyond that, I have found potential in the concept of recreating different “languages” of jazz throughout the site, in a way that’s coherent and balanced enough that isn’t confusing or misleading for people.

A huge thank you to @pablohoneyhoney for the continuous help and guidance in these iterations. I’m very happy to share bits of this work in progress, which is all available in this Figma link, and will try to post updates as regularly as possible.

I hope you’re as excited as I am about this, and I can’t wait to know what you think in comments below!

Editorial postscript – The design above is early, but has already gone through multiple iterations. As with so many open source things, all feedback is welcome and anything that can be changed will be. 🙂 ~josepha

Widgets in WordPress 5.8 and Beyond

WordPress 5.8 (released last week 🎉) brings the power of GutenbergGutenberg The 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/ blocks to widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas — which means highly customizable layout and styling options, and a more WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. editing experience. I made a test site based on oldie-but-goodie Twenty Sixteen theme, which has 3 separate widget areas to work with. In this post, I’ll highlight a few cool things that are now possible to do with your widgets, and a take a look at where things may be heading next.

Zoomed-out view of a single post with one sidebar widget area and two footer widget areas. The site content is about Marine Park Salt Marsh. There are is a “List view” of blocks floating next to each widget area showing how the design is constructed.

Create interesting visual effects with overlapping layouts and Duotone images

Appearance-wise, users have a lot more control over widgets areas than ever before — especially through the use of blocks with tons of customization options like the Cover and Image blockBlock Block 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.. Here’s what I’m able to create in the classic widgets editor (above) versus what I’m able to create in the new block-based widget editor (below).

Intersperse widgets and custom code throughout your visual designs

Container blocks like Cover and Columns make it really easy to weave dynamic or interactive elements into your designs. While dynamic/interactive elements are sort of a given for many types of widgets, the block versions of widgets can be easily wrapped and layered within container blocks to more fully integrate them into your layout.

In the example below, I tried placing a Search block in front of a Cover block, which creates a nice layered effect. I also tried inserting Custom HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. blocks within a Columns block to display different messaging depending on the time of day. (jQuery script here)

Use traditional widget layouts (or not) with lots of flexibility over title and structure

Classic widgets have always had a lockup that includes a widget title. One cool thing about having blocks in widget areas is that you have complete flexibility over how titles appear. For example, you might choose to have a title over every widget, you might only want one title at the top of each widget area, or your design might not need titles at all.

Note: Some themes, like Twenty Twenty-One, are designed to flow content horizontally within widget areas. If you’re having trouble with a theme splitting your layout into columns, you could try keeping the lockup together by containing it within a Group block.

Side-by-side comparison of List view of a Sidebar widget area with and without grouped/nested lockups.
Ungrouped layouts (left) versus grouped layouts (right)

Copy & paste existing layouts from the WordPress Pattern Directory

While patterns haven’t been fully integrated into the widget editors yet, one thing you can do is copy and paste patterns from the game-changing new WordPress Pattern Directory into your site’s widget areas. I used this horizontal call to action pattern from the directory almost exactly as is, with minor color and copy adjustments:

Footer widget area with a black box that reads, “Become a monthly Patron” with paragraph text and a “Join now” button in a separate column. A painted image of a waves hitting rocks is directly below with no space between.
FYI: Patterns have not been curated for or integrated into widget areas yet, so you may run into some unexpected behavior!

Inserting widget patterns

There is some early discussions about how patterns can begin to be integrated into the widget editors in GitHub issue #26170. Some of the conversation has been around introducing a Patterns tab into the inserter, which would allow users to browse patterns the same way as in the post editor.

Three side-by-side views of the inserter: in the first, the Search bar is focused and “text” block icons displayed. In the second, the Patterns tab is selected and patterns are shown in a list. In the third, the drop down menu open with the “Sidebar” option hovered/active.

A couple of goals for introducing pattern insertion UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. into the widget editors are:

  • Display patterns that make sense to use in a constrained sidebarSidebar A 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. or footer area, depending on the type of widget area being edited.
  • Surface patterns in a extra discoverable way for users (including classic widget users who want to quickly recreate a traditional layout).

Based on this, I’ve been exploring ways that patterns could be surfaced in the quick inserter as a default/resting state as soon as the popover is opened:

Footer widget area with a search bar and block options in the top section and pattern options in a section below. There's a black “browse all” button that stretches across the bottom of the popover.
Currently, patterns are surfaced below quick inserter options after the user begins typing in the search box. Perhaps a couple of patterns could be visible by default.
Footer widget area with a search bar and block options in the top section and pattern options in a section below. There's a black “browse all” button that stretches across the bottom of the popover.
The quick insterter could display a list of patterns that show a fly-out preview when hovered. A similar style has previously been explored for the block switcher menu.
Footer widget area with a search bar and block options in the top section and pattern options in a section below. There's a black “browse all” button that stretches across the bottom of the popover.
The quick inserter could contain a single large preview with carousel navigation to browse through patterns. This mimics the pattern placeholder setup UI.

Thoughts?

How would you like to see patterns incorporated into the new block-based widget editors? Join the discussion by opening a new issue on GitHub or commenting below!

#blocks, #design, #gutenberg, #widgets

A Walk Around… The Search Block

Welcome to a new installment of the series where I look at the current state of GutenbergGutenberg The 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/ blocks and propose improvements.

In my previous post, I talked about the Table blockBlock Block 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.. This time I’ll be discussing another important component: the Search block.

Since search is a central activity for blogs and other sites that index content, it’s essential to give users the ability to customize the appearance of their search bars so that they don’t look alien or feel disconnected from the design of their sites.

The Search block options are pretty limited at the moment, and the block can only offer a short range of styles. The good news is that just by adding a small group of settings (many of which already exist for other blocks), users will be able to customize their search boxes in many different ways:

With that in mind, let’s have a look at this block.

Toolbar

The current toolbar has three main buttons that perform the following actions:

  • Showing and hiding the search label.
  • Changing the position of the search button (outside, inside, or no button).
  • Toggling between a search button with text or an icon.

To be more consistent with the way other blocks present the options and also to simplify the toolbar, we could move the second and third buttons (“Change button position” and “Use the button with icon”) from the toolbar to the sidebarSidebar A 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.. In the case of “Use button with icon”, I think this is not a primary action, and also the icon itself doesn’t convey the actual operation behind the button.

We could also add a setting to modify the alignment of the text inside the input field and the position of the text button. Controlling the alignment would allow users to create bars like these ones:

For languages that use right to left scripts like Arabic, Hebrew, or Urdu, we automatically switch the alignment of the text and the position of the search button.

To allow having styles that use the writing direction defined by the language, we could offer four alignment options:

  • Default (it uses the direction of the selected language)
  • Left
  • Center
  • Right

The last three options would overwrite the direction defined by the selected language.

Sidebars

Let’s review how the sidebar could look like and the sections that it would include:

Styles

This section would replace the “Change button position” that we removed from the sidebar, and add a new option: Button only. There’s an open issue that discusses this option here.

When users add a new search bar, they’ll get the default setting (Button outside), but will have the other styles visible on their sidebars for a quick switch.

Display settings

This section would allow adjusting the general width of the block (a feature that is currently present) and also toggling the following settings:

  • The icon inside the search input.
  • The icon inside the search button.

Here is a list of variations that those two settings would produce:

Spacing

In this section, users could change the padding of the item and also affect the spacing (the distance between the button and the input field).

There’s an interesting conversation around contextual padding controls in this GitHub issue, which could probably be applied to this block.

Depending on the style (button outside or button inside) the padding could behave differently:

  • If the style button outside is selected, the padding will affect both the input field and the button.
  • If the style button inside is selected, the padding will affect the outermost element.

The spacing setting could also be adjusted using a handle in the block itself. The control between the input field and the button would change the spacing, whereas the control in the button would allow resizing the whole block (which is the current behaviour).

Border

I think we should allow users to modify the border of the input field and the button independently for each of the four sides. That would give them great control to create different styles. For instance, they could create search bars with just a bottom border.

There’s an open PR that deals with border color support and border style here.

Typography

Depending on what element is selected, the typography section would affect the font and style of the input field, the text button, or the label.

Color

Like in the typography section, this one would affect the text and background colors of both the input and the button (again, depending on the selection).


As I mentioned at the beginning of this post, if we implement these changes, users will be able to customize their search bars in many different and exciting ways and have more control over the design of their sites.

You can check all the designs I presented in this post in this Figma file and follow the development status in this GitHub search.

And as always, if you have any thoughts or feedback for this block, please drop a comment below. Thank you!

#blocks, #design, #gutenberg, #search, #site-editor