Size Change: +8.46 kB (+1%)

Total Size: 1.41 MB

_{compressed-size-action}

Why assume the next thing I want to select is a different template to edit vs. a template part or going back to the dashboard?

Presenting the Templates panel makes it easy to continue editing templates. Decidedly easier than having to navigate all the way back to the panel manually, especially when it might be nested 2 or 3 levels deep in the future (e.g. Theme > Templates > List).

It is much easier to drill up (to do something else entirely) than down because:

1. The back button is always in the exact same location and behaves the exact same way.
2. Zero cognitive load working out where something might live in the iA.

It therefore makes sense to present a user with adjacent tasks rather than dropping them at the root.

This is just my opinion, so I'd love to get thoughts from other designers.

Presenting the Templates panel makes it easy to continue editing templates.

True, but just because the editor initially loads with one entity type to edit does not imply that is what the user is necessarily there for. Similarly, just because a user is done editing a template does not imply the next thing they need to edit is also a template.

It is much easier to drill up (to do something else entirely) than down because

Good point.

easier than having to navigate all the way back to the panel manually, especially when it might be nested 2 or 3 levels deep in the future (e.g. Theme > Templates > List).

There is still the 'browse all templates' button that leads directly to that menu.

Presenting the Templates panel makes it easy to continue editing templates. Decidedly easier than having to navigate all the way back to the panel manually, especially when it might be nested 2 or 3 levels deep in the future (e.g. Theme > Templates > List).

It is much easier to drill up (to do something else entirely) than down

Right. I agree. Thinking about this in only the templates context is a little tricky because it's very possible that folks are going to want to head to their dashboard after modifying a template. That's not going to be the case for many other sections or even the current behavior of the Post editor. Currently, when you click the "W" logo in the post editor, you end up on the Posts view with the sidebar open to the Posts context.

A good example is how plugins may adapt this sidebar down the road. If I'm on a WooCommerce Orders page and want to navigate to WooCommerce's Settings page, I don't want to start at the highest level menu and keep drilling down. I want to click the "W" and then click WooCommer's Settings link in the sidebar. Does that make sense?

Throwing a random idea: what if we replaced the site title with the back to dashboard button?

Currently, when you click the "W" logo in the post editor, you end up on the Posts view with the sidebar open to the Posts context.

True, but you got to the post editor in the first place by choosing to edit posts. Currently, we are not choosing to edit any specific entity type when we select the site editor - it just loads in template context by default regardless of the users intention. I think this concept of starting on the 'appropriate menu' would make much more sense if we we actually had contextual entry points to select. Until that is the case, this is kind of funky.

If I'm on a WooCommerce Orders page and want to navigate to WooCommerce's Settings page, I don't want to start at the highest level menu and keep drilling down. I want to click the "W" and then click WooCommer's Settings link in the sidebar. Does that make sense?

Yeah, that makes a lot of sense 👍

Going with the idea of automatically opening to the appropriate menu, how should this work on closing/re-opening the sidebar:

• Users loads into editor (or selects a new entity to edit) - first time they open the sidebar it is on the 'appropriate menu' - "Menu A".
• User interacts with the sidebar and explores other menus.
• User closes the sidebar while on "Menu B", without ever selecting a new entity to edit.

Now, when the user re-opens the menu - Should it still be on "Menu B", or should it open back on "Menu A" ?

it just loads in template context by default

This may not always be the case – indeed I think it quite unlikely to be. I suspect that something like the Mosaic View would be a more practical destination for the Theme Editor link. On that note, this PR is also relevant to the conversation.

Now, when the user re-opens the menu - Should it still be on "Menu B", or should it open back on "Menu A" ?

That is a very good question, but not one that necessarily needs to be answered in the context of this PR. It feels like one piece of a more holistic discussion that needs to occur if/when this pattern is ever considered to replace the entire wp-admin navigation.

I must say that the nav panel "remembering" where you are sounds sensible in theory. But in practice I wonder if it may be more confusing due to the fact it relies on the user also remembering where they were for it to feel intuitive. I find my memory much less reliable than my computers, haha. There's absolutely no harm in trying it though!

