Site Editor (Experiment): Automatically open the sidebar to the appropriate menu #26964
Conversation
Copons
requested review from
mattwiebe,
jameskoster,
vindl,
david-szabo97,
jeyip,
noahtallen and
Addison-Stavlo
|
Size Change: +8.46 kB (+1%) Total Size: 1.41 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
The code looks good and it functions like I would expect (I think?)... although it feels very weird and a bit heavy handed.
Im editing a Template, I want to open the sidebar to either select something else to edit or go back to the dashboard. It immediately opens to the 'Templates' menu. This would make sense if the menu had editing options for the entity I am working on, but its just a selection interface. 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? This doesn't make sense to me.
So now the panel always opens to a nested level. Even if I open it, go back one level, close it, and re-open it, it still opens to that nested level again. This is also awkward. The drill-down pattern is never used starting from the top-level anymore.
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:
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. |
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.
Good point.
There is still the 'browse all templates' button that leads directly to that menu. |
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?
|
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.
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:
Now, when the user re-opens the menu - Should it still be on "Menu B", or should it open back on "Menu A" ? |
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.
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! |
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?
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. |
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.
@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. |
Fair enough. 👍 |
Copons
force-pushed
the
update/fse-sidebar-initial-menu
branch
from
775abaa
to
9ee2758
Compare
|
Here you go @jameskoster, I've rebased this and it should work as intended now. 🙂 |
packages/edit-site/src/components/navigation-sidebar/navigation-toggle/index.js
Outdated
Show resolved
Hide resolved
packages/edit-site/src/components/navigation-sidebar/navigation-toggle/index.js
Outdated
Show resolved
Hide resolved
|
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". |
Copons
force-pushed
the
update/fse-sidebar-initial-menu
branch
from
e550189
to
fd37406
Compare
@jameskoster I've updated the PR as requested (definitely missed the whole discussion around it 😅). Templates, on the other hand, will keep opening their main menu. |
|
No worries! Template parts are working well.
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 |
|
@Copons This one is good to go once the tests are fixed 🚀 |
|
Thanks @david-szabo97! |
|
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. Screen.Recording.2021-03-23.at.18.00.15.mov |
|
Something is still going on 🤔
Screen.Recording.2021-03-24.at.9.56.55.mov |
|
Blurgh! I think those issues were happening before this PR, but either way. |
Description
Fixes #26924
Clicking on the navigation toggle button will open the navigation sidebar to the appropriate menu, either Templates or Template Parts, depending on the template type that is being currently edited.
How has this been tested?
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: