Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Block: Navigation #1466

Closed
melchoyce opened this issue Jun 26, 2017 · 43 comments
Closed

Add Block: Navigation #1466

melchoyce opened this issue Jun 26, 2017 · 43 comments

Comments

@melchoyce
Copy link
Contributor

@melchoyce melchoyce commented Jun 26, 2017

...Which I think we should rename to "Navigation Menu." :)

I have a lot of questions around best practices for something this dynamic:

  • Should the menu building happen in the Inspector, or in the preview?
  • Like the Custom HTML block, should there be a way to toggle between entering content and previewing it?
  • Should the block start with any pages, or should it be totally empty when you make a new block?
  • Should we have an option to display pages as a vertical list, or a horizontal bar/list?

Related to #1011.

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jun 26, 2017

Also worth noting: once we establish the pattern for "building" a block's content in Gutenberg, we can also then show how that could be applied to something like a contact form block.

@melchoyce melchoyce changed the title Widgets: Custom Menu Add Block: Custom Menu Jun 26, 2017
@jwold
Copy link

@jwold jwold commented Jun 26, 2017

@melchoyce just to clarify, are we trying to replicate experience from: Appearance > Widgets or Appearance Menus?

I started to think through how the experience should be with the Widgets but realized I should check first.
gutenberg 1466

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jun 27, 2017

To be honest, I don't think we should necessarily replicate either — I think this would be a good chance to re-examine what it looks like to build a menu, independent of menu locations. Maybe in the short-term, any menu built as a block is back-compat as a new menu to nav-menus.php so you can use it in other places, but in the long run, I think abandoning menu locations for blocks is going to make site building much easier to understand.

@jwold
Copy link

@jwold jwold commented Jun 27, 2017

What do you think about this? Anything we should change/add/remove?

wireframe

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jun 29, 2017

So: list of pages/etc. in the inspector, drag (or tap) from the inspector into the menu block? That's an interesting idea — @jasmussen, what do you think?

Since this is a complex block, it might be good to explore a couple different ideas before settling on a direction.

@jwold
Copy link

@jwold jwold commented Jun 29, 2017

Since this is a complex block, it might be good to explore a couple different ideas before settling on a direction.

Absolutely! I think this idea is one direction to pursue, but would love to see what others come up with.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Jun 29, 2017

Solid discussion, great ideas. I think the inspector feels like the obvious place to configure the contents of this block, yes, but even then it's just nice to see baby steps to fix this.

I think a pretty key aspect to figure out, and perhaps this overlaps with #1516, is how do you save these menus and how can you re-use an existing menu. Does each menu you save become a new block in the inserter? Or is there a single menu block you insert, and you then pick a saved menu from the block itself as the first step? And/or customize it then and there? Probably good to explore a few directions so we can cauterize them until only the best approach remains. (As Mel essentially said already)

@folletto
Copy link

@folletto folletto commented Jul 3, 2017

how do you save these menus and how can you re-use an existing menu.

I feel the shared blocks idea is how to deal with it, without making an ad-hoc UI specifically for menus.

In the work I've done so far with menus both .org and .com the "reusability" factor didn't show up as a user need, and in fact caused a LOT of trouble due to how complicated it made the UI (associating a menu is a hard concept to grasp).

I'd consider not addressing that part of the UI for the time being, and iterate back once #1516 reaches a solid v1.

@westonruter
Copy link
Member

@westonruter westonruter commented Jul 9, 2017

I think the initial version of the block should omit the “create a new menu” link. This is only present in the Customizer, and it is not available on the Custom Menu widget that appears on the widgets admin screen.

Aside from the issue of being able to create a new menu in a block which isn't yet published (i.e. what the Customizer implements as a placeholder menu), an additional complication for the menu block is that nav menus aren't yet available for manipulation via the REST API.

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jul 10, 2017

@westonruter I think those are issues we're going to want to solve before pushing up this block — definitely before launching it to the next-gen Customizer. I think it's worth doing the hard work now so we can create a block with a more ideal menu creation process.

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jul 13, 2017

Okay, this might be terrible, but here's another menu idea:

menu block

This one takes some cues from the inserter and the existing Customizer menu patterns. The block shows an abstracted live preview, and all the editing happens in the Inspector. When you add a menu item, a menu item picker styled after the Inserter pops up.

Please note there's a bunch of stuff missing, and this is just to get some more conversation rolling. :)

@westonruter
Copy link
Member

@westonruter westonruter commented Jul 14, 2017

