Gutenberg Contributors Explore a New Browse Mode for Navigating the Site Editor

It’s easy to get lost while trying to get around the Site Editor unless you are working day and night inside the tool. The navigation is jumpy and confusing, especially when going from template browsing to template editing to modifying individual blocks. A large PR is in progress for redesigning this UI with the introduction of a “browse mode” that would make the experience feel more like a design tool.

Gutenberg lead engineer Riad Benguella opened the PR as a continuation of the ongoing work on this project, which has its roots in ideas and explorations that have been fermenting since 2019. He shared a video that roughly demonstrates the target for the proposed UI changes.

It essentially introduces a “navigable frame” where users can select from a menu of features on the left. More detailed efforts on improving the animations and placement of the menu items is happening simultaneously within the ticket.

The original idea was to include the “Navigation menu” item inside the sidebar, but Benguella removed it in favor of keeping the PR contained to simply adding the “edit/view” mode.

Although such a large PR has the potential to introduce a slew of regressions, Benguella said there is no other way around a big PR due to the the necessity of the structural changes to how the site editor is organized. He is attempting to keep it narrowly focused and not try to tackle features like browsing capabilities and adding UI (template lists, global styles, etc) to the sidebar.

The idea is not without some pushback. Alex Stine, Cloud Platform Engineer at Waystar, warned against introducing another Mode into Gutenberg, saying it “feels kind of reckless considering we haven’t refined existing modes for all users.” He noted that Gutenberg already has select/edit mode contexts.

“This was a feature basically added for screen readers only,” Stine said. “I am hoping this will one day be removed, but we’re not quite there yet.

“I think the community is trying to solve the wrong problem. If Gutenberg itself did not have such a complex UI, there would not be the need for a hundred different modes in a hundred different contexts, blocks, or even editors. We have gone so crazy making everything so quickly, no one thought about how to unify the interface across all editors. This feels like it could be another patch to a bigger problem.”

Stine cautioned against growing the UI for something that ultimately doesn’t make things any simpler.

“In a sense this PR doesn’t introduce any new mode, it just redesigns the current navigation panel a bit,” Benguella said in response. “I think it’s an opportunity to improve the a11y of the navigation in the site editor.

“The confusion in this PR is that it’s not about another mode in the editor itself, it’s higher level, it’s how we choose which template and template part to edit before actually entering the editor.”

Although the project’s contributors have been referring to it as “browse mode,” it is essentially a redesign for the existing UI to make it more intuitive for users to navigate. Gutenberg may not need any more new “modes” but the site editor is in dire need design improvements that will unify the experience and make it less chaotic for getting around.

During the most recent core Editor meeting, Gutenberg contributors called for feedback on the big PR, since it has so many moving parts and needs more scrutiny. It’s not ready to land in the next release of Gutenberg yet, but the concept is rapidly taking shape and may expand to include more features in the sidebar once the basic structure is in place.

10

10 responses to “Gutenberg Contributors Explore a New Browse Mode for Navigating the Site Editor”

  1. I don’t really understand it. I wish we would stick to one thing and get it done completely before we added something else.

  2. This may seem like it’s out of place or just another UI convention that is going to muddy the waters but people should really follow the development of the Gutenberg project more closely. They’d see this isn’t random or out of place but instead it is laying foundations.

    Something to note is this UI/UX comes directly from ongoing work being done to completely redesign the WooCommerce admin UI.

    Read between the lines and this is where the UI/UX of the entire WordPress Dashboard itself is going.

    That nav that slides in and out on the left? It’s going to replace the main WordPress Dashboard navigation eventually.

    • Completely redesigning UX/UI at the same time that the technology is changing so much, from classic to block? (though there are still a lot of us using classic/block-friendly themes, and I suspect that will be true for some time to come)

      I admit to being a bit nervous; I tried a FSE theme on my last site and got so lost I reverted to classic with block editor. I am pretty comfortable in that mode, after the better part of a year working (very part time) on that site and 4 others on which I work as part of volunteer advocacy, and I can see some features of FSE that I would like to incorporate, but gradually, so that I still feel comfortable with the basics.

  3. Thanks for writing about this in progress work. Having seen repeated concerns about the site editing experience for the last two years, I think this exploration promises a more intuitive navigation of the pieces of the site editor. At the same time, this PR is just a start and part of much wider efforts too: https://github.com/WordPress/gutenberg/issues/36667 & for an even larger picture: https://github.com/WordPress/gutenberg/issues/33094

    I wanted to note for anyone reading along and wanting to have a say that I am following this work closely in order to have it as part of an upcoming FSE Outreach Program call for testing: https://make.wordpress.org/test/handbook/full-site-editing-outreach-experiment/ Stay tuned and know lots of feedback will be collected along the way. Of course, you’re always welcome to share directly in GitHub too!

  4. The idea that clicking the W (wordpress logo) opens and closes the menu sidebar is high on the scoreboard of unintuitive additions to WP-admin

    Clicking the logo in most sites takes a user to the site homepage, and in this case when we are not at WordPress.tld (we are at mysite.tld) clicking the logo implies we will visit WordPress.tld

    • I totally agree with you, I thought it will be back to wp-admin, didn’t expect that new behavior.

      It will confuse the current user.

    • The W logo in the block editor brings me out of the specific post or page on which I am working to the list of posts or pages, respectively. When I am in the dashboard itself, it takes me to a WordPress page. I am used to and expect this behavior. IDK what .tld is.

  5. When I tried out FSE, the most obvious thing that became apparent to me is that you have too many different “modes” active at the same time and it would be easier if you allowed the end user to just focus on a one mode at a time.

    For example, you have the layout structure tree on left side of the screen and when you click on an area of your site, it highlights the specific layout structure area within the tree. This is what I would expect to happen if I’m in a “layout mode”.

    However, when I opened the Style area on the right hand side of the interface, I expect the interface to switch to a “style mode”. In this mode, I expect that when I click on a site element, it immediately shows the appropriate style element related to it, so that I can easily modify it (i.e. clicking on the Site Title shows the specific style settings for it). But it obviously doesn’t work this way because they aren’t differentiating the different modes.

    This is basically how Squarespace used to work way back in Version 5, when they had different modes (i.e. Preview, Content, Structure, Style). It made it pretty easy to use. Something that WordPress will have to think about, if it ever integrates front-end post / page editing in the future.

  6. Gutenberg contributor Andrew Serong has created a draft exploratory PR for adding opt-in, server-rendered background support for blocks, which would save background image values to the block’s style attribute in a backgroundImage key. Serong created the PR as a rough, experimental approach and published a few screenshots of how the inspector controls might fit in. However, Gutenberg designers are working on a more refined design for background support in the editor.

    Today, Gutenberg designers Joen Asmussen and Javier Arce published a GitHub issue with their vision for a complete reorganization of background controls that includes layer management, layer reordering, and support for filters/blend modes.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: