FSE: Use navigation mode as the default #24394
Conversation
noahtallen
requested review from
ockham,
Addison-Stavlo,
Copons,
jeyip and
vindl
noahtallen
added
[Feature] Full Site Editing
[Type] Enhancement
|
Size Change: +72 B (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
noahtallen
force-pushed
the
try/nav-mode-only-fse
branch
from
cf3088d to
96f387f
Compare
|
props to @Addison-Stavlo for 96f387f. We additionally switch back to select mode whenever there is no selected block. This means that we can end up in select mode much more frequently now. For example, switching to header/footer or back to template will put you back into select mode. It feels mostly good, with a couple of rough edges (sometimes you switch from edit -> select mode at unexpected times. Here's a gif: cc @dubielzyk
|
|
I'll start looking into playing with this locally. Some thoughts:
This is starting to shape up nicely! Awesome job |
What do you mean by this? Like when clicking into different blocks, how other blocks resize?? |
Yep. I know that some of this is caused by the [+] button that appears, but as FSE is moving away from a "writer canvas" and into a WYSIWYG editor, it's way more jarring when content jumps around as you're hovering stuff |
|
Managed to run it locally now and test it out. Definitely like the navigation mode by default. I'll check with some others to see if it's a problem. There's some stuff about the hover behavior that isn't there yet, but I'll file that in the appropriate PR :) |
|
Cool. I think we can continue working on the jumpiness as a follow up. I think that's definitely an issue. |
|
I'm also not sure what next steps are here. I think the interaction is mostly solid. We could also remove the "automatically switch back to nav mode when there is no selected block" and just leave it with loading nav mode at the start |
|
I recon we go for this and get it merged so we can see what people think. Currently this is just a testing ground, so we might end up reverting some of these decisions, but I've heard people want this functionality before. |
noahtallen
force-pushed
the
try/nav-mode-only-fse
branch
from
96f387f to
ba39c8d
Compare
noahtallen
force-pushed
the
try/nav-mode-only-fse
branch
from
ba39c8d to
98a35ef
Compare
|
@shaunandrews @MichaelArestad any thoughts on this? I think it'd be cool to try out in the site editor. I think since it's a layout application, it makes sense to have something like this as the default. The specific behavior here is:
This means that:
|
|
This works fine for me so far. I noticed a couple of smaller issues that could be polished in a follow-up:
|
Yeah. This is unfortunately just an issue with select mode in general, and I think we want to look into solving that in the future as well :/ |
|
I find this a little strange. I'm not entirely sure it helps me understand what I'm editing, but it does put a barrier to interacting with blocks. If I was unfamiliar with the way the modes work, I'm not sure I'd understand what was happening, or how to get to a block's toolbar. Here's a quick GIF that shows my first experience with this:
|
So the big thing here is that when you click on the content, it says "post content". In edit mode, that label wouldn't show up and you'd just be editing that text directly. This is great for posts, but in the site editor... If you're used to the post editor, what makes you think that the top cover block is just part of the template? To a new user, it would seem just like everything else on the page. "Post content" is a cue which indicates that something a bit different is happening here. I really don't believe edit mode as it stands today helps solve this problem. I don't think interacting with the blocks in the post content needs to be the first priority -- you can do that just fine in the post editor. (The site editor's purpose isn't to give you a really great essay-editing experience, to me) We need to have a way to help the user understand exactly where that content is coming from (is it a post? a page?), and same with the header/footer. I'm super open to other ways of accomplishing this! Select/nav mode came to mind because it has some of these concepts built in already |
I agree with the above. And with that context in mind I don't think that displaying this information for regular blocks ( I think the above is already being explored in #24557. |
|
I think we should tread very carefully around the idea of introducing different mode interactions between contexts (site editing vs content editing). These concepts already require some mental gymnastics to grasp, and I'm not sure the average user will understand (or care about) the differences between site editing and content editing. At the end of the day it's all just editing, and the patterns of the post editor are well established at this point. With that in mind I wonder how prominent the solution to the "what am I editing?" problem needs to be? Two considerations there;
|
|
Thanks for the thoughts!
I don't think most users (i.e. beginners) will be aware of those features. 🤔 There is also the breadcrumb at the bottom of the screen which helps a bit. I mean bluntly, this is a problem even I run into! e.g. where does the template part begin or end? This information is currently not answerable at a glance through block navigation or multi-entity saving. Additionally, multi-entity saving is hidden behind a few buttons so by default, folks won't understand that they are changing multiple entities.
I think this is exactly my motivation for this. There is a massive difference between page building and writing an essay. I want design controls and outlines when building a page, but not when writing a post. When writing a post, I want the editor to get away -- I don't need those tools! I'm personally not convinced that we should be hiding this difference. :) To give an example, look at the "site title" block. If you're used to the established patterns of the post editor, you might expect this to behave exactly like a heading block (nearly everything about it looks and feels the same). But the site title block has a totally different effect: it updates the title in the database (separate from the rest of the post) which changes things like the browser tab, what shows up in different feeds, etc. All that to say... I personally think we do need to be more obvious. And I think we're all striving for the same thing: we want users to understand what they are editing in the site editor! |
|
Also, I wanted to add that I'm also not sure that navigation mode solves the problem well either, so I'm not arguing in favor of nav mode specifically, just in favor of being more clear and obvious about how entities work in the site editor :) |
|
I think let's perhaps hold off on this change since there's no clear agreement. We'll can revisit and see if this is worth implementing when we've fixed some of the things we want to do in Edit mode :) |
|
Sounds good! I will close this PR for now. |
Description
This partially iterates towards #22064, and helps solve the problem of "what am I editing" when first entering the site editor. This is an important question to answer for the user, because there are many different entities available to edit (unlike the normal post editor.)
To do:
How has this been tested?
Locally, in edit site.
Screenshots
Types of changes
UX
Checklist: