Try: Navigation Menu Sidebar #38600
Try: Navigation Menu Sidebar #38600
Conversation
|
Size Change: +1.21 kB (0%) Total Size: 1.16 MB
ℹ️ View Unchanged
|
|
Very cool. There are some excellent first steps to take in this comment, and your PR and it feels like this one is blazing a trail towards that! On the side, I think we can explore some of the larger design-related changes with some fresh mockups, I'll get on that, but it's nothing that should block this functionality, so thanks for working on this!
In general I'm always a fan of starting as simple as possible and only add complexity on top of that when we learn that it's necessary. That could look like this:
Buttons for creating and managing menus can always come later. But an additional benefit of starting with less is that it lets us figure out how prominent such controls need to be; is such menu management something you do all the time? Or do most sites indeed have a between zero and 2 menus in total? Something to consider for the future is that case where a site has zero menus, and whether it might make sense to show all the pages of your site and only save it as a CPT if you make a change. |
Right, I think there's some interesting navigation menu building we can iterate on in future PRs. For the 0 navigation blocks case initially I might not show the sidebar, or perhaps just note that there are no navigation blocks (and maybe link to a shortcut for inserting one into the document).
Sounds good to me. I suppose we'll also see how useful the navigation menu names are. If we end up using it a lot I might need to rethink how we store data on the client to make the lookup a little less awkward. One other thought is that folks will likely want to edit classic menus too, but that can also be left as a follow up. I imagine that we don't want to necessarily convert these navigation menus automatically. |
|
Not feeling great 🤧 so leaving some midday notes for myself:
|
gwwar
force-pushed
the
try/nav-dedicated-sidebar
branch
from
4dbbe34
to
90b67ad
Compare
|
Heads up that I'm going to tidy up the summary |
gwwar
added
[Package] Block editor
gwwar
requested review from
jasmussen,
youknowriad,
getdave,
tellthemachines and
talldan
There was a problem hiding this comment.
Thanks for trying this out! This is just a quick first pass from me, mainly testing; I haven't looked at the changeset in depth yet.
A few thoughts/questions:
- Does it make sense to introduce this to the post editor, at least at this point? Because navs are being fetched from the editor content, and posts will most often not have them, it feels a bit unnecessary.
- Reading through Introduce "Browser" and surface main navigation UI #36667 it looks like the aim is for this sidebar to be a representation of the site structure, with each nav link actually taking us to a view of its page in the editor. This will only work if the nav consists solely of a curated list of links. Page list block is opaque, so if the nav is just a page list, we won't benefit from this view at all. And other blocks that might be added, e.g. Search or Spacer or even Social Icons will muddy that representation quite a bit. I don't have any ideas here except that we should probably decide early on whether we want this list to function as a nav-editing device, or a site structure representation, because we'll need quite different solutions for each of these aims.
- Wasn't this view meant to be on the left hand side of the editor? I noticed you also opened Navigation Sidebar: experiment with a persistent vertical display #38465, is that meant to complement this PR?
- The list view does provide a much neater interface to move nav items around ⭐
- We should probably look at a way to move items with the keyboard in list view (as a separate piece of work, of course 😅 )
| /** | ||
| * WordPress dependencies | ||
| */ | ||
| import { useEntityProp } from '@wordpress/core-data'; |
There was a problem hiding this comment.
Is there any way we can avoid having core-data as a dependency of the block editor package? Block editor should be usable independently from WP.
Could we perhaps add the title as an attribute of the nav block, and then use getBlock to access it instead?
|
Thanks for the PR! This looks like a great start. I think my main remark here is close to what @tellthemachines shared above: basically this PR is making the added sidebar part of the "block editor" like an "additional block inspector" blocks can use to trigger sidebars while it seems to me like the main goal of the original issue is to add something that is more "site wide" and not specific to the current post/page/template being edited. In other words, this should be a sidebar of the site editor (and probably not have anything to do with complementary editor areas), it's more global that the thing being current edited in the site editor. I think reusing the list view UI is indeed the right approach but it doesn't have to be the exact same thing used by the navigation block's modal, that one is contextual to the current navigation block being edited in the canvas. |
|
Nice work 👏🏻
I think we do. We don't want to manage classic menus via a block structure as this has resulted in many setbacks in last year's explorations for adding a block editor for wp menus. |
|
Thanks for the speedy feedback y'all, so to summarize what I'm hearing:
Questions on behavior:
|
gwwar
force-pushed
the
try/nav-dedicated-sidebar
branch
from
ee77be3
to
615b3f3
Compare
|
So to move to fetching all navigation items, from the package architecture page it sounds like it might make sense to add some
|
|
Being able to load any menu gives us an interesting problem to solve. The ListView component currently assumes that any blocks it displays are available in the Imagine that we're editing the index template, which has a navigation block that points at a There a few ways of approaching this, but I think these two might be more promising. Option A: Provided that there's at least one navigation block in the template, selecting a menu ref, also updates the block attribute. I pushed a happy path example to the branch. There's still corner cases to work through. CleanShot.2022-02-11.at.13.53.18.mp4Option B: Update ListView (or create a new component) to decouple dependence on specific data stores. If we pass a fully populated list of blocks, we should see a nice preview. @youknowriad had a preference for this one. |
gwwar
removed
[Package] Edit Site
|
Hey @jasmussen , thank you for the ping! I just wanted to mention an experimental component that was recently added to the
Currently components from But theming is definitely an area that we intend to explore in the future, and the work on the Navigation Menu Sidebar could be very useful in exploring how that could look like. |
Thanks a bunch for chiming in. The missing theming is definitely a bit of a challenge for this PR, and even just the general concept of having inspector-like controls on a dark background, which is otherwise conceptually interesting. You can see the GIF here when diving into "All blocks", the controls start working less well there. If we wanted a near-term solution to this, what's your best idea for accomplishing this? Color overrides in CSS could probably work, but we'd ideally want to do it in a way that didn't incur a ton of technical debt. |
Zooming out a bit for theming requirements in components, I feel like there are a few different layers to this:
OS Preferences for Dark/Light modesIf a user sets an OS level preference, the UI should ideally respond to this. If someone picks a dark mode, what does the current design look like for block editing areas? Admin theme schemeBeyond that users may also pick an admin theme. Plugin ThemingFinally, if |
|
At the risk of sounding a bit boring, I think the Apple approach works very well. IE choose either light, dark, or auto mode, and then select an accent color to personalise. Plugin theming feels like a whole other discussion. There's a question around the benefits of interfering with customer preferences in this way. Should branding be introduced another way? |
|
I wan to just post some 👍🏻 s for the cool separation of global dark left and local white right, feels like something that is quickly learned without training. In terms of navigation we should be able to create navigation in that area as well and I feel looking at the demos that we kinda need to introduce the concept of primary / secondary right there? Maybe, not sure.
@jameskoster this being totally true, it's also a thing that for a page to be homepage the index template is assigned, so the thing becomes should we have some default site structure where there is a menu that by default contains a "Home" link? |
That's a good question. I'd love to hear more thoughts on this, but I would be inclined to exclude the home link by default because the Site Title / Logo generally provide this functionality. The question then becomes: how do we expose pages that are not part of the default menu in the site structure? That's probably something to explore separately, but perhaps there's an "unlinked" section below the menu? That could contain things like the home page, and perhaps even post categories, tags, and other archives. Folks would be able to simply drag items from the "unlinked" section to their menu if they want to add them. |
We are definitely aware of that. Adding theming support (at least at a basic level) has already been discussed and we have an idea about how to approach it, although we haven't had the capacity to actually start experimenting on it yet (most of our time is spent helping folks with daily reviews, while slowly working on a few structural and fundamental package-wise improvements which will unblock future work). We are still unsure about the specific requirements for the exposed theming APIs. In that regard, proceeding with style overrides on this project really is a helpful step because we can look at those overrides to understand what variables really need to be exposed, and we can keep that in mind so that the "theming" for this particular feature doesn't become too ambitious in the first place.
The best short-term solution would be to apply CSS overrides to these components where they are consumed (e.g. in the
The approach that was discussed on our end was to have the It would be up to the consumer of |
That would be my instinct as well. There could be many pages, though, so we could need a button drawer for "more", so we at least avoid needing pagination.
👍 👍 I would echo Jay's assessment of Kerry's proposal, though: keep it simple, so components retain their baked-in accessibility and DNA. So working on light and dark backgrounds would be step 1. System level dark mode is probably not near term for the project, so that's mostly something to keep in mind, but even with that, there will be cases in light mode where we need components that show up on a dark background, so it can't just be a blanket switch. For any theming properties beyond light and dark, I would imagine a single accent color and possibly border radius. Both should probably be component-wide, i.e. don't mix multiple accent colors and radiuses across the UI. Fonts and font sizes should probably be inherited by the context, mainly. Does that sound right to you? |
|
@jasmussen I agree with everything you said — we do want to keep things as simple as possible (especially during the first iterations), which includes exposing only the "theming variables" that strictly necessary. We'll definitely keep you, Jay and Kerry in mind for gather early feedback too! |
|
I had a go at using inner blocks for Page List in #39087, which would solve the issue of it not showing its contents in this sidebar. It doesn't actually seem too bad. The new block locking features bring us a lot closer to this being a possibility. |
|
This is great work. I'd like to look at breaking this PR down to the essentials required to merge a Navigation Menu (only) sidebar. I'll be testing this PR and disentangling what is reusable. |
|
@getdave I'd be happy to pull out those parts for you. |
gwwar
force-pushed
the
try/nav-dedicated-sidebar
branch
from
5eb2efc
to
57e65c0
Compare
gwwar
added
the
[Type] Technical Prototype
|
Testing using this method: https://make.wordpress.org/design/2021/03/03/testing-a-gutenberg-pull-request-pr/ It is quite a contrast. Before: After: My initial reactions. What if the Nav and Styles were instead moved into the W menu area like so: Here we are gradually recreating the left WordPress admin menu. In addition to the adjustments I suggested above we could add the full Navigation into List view. Currently we see this: What if we instead of the Page List actually saw when opening the Navigation in List view saw the full navigation and also moved the various links around. (Similar to how we can move things around in the current classic Navigation screen.) This way we are reusing an existing List view feature. Going into the details of a block. Being able to adjust the contents inside the block by using the List view. Edit settings sidebar panel. |
|
@paaljoachim Thank you for taking the time to review. Unfortunately, this PR is actually pretty broad right now and it trying to tackle a number of things. I can't see it landing in 6.0. Kerry ended up extracting a subset of this PR into #39290 which adds a more simple Navigation-only sidebar. I think we should pursue the more limited scope outlined in #39290 else we're going to bite off more than we can chew. It might be worth taking a look at that PR.
This works already. You are using the Page List block which currently doesn't expose inner blocks within the list view. Instead try adding some standard links to the Navigation block and then opening it in list view. You'll see you have full control of the Nav structure within the list view. That said I don't currently believe list view can handle all the requirements necessary to fully manage a Navigation (think managing styles, block settings, editing text .etc). It's going to end up replicating the functionality which we already have within the editor canvas via blocks. My preference would be for list view to remain "structure only" and for more dedicated approaches to handle the more complex parts of editing a Navigation. |
|
Goals in #36667 are a bit broad. To clarify a bit further the PR here is a technical prototype that quickly shows what it looks like UX might feel like with a dedicated vertical rail on the left for global panels, and how we might make it easier to manage navigation structure. I think folks are leaning toward other UX options, so it's pretty unlikely that this PR will land. I think it's still useful for folks to play with the branch, as it does quickly highlight some technical issues, especially if folks end up wanting to add additional functionality to ListView to make it more of a mini-editor. There's quite a number of side-effects that will need to be untangled from block list if that's so.
@paaljoachim, @talldan explores this in #39087 |
|
A few things. From my limited exploration it seems that List view is working fairly well with drag and drop of individual links. It should be kept simple and deeper methods are needed elsewhere.
I went ahead and left feedback there. Bottom line that I find would be helpful would be to in some way connect the "Navigation Editor" with the Nav block sidebar panels. Because a deeper editing of the Navigation should be associated with the Navigation settings. |
|
Created a rebase here: #39885 |
Part of #36667.
This is a wide exploration PR which adds a new sidebar to the site and post editor to help with navigation menu management.
After
The new navigation sidebar reuses the ListView component and allows users to easily reorder items even when the menu might be hidden (for example in a mobile menu).
CleanShot.2022-02-17.at.09.38.25.mp4
Before
Previously, clicking on the open list view button would open a modal.
Testing Instructions
Notes
Navigation blocks can store their data in many ways:
__unstableLocationsuch as a "primary" menu. The site editor incorrectly renders an empty placeholder in this case. Note that I won't address that in this PR.Wiring up the list view button on the Navigation block toolbar is a package puzzle.
while in the post editor it is:
To solve this, I opted to add an unstable slot/fill following the pattern set by
__unstableBlockSettingsMenuFirstItem. If folks have a better idea of how to untangle this, I'm happy to hear about suggestions.