#14 – Dave Smith, Isabel Brison and Joen Asmussen on the New Navigation Block

On the podcast today we have three guests… Dave Smith, Isabel Brison and Joen Asmussen.

They’re all employed by Automattic, and whilst, as you will hear, they’ve had a variety of backgrounds, most recently they’ve been working on the new Navigation Block.

Up until now WordPress menus have had their own dedicated area of the admin, but as of the most recent release of WordPress, 5.9, this has changed. If you have a block based theme you now create and edit menus in the block editor with the navigation block.

Perhaps you were very happy with the way that menus have worked until now, but on the podcast today we explore why navigation was given such a large overhaul. It’s a complete break from the past and may need some getting used to for yourself, or possibly your clients.

So why did this all happen? What was wrong with what we had until now?

These are the topics that we discuss on the podcast today. Along with:

  • What are the options available in the new UI?
  • Does the navigation block have any benefits over a dedicated menu screen?
  • Will the classic way of doing things be supported?
  • What’s on the roadmap for the future of WordPress navigation?

To get in touch with the guests on the ‘Making WordPress’ Slack:

  • Dave: @getdave
  • Isabel: @tellthemachines
  • Joen: @joen

Gutenberg support

Full Site Editing Outreach Program

Navigation Block Tracking Issue i3 #38275

Dave on WP (YouTube channel)

FSE Program Exploration – call for testing

Core Editor chat summaries

The new Navigation block entry in the WP 5.9 release notes

Navigation Block – an article explaining how the navigation block works

Transcript

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the new navigation block. Before we begin, I would encourage you to subscribe to the podcast so that you can get all the episodes automatically each and every week.

You can do that by searching for WP Tavern in your favorite podcast player, or by going to WP tavern dot com forward slash feed forward slash podcast. And you can copy and paste that URL into most podcast players too. I’d really like to hear from anyone out there who would like to come onto the podcast and talk about whatever it is that you do with WordPress.

It may be that you’re a developer, a WordCamp organizer, a contributor, a designer. Honestly, if it’s about WordPress, I’m really keen to hear from you. And hopefully get you on the show. Head over to WP tavern. dot com forward slash contact forward slash jukebox. And use the contact form there.

So, on the podcast today, we have three guests, Dave Smith, Isabel Brison and Joen Asmussen. They’re all employed by Automattic and whilst, as you will hear, they’ve had a variety of backgrounds, most recently they’ve been working on the new navigation block.

Up until now, WordPress menus have had their own dedicated area of the admin. But as of the most recent release of WordPress, 5.9, this has all changed. If you have a block-based theme, you can now create an edit menus in the block editor with the navigation block. Perhaps you were very happy with the way that menus have worked until now, but on the podcast today, we explore why navigation was given such a large overhaul.

It’s a complete break from the past and may need some getting used to by yourself, or possibly your clients. So why did all this happen? What was wrong with what we had until now? Well, these are the topics that we’re going to be discussing today. Along with: what are the options available in the new UI? Does the navigation block have any benefits over a dedicated menu screen? Will the classic way of doing things be supported. And what’s on the roadmap for the future of WordPress navigation.

If you’re interested in finding out more, you can find all the links in the show notes. Head over to WP tavern dot com forward slash podcast. And look for episode number 14. And so without further delay, I bring you, Dave Smith, Isabel Brison And Joen Asmussen.

I am joined on the podcast today by three people. I’m not sure that we’ve done this too often in the past, but three people we have with us today. We have in no particular order, Isabel Brison, Dave Smith, and Joen Asmussen. We’ll go through one at a time, perhaps if we start with Isabel and then go to Dave and then Joen toward the end, and just introduce yourselves, tell the listeners who you are, and how come you’re on the podcast today talking about navigation menus in WordPress.

[00:03:44] Isabel Brison: Hi, I’m Isabel. I am a front-end engineer at Automattic. I’m dedicated full-time to working on WordPress. That means Gutenberg most of the time. And I’ve been working on the navigation block for, oh, I don’t know. It feels like a year probably I’ve have been mostly dedicated to that. It’s an extremely complex block. That’s why it took so long to get it ready.

[00:04:10] Nathan Wrigley: Well, thank you, and Dave.

[00:04:12] Dave Smith: Yeah. Hi, I’m Dave Smith. I’m getdave on core Slack, and get underscore dave on dot org annoyingly. I’m a software developer and based in the UK. And I also work for Automattic. Been here for about three years now. Before that I worked at various digital agencies using WordPress. So I must’ve used it for about 10 years now, I guess. But I’m lucky enough now that I get to contribute full-time to the Gutenberg editor and that’s part of Automattic’s five for the future commitment.

And of course I’m principally focused on all aspects of navigation and particularly the block, which is presumably why I’m here today. I also run a YouTube channel called Dave on WordPress, where I try to provide my insights as a full-time Gutenberg developer on how to best make use of the block editor.

[00:04:56] Nathan Wrigley: Thank you very much Dave, I will make sure that the link for your YouTube channel and various other bits and pieces do make it into the show notes, but that’s very kind of you, and finally Joen.

[00:05:06] Joen Asmussen: Hello? Yes, I’m Joen. I’m a product designer in Denmark for Automattic. I have been working on the block editor project ever since the beginning and the navigation block for more than a year. It has been fun.

[00:05:19] Nathan Wrigley: Thank you very much indeed. So obviously we’ve got the panel. If we were to be talking about WordPress navigation and the future of WordPress navigation, you really are the people to be discussing it with. So just last week, we’re recording this at the very beginning of February, just last week, The way that menus are handled within WordPress got a bit of a shakeup. You’ve been thinking about it for a long, long time, but the vast majority of WordPress users probably came across it for the first time this week. I don’t know who wishes to answer this, it doesn’t really matter. You could all overtalk each other or interrupt, that’s completely fine by me. Why do we now have a navigation block and why are we no longer using the tried and trusted appearances menu section. What’s the point of that?

[00:06:05] Dave Smith: Yeah, absolutely. I’m happy to give that a go if you would like. So menu system in WordPress has obviously existed for quite some time, and we’re now calling that the classic menu system. And that’s where you go into WP admin. You go to the menu screen and you can start building out your menu from there.

But obviously with the advent of Gutenberg, and particularly with the advent of full site editing, we’re moving towards say a, sort of a more wysiwyg approach or direct editing paradigm. If you will, whereby we want to be able to create things directly in the site editor canvas. So that we have a one-to-one representation between what you see in the editor and what you see on the front of your site.

So the goal of the navigation block is really to facilitate that within the editor. So it’s part of a new way of building out menus in WordPress, and really, it gives you a lot more control over the style, but it also removes that disconnect that we felt with the menu screen perhaps. As I said, I worked in agency background previously and I worked with a lot of clients and they often struggled to understand, I’m editing this menu, this navigation in the menu screen. How is that actually going to affect what I see on the front of the site? We’re hoping that with the new navigation block, it becomes a lot easier to appreciate that, because all you do is you go into the site editor, you look for where your navigation is that you see on the front of your site, within the editor and you start making changes directly there. You hit save, and on the front of your site, you get to see exactly the same. And that’s really, really powerful. And I think that’s the principle reason why we, why we started on this project, but, Joen and Isabel might have some other insight as well.

[00:07:42] Nathan Wrigley: Yeah, feel free Joen or Isabel to give us your take on that as well please.

[00:07:46] Isabel Brison: I think on top of that, we’ve tried to create more flexibility regarding the navigation layout. Yes, it’s the visual experience of being able to edit the navigation in place, but it’s also that you can now do a lot more with that navigation in terms of positioning the elements and putting in other elements that did not fit into a classic menu, such as your site logo or a search bar, and displaying them as an overlay or not. So there’s a bunch new things that we can do with the navigation in terms of layout that are a lot more complex than we used to be able to. Or things that possibly could be done by a theme, but then they were fixed in that theme, and you wouldn’t have the opportunity to customize them.

[00:08:29] Nathan Wrigley: Thank you very much, and Joen it sounded like you had something to contribute there.

[00:08:33] Joen Asmussen: Yeah. So I think those were some great points already made. I would add that one of the aspects of the navigation block is specifically that it is a block. The idea being that with the block editor, everything is a block, widgets embeds, all of it is blocks. And so once you learn the block editor, ideally, the jump to full site editing, in some cases it just means the addition of the header and the footer in the same canvas become available using the same block interface. So ideally, less to learn because you already know how to use the block editor.

[00:09:09] Nathan Wrigley: The thing which I, well the takeaways which I have from my brief forays into using the navigation block are, number one to Dave’s point, the fact that it’s all happening on the screen is really, it’s quite interesting. It made me sort of sit up and think, okay, this is where it is now. This is new, this is interesting. I never quite found the difficulty in having a menu section. I think after a certain period of time, it kind of became instinctive. But then again, I was always playing with WordPress pretty much all day, every day. So I think Dave’s point is a really good one.

Now everything’s handled in the same place. The UI is the same. It’s easy to understand. And speaking to Isabel’s point, the fact that you can surround your navigation with whatever you choose. It’s no longer just what the theme handles. It can be anything, you know, so you could put a logo right next to it, or a button to the right of it, or anything you like. You can just surround it by other blocks if you so choose. So I can see that promise is really good. Are you happy with the implementation that you’ve got at the minute? Because obviously, there’s things which I’m sure you’ll be telling us later about roadmap features and so on. Do you feel that the jump, which people are going to have to go through on day one, so if they install a block-based theme and they’re suddenly confronted with navigation being something that’s done inside the block editor, do you feel that the UI is intuitive at the moment or are there things that you would like to have. Implemented fairly soon?

[00:10:37] Joen Asmussen: I can take a quick stab I think it’s important to look at what is available in the block today and you can import an existing menu, you can create a new one from scratch, you can swap menus, you can edit them, move these blocks around. You can collapse it into this little hamburger menu with a toggle in the sidebar, and instantly you see the effect in the canvas. You see it becomes that little menu button. You can create all these sub menus, build them visually. There are a number of styling options available. And in fact, you can accomplish some pretty complex layouts by combining this block, as you just said, with a number of other blocks. And being such a key part of full site editing it is in almost every website. The very header that makes up your primary point of interaction. It was very important to get the block out there, and I think with the experience we are shipping in 5.9, and the features it’s definitely ready to get some feedback. But I would also say that 5.9 is a great opportunity to find out some of those rough edges and figure out how to prioritize the next steps. There’s a lot of work to be done still. Some of those changes affect the block editor directly, like selecting the right block, moving it around, the right nesting level. All of these things, when fixed in the block editor itself, improved in the block editor itself, elevate the rest of the block editor UI. For example, the gallery block is also receiving nesting. So whatever we can improve there, will benefit both navigation and other nested blocks as well. So there’s definitely lots to do still, but it’s in a good place to use on your website even today, I would say.

[00:12:25] Nathan Wrigley: Thank you. Dave or Isabel.

[00:12:27] Isabel Brison: I agree with that assessment. I think it’s in a good place. And I think Joen said something very interesting here, which is, a lot of the improvements that we can make to it, our general block editor improvements. So things that will make the experience of nested blocks better. We’ll also as a consequence, make the navigation block, which is a series of nested blocks better.

I’m looking in particular to few accessibility issues. You mentioned accessibility earlier. I’d say, yeah, there are points that can be improved at the moment, particularly with keyboard accessibility, but those are overwhelmingly issues that affect the editor as a whole. So the nested blocks are complicated structures that we’re still working through in terms of usability.

So there are definitely improvements to look out for in the near future with regards to that.

[00:13:19] Nathan Wrigley: Thank you, Dave.

[00:13:21] Dave Smith: Yeah, absolutely, and all the points that’ve made so far been really accurate and really great. I think there’s also two ways of looking at this, because you can have coming to the navigation block from a classic world of WordPress and you’ve already used WordPress and it’s something you’re familiar with and you’re familiar with the menu screen. Or you can be coming to WordPress as a brand new user, you’re landed in full site editing and you experience navigation block. And I think there’s going to be two perspectives then, two different experiences. And as I said previously again, I worked for agencies and I can imagine some of the clients I used to work with. They’ve got familiar with the menu screen. They’re very happy with how it works. They’ve worked around the quirks of it, and then they are being asked to use this completely new interface. And obviously with any change like that, there’s going to be a bit of friction. There’s going to be a bit of pushback, and there’s going to be some overhead for people who’re having to teach these people how to use the new interface.

But again, the direct editing paradigm really makes things a lot easier because the overhead to learning how to use this new system is much, much lower. It is. Point and click, change things that are there and they’ll look like that on the front of the site. And that’s a really big win. And that also carries over really nicely into first-time WordPress users, because they won’t have that backstory of having used the existing menu screen. They will be probably familiar with other systems where they are more of a wysiwyg system, what you see is what you get, and that’s the acronym. And they will be familiar with something where they can just point and click and change things. And I think that really helps. So, yes, I definitely definitely agree, there are rough edges around the block. It is a V1, but we’re looking for feedback from WordPress 5.9, so if people have that feedback, they find these edge cases, all these frustrations, the best thing to do is to let us know. And yeah, we can look to address those in future releases as required.

[00:15:10] Nathan Wrigley: Dave, could I ask at this point, given that that’s the case and you are looking for feedback actively, what is the best way that people could provide that feedback?

[00:15:19] Dave Smith: Yeah, absolutely. There are a number of ways, different people might find different channels helpful. I think perhaps one of the first ones might be the Gutenberg plugin forums, which you can reach at wordpress dot org, we’ll put a link to those, and there are plenty of contributors who go into those forums and regularly check them for people who are providing feedback.

Also there’s the full site editing outreach program, which is run by Anne McCarthy. Who’s a colleague of ours at Automattic. And she often has these series of sessions where we’ll go out saying we’re going to focus down on one particular aspect. And so there might be opportunity to provide feedback. There’s also make blog posts that came out, around these topics, which you can follow up with and leave your comments there. And there’s obviously also Github as well, where you can raise issues about your frustrations. Or if you’re really, really keen, you could join us in WordPress core Slack, everyone’s a friendly bunch and, you can just drop into the channels and say, hey, I’ve got this frustration, I’ve got this feedback. And someone will pick up that, and put you in the right direction and help you to get an answer and resolve those things. Joen and Isabel, have you got any other suggestions? You probably know some more, other interesting places.

[00:16:28] Joen Asmussen: I thought that was very exhaustive. I would only echo that we are very appreciative of all these thoughts. One of the opportunities we have with listening to that feedback and the plugin model where we can land features in the plugin. Already now, if you install the plugin, you’ll see some changes based on what we’ve learned already with the first set up state for the navigation block, it’s already being tweaked in the plugin. So we can react relatively quickly, and you can see those changes in the plugin and then eventually they’ll land in the next version. So definitely don’t hold back on the feedback.

[00:17:04] Nathan Wrigley: Just for the benefit of users, when you, I think it’s probably clear to all of us what you’re describing there, when you say the plugin, just explain for the listeners who perhaps don’t know what that step involves and what it means.

[00:17:16] Joen Asmussen: Thank you, and I do apologize. So the Gutenberg plugin was the plugin project to create the block editor, way back for WordPress five point zero. And it has since become the testing ground for development. So what happens is we work in Github on the Gutenberg project to create these new features, fix these bugs. And then every, I think it’s every two weeks we land these new features in the Gutenberg plugin, so you can test them out. It’s fairly stable and we definitely push patches to make sure it’s pretty stable. It’s not going to be quite as stable as the full WordPress releases 5.9, 6.0 and so on. But it is a way to preview what’s coming next. You can activate the plugin, just search for Gutenberg in the plugins page. You can activate it, see these new things. You can deactivate it again if you like.

[00:18:10] Nathan Wrigley: That clarifies it beautifully. So the intention there is that if you want to live on the bleeding edge and be involved with seeing what’s coming with Gutenberg, and in this case the navigation block, then that is the process that you would go through and you’ll be using something which may not be mission critical ready, but we’ll certainly be a lot of fun to play with, that’s for sure.

I don’t know who wants to take this one, but working on the basis that some of the listeners by now simply will never have touched WordPress 5.9. Would one of you take on the onerous task of trying to describe the differences in the UI? So I’m meaning things like the fact that we’ve now got edits site as a menu option. The fact that the traditional area where you would go and customize things, the customizer has been removed, if you use a block based theme. And then moving on to, how do you actually get a navigation area onto the website and, what’s the process that you go through basically? I know there’s an awful lot to unpack there, but it just occurs to me that there’ll be quite a lot of people who haven’t yet tried 5.9. Maybe they have, but they’ve stuck with their old theme and they don’t wish to dabble. So we’re trying to persuade them I think that it’s not as difficult as it sounds.

[00:19:23] Joen Asmussen: I could take a quick stab because I think it could be worth it to clarify one thing right upfront. That existing WordPress themes should work just as they already do, with the existing navigation screen and all that stuff. The new navigation block would be available for the block editor, but the site editor is primarily available when you activate a block theme. For example, Twenty Twenty-Two, which is just the most beautiful theme. If you haven’t seen it yet, I definitely recommend, just take a look, try it out. It is the most wonderful thing I’ve seen in a decade. And notably, if you are a WordPress developer, do download that theme, unpack the zip, take a look at the structure and see how it’s built. It is something else, makes me very excited about the future of theme development.

You can also mix and match between block themes and let’s call it classic themes, towards these hybrid themes. So you can, sort of, gradually opt to these new paradigms. But assuming you activate Twenty Twenty-Two today on a fresh install and you want to see all the new stuff, you go into appearance, you have this edit site button which lets you see the whole of Twenty Twenty-Two. Header and footer and the loop in the middle. With everything being blocks, you can click everything and edit it right there. It should be pre-populated because it comes with these templates, it already includes a header. It already includes a place for your navigation. So ideally the experience is that you activate this theme, you click the navigation block and then you, you start the flow, either create a new menu from scratch or import an existing

[00:21:07] Dave Smith: Great points that Joen’s made that. One of the key things, if you’re more of a developer mindset as well, is that we’ve moved away from a lot of the theme chrome as you might say. So that things like the header, the footer, the sidebar, instead of those being controlled via PHP templates in the theme, they’re now controlled via the site editor, with this again, direct manipulation paradigm, which I keep going on about, but it’s so critical to how full site editing editing works.

And so you can just go in and previously you’d have to, as a user, if you want to change, I don’t know, let’s say something like, you’ve got a list of posts and you’ve got an avatar picture of yourself, next to each one of those posts. You say, oh, actually, do you know what? I want to move my avatar over to the right hand side.

Now in classic WordPress, the only way you could do that is either you’d have to dig into the template files and understand a bit of PHP and HTML and move that and possibly, change some CSS styling as well. But with full site editing, what you can do is just go straight into the loop, like Joen’s mentioned, click on the avatar, the author, avatar and manipulate it however you’d like with the controls that the editor provides you. Now, of course you may not have all the controls you want from the get go, especially with 5.9. But the goal is that you can just do that directly and you don’t have to go then to your developer or your technical person to get that done.

And I think it’s like really democratizing design. We talk about this a lot of time in WordPress, democratizing publishing, but this is like democratizing the design of themes and of your site and giving users power. I hear a lot of, this is a scary thing to a lot of people, and I get that. I come, as I said, from an agency background and I’d be thinking, goodness, me, I don’t want to give my clients too much control, lest they do something to their site that would be less than desirable. But, I think we give the controls to be able to lock a lot of these features down and those will only improve.

But the key thing is that if you’re someone who just wants to start a website and you don’t have the technical expertise, you can do so much more now with full site editing, than you could ever do with classic themes without having to have that technical knowledge. And I think that’s a key thing.

[00:23:18] Nathan Wrigley: Yeah, that’s a nice answer. Isabel, anything to add there?

[00:23:21] Isabel Brison: Yeah, to add specifically to the issue of it being scary that people have all these power. That won’t necessarily happen. It depends also on how the theme is structured. So you can implement controls in the theme to limit the amount of editability of the various site areas.

So that’s something that would potentially also be very convenient for agencies to use. It makes it a little bit less scary.

[00:23:47] Nathan Wrigley: Yeah. Good point. The way that you would interact with it then is you have a block. The best way to describe it really would be to go and install Twenty Twenty-Two and as Joen said, click on the navigation block, perhaps open up the list view. In fact, I would say, open up the list view first and you’ll be able to see the stack of things that may or may not be contained within the navigation. So for example there may be sub-pages that you’ve listed depending on how the menu is structured. And so let’s get into what the sort of features are that you can have inside of the navigation block.

If we click on the navigation block itself, we’re presented with some features in the menu on the right, some styling options and so on. So tell us what’s there at the moment. What can we configure? What can we change? Whoever wishes to take that.

[00:24:34] Isabel Brison: One thing I think it’s very important to keep in mind when we start working with the navigation block is, we create the block and let’s say we add a bunch of pages to it, links maybe a few social icons, whatever we want inside it. And then the block is saved and the contents of that block are going to be reusable in others. So I can have exactly the same navigation in two different templates. I can have it on my header and then again on my footer, and the changes that I make to the content of the navigation are going to be reflected in all the places that it’s used. But in terms of the presentation, that will be specific to the place where the navigation is.

So we have this difference between what the content is, so the links that make up the navigation, and then the presentational aspects that will be specific to wherever. So in the navigation being used in the header, it might have a background color. It might be set to be a hamburger menu on desktop and mobile.

And then the very same navigation being reused in the footer might have no background color. It might be set to always show all the links, and not turn into a hamburger at any point. So there’s this distinction that’s important to make between the presentation.

There’s a lot you can change, well you can change the colors. You can change the layout, you can move it to align on left on the right or the center. If you have sub menus, you can configure those sub menus to open on hover or on click. As I mentioned, Joen also mentioned the hamburger menu. You can make it display as a hamburger menu on mobile or all the time or never. There are topography settings, padding settings. That’s probably the lot. I’m not sure if I’m forgetting something here.

[00:26:27] Nathan Wrigley: I think that’s right, certainly from what I’m looking at at the moment that it appears that you’ve covered everything, unless one of the other two of you have got something that we’ve missed.

[00:26:36] Dave Smith: It is difficult to describe the UI, isn’t it? I think there’s a pretty good developer, not developer doc, a user facing doc for the block as well. And that was put together by Anne McCarthy. Again, that goes over a lot of these options. If people want to read that afterwards as well, and that’s kind of helpful.

[00:26:49] Nathan Wrigley: Joen?

[00:26:50] Joen Asmussen: Yeah, I would just add that it’s worth noting that these are the user-facing controls where you can configure and tweak and adjust in that way. There are some additional controls that aren’t yet surfaced to the user. We have this system called global styles, which ultimately is this reflection of properties in the theme dot json file.

And you can target specific sub blocks and add padding to those, and change these right in the code. The idea being that these properties would be reflected in the UI as well, at least as a rule of thumb. Some of those are on the to-do list. Some of them are already there, like Isabel mentioned fonts, colors, and line height, all that stuff.

And of course, ultimately we’re making markup here, and you could style things in CSS if that is your preference, provide some defaults in that way.

[00:27:45] Nathan Wrigley: It might be a good idea to draw some comparisons with current themes. It seems like a lot of theme developers have really made things like menus and navigation and headers and footers make them a real feature of their work, and I can think of some, dot org themes as well as commercially available themes where the menus, the customization options that are there, are truly remarkable, you know, within the customizer, you can change more or less everything. You could have a logo that center aligned and you could have different fonts and hover effects and all of that kind of stuff. And it’s all available there in a sort of point click interface. I’m just wondering if there are things that, well any comparisons to be made? Are there any things that you are hoping to achieve in the near future that might bring some parity to those edge cases? Or is it very much going to be that WordPress is sticking with, here it is, it’s a menu, you can figure out how to do the styling yourself. You can learn a bit of CSS and what have you. I don’t know if it’s all going to be point click or if there’s going to be some sort of technical requirement to make them super individual

[00:28:47] Joen Asmussen: I can take a stab. I think the key feature of the navigation block. I apologize if I’m repeating myself, is that it is a block, which means you can insert it in patterns as well. A block pattern is a configuration, an already made configuration of a bunch of blocks. You click the blue plus button at the top left corner. You click patterns and you can insert this shortcut to a layout. Twenty Twenty-Two comes with a number of these header patterns pre-made, and they’re all completely beautiful. So you can browse those and you can insert this header that has maybe a circular logo and a tagline than the navigation below. Or you could find one that has the logo on the left, and the navigation collapsed into the hamburger on the right. And you can just insert one of those. And the entire layout is pre-made and pre inserted, wherever you like. And I think that is one of the key benefits of it being a block, that every single benefit, every single feature we add to the block itself will benefit the navigation block as well in the future. Any global style changes, any new features to fonts, font weights, or paddings, margin, spacing, gap colors, nested changes. All of those will benefit across all of blocks, rather than just for this one piece of software called the navigation block.

[00:30:18] Nathan Wrigley: Yeah, I think you made a really good point at the start and maybe it’s something that we haven’t really dwelled on enough, is that it is a block, so it can go anywhere. So, you know, should you wish to have a page full of navigation menus, you could do that. I don’t know why you would wish to do that, but you could. Whereas in the past that would be probably out of bounds, for the expertise level of most people. They would just be happy with what came along with the theme.

And there it is right at the top usually, and probably something in the footer. But you could create, I don’t know, a layout where there were menus in sidebars of different types and menus all over the place. And that’s the point. It can be surrounded. You can put things in front of it, behind it, above it, below it, whatever you want. And maybe we haven’t made that point strongly enough.

[00:31:00] Dave Smith: It’s a really, really good point? And it also comes back to, you know, getting back to your question it’s like, what can you achieve with a block versus what could you achieve with a classic menus system? And I think if we compare sort of a classic theme experience with a block theme experience. With the classic theme, if you want to style your navigation, your menu, all the control is really requires quite a lot of technical expertise, whether that be CSS styling, or changing the layout in terms of the ordering of things or where the actual navigation is placed. I mean, you might not want it in the header, you might want it below the logo or et cetera. And for that, you would need a developer. Contrast that to block themes, and as Joen says, it’s a block. So you can put your navigation wherever you like. It’s really opened up that power. And again, with styling, you’ve got all the power that the block provides, and that is actually quite a lot.

And I think that the barrier to entry for customizing your navigation has gone down considerably. Obviously with classic WordPress and all WordPress, you can install plugins and there will always be extenders that create these amazing systems that allow you to modify your menus. But I think there’s also opportunities for that with the block editor, and I’m sure that we’re going to see the extender community building on top of the block and creating really exciting, really, really powerful things. Perhaps sort of mega menu builders and things like this will come.

I’m excited to see what happens and what comes down the line. Also if we’re talking about some limitations of the block at the moment, specifically things that I’m aware of are the ability to style interaction states. And by that, what I mean is, imagine when you’re hovering over your navigation. Sometimes you see the style of the item you’re hovering over change, when you roll over it with your mouse or when you select it, focus it with your keyboard. And that’s not something you can do currently. You can’t change the style of that within the editor. So that’s one thing, and also like spacing and padding control for the menu items themselves. I don’t believe we can do that at this current time, but they’re all things that are on the roadmap and they’re looking to be addressed in future releases of WordPress.

And of course, there are always going to be certain advanced customization things that are always going to require CSS, and you can still do that. So if you need something really specific, really custom, you can still ask your technical person or you can jump in to learn CSS yourself, and that’s a great way to do it.

[00:33:13] Nathan Wrigley: Thank you. Isabel?

[00:33:15] Isabel Brison: Yeah. Well in terms of limitations or things that we have on our roadmap, rather like add-ons, I guess. A very interesting challenge will be mega menus, creating more complex drop downs, and that will be a challenge partly for semantic reasons because we had a lot of work in trying to keep a semantic structure for the navigation, with all the different types of blocks that can fit in there.

And mega menus will present the furthest step in that challenge. Which will be great to work on. And the other thing that I think would be good to see is the ability for extenders to add child locks to the nav. So say someone has, I don’t know, an e-commerce plugin, there’s sort of a products block that currently the nav only takes a very limited set of blocks that are hard-coded. And so one of the things that we will work on in the future is to make it possible for other blocks to be added. If a plugin has specific blocks that might suit the nav.

[00:34:15] Nathan Wrigley: Turning attention towards accessibility. Probably reasonably briefly, but nevertheless an important part of any menu structure, the ability for people with different capabilities or different ways that they’re interacting with the internet. Has a lot of thought gone into that? Was that a particular challenge? Have you endeavored to make this as easy to use for everybody as possible?

[00:34:37] Isabel Brison: Yes. A lot of thought went into them. Well, yeah. a lot of thought went into the front end and that was why I mentioned the semantics earlier. We had to get it right for the structure of the navigation to make sense. When you’re navigating the page with various assistive technology, In terms of the interface itself for those who are editing a navigation block. Yes, but there’s always things that we can improve. So we’ve done a fair bit of work in that sense, but not specific as I think I mentioned earlier, there are not a lot of challenges that are specific to the navigation block in that area. There might be one or another issue, I think there might be a couple of issues, small things such as a button that’s specific to the block toolbar that’s not putting focus in the right place when it closes whatever. I mean 99% of accessibility issues that we have flagged for the navigation block that we have opened on our repo are issues that are transversal to other blocks.

[00:35:38] Dave Smith: Yeah, I definitely agree with that. I was putting together the new tracking issue for the navigation block, post 5.9. And if anyone is interested that’s 3 8 2 7 5 in Github. As part of that, one of the things that we want to focus on, was the accessibility and just put that of front and center from the start. A high priority item as we move forward with future releases, just keeping that like right there. So we’re not losing sight of that, and it’s really, really important and we continue to work with the WordPress accessibility to community on it.

[00:36:07] Nathan Wrigley: Joen?

[00:36:08] Joen Asmussen: Yes, I would add also that one of the best features of the navigation block, yet another reason why it took a while to get right. Isabel mentions the semantics, but the thing is when you use the navigation block, what is output all the front end, whether it is sub menus or even just the basic menu, or even the overlay is all fully accessible and you don’t have to worry about that aspect on its own. For example, by default the menu, you tab through it and menu items open on hover and sort of the classic menu default way for WordPress. But you can change that so that sub menus open on click instead. There’s even some details around how that little triangle dropdown for sub menus has a separate focus item. So you could focus the parent menu item, go to that or focus the sub menu toggle to open the sub menu. There’s a great deal of nuance to how you navigate through a menu. And the hamburger opens a proper modal that you have to close with escape and it traps the tab inside until you’re done.

So there’s a great deal of energy already put into making sure that your website will be accessible when you use the navigation block. There’s always going to be additional work to do. Work is never over, but, there’s quite a lot of stuff already there which simply will improve and be there for any block theme that uses this block without the theme developer having to implement this accessibility themselves.

[00:37:49] Nathan Wrigley: The three of you, we never really established this at the beginning, is the navigation block, is this your primary focus of your time when you punch the card at the beginning of the day and then knock off at the end of the day? Is navigation where you mostly spend your time?

[00:38:05] Isabel Brison: Well, it has been for me for most of a year, on and off, there were a couple of other projects that I worked on for little bit, but I’ve been mostly, I can say mostly working on navigation to the best parts of the year.

[00:38:19] Dave Smith: Yeah, same here. I mean I’m every day, the first thing I’m doing is catching up with the navigation block. Earlier on in the year, prior to 5.9, I was quite heavily focused on the navigation editor project to which you might come to later. But, certainly all this run up to 5.9 has been very much navigation, navigation, navigation block.

[00:38:37] Joen Asmussen: Yeah, same here. I would add also that, as we mentioned, there are a lot of block editor specific issues that are surfaced due to the navigation block. Issues we encounter, but which need to be fixed for the block interface as a whole. Nathan, you appreciated the persistent list view.

One of the reasons for that to become this tool, this left sidebar that lets you drag and drop, move, delete blocks right there. That came also from the realization that the nested structure of menus, especially with multiple sub menus, was easier to get an overview of in that interface.

[00:39:13] Nathan Wrigley: It was actually quite a realization to me when I saw it in the list view. I made it so that the pages were listed out and it was quite fascinating to see the list of pages in the menus, in the list view. I confess I hadn’t expected that. There it was, it was real easy for me to see what my menu structure looked like without having to dig into a further interface. It was really nice.

[00:39:34] Dave Smith: And you can modify it as well, in place, within this list view up and down drag and drop. A lot of work went into

[00:39:40] Nathan Wrigley: Okay. A couple of things just before we round out. Yeah, you mentioned Dave, the navigation editor project, which my understanding is it’s now stalled. Do you want to just describe a little bit around that? What was that endeavor and why has it been mothballed?

[00:39:53] Dave Smith: I think the first thing to say is that, I definitely don’t think the project is mothballed, and stalled might even be a step too far. It’s definitely on a moment of reflection and pause at the moment. it’s a topic of conversation within the contributor community around navigation.

One of the other things to say is that the navigation editor is not in 5.9 and there’s been some confusion around that, but it is not the menu screen remains for classic themes. And the navigation editor is not there. The original project was actually basically to a replace the classic menu screen in WordPress.

That scope of that project was very ambitious. It’s easy to say that with hindsight, but it never really managed to make it out of the experimental state, even in the Gutenberg plugin. I think part of the reason for that is that the scope called for the ability to edit both classic and block-based menus within the same interface and save them back to their original format so that you could switch back to a classic theme and still have your menu in place, even though you’ve edited it in a different interface.

And that is a big, big challenge. And the main reason for that, even though it was achieved and testament to the people who worked on it, but before me, it was pretty much there when I started working on that. it was very, very difficult for backwards compatibility reasons, and it quickly became clear that the scope was very, very large of what we had to achieve.

And then they’d run up to 5.9, there were some, a realignment of the direction on the nav block and specifically the creation of this ability to reuse menus, which required the creation of a custom post type, where the items or the menu were saved too. And that was a big impact on the editor. And basically it was determined that we need to sort of reprioritize the available contributor resources towards the block.

I’m glad we did so, because I think it allowed us to really focus down on the block rather than perhaps managed to not land either. But, going forward, I think we need to look really, really carefully at the use cases and the requirements and the scope of this project. The first thing is, is there a use case for a standalone editor for editing menus and WordPress?