This may not always be the case – indeed I think it quite unlikely to be.

I agree as well. However my point is this doesnt make much sense until that is the case. Furthermore, this implementation only supports the context of template and template parts, not pages, posts, etc. as those menus don't exist yet. So the implementation will need to be updated in the future to support what we really want to use it for anyways. That is easy to do, but considering the flow doesn't make sense without contextual entry points and that it would need to be updated in the future to support other menus anyways... does it really make sense to add this now vs. later?

That is a very good question, but not one that necessarily needs to be answered in the context of this PR. It feels like one piece of a more holistic discussion that needs to occur if/when this pattern is ever considered to replace the entire wp-admin navigation.

Im not sure what the wp-admin navigation has to do with it, maybe we have our wires crossed. The flow I am describing never leaves the site editor, just explores the navigation panel while inside of it. Either way, it's a simple implementation detail in this PR that could easily be adjusted in the future. Technically it just comes down to if we want to set the active menu a) every time we open the panel, or b) whenever the entityType context changes.

does it really make sense to add this now vs. later?

This entire feature (theme/site editing) isn't even officially a beta yet, and I wouldn't consider it one until most of the pieces you describe exist. So I would say yes, if for no other reason than it crosses an item off the list.

Throwing a random idea: what if we replaced the site title with the back to dashboard button?

@Copons sorry I missed this earlier, the original plan was for the Site name to link to the frontend of the site, just like it does now in wp-admin.

This entire feature (theme/site editing) isn't even officially a beta yet, and I wouldn't consider it one until most of the pieces you describe exist. So I would say yes, if for no other reason than it crosses an item off the list.

Fair enough. 👍

I think this is going to be quite important along with the sidebar menu organisation refinements we intend to make (#29150). I tried to build the PR and ran into some brick walls @Copons 🙏

Here you go @jameskoster, I've rebased this and it should work as intended now. 🙂

Close @Copons :D When I open the sidebar while editing the Header template part I am taken to the "Template Parts" section, I should instead be taken to the "Headers" section within "Template Parts".

Close @Copons :D When I open the sidebar while editing the Header template part I am taken to the "Template Parts" section, I should instead be taken to the "Headers" section within "Template Parts".

@jameskoster I've updated the PR as requested (definitely missed the whole discussion around it 😅).
Now, template parts open the panel into their corresponding sub-menu (which, for TT1 is just "General").

Templates, on the other hand, will keep opening their main menu.
Let me know if this is not desirable, and if you'd like to have them open their corresponsing sub-menu instead.
I haven't tried it, but I think it should be possible without too many headaches.

No worries! Template parts are working well.

Templates, on the other hand, will keep opening their main menu.

I believe the idea is to be consistent in both cases. So if I go to Templates > General > page-home, when I next open the menu I should be looking at the Templates > General panel and see the page-home template with the active state.

@jameskoster I've opened a separate PR to handle the templates, as there's (much) more work involved: #30098
It mostly build up on @david-szabo97 past work, so I've added you two to review while it's WIP. 🙂

@Copons This one is good to go once the tests are fixed 🚀

Thanks @david-szabo97!
I've updated the tests mocking the new selector (and removing a mocked selector no longer in use).

I did more throughout testing this time. Noticed a weird behavior. If you click any item in Content submenu then close-open the browsing sidebar, then it shows both menus.

Something is still going on 🤔

1. Click on "Content -> Pages -> Any page"
2. Close browsing sidebar
3. Open browsing sidebar
4. (Now Templates should be open) Click on "< Theme"
5. Content is shown without a back button 😕

Blurgh!
@david-szabo97 thanks for the thorough test and apologies for failing to notice those behaviours in the first place.

I think those issues were happening before this PR, but either way.
The problem was that the content menu was handled by the internal state, which meant it wasn't reset to MENU_ROOT on close. So it could get stuck on a sub-menu, messing up how it interacted with the navigation menu.
My solution was to reset it to root on menu open.
This should hopefully sort out all the issues!