@melchoyce It seems a bit outside the pattern of how blocks have been implemented to have the block manipulation disconnected from the block preview. Should it not be inline? If the inspector has been deemed the area where “advanced” settings are managed, I don't think we should manage the menu items in the inspector. I think the items should be manipulated inline in the block itself. When the block is not selected, it can appear as you have mocked above. When you have selected the block, then its focused state can then turn each of the menu items into draggable elements. Maybe the UI for searching for items to add could be in the inspector, or maybe that too should be shown as a floating panel above the block.

I'm happy that we're looking at implementing the nav menu item management UI in components!

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jul 14, 2017

Yup, could totally be a bad idea. :) Trying to explore as many options as we can, since sometimes great ideas emerge from putting out as many bad ideas as we can.

Here's one that would do all the editing and adding from inside the block:

img_9355

Unselected, you'd see an abstracted live preview. When you click into the block, you'd get the menu builder. It would use the same page-insert popover as my previous idea. The inspector would only be used for settings.

@afercia
Copy link
Contributor

@afercia afercia commented Jul 14, 2017

sometimes great ideas emerge from putting out as many bad ideas as we can.

❤️

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Jul 21, 2017

This is a 🌟🌟🌟🌟🌟 ticket, and I love the way this is evolving.

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jul 23, 2017

Less sketchy:
menu block v2

@westonruter
Copy link
Member

@westonruter westonruter commented Jul 24, 2017

I like this a lot. I presume that items in the the menu item inspector could be dragged into place, in addition to being added at the end if one is simply clicked?

(Initial comment had typo “Unlike” instead of “I like”!)

@afercia
Copy link
Contributor

@afercia afercia commented Jul 24, 2017

With tabs at the bottom:

28501794-75cb46f0-6fb1-11e7-881b-952a362e1d46

keyboard users would be forced to tab through (potentially) dozens or hundreds of links before reaching the Pages | Links | Other tabs. Then, once there, they would be forced to navigate backwards through dozens or hundreds of links to go back to the search or to make their choice.

I don't think we should necessarily replicate either — I think this would be a good chance to re-examine what it looks like to build a menu

I'd totally second this 🙂 it would be great to examine in depth what the biggest flaws are in the current menu building experience (both Menus screen and Customizer) and try to simplify as much as possible.

Worth noting plugins can add their own custom post types and custom taxonomies, and then they become available as "groups"; see for example what happens with Jetpack enabled and with some existing Testimonials, Projects, and Project taxonomies:

screen shot 2017-07-24 at 08 48 48

Should all this go under the "Other" tab?

@hedgefield
Copy link

@hedgefield hedgefield commented Jul 24, 2017

Great ideas in here so far! I like both 'angles' (choosing the items from the inspector or choosing them inline, inspector style), but I was thinking what would be the most pleasant way to do this on mobile, and then I think my preference goes to the inspector, with the block being the live preview.

Something like this - borrowing mel's sketch template for a sec 🙂 :

menublock

If we're opening a menu on mobile, might as well have all the options in the same place I reckon? And then easy tap-to-select for each item. Possibly divided into multiple categories, for those custom menu items @afercia mentioned.

I like the idea of naming and saving the menu in the block, like @jwold's second mockup. We should also at least put a button in there when the menu is empty that says 'start adding items" or something, which opens/focuses the inspector.

And I like the idea of rearranging in the block itself, it feels like more of a 'presentational' edit. I'd much prefer to have true drag-n-drop for that though.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Jul 26, 2017

I really really like #1466 (comment).

To me, it feels like it really captures the spirit of blocks as I have imagined them:

  • Unselected serves as preview
  • Selected serves as option to customize
  • Advanced configuration that is non-critical to the operation, like layout, is in the block inspector

To elaborate a bit on "non-critical stuff in inspector" — examples would be changing defaults like the layout, number of posts in "Recent posts", drop cap for text. Anything that you don't actually have to adjust in order for the block itself to work. The thing is, the sidebar is dismissable.

Some questions to explore together:

  • There doesn't seem to be a quick toolbar. I think the quick toolbar will probably be where at least some layout options appear.
  • In the sketch the block is not full width, which every block is by default when inserted. It looks like it's left floated.

Maybe this type of block doesn't concern itself with layout at all, and so it comes with no options to configure it — it's just a menu, and it is subject to the layout given by the page building magic that we need to think about. It depends on what purposes this block can serve, outside of its usefulness in a page building context. Would there ever be cases where this block is nice to insert inside a post?

@westonruter
Copy link
Member

@westonruter westonruter commented Jul 28, 2017

Would there ever be cases where this block is nice to insert inside a post?

Yes. I don't see why not. It could essentially serve the needs of the curated dynamic content as proposed in #1651.

At the end of a post, for example, you might want to add a block that has cross-links to other pages, posts, and even external links that have relevant further reading. A menu block would be a great use for this.

@melchoyce melchoyce removed the Needs Dev label Apr 24, 2018
@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Apr 24, 2018

There's already a PR: #5036

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented May 9, 2018

Took another look at how we could make a more dynamic menu builder, using some of the more recent patterns established by child blocks.

Vertical menu: https://wp.invisionapp.com/d/main#/console/14236754/296207878/preview
Horizontal menu: https://wp.invisionapp.com/d/main#/console/14236754/296207970/preview

@danielbachhuber
Copy link
Member

@danielbachhuber danielbachhuber commented May 16, 2018

@melchoyce @westonruter Is this still slated for WordPress 5.0? And will this be server-side render or pure JavaScript?

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented May 17, 2018

We'd like to get a v1, server-side rendered version in for 5.0, then focus on making a pure JS one for 5.1, but we'll need someone to pick up the PR and finish it off.

That said, if anyone has time to tackle the JS one now, we might be able to get it in to 5.0. Will depend on what @mtias and @karmatosed want to do.

@mtias mtias changed the title Add Block: Custom Menu Add Block: Navigation Oct 7, 2018
@mtias
Copy link
Contributor

@mtias mtias commented Oct 7, 2018

This will be a big focus for phase 2 of Gutenberg. I'd rather not add a server side rendered here as it'd constrain the user expectations going forwards.

@aaronjorbin
Copy link
Member

@aaronjorbin aaronjorbin commented Oct 7, 2018

based on @mtias's last comment, adding the future label.

@mtias mtias added this to the Future: Phase 2 milestone Oct 12, 2018
This was referenced Dec 27, 2018
@paaljoachim
Copy link

@paaljoachim paaljoachim commented Dec 27, 2018

I have begun thinking of how a possible Menu Block could look like. Here are my thoughts...

menu-gutenberg-suggestion

Toolbar:
I added alignment options to align menu left, center or right.
Then icons for adding pages, posts, categories (taxonomies) and custom links.
Click the icons to open a modul/dialog box then click the menu items one wants to add. Rearrange the menu links as boxes (somewhat similar to the existing solution in Appearance -> Menus) inside the layout area of the nav block, by visually dragging the menu links to order them into the correct menu item relationship.

I am trying to keep most of the interaction directly inside the block layout area. As it shows right away what it looks like. It is the area with the biggest space available. The sidebar settings is a lot smaller and can easily be overlooked by many.

https://make.wordpress.org/design/2018/12/18/exploring-a-nav-block-at-wordcamp-us/

For administrating where on which page etc a specific menu is to be seen then a conditional block would help. #6866
As one would then just place the menu block inside the conditional block (perhaps even add conditional logic to the container block.)

@jwold
Copy link

@jwold jwold commented Dec 27, 2018

@paaljoachim really love the exploration here! If we could sketch out the steps someone would take to create a simple little menu, then we could build out further from there.

This wireframe is a great start!

@gravnetic
Copy link

@gravnetic gravnetic commented Jan 8, 2019

"I think this would be a good chance to re-examine what it looks like to build a menu"

Modern navigation menus are often much more than links to pages or posts.

Since it is likely that the block is a complex block some consideration should be taken to look at implementing widgets/blocks and also mega: parent > child > column options. These ideas are not edge-case at this point and there are some very well vetted examples in the wild. The ability to add blocks rather than just pages/post links would be a big leap forward! I can share some ideas I have about these options as basic block layout designs if it would be considered in the scope of this release.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Jan 9, 2019

Dig the ideas so far.

There's one aspect to this that I haven't seen deeply explored. This idea could be key to unlocking simplicity, or it could be a dud, either way it's worth exploring I feel. When I get some bandwidth, I'll take a look, but others should feel free to run with this idea also, if they get inspired:

  • The Menu block does very little. It allows you to choose the look/style (pick a variation in the block switcher), and it allows you to set a few options, like "show children", as well as picking which registred menu to show.
  • The "Pages" section becomes where most of the actual site building structure happens. This is where all actual menu management happens, and every page on your site is grouped in two categories, "Main Navigation" or "Not Linked". Pages in "Main Navigation" show up in the default menu registered by the theme, pages in "Not linked" are just pages that are not in any menu.
  • Additional menus registered by the theme will show up as additional groups here. Same with user created menus.
  • You can rearrange page sort order using the up/down movers, or drag and drop, same for making subpages.
  • You can add links or categories or other non page links to a menu using a (+) button that looks like the Block Library on open.
  • If you want the same page to show up in multiple menus, just press the (+) button and choose "Page Alias" (or "Link to page" or a better name?). The 2nd instance is a symbolic link to the first one and has a link icon to it.

