Block Editor: Hide the block editor sidebar on first home page edit

[apeatling]

Please watch the "Making First Home Page Edits" testing video on this post: p58i-8d4-p2

On first entry into the block editor, the sidebar is very distracting and doesn’t contain anything immediately relevant or useful to the user. We’ve seen this as an issue in almost all user tests. He goes through the sidebar and quickly realizes there is nothing there for him. “Move to trash?! I don’t want to do that!”

As a secondary note, this hurts sidebar interactions later on when there are useful items in the sidebar for blocks. We’ve immediately set the expectation that the sidebar is something to avoid.

[jasmussen]

I would strongly vote for this as being not only the "first home page edit" experience, but the default experience. In other words, the sidebar should be closed by default, and only opened when the user actively chooses to.

This is, of course, important to test so that our assumptions of simplicity aren't erroneous. But in addition to the assumption that a simpler initial experience will be good for the user experience, the sidebar was intentionally designed to be something you can toggle off for that exact reason: it contains a lot of complicated UI that is overwhelming to new users. That, and to provide an interface that can scale to mobile, where the sidebar is a modal toggle.

Also, the pre-publish experience was created to close the gap of the most important things you might want to customize before you publish; it contains redundant UI for tags, categories, post scheduling and such.

On top of this, a block design principle from the very beginning is that the block is the interface, and the sidebar inspector should contain only secondary UI that is not critical to the user journey.

All that is to say that the interface was designed, from the start, to ensure that you never had to open the sidebar in order to accomplish your work. So there's no reason not to test this, and if the test is successful, making it the new default.

[olaolusoga]

Is this being worked on in Milestone 2 (M2)—when we drop folks in the editor after onboarding—M3, or a future milestone?

[apeatling]

Not in M2, so a future milestone.

[davipontesblog]

I am gonna play devil's advocate a bit here just to spice up the discussion a bit :) This doesn't work in the same direction as #37781, so users won't know how to easily change page layout if we hide on first edit. Also, if we hide this, how do we think users will find their way to change basic formatting options such as font size and color options for given blocks? Those are in the block settings in the sidebar. What if we, instead of hiding the sidebar, cleaned it up a bit? If the reason is "noise", perhaps we could remove the noise? A lot of the things you see in the sidebar could maybe be placed inside a "More" section collapsed by default:

• Permalink
• Featured Image
• Excerpt
• Discussion (does this even apply to pages?)
• Page Attributes

[jasmussen]

This doesn't work in the same direction as #37781, so users won't know how to easily change page layout if we hide on first edit

This assumes the sidebar is the only interface in which we can show page layout selection, when in fact founding block editor principles suggest you should only ever put something in the sidebar if it's secondary or redundant UI.

Instead of assuming the sidebar is the place to put things, a different way to frame the question is: how can we surface advanced block settings starting from the block itself?

The block setup state, quick and dirty:

It would be fine to then also have the interface remain in the sidebar as redundant UI to change templates after the fact.

Also, if we hide this, how do we think users will find their way to change basic formatting options such as font size and color options for given blocks?

Basic formatting options should not be in the sidebar. I recognize there are advanced features there, but if we find any of them to be truly "basic", then they should be moved to the block interface itself. From Advancing the Block UI, here are color options for the Cover block shown in the block UI itself:

What if we, instead of hiding the sidebar, cleaned it up a bit? If the reason is "noise", perhaps we could remove the noise?

The sidebar should definitely be cleaned up regardless of any block-first efforts also done. But the sidebar remains designed for secondary UI, also to ensure an experience that scales all the way to mobile whe the sidebar shows up as a modal dialog or modal bottom sheet, covering all the content.

In the end it's argument against argument, and if it's easy to test both, let's definitely do that. But it wasn't what the sidebar, nor the blocks, were designed for.

[davipontesblog]

I love this explanation @jasmussen. These concepts weren't familiar to me, so I appreciate the detail and screenshots - are they a new concept UI for Gutenberg? I think they answer a lot of those questions and are definitely intriguing and exciting all the same :) As long as we answer those questions, in the simplest of ways, we will have a good product, and I am excited about that!

[jasmussen]

These concepts weren't familiar to me, so I appreciate the detail and screenshots - are they a new concept UI for Gutenberg?

The concept of the sidebar as secondary has been sort of a founding principle, but I will be the first to admit that the principle itself has been a bit buried. I think it's still important to keep in mind for future efforts, though, as some of the discussions in the upstream repo do suggest that the sidebar could theoretically become a modal dialog by default. This is just being discussed at this point, but it's nonetheless something that comes from the idea of options there being secondary.

Some of the mockups above are from WordPress/gutenberg#18667 which is definitely new, it's an exploration into a refresh of the block toolbar UI.

As you can tell, I have a lot of historical lore of the editor, if you have some question about historical decisions always feel free to ping me.

[MichaelArestad]

The concept of the sidebar as secondary has been sort of a founding principle, but I will be the first to admit that the principle itself has been a bit buried.

@jasmussen It is not forgotten. It's extremely rare in our mockups for FSE, which is arguably has some of the most complex flows/needs.

[davipontesblog]

I am adding this to the Gutenboarding and Create boards for consideration in the context of our new onboarding. Also discussed yesterday in Usability test with a user - whether we should show the sidebar in the Gutenberg editor or not the first time the user is taken there. cc @ianstewart @boonerang @rickybanister @lcollette @shaunandrews @dubielzyk

[dubielzyk]

A prototype I made a while back had a similar solution that @jasmussen suggested originally:
The sidebar is closed on default, but instead opens when a user first interacts with it. Then it would close only when users actively closes it. (This video isn't a perfect match since it was a prototype for something else, but you can get the idea)

I also wasn't aware of the core founding block principle about the sidebar so that's wonderful context to know about.

[jasmussen]

The sidebar is closed on default, but instead opens when a user first interacts with it. Then it would close only when users actively closes it.

Yep, the opposite of what we have today. I think it's definitely worth trying!