Now the anecdotal feedback I’ve got so far from 5.9 is that, that seems to be a case for that. Specifically around block-based menus and the system we’ve just been talking about. There was no way to edit your menu outside of a navigation block itself. And that might sound good because, you know, I said direct editing is good, right? But, the problem is we have no safe space to create and explore and edit our navigations outside of the canvas of the post or the site editor. A good example of why that might be necessary is if you had a e-commerce site, you had your primary navigation, and then on black Friday month, your client comes to you and says, I need to use a different navigation for black Friday. Can you get it ready for me? And at that point, you’re in a really difficult use case where you can’t really change your things in your site editor and change your nav because then it would go live immediately. The workflows become pretty, pretty hacky. So there’s a good case there for an isolated editor to be able to edit these block based menus.

I will say this is my opinion, this is just a caveat that, but I think it’s unlikely that we’ll see the nav editor revived in nt current form and current scope because I’m not convinced there is a case to save back to the classic menu format at this point. I think we need to be really careful about taking it really slowly. Looking for actual user use cases and doing things in phases, perhaps starting with this focused navigation editor mode. And in fact, that’s something that Matias Ventura, the lead architect of the Gutenberg project outlined in his sort of what’s next for the 6.0 release post and this focusing editor mode for navigation would be the first step, and then in the future, perhaps we introduce the ability to import your classic menus, manage them there. But, that needs to be based on actual feedback. I think we should listen to the community about it.

[00:43:27] Nathan Wrigley: Do you know, that’s really interesting, and it hadn’t occurred to me that your example of a, let’s say, black Friday menu, that the fact that it’s not done in the same interface could potentially cause problems. That’s really fascinating. Do you think there’ll be a time where theme developers are only able to use the block. I know that’s a bit of blue sky thinking and, at some point WordPress has to marshal its resources in, in one way or another. You can’t support everything forever. Much like we would like to. Is there any discussions around that? Whether the development will sort of stop on the pre 5.9 way of doing menus, or is it always going to be updated in perpetuity?

[00:44:09] Dave Smith: Well, I don’t know if Joen or Isabel have got any insights into that, but my gut instinct to that would be, I can’t really imagine a situation where we’re going to cut off support for the previous menu screen, just because of the backwards compatibility contract that WordPress has with its users.

But that’s not to say, will there be continuing level of effort put into that screen as there was previously? Perhaps not because perhaps, you know, the world of WordPress moves forward with blocks, perhaps it doesn’t. But if it does then, you know, we’re probably going to see less and less features added to the classic menu screen and more effort put into extending the abilities of the block and any future isolated editor mode.

I’d be interested to hear what Joen and Isabel think.

[00:44:46] Joen Asmussen: I can only mainly echo your excellent insights already shared. I think one of the benefits of WordPress and open source also sometimes to its detriment is that it has this giant legacy that it’s supporting. It’s worth noting that this existing navigation screen, it still exists. You activate your classic theme and the navigation is there. I imagine so long as there are users that do that, it will be possible in some form or other. That’s just my personal thoughts based on how WordPress has always worked. I imagine it will be there for a long time.

[00:45:23] Nathan Wrigley: Isabel?

[00:45:24] Isabel Brison: That’s it really, I mean, things in WordPress tend to linger for a long time because we’re big on backwards compatibility. And while there are classic themes, the menus interface will continue to exist, because that’s what classic themes use. There probably won’t be a lot of new features developed for it. It’ll just be low key maintained in the background as it were. So I don’t think it’s going anywhere anytime soon.

[00:45:50] Nathan Wrigley: For the novice learner of WordPress, I can imagine that fork in the road is going to be, it’s going to be interesting, shall we say, because there’s probably a million YouTube demonstrations of how to make menus work in WordPress, and they’ll be now millions more about how to do it in an alternative way. And so a quick Google search of how do I structure my WordPress menus could well lead people down a very frustrating path I imagine it doesn’t even look like that. I don’t understand.

[00:46:18] Joen Asmussen: I think WordPress 5.9 is really an opportunity to try full site editing as it exists and then provide a great deal of feedback. And then WordPress 6.0, could be an interesting evolution and reaction to that feedback. So I would just echo that whatever feedback you have, it’s something we can act on and learn from.

[00:46:42] Dave Smith: I had a bit of a point about the theme switching process. I’m not sure we touched on that much, but, there’ll be I’d imagine sizeable majority of your users who are on currently on the classic theme, they’ve probably got a menu in that theme, and they’re going to be thinking of, so what’s the process when I come to switch to this block theme, what happens? And as I think Isabel mentioned earlier that, you know, the menus are reusable so they are saved. So the good thing about it is that when you switched to your block theme for 2022, and you go to the editor page and you click on your navigation block, the initial experience is probably going to see a lot of pages there, but what you can do is switch and select a different menu, and you can actually select your classic menu from your classic theme, and use that immediately within the block theme. So there’s none of this, oh I have to recreate my menu from scratch.

You know, all of that overhead. All you have to do is just select that menu from under the classic menus section and it will immediately appear. I think that’s a really powerful thing. And again, if you switch from a block theme to another block theme, the same process. You can select the menu created in theme A and use that in theme B, even though there’s completely different styling and that’s really, really powerful,

Should also mention that if you do import a classic menu then it is a import. It is a copy. And your original classic menus is retained as was. This is perfect if you want to just experiment with full site editing, because what you can do is, you know, spin up a local copy of your site or a staging site. You can switch on to Twenty Twenty-Two, import your classic menu. Have a play around with that, see what you can achieve and then when you’re finished or if you don’t like it, you can switch back to your old theme and your classic menu will be still there as was, no changes at all. So that’s really confidence inspiring, I think these sort of flows allow people to just dip their toe in the water, so to speak.

[00:48:23] Nathan Wrigley: Yeah, that’s a really good point because every interaction that I’ve had with 5.9 so far has been basically on a vanilla site. I hadn’t really thought about the consequences of going to a block-based theme on a site which was already in existence with potentially lots and lots of complexity inside the menu. So well made. Thank you. And Isabel.

[00:48:42] Isabel Brison: I’d just add to what Dave was saying. If you are using a classic theme and you’re really curious about the navigation block and how it works, you can always make an experiment of adding a navigation block to a regular post because it’ll work in the post editor and just play around with it and see what you think. And by all means, do please give us feedback.

[00:49:02] Nathan Wrigley: I will make sure that all of the things that we mentioned at the top of the podcast, ways to get in touch are listed as show notes. So please, if you are curious about this, go and have a play WordPress 5.9. See what you think. Play with the navigation block. These good folk will be very, very keen to hear whatever feedback you have, and go and check out the show notes on the podcast episode, and you can get in touch with them and let them know your thoughts. So thank you for joining us today. Dave Smith, Isabel Brison and Joen Asmussen. Thank you very much for joining me today.

[00:49:33] Isabel Brison: Thank you for hosting us.

[00:49:35] Dave Smith: It’s great to be here.

10 Creative Hamburger Menus + Tips & Tricks

When browsing through websites, you’ve most likely come across three horizontal lines on the top right corner of the webpage. While not present on every site, these lines are commonly referred to as “hamburger menus” by UI designers.

What is a Hamburger Menu?

A hamburger menu is a navigation tool that opens up to a side menu and is used for both mobile apps and websites. The role of these navigation bars is to help you easily maneuver anywhere on a website in a user-friendly manner and without having to scroll up to hunt for navigation.

Hamburger menus were first introduced more than three decades ago by a man named Norm Cox. He made the burger icon for Xerox Star, which was the world’s first graphical user interface. The purpose of the triple bar icon was to let users know that the button contained a list of items. However, despite it being around for quite some time, it wasn’t widely used until 2009 and has gotten a lot of criticism over the years.

The UX Designer Toolbox

Unlimited Downloads: 500,000+ Wireframe & UX Templates, UI Kits & Design Assets
Starting at only $16.50 per month!


 

Pros and Cons of Hamburger Menus

Before we get into the examples, let’s first explore the pros and cons of using hamburger menus.

Pros

  • It provides quick secondary access: Users can quickly access desired pages without having to scroll through pages.
  • Recognized by many users worldwide: The sign is common and can be found everywhere from mobile games to web pages to apps.
  • Makes the webpage appear organized: The hamburger menu helps with maintaining focus on the important web features you’d like users to see. It also keeps the web page clean.

Cons

  • Lower engagement: When users can’t easily access a web page, they’re less likely to click on it.
  • Makes pages seem less important: Because all the important information is accessed on the first page it’s less likely for users to navigate through the menu.
  • Hard to reach: Hamburger menus can be hard to reach or press in some mobile designs.

Tips for Making a Good Hamburger Menu

Here are a few quick tips for ensuring your hamburger menu is identifiable and effective:

1. Use Animation