Potential benefits to this approach:

  • It makes the relationship between pages and menus clear.
  • It can make it trivial to sort pages, or convert a page into a subpage.
  • It can simplify the menu block design drastically, by making menu editing happen in an obvious place to look. We can even link to this page from the actual menu block using an: "Edit your menu" link that takes you there.
  • It means we don't have to have yet another place to manage menus.

The potential downside is that it's a bit of a change to how things currently work, and will take a bit of getting used to. But this is not necesarily a fundamental flaw in the context, it just means we have to be extra careful to consider use cases that are highly tailored to the existing setup. For example we need to consider sites that have thousands of pages, and ensure a convenient management/sorting interface for those.

Thoughts?

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jan 9, 2019

I feel like we've been talking about combining menus and pages for years — maybe now it's time.

@afercia
Copy link
Contributor

@afercia afercia commented Jan 9, 2019

I'd just like to remind everyone one of the main accessibility barriers outlined in the Gutenberg accessibility report by the accessibility team is about the super difficult navigation between the content area and the sidebar.

Placing important features or editing capabilities in the sidebar is something that needs to be avoided, to not repeat the same mistakes made during phase 1 🙂

@paaljoachim
Copy link

@paaljoachim paaljoachim commented Jan 9, 2019

@gravnetic Please do share Jake. I really would like to know more of what your thinking. Perhaps include som basic sketches.

"Modern navigation menus are often much more than links to pages or posts."
This is a very good point!


@jasmussen Hey Joen. It would be great with some simple sketches to get a visual feel for what you mean.


@melchoyce
Mel's comment:
"I feel like we've been talking about combining menus and pages for years — maybe now it's time." This sounds really interesting!


@afercia
Regarding Andrea's comment.

The more options we are able to interact with direct in the layout the better. Placing things as various options in the sidebar can make it more difficult to discover. I am thinking we can look for solutions in both areas. I also do understand Andrea's point. I have heard from a few people that various options were not seen because they were in the sidebar area. Here we could also look through how the general interaction between sidebar and layout is done. How we can at the same time also focus on improving it. Sidebar actions can easily become stale. Layout actions usually are much more alive as one is interacting with the layout to accomplish a specific goal. Lets work on keeping the user in general in the layout area, and the sidebar as an area one goes on occasion when needed.

Btw Andrea's comment is something I will keep in the back of my mind.

@melchoyce
Copy link
Contributor Author

@melchoyce melchoyce commented Jan 10, 2019

Old concept from @shaunandrews:

menus-love-pages

@deckerweb
Copy link

@deckerweb deckerweb commented Jan 21, 2019

Coming from the Make Blog statement on .org, my 2 cents on the discussion:

Please keep the Menu Creation and the Nav Menu Block SEPARATE from the Pages screen.
For the "simple" reason that menus can contain any content type - Pages, Custom Post Types (e.g. WooCommerce Products), Taxonomies, whatever.

It would be unlogical to send a client to the pages screen to create a menu, plus a nav menu block. It doesn't make sense to me - and to hosts of other users, devs, and of course, clients.

@gziolo gziolo moved this from In progress to To Do in Phase 2 Jan 22, 2019
@noisysocks noisysocks added Needs Design and removed Future labels Jan 23, 2019
@noisysocks
Copy link
Member

@noisysocks noisysocks commented Jan 23, 2019

I added the Needs Design label as it doesn't yet look like we have a concrete plan on what a Navigation block will look like as part of Phase 2. Correct me if I've missed something, though! 🙂

@sarahmonster
Copy link
Member

@sarahmonster sarahmonster commented Feb 6, 2019

@melchoyce and I have spent some time exploring this in more detail this week. Since there's a a year and a half of discussion here and Github isn't great for super long threaded discussions, I'd like to reframe the conversation in a new issue, so we can approach the solutions with a shared understanding of the problem and of our framework for evaluation.

Thank you for all the valuable ideas and insights explored here! 🌟 We've built on these discussions to propose two suggested paths to a solution. Please leave your feedback on #13690!

Phase 2 automation moved this from To Do to Done Feb 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Potential blocks
List of blocks
Phase 2
  
Done
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.