Wow. I seem to be fixated on navigation lately. Anywho - on to the topic at hand. One of the problems with the popular "drawer" style menu is that its width is limited, creating no extra room for drop-downs or fly-outs. This makes complex, multi-level menus difficult. Let's see if we can't fix that.
It's important to note that this is a thought experiment, and I'm concentrating a lot more on UX than I am on code here. The code is accessible in the embedded pens, but I'm not going to go too deeply into it. As always, any questions can be asked in the comments below.
As I said above, having a narrow, limited width menu makes it difficult to have any type of drop-downs (they push items below them around, and that's horrible UX) or fly-outs (there's no room!) for child menus. We're also in a mobile-first world, and since these types of menus are usually initiated on :hover, we shouldn't base any type of essential UX on it.
Another equally important thing to consider is that this solution should not be necessary. Your menus, ideally, should be simple, concise and intuitive enough to function in a limited space without issue. That being said, many clients define what their menus will hold and it is not always in control of us web designers. Since this isn't a UX problem, let's put a pin in that for now.
Up to this point, I don't think that many solutions to this problem have been successfully devised. Usually, it involves a toggle that slides open a child menu below its parent, like this:
While this is a good design, and the code is quite nice as well, the UX is not optimal. Any interaction changes the initial position of other menu items, and once you've opened more than one or two items, the menu involves a lot of vertical scrolling. This places some main menu items well 'below the fold'. Not good.
Let's see if we can improve on this solution, shall we?
Before we discuss the solution, let's see if we can break down what we want to get out of it.
Ok. There are other little things we want out of our solution, but I'll walk through those as we examine it. Without any further ado, here it is:
Let's discuss this, using the points above as a guide.
First, we didn't want menu items to move from their original positions. To solve this, we simply overlay the child menus 'above' their parents, while making it easy to backtrack if the user wants to. This applies to each level of the menu by sliding child menus in from the right and leaving the parent menu visible to the left (click anywhere on the parent menu and you go back to it).
Secondly, we wanted as many items accessible as possible, without having to scroll. Stacking the child menus accomplishes this, while keeping the priority squarely on the current menu. This is similar to the 'card' style UI that is being utilized in many mobile OSes for multi-tasking.
In order to make a parent link to its own page, while also allowing for toggling its children, we separated each parent link into two areas. The larger area is the link itself, and would take the user to the appropriate page. The arrow on the right of each parent functions as a toggle, and brings into view the child menu when clicked.
I believe that the combination of these ideas focuses everything on the items immediately relevant to each users needs, and does so in a very intuitive, simple way.
All of this is all well and good, but there are often many ways of accomplishing the same thing - what do you think of this solution? Is there anything you would change or do differently? On your mark, get set, comment.
Did I help you out?