A hamburger menu without an animation that turns the three horizontal lines into another shape is rarely seen. Put it to good use.

2. Use a Custom Icon

It’s important that the menu remains recognizable to ensure a great user experience. Using a custom icon helps many users identify it.

3. Responsiveness

Mobile users prefer the vertical sliding or the horizontal navigation bar while computer users prefer a more detailed menu with tabs of content, rows, and vertical links. Designing your hamburger menus to be responsive will ensure users are presented with the ideal menu option regardless of the device they’re using.

10 Worthy Examples of Hamburger Menus

What follows are 10 high-quality options of hamburger menus currently available on Codepen to choose from. Why start from scratch when you don’t have to?

Menu Toggle by Tamino Martinius

See the Pen
🍔 <-> ❌ (version 1)
by Tamino Martinius (@Zaku)
on CodePen.light

Drawn Hamburger Transition by Jesse Couch

See the Pen
Drawn Hamburger Transition
by Jesse Couch (@designcouch)
on CodePen.light

Hamburger Menu with Cheese by Michael Smart

See the Pen
Hamburger Menu (with cheese)
by Michael Smart (@mikedevelops)
on CodePen.light

Atomic Menu by Alex Coven

See the Pen
Atomic Hamburger Menu CSS
by Alex Coven (@alcoven)
on CodePen.light

Pure CSS Fullscreen Navigation Menu by Brenden Palmer

See the Pen
Pure CSS Fullscreen Navigation Menu
by Brenden Palmer (@brenden)
on CodePen.light

Animated Hamburger by Steven Fabre

See the Pen
Hamburger Animated Icon
by Steven Fabre (@stevenfabre)
on CodePen.light

Open Close by Vineeth TR

See the Pen
Open Close
by Vineeth.TR (@vineethtrv)
on CodePen.light

Morphing Hamburger by Sergio

See the Pen
Hamburger icon with Morphing Menu
by Sergio Andrade (@sergioandrade)
on CodePen.light

Animated Hamburger Menu by Mathew Ladner

See the Pen
Animated Hamburger Menu
by Matthew Ladner (@netfuel)
on CodePen.light

CSS3 Only Hamburger by David Krajewski

See the Pen
Hamburger Icon CSS3 ONLY Animation
by Dawid Krajewski (@DawidKrajewski)
on CodePen.light

Hamburger Menu Alternatives to Consider

If hamburger menus aren’t speaking to you, there are some alternative options worth taking a look at.

1. Scrollable Navigation

This type of navigation tool is normally used for longer lists. Making the list scrollable allows users to easily move side-to-side. For example, it’s mostly used for news websites when users are expected to scroll through news categories, and also works well for online stores and music apps.

2. Tab Bar

Tab bars are considered to be the simplest navigation option with the main navigation options easily visible. For example, if you have an app that has a limited number of web pages/features then this is definitely the way to go.

Some things to consider with this navigation include:

  • The home page has to be in the first tab and the rest should follow according to the level of importance.
  • The tab bar allows no more than five navigation options.
  • It’s important for at least one of the options to be highlighted and active.
  • Use icons with labels unless for actions that are common and easily recognizable.

3. More Option Tab Bar

The ‘more’ option tab bar is most suitable if you have more than five top-level destinations.

The extra option can work well as a dropdown menu. To improve navigation you’ll need to correctly prioritize the options for users to have at least four to five on the screen at all times.

4. The Progressively Collapsing Menu

This type of menu fits on the whole screen and shows as much of the navigation as possible. Everything else is put under the “More” button. This provides a better user experience than the tab bar design.

5. Full Screen Navigation

The full screen navigation solution takes up the whole homepage for navigation purposes. Users then swipe to access additional menu options as they scroll up or down.

This type of navigation helps designers organize huge amounts of information without overwhelming the user.

Conclusion

When picking out a hamburger menu, make sure you pick one that’s most suitable for your website or app. Making navigation within an app seamless and user-friendly will encourage users to engage with it more than once and even attract new users. Just make sure you test the speed and efficiency before implementing. But then you should be good to set your visitors browsing. Good luck!

How to Create Actions for Selected Text With the Selection API

Click, drag, release: you’ve just selected some text on a webpage — probably to copy and paste it somewhere or to share it. Wouldn’t it be cool if selecting that text revealed some options that make those tasks easier? That’s what a selection menu does.

You may already be familiar with selection menus if you’ve ever used an online editor. When you select text, options to format the selection might float above it. In fact, I’m writing this draft in an editor that does exactly this.

Let’s see how we can create a selection menu like this using JavaScript’s Selection API. The API gives us access to the space and content of the selected area on a webpage. This way we can place the selection menu exactly above the selected text and get access to the selected text itself.

Here’s an HTML snippet with some sample text:

<article>
  <h1>Select over the text below</h1> 
  <p>Cascading Style Sheets (CSS) is a style sheet language used for describing the presentation of a document written in a markup language such as HTML. CSS is a cornerstone technology of the World Wide Web, alongside HTML and JavaScript. CSS is designed to enable the separation of presentation and content, including layout, colors, and fonts. This separation can improve content accessibility, provide more flexibility and control in the specification of presentation characteristics. </p>
</article>
<template><span id="control"></span></template>

There’s a <template> tag at the end there. The <span> inside it is our selection menu control. Anything inside a <template> tag is not rendered on the page until it’s later added to the page with JavaScript. We’ll add the selection menu control to the page when user selects text. And when the user selects that text, our selection menu will prompt the user to tweet it.

Here’s the CSS to style it:

#control {
    background-image: url("data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 width='40px' height='40px'><foreignObject width='40px' height='40px'><div xmlns='http://www.w3.org/1999/xhtml' style='width:40px;height:40px;line-height:40px;text-align:center;color:transparent;text-shadow: 0 0 yellow, 2px 4px black, -1px -1px black;font-size:35px;'>💬</div></foreignObject></svg>");
  cursor: pointer;
  position: absolute;
  width: 40px;
  height: 40px;
}
#control::before{
  background-color: black;
  color: white;
  content: " tweet this! ";
  display: block;
  font-weight: bold;
  margin-left: 37px;
  margin-top: 6px;
  padding: 2px;
  width: max-content;
  height: 20px;
}

Check out this article to learn how I used an emoji (💬) for the background image.

So far, the sample text is ready, and the selection menu control has been styled. Let’s move on to the JavaScript. When a selection is made, we’ll get the size and position of the selected area on the page. We then use those measurements to assign the position of the selection menu control at the top-middle of the selected area.

var control = document.importNode(document.querySelector('template').content, true).childNodes[0];
document.querySelector('p').onpointerup = () => {
  let selection = document.getSelection(), text = selection.toString();
  if (text !== "") {
    let rect = selection.getRangeAt(0).getBoundingClientRect();
    control.style.top = `calc(${rect.top}px - 48px)`;
    control.style.left = `calc(${rect.left}px + calc(${rect.width}px / 2) - 40px)`;
    control['text']= text; 
    document.body.appendChild(control);
  }
}

In this code, we first get a copy of the selection menu control inside <template>, then assign it to the control variable.

Next, we write the handler function for the onpointerup event of the element carrying the sample text. Inside the function, we get the selection and the selected string using document.getSelection(). If the selected string is not empty, then we get the selected area’s size and position, via getBoundingClientRect(), and place it in the rect variable.

Using rect, we calculate and assign the top and left positions of the control. This way, the selection menu control is placed a little above the selected area and centered horizontally. We’re also assigning the selected string to a user-defined property of control. This will later be used to share the text.

And, finally, we add control to the webpage using appendChild(). At this point, if we select some of the sample text on the page, the selection menu control will appear on the screen.

Now we get to code what happens when the selection menu control is clicked. In other words, we’re going to make it so that the text is tweeted when the prompt is clicked.

control.addEventListener('pointerdown', oncontroldown, true);

function oncontroldown(event) {
  window.open(`https://twitter.com/intent/tweet?text=${this.text}`)
  this.remove();
  document.getSelection().removeAllRanges();
  event.stopPropagation();
}

When the control is clicked, a tab opens with Twitter’s “New Tweet” page, complete with the selected text ready to go.

After the tweet prompt, the selection menu control is no longer needed and is removed, along with any selection made on the page. The way that the pointerdown event cascades further down the DOM tree is also stopped at this point.

We also need an event handler for the onpointerdown event of the page:

document.onpointerdown = ()=> {    
  let control = document.querySelector('#control');
  if (control !== null) {control.remove();document.getSelection().removeAllRanges();}
}

Now the control and any selection made on the page are removed when clicking anywhere on the page but the selection menu control.

Demo

Here’s a more prettified version that Chris put together:

And here’s an example showing more than one control in the selection menu:

About that <template>

It’s not totally necessary that we use it. Instead, you can also try simply hiding and showing the control some other way, like the hidden HTML attribute or the CSS display. You can also build a selection menu control in the JavaScript itself. The coding choices will depend on how efficiently you execute them, and their fallbacks, if needed, as well as how they fit in with your application.

Some UI/UX advice

While this is a nice effect, there are a couple of things to consider when using it to ensure a good user experience. For example, avoid injecting your own text into the text selection — you know, like appending a link back to your site in the auto-generated tweet. It’s intrusive and annoying. If there’s any reason to do that, like adding the source citation, let the user see a preview of the final text before posting it. Otherwise, the user might be confused or surprised by the addition.

One more thing: It’s best if the menu control is out of the way. We don’t want it covering up too much of the surrounding content. That sort of thing adds up to CSS “data loss” and we want to avoid that.

Bottom line: Understand why your users need to select text on your website and add the controls in a way that gets out of the way of what they’re trying to do.


The post How to Create Actions for Selected Text With the Selection API appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

In Praise of the Unambiguous Click Menu

I still remember my excitement when I learned how to build a hover-triggered submenu with just CSS. (It was probably after reading this 2003 article from A List Apart.) At the time, it was a true CSS trick. Seriously. Wild times.

That went a little something like this:

<ul class="my-menu">
  <li>
    <a href="page-a.html">Page A</a>
    <ul>
      <li><a href="page-b.html">Page B</a></li>
      <li><a href="page-c.html">Page C</a></li>
      <li><a href="page-d.html">Page D</a></li>
    </ul>
  </li>
  <!-- etc... -->
</ul>
/* Position submenus relative to parent list item */
.my-menu li {
  position: relative;
}

.my-menu ul {
  /* Hide my submenus by default */
  display: none;
  /* Position submenus, when open */
  position: absolute;
  left: 0;
  top: 100%;
}

/* Look, Ma! No onclick handler! */
.my-menu li:hover > ul {
  display: block;
}

These days, we can improve the accessibility of CSS-only menus with a newer trick! Menus can open and close when navigating them with a keyboard, thanks to :focus-within.

/* No IE11 support */
.my-menu li:focus-within > ul {
  display: block;
}

Try using both your mouse and the TAB key to move through the demo.

But times have changed from when I first learned these tricks, and so have I. Since then, I’ve built a bunch of websites and learned a lot more about usability, accessibility, and content strategy. Now, I find hover-triggered menus lacking on all those fronts. So, a few years ago, I quit building hover-triggered submenus and switched to click-triggered submenus. (From here, I’ll just call them “hover menus” and “click menus.”)

I think you should should stop building hover menus too. I’m here to tell you why.

Hover menus are inconsistent

Take a look at this real menu from a site I built:

Simple enough, right? The arrow icons show us there are submenus for each item except “Home.” But if those submenus appear on hover, there are at least four ways the menu might work, and you’ve probably experienced all four of them.

  1. The top “parent” menu item links to a page and each submenu item links to another page. For the example above, “Services” would be a unique page and so would every link in the “Services” submenu.

But somewhere along the way, a second very common pattern arose.

  1. The parent item has href="#"— or even no href at all 😱and the only functional links are in the submenus. In our example, “Services” is still a link, but nothing happens when you click it.

This inconsistency — is the parent item a link or not? — leads to lots of confusion when I watch people use websites. Some people skip right past helpful top-level pages, assuming those items aren’t links. Yet others assume the top-level links are pages and try to click them.

This leads to the third and fourth not-so-great patterns you’ll encounter. My guess is that these evolved from attempts to compensate for the confusion caused by the first two setups.

  1. The parent item and first submenu item link to the same page. Making matters worse, the parent item and first submenu links having different link text violates a WCAG 2.1 Level AA accessibility standard.
  2. The parent item links to a page containing useless fluff content or only the links in the submenu. The page itself serves no real purpose for anyone visiting it.

These last two configurations waste time for people who do know the parent items are links with redundant or useless content.

Here’s a diagram showing all four possible hover menu setups.

Image of a white menu with four menu items going from left to right. The menu is against a gradient background that goes from a burnt orange to a deep purple horizontally. Each menu item corresponds to one of the usability issues that were described.
When first seeing a hover menu, a visitor can reasonably wonder which of these four ways the menu might work.

Visitors are reasonably confused by hover menus

No matter how we implement hover menus, our visitors can reasonably wonder:

  1. Can I click the parent items?
  2. Will the parent item be a link to the same page as the first submenu link?
  3. Even if the parent item is a unique link, is it worth my time to view?

That leaves us with no good options. It makes it impossible to satisfy Jakob’s law of usability that “users prefer your site to work the same way as all the other sites they already know.” There is no standard implementation when it comes to hover menus, so we need to do something different to provide a consistent user experience.

What about “Split Button” menus?

Probably the least common type of menu I see uses a “split button” design where the parent item is a link and a separate drop-down icon opens and closes the menu. The Twenty Fifteen default WordPress theme uses that pattern. Because it’s so uncommon, I find that visitors often overlook the top-level page link, and research suggests that users don’t perceive a label and icon as being separately clickable.

A “split button” menu item from the Twenty Fifteen WordPress Theme
Until someone hovers or focuses the arrow button, they probably won’t guess it’s independent of the link.

So, what’s the better option? Enter the click-triggered submenu!

Click menus to the rescue

Instead of relying on the hover interaction or some other “creative” (and confusing) solution, let’s build menus where parent items are buttons that show and hide submenus when clicked. This instantly solves the hover menu problem because click menus work unambiguously.

  • Site visitors must click the parent item to view its submenu.
  • All links are contained in submenus except for top-level items that have no submenu (e.g. “Home”). We’ll deal with what happens to those top-level pages in a moment.

When you think about it, click menus are actually what we expect already in most other contexts:

  • Using a touch device? Hover isn’t really a thing there.
  • Using an application menu (e.g. File, Edit, etc.)? Those almost never appear on hover!
  • Using anything other than a mouse? Pressing ENTER or activating a link with any type of switch control is more equivalent to clicking than :focus is equivalent to :hover.

Regardless of your device or input mode, a “click” is a more universal and solid interaction. Let’s use it to make our website menus awesome!

Switching to click menus

My gut feeling says that a lot of sites have recently switched to click menus. Join the party! As more and more sites make the change, people will again develop simple and useful expectations of “how websites work” (thereby satisfying Jakob’s law).

When you first make this change, it’s true that some visitors might still expect hover menus. They may even say they prefer them if you ask. What I can tell you from watching people use click menus, though, is that everyone figures it out quickly and adjusts.

And don’t just take my word for it! The U.S. Web Design System’s (USWDS) navigation patterns use click menus. Here’s what they have to say:

Avoid using hover to expand dropdown lists. Hover is difficult for some users and won’t work on touch screens. Dropdowns should expand on click or with keyboard navigation.

Bootstrap uses click menus, too, for these same reasons:

What it really boils down to is user intent. The purpose of a hover state is to indicate something is clickable (underlined text)… The purpose of a click is to actually do something, to take an explicit action. Opening a dropdown is an explicit action and should only happen on click.

From the same article, there’s this great nugget:

The caret in a dropdown link is the equivalent of underlining a link: it provides some affordance for what will happen when you click this element. Don’t mistake that for providing enough information to pop the dropdown on hover though.

So it’s not like we’re exploring uncharted territory here. And, the UK.gov design system has another good reminder: Maybe you don’t even need submenus at all! Their menus are just a list of links, using on-page grids of links and accordions to help visitors navigate. Heck, you won’t find submenus on CSS-Tricks either!

Click menus come with bonus benefits!

The more you work with click menus, the more benefits you discover:

  • You decide whether you need a category/overview/landing page… or not! Instead of forcing content to match a menu’s structure with links that are parents of other links, your content strategy and information architecture dictates what types of pages you need and how they are labeled. If an overview of your services is helpful for your visitors, put “Services Overview” or “All Services” as the first item in your “Services” submenu.
  • Submenus stay open until they are closed. Hover menus have a nasty way of disappearing when people bump their cursors or even just try to click a submenu link. This is especially the case for submenus that “fly out” rather than below the parent item. The persistence of click menus makes for a more “solid” experience so users trust the interface and don’t get frustrated.
  • The persistent submenu behavior is even more crucial for megamenus. When visitors need more time to take in the submenu contents, they can’t afford to have the menu close unexpectedly.
  • The JavaScript is the same for “mobile” and “desktop” menus. Whether the menu is hidden behind a hamburger or visible on mobile, the interaction is always the same. I only need to change my CSS to make a responsive click menu.

Building click menus

When I set out to build my own accessible click menu script, I found there wasn’t a single standard for how to do it. My own thoughts and code were most heavily influenced by:

The key takeaways from my research on implementation:

  • The element you click to show the submenu should be a <button> since it doesn’t link to a page.
  • Use aria-expanded (on the <button>!) to communicate the submenu’s open and closed states.
  • Use display: none or visibility: hidden so that keyboard users can’t get to submenus when they are closed.
  • aria-controls is poop, but you might as well add it.
  • Do not use role="menu" (and the whole ARIA menu pattern) or aria-haspopup. Those feel related but they aren’t for building navigation menus.
  • Close an open submenu when:
    • Another submenu opens
    • The user clicks outside the menu
    • The user presses the ESC key when focus is inside an open submenu. (Not all users expect this, but I think it’s a nice touch.)

Since click menus require JavaScript, we should consider how this menu can be progressively enhanced in case JavaScript fails for any reason. Our classic hover CSS trick is still good for something after all!

I start building my click menu as a CSS-only hover menu that uses li:hover > ul and li:focus-within > ul to show the submenus. Then, I use JavaScript to create the <button> elements, set the aria attributes, and add the event handlers. This means the menu still mostly works without JavaScript and plays nicely with link-only menus built in WordPress, my CMS of choice.

You can check out the script I use below, but I’ll be the first to admit there are probably better ones. What’s important is that you test it with real users… and stop using hover menus. 😃


The post In Praise of the Unambiguous Click Menu appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

17 Navigation Menus Made With Only CSS (No JavaScript)

We’ve been on a kick lately here at 1WD, looking at ways to code things in pure CSS without utilizing JavaScript, not because we don’t like JavaScript, but when you can avoid using it and still accomplish what you set out to do, why not? So today we’ve gathered 17 examples of navigation menus coded this way. Have a gander and see if there are any you can use in your future projects.

Web Designer Toolbox: Unlimited Downloads Starting at $16.50/Month
Website Kits

Website Kits
16,000+ Web Designs

UX & UI Kits

UX & UI Kits
14,000+ UX & UI Kits

Graphic Assets

Graphic Assets
33,000+ Graphics

DOWNLOAD NOW
Envato Elements


Mobile Overlay Menu

Here’s a hamburger icon that reveals a full screen overlay when clicked, with a nice animation of the hamburger turning into a close “X” icon.

See the Pen Mobile Menu – CSS by Daniel Hearn (@danhearn) on https://codepen.io‘>CodePen.dark

Mobile Fade In Menu

A slightly different approach with the menu fading into view to the right of the hamburger icon. This obviously would work best on small screens with only a few menu items.

See the Pen Mobile Menu (CSS) by AY (@amycodes) on https://codepen.io‘>CodePen.dark

Hamburger Menu With Animations

Some eye-catching animations make this menu stand out.

See the Pen Hamburger Menu – Pure CSS by Mark Claus Nunes (@mnunes) on https://codepen.io‘>CodePen.dark

Tumblr Inspired Menu

As the title says, this menu was inspired by Tumblr and has some slick animation.

See the Pen Tumblr inspired menu (pure css) by John Riordan (@JohnRiordan) on https://codepen.io‘>CodePen.dark

Hidden Navigation Menu

An off-canvas menu that slides out and back in when toggled.

See the Pen Hidden Navigation Menu (Pure CSS) by Jessica Jones (@helloheyjess) on https://codepen.io‘>CodePen.dark

Fade In/Fade Out Menu

A modal window that fades in and out houses the navigation menu in this example.

See the Pen Fade-In/Fade-Out Menu – Pure CSS by Ben Melluish (@pseudosocial) on https://codepen.io‘>CodePen.dark

Mega Menu

How about a full-width mega menu? Nicely done!

See the Pen Mega Menu Pure CSS by Mohammed Naji Abu Alqumboz (@mohnaji94) on https://codepen.io‘>CodePen.dark

Off-Canvas Menu

A well-designed slide-out menu with a nice UX.

See the Pen Off Canvas Menu – Pure CSS by Muhamed Ibrahim (@MuhamedIbrahim) on https://codepen.io‘>CodePen.dark

Animated Radial Menu

Here’s a cool social sharing icon radial menu.

See the Pen Animated menu by Dario Fuzinato (@fuzinato) on https://codepen.io‘>CodePen.dark

Mobile-Like Aside Menu

Another slide out hamburger menu example.

See the Pen mobile-like aside menu pure css by Felipe Nunes (@willpower) on https://codepen.io‘>CodePen.dark

Material Design Round Mask Menu

An interesting concept where the menu appears on hover.

See the Pen Material design round mask menu (pure css) by Sorin Botirla (@sorinbotirla) on https://codepen.io‘>CodePen.dark

Just Another Menu

Not really “just another menu”, this one is a share icon menu that would work well on blog posts or other content that needs to be shared.

See the Pen Just Another Menu(Pure CSS) by Akhil Sai Ram (@akhil_001) on https://codepen.io‘>CodePen.dark

Drop Down Navigation Menu

A drop down menu with sub-items appearing with an interesting animation.

See the Pen #CodePenChallenge: Menu by Hakkam Abdullah (@Moslim) on https://codepen.io‘>CodePen.dark

Radial Menu

Another radial menu not unlike the previous examples.

See the Pen Radial Menu – Pure CSS by Colin Hall-Coates (@Oka) on https://codepen.io‘>CodePen.dark

Fullscreen Overlay Menu

And here’s another fullscreen overlay menu with some nice animation.

See the Pen Fullscreen overlay menu (pure css) by Vlada Oleynik (@vladaoleynik) on https://codepen.io‘>CodePen.dark

Responsive Hamburger Menu

A nice navigation menu that adjusts to various screen sizes like a responsive menu should.

See the Pen Responsive hamburger menu – pure CSS  #1 by mutedblues (@mutedblues) on https://codepen.io‘>CodePen.dark

Animated Mobile Navigation Menu

Lastly, we have a bottom of the screen mobile device menu with a slick animation.

See the Pen Animated mobile navigation menu (pure CSS) by Lovro Kalan (@LovroKalan) on https://codepen.io‘>CodePen.dark

How Will You Use These Pure CSS Navigation Menus?

We hope these examples of navigation menus will prove useful for your future projects. Be sure to check out our other collections of pure CSS code snippets too!

Using <details> for Menus and Dialogs is an Interesting Idea

One of the most empowering things you can learn as a new front-end developer who is starting to learn JavaScript is to change classes. If you can change classes, you can use your CSS skills to control a lot on a page. Toggle a class to one thing, style it this way, toggle to another class (or remove it) and style it another way.

But there is an HTML element that also does toggles! <details>! For example, it's definitely the quickest way to build an accordion UI.

Extending that toggle-based thinking, what is a user menu if not for a single accordion? Same with modals. If we went that route, we could make JavaScript optional on those dynamic things. That's exactly what GitHub did with their menu.

Inside the <details> element, GitHub uses some Web Components (that do require JavaScript) to do some bonus stuff, but they aren't required for basic menu functionality. That means the menu is resilient and instantly interactive when the page is rendered.

Mu-An Chiou, a web systems engineer at GitHub who spearheaded this, has a presentation all about this!

The worst strike on <details> is its browser support in Edge, but I guess we won't have to worry about that soon, as Edge will be using Chromium... soon? Does anyone know?

The post Using <details> for Menus and Dialogs is an Interesting Idea appeared first on CSS-Tricks.

WordPress Designers Seek Feedback on Navigation Menu Block Prototype

Creating a block for navigation menus is one of the nine projects Matt Mullenweg identified as a priority for 2019, and the future of WordPress menus is starting to take shape. Designers working on the new Navigation Menu block have published a prototype this week with detailed notes on how users will interact with the block.

The proposed solution would automatically generate a menu and users would able to delete menu items using the keyboard or block settings ellipsis menu. Individual menu items can be moved right or left and more advanced options for reordering or nesting would be hidden behind the block inspector.

Adding a menu item opens a search bar that would give quick access to all the content in the site. From here users can create a new page or use advanced mode to bulk add more pages. The designs aim to hide most of the more complex tasks behind the block inspector.

Reading through the list of interactions this design is expected to cover, it’s clear that navigation menus are one of the most challenging interfaces to bring into the block editor. One of the principles the designs are based on is that “The editing state of the block itself should mimic as closely as possible the front-end output.” However, it’s difficult to fully visualize how this will work. Navigation menus are most likely to be used in the header and/or footer of a website, but it’s not yet clear how themes will reveal a navigation area to Gutenberg.

There are still many questions to be answered and the design team is seeking feedback on the prototype. Comments are open on the post and feedback on more specific interactions can be left on the relevant GitHub tickets or in Figma. The tickets related to the navigation block discussion are listed in the proposal. The design team is currently working on usability testing and aims to have a final design by the end of March.