Navigation: change navigation link variation scope to block to avoid cluttering the inserter #35056
Conversation
…cluttering the inserter
|
Size Change: +9 B (0%) Total Size: 1.06 MB
ℹ️ View Unchanged
|
|
I'd be perfectly happy to ship this as is and just hide link variations from users altogether 😄 because they add a layer of complexity to the process that shouldn't be needed at all. In the classic menu interface, it's easy to just browse the accordions if we're not sure where to find the link we're after, but with all these blocks we're forced to guess, or at the very least to stop and think about it before choosing one. It would be easier to just have one Link block, and all variations could be accessed from there. The bulk UI exploration in #31667 seems super promising in helping to simplify this flow, and would be great to combine it with this PR. One thing I'm thinking is that if we're exposing a single Link block, then it might be clearer to just call it Link instead of Custom Link. |
|
I share the general instinct that there isn't a great deal of value in letting you choose between page, category, tag or custom links, because in the end they are all just links. The challenge as I see it is that the URL dialog that lets you pick what to link to, right now, is very limited in utility, showing just the 3 most recent published items, regardless of type. Which effectively means at the moment you have to remember the page you want to link to, then search for it. There really is no browsing mechanism at all. This mockup imagines curating those suggestions based on block type:
I imagine this will need a different approach if we were to decide on effectively a single link type, needing some other way to browse lists of content on your site in the URL dialog. So effectively the question becomes: when do we want to let the user make a choice of link type? Without a link type, we're left with search, which can never be as good as picking from a contextual list. If we keep #34041 in mind as well, the intent of that is to create two phases of the navigation block: the basic phase where all you insert are Page Links (which if paired with the mockup above would let you quickly pick a page), and the advanced phase, where you get the full quick inserter back that we have today. From the discussion it seems clear that the primary challenge here is: how do we make it intuitive to switch from basic nav building, to advanced nav building? If the "transform" mechanism isn't intuitive enough, we'll have to look beyond that. |
I just opened #35104 to propose changing the initial suggestions for the Nav link block, which I think will bring us closer to the intention in #34041 of default inserting a Page link, without limiting that default block to inserting pages only.
This is a complicated problem to solve in a little link popup 😅 but if #31667 goes ahead, we may not need to solve it here. If we have a sidebar inserter where we can choose between all types and taxonomies, the link control popup becomes more like the quick inserter, where we just show what we think will be most handy and allow searching for anything else.
Yup, this would be worth some exploration all on its own. What might we do beyond the transform button in the link control? Would it make sense to use toolbar buttons (either on Link or on the Navigation itself) to call attention to some of the other possibilities, like Search or Social? |
I think it valuable to approach this from a generic viewpoint, seeking a solution that could work for any container block beyond Navigation. I don't think "Buttons" will be able to contain other child blocks any time soon, but if in the future these container blocks start to converge (we already have a Row block that's like the Buttons block but for any child), a solution we find here would benefit both. That's what informed the initial exploration, which embraces the transforms interface: Keeping in mind that as soon as the navigation container has more than one type of block, we revert back to the full quick inserter, all we need is an "escape hatch" block to enable that. So we could look at giving more prominence to a curated list of child blocks:
Another option is to put a toggle in the inspector, which when untoggled simply allows additional blocks. This toggle might even be able to exist in addition to the "transform" options illustrated above:
Note that the labels and phrasing in the above would need work. |
|
Oh, showing that "...or transform to block" section with a few actual block examples is a good workaround for the issue @karmatosed raised about transform not being well-known enough. That would make it pretty clear! Perhaps we should give it a try in another PR. Would we be able to access the full list of blocks from there, or would it just show the most popular options? An inspector toggle might not be super easy to find, though conceptually it fits in well with the idea that adding other types of blocks is an "advanced" mode of editing. I'm divided on this one 😂 Regardless of how we implement the transforms interface, this PR is a good enhancement. If/when #34899 is merged, I think it will make even more sense to not show dozens of link types in the quick inserter. |
|
IMO, the link variations don't add much besides promoting visibility of installed CPTs and helping lock down search results for links. We're probably pretty close to being able to removing these from the quick inserter, but we'll need to be careful to see that the navigation editor has a viable flow. @jasmussen what if we added some more filtering options to search? As a really quick example, here's a rough mock where we might have a dropdown next to the search filter that could set the post type to filter to.
I wonder if we should consider paging as well, since I'm not sure if folks know what to search for in all cases either. |
|
There's a bit of discussion on the topic here as well. The big challenge to me is that search feels like what should be employed when all other options fail, because search requires you to know what to search for. The big benefit of being able to surface a hierarchically indented page list is that it reminds you of both the structure of pages as you might have created them already, as well as all the pages there are. The comment here suggests contextual suggestions based on CPTs, but reflecting on your comments it does seem like it's optimizing for edgecases. Perhaps we could go as simple as this: Always show a list of hierarchical pages, because that's what you're adding to navigation menus 80% of the time. Anything else, you search for. Would that make for a good starting point? |
This could be a good optimisation. At the same time a site is likely to have lots of posts and tags, so filtering options could still be useful. Just looking at a site like Making WordPress, and that has thousands posts and tags combined 😱. It'd be interesting to sync up with @javierarce's work on the bulk link inserter here, lots of similar concepts. |
|
I like the hierarchy, though just had a thought, do you think there will be confusion over whether all the nested pages are inserted if 'Products' is clicked? That makes me wonder if we should have some kind of optimization for this in the submenu block, if a Page is made a submenu it could offer to insert all the child pages as a second step. (this is probably a stretch goal for after the rest of the flow has been sorted, but just wanted to record it somewhere). |
What a great insight. If we made it easy enough to delete submenu items, perhaps it would be fine to just insert page plus submenus by default? |
Indeed. Perhaps we could start with the page-list-by-default, especially paired with Page Link being the default block inserted. Then if we kept the CPT link variations, those could still tailor the list in the popover? |
skorasaurus
added
[Block] Navigation Link
This PR changes navigation link variations to block scope. A quick draft, we likely can't land this until we have alternate ways of searching/filtering out other types of links.