Add a menu-styles API into core

[klonos]

After a recent comment from our friendly Monkey, I started reading a few articles and blog posts that were returned from google search for "I hate Drupal". I wanted to get a better idea of what it is that people hate about Drupal. What makes them give up and choose another CMS? Most of the things that pissed users off were things that they thought should be fairly simple tasks or offered out of the box by a modern CMS. In reality, these features in order to be implemented in Drupal 6/7 required a multitude of contrib modules. Then came a lot of reading and then a lot of fiddling and pogo-sticking around the UI and perhaps having to battle with bugs and feature requests lingering for ages in the respective issue queues (that could last for whole days or even weeks). Finally, when/if they somehow managed to make all these contrib modules and 3rd party libraries "sing" together, they had something that they thought was "plain ugly" or made their site slow.

Some of these commonly-requested features that seem to be coming up over and over in these articles over the net are a WYSIWYG editor (we have this covered now), a slideshow (will cover it in #1152), better media handling in general as well as being able to create drop-down menus, which is what this issue here is about...

Lets please pick a library or a contrib module among the many that exist for D7 and have drop-down menus be an out-of-the-box feature for Backdrop that is a breeze to set up. It doesn't have to be anything too complicated like say Megamenu.

The most installed modules that come up after a search for "menu" in d.org are:

1. Superfish: more than 140k installations
2. Nice Menus: more than 86k installations
3. Responsive Menus: about 35k installations

It's interesting that the one module in the list that claims to be responsive is the one with the less installations out of the three - with a considerable difference too. So, when you add the term "responsive" to the same search, you get:

1. Responsive Menus: about 35k installations.
2. Responsive Dropdown Menus only about 2900 installations.
3. Mobile Navigation: only about 2400 installations.
4. Responsive Navigation: close to 500 installations.

Curious as to what are others using.

Also, could we perhaps adapt/reuse what we have for the admin bar?

[klonos]

...one thing that always took me quite some time to setup initially was the css of these menu solutions (usually Superfish or Nice Menus) in order to match either the custom theme I was building or the contrib theme I was to use. If we were to include a solution in core, perhaps we'd delegate some of this css fiddling to the wider community and have themes that work with the drop-down menu we provide out of the box too. Problems that are hard to figure and that require advanced css knowledge and experience would then be addressed sooner and benefit more.

[klonos]

Adding up the usage stats of these modules (and given that there won't be many sites that use more than one of them at a time), they add up to only 25% of D7 installations. So I will understand if this feature request gets shot down due to our principal to write code for the majority. It just feels like this is a very common feature and it is one of the main reasons why people seem to hate Drupal for.

To it's defense when it comes to usage stats, 25% might not be as high as Views, Date, Token or Pathauto, but it is close to (and in some cases even more than) what other popular modules have. Some of these are (and yes, I admit that I intentionally have chosen the ones that we have either already merged in core or plan to) Views Bulk Operations (already in core despite its ~22.5%), Email Field (only 13%), Transliteration (~23%) and of course Dialog (only about 3000 installations - "ABSURD!" I yell) :smile:

[sutibun]

What makes them give up and choose another CMS? Most of the things that pissed users off were things that they thought should be fairly simple tasks or offered out of the box by a modern CMS...

Waaah, you've managed to pin point Drupal's problem. The process sound eerily familiar... (except 4)

1. "In reality, these features in order to be implemented in Drupal 6/7 required a multitude of contrib modules."
2. "Then came a lot of reading and "
3. "then a lot of fiddling and pogo-sticking around the UI and "
4. "perhaps having to battle with bugs and feature requests lingering for ages in the respective issue queues (that could last for whole days or even weeks)."
5. "Finally, when/if they somehow managed to make all these contrib modules and 3rd party libraries "sing" together, they had something that they thought was "plain ugly" or made their site slow."

Bd needs: polish and integration. (1.3.x is a good step) contrib modules will of course play a part since different websites require different needs but the core CMS needs to be at a certain level (need to integrate well) and "have" (and working well) what most people expect i.e. "common" things. (especially when the contrib module community isn't at full force)

User: I want to create a simple photo gallery to show off my family photos. How do I do that?
Bd: yeah, you got to understand how Bd works. If core doesn't have it, check out contrib modules. Check out module... looks but finds nothing ... uh...
User: so, what do I do...
Bd: uh... just do [offers some hackish way to go about it]
User: sighs that sounds complicated but ok... days later sigh. forget about my photo gallery, I can't even customize my own site so it looks nice.... I hate Bd!

I remember checking out the backend of a WP installation for an org and noticing they had a few plugins like a photo gallery, email sign up thing-a-majig, etc. Their main focus, to me at least, was providing info (via blogs and pages) and doing so in a great presentation. It didn't seem like they spent a lot of time fiddling with site set up. i.e. they used most of what WP provided.

Anyway, this is a long and round about way to get to my main point.

I think having some user avatars (grrr can't think of the proper word design ppl use) in mind is always helpful... something like so In other words, what do we expect "our" community to want and need.

Some of these commonly-requested features that seem to be coming up over and over in these articles over the net are ... being able to create drop-down menus...

Having said that, I'm kind of leaning for the idea of drop down menus being in core. My thinking is

• convenience. people see this on other sites and they're like, "I want that... oh, how nice it's built in and I only need to focus on customizing" (creating/searching for a module vs customizing) Instead of focusing on WHAT to do to get this feature, they can immediately focus on HOW they want it to appear e.g. organization, hierarchy, etc.
• it's a common feature you see on many sites. Once you've made your menu, drop down menus are a common expansion. Reasonable to expect users will want one. By having in core, maybe Bd can standardize how drop down menus are done (Contrib modules of course can provide alternative ways) and themes won't have to implement their own solution. Themers can expect all sites will have this feature and can design for it.

That's for the idea though. Didn't know these kind of modules existed so dunno know which of them are best.

PS.

I started reading a few articles and blog posts that were returned from google search for "I hate Drupal". I wanted to get a better idea of what it is that people hate about Drupal.

I... I... I should've done this. lowers head

[Graham-72]

I am wondering whether it might be a mistake to think that much extra should go in Backdrop's core. It is a while since I had detailed involvement with a wordpress site but I seem to remember that the strength lay in the quality and comprehensive detail of the themes, so that for example if you are a photographer wishing to provide a showcase for your work you could install wordpress with a theme called Photocrati, and this would add all the necessary modules, styles, artwork etc as a ready-made package.

The reason I, as a web developer, chose to work with Drupal rather than Wordpress was that it seemed (and still seems) much easier to tailor it to a customer's needs through adding contributory modules, new types of content, modifying templates, customising style sheets, creating views and layouts - things that are much easier now with Backdrop. But these are not things that someone wanting a website 'out-of-the-box' will want to have to learn to do.

This takes me back to the exchange of thoughts in https://github.com/backdrop/backdrop-issues/issues/1359 'First Impressions and Feature Requests'. In my view we need to develop these ideas of a few types of ready-made package of core plus contributed modules, wrapped up in a theme, that would meet some mainstream small-user needs. Though this is not actually what I need to provide my service to clients.

[klonos]

...a few types of ready-made package of core plus contributed modules, wrapped up in a theme...

That's the notion of distributions you are describing there:

What are distributions?

Distributions are full copies of Drupal that include Drupal Core, along with additional software such as themes, modules, libraries, and installation profiles. There are two main types of Drupal distributions:

[Graham-72]

Yes, well I hadn't intended to go so far as a distribution, though that might suit some users. I do think that many adopt Wordpress because you just need the core system plus one good theme that packages everything else you need for your application.

[biolithic]

I also agree with Graham/Clonos in the "small-ish core + distributions" model. To me a problem might not be "responsive menus" or "other widgets" but that project browser is not yet arrived for users or some modules lack official releases or bd.org or some site might lack documentation/marketing on what exists or is out there or not enough modules ported or search engine on bd.org is not working great. Maybe in place of these things (what should be in core...), some just general recipes of themes/ should be put together as either a list of html links or something more advanced (make files, composer, hosted files etc).

"Though this is not actually what I need to provide my service to clients." == me too. A client doesn't sell a photo gallery, they sell their club and how exciting it is for you to join and you can see in our photo gallery which tomorrow may be changed to be large font quotations or video or virtual reality, etc...

A simple search on BD reveals ported modules such as: https://backdropcms.org/project/wpmenu https://backdropcms.org/project/mobilenavigation https://backdropcms.org/project/responsivemenus

So we are not starting from scratch on Wordpress or mobile or responsive menus if we don't want to...

On Sun, Dec 27, 2015 at 4:23 PM, Gregory Netsas notifications@github.com wrote:

...a few types of ready-made package of core plus contributed modules, wrapped up in a theme...

That's the notion of distributions https://www.drupal.org/documentation/build/distributions you are describing there:

What are distributions?

Distributions are full copies of Drupal that include Drupal Core, along with additional software such as themes, modules, libraries, and installation profiles. There are two main types of Drupal distributions:

— Reply to this email directly or view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1457#issuecomment-167445036 .

[sutibun]

The missing glue in Bd

I am wondering whether it might be a mistake to think that much extra should go in Backdrop's core

I just think that responsive menus are a common design feature that users will want. Similar to how a Rich Text Editor was brought into core and thus standardized, we can do the same with drop down menus. Klonos explains it better than I can:

If we were to include a solution in core, perhaps we'd delegate some of this css fiddling to the wider community and have themes that work with the drop-down menu we provide out of the box too.

Bd themes can then focus on styling.

I won't push this too hard then... maybe this is a difference in approach. Hopefully others can chime in.

Hmm, let me backtrack a bit and explain my underlying philosophy. From my perspective, I think there are two extremes to avoid:

1. stuffing Bd with many features/modules. The problem becomes what'd you call bloated software. Because Bd doesn't target a specific niche/audience, you can't possibly cover all user needs. (e.g. photographer, e-commerce, gov) Hence, the importance of contrib modules
2. keeping Bd as lean as possible. In this case, you're placing the burden on users to "start from scratch" and assemble everything. i.e. to build up their site to their liking. The thing to take into account is human behavior: some people have no problem building something given the "Lego pieces" (e.g. Drupal module approach) but others prefer a ready-made package that just works. (e.g. WP theme that sets everything up for a photographer)

I do think that many adopt Wordpress because you just need the core system plus one good theme that packages everything else you need for your application.

Think so too. This caters to the non-"lego builder" I mentioned earlier. The issue is trying to combine the power/flexibility of Drupal with the ease of WP.

...for example if you are a photographer wishing to provide a showcase for your work you could install wordpress with a theme called Photocrati, and this would add all the necessary modules, styles, artwork etc as a ready-made package.

I thought Drupal themes couldn't do this. i.e provide the whole ready-made package like WP?

To me a problem might not be "responsive menus" or "other widgets" but...

• "that project browser is not yet arrived for users or"
• "some modules lack official releases or"
• "bd.org or some site might lack documentation/marketing on what exists or is out there or"
• "not enough modules ported or"
• "search engine on bd.org is not working great."

I agree. Those factors do play a part for Bd but then how does that explain Drupal? Aside from project browser, Drupal has all the above implemented yet some users are complaining about the lack of drop down menus, among other stuff like "you can't build anything easy on Drupal".

I think fundamentally, the Drupal approach of only providing the building blocks doesn't appeal or work for "normal" users. They like the WP approach of everything packaged and done for them. For "lego builders", it's fine since they're willing/able to search and build their perfect CMS.

Project browser will no doubt help the UX by

• making module installation more convenient and
• exposing modules to more users

but this appeals more to the "lego builders". They're the ones who will benefit the most. (don't misunderstand, I like PB) Besides, even if the module installation process is improved, "normal" users will hit another wall. I'm willing to say that Bd/Drupal modules are generally non-intuitive, are complicated to set up, and come with their own problems.

So let me start from the beginning again. WP has the following:

WP Plugins	WP Themes
A	1
B	2
C	3

Looking at Bd/Drupal, we have the following components

Bd Modules	Bd Themes	Bd Views	Bd Layouts
a	1	xxx	aaa
b	2	yyy	bbb
c	3	zzz	ccc

Looks similar except WP plugins/themes can automatically customize and package the whole site to suit a particular audience. (think of the mentioned "Photocrati" theme that "adds all the necessary modules, styles, artwork etc as a ready-made package") Whereas most Drupal modules/themes are generally focused on one task/feature.

• module X provides photo gallery
• theme Z provides a generic look whose style you need to customize to suit your need (e.g. fashionable photography site)

That's not necessarily a bad thing but it goes against what appeals to the other user type. Since neither Bd theme or module are holistic/comprehensive, you have to go find the best suitable components yourself and build it.

What's missing is the mechanism that brings everything together... that packages the themes and modules for the user.

Maybe in place of these things (what should be in core...), some just general recipes of themes/ should be put together as either a list of html links or something more advanced (make files, composer, hosted files etc).

Assuming I understand that last part, we're thinking along the same lines. I proposed something similar at #1175 where Bd should have a new component. I call it "Bd scripts"

This is the missing glue.

Bd Modules	Bd Themes	Bd Views	Bd Layouts	Bd Make files
a	1	xxx	aaa	"Photocrati suite"
b	2	yyy	bbb	"Simple blog"
c	3	zzz	ccc

Everything is the same as is now except the Bd Make Scripts acts like a curator.. mimicking the WP themes that packages everything together. So, if a newbie installs the "Photocratic suite" Make Script built by Graham Cookies, (the pro photographer :p) it will download and customize the necessary modules, themes, artwork, add necessary views, Layouts, such that the newbie's site is now a photography website.

If someone instead installs the "Simple blog", it will configure the site to have a simple blog (prob just views + content type)

I think this is how you get around the "Drupal/Bd is hard" issue. You keep the modularity but provide the glue.

er.. hope that makes sense.

PS

Some of you might look down on less technical users but here's a great scenario to feel their pain and not think less of them.

As you probably should know, we all need to prepare for our retirement at some point and think about investments and such. Let's say you have some side money stashed away so you go to an adviser for counsel (read: CMS). What if he said,

"Investing isn't hard at all. I recommend personally selecting all the investment vehicles yourself so you build the perfect retirement package that's right for you. You have a ton of options to choose from (read: modules) like mutual funds, index funds, annuities, Roth, stocks, 401k, life insurance, bonds, ETF, etc. Just tell me which of those you want and how much you want to invest?"

Most of you probably don't even know the difference but let's say you select stocks. The adviser then queries,

"Sweet. So, what stocks do you want to buy? Google, MS, etc?" (read: Of the 10 photo gallery modules available, which one do you want to go with?)

You know you're not stupid but you just don't get investments. You try to read up on each option he mentioned but you feel overwhelmed.

Now, imagine if you go to another adviser who says something like,

"We know investing for your retirement is hard. That's why we've come up with three packages that go from the most conservative to the riskiest but comes with higher returns. You don't need to know what's an ETF or annuity. We take care of all those details. You just worry about how risky you want to be with your money and choose the appropriate plan"

Which approach would most people go with? (read: which is easier to swallow)

You're smart with technology and all that but placed in the investment world, you become the "normal" user. (Some more savvy investors may even consider calling you a dumb investor/user) In this situation, wouldn't you want someone to just do it for you and get you the end result as well? You'd wish investment was just easier.

[Graham-72]

@sutibun thanks for sharing these excellent thoughts.

One point that now occurs to me is that one of the advantages of including a module in core is that it gets reviewed by @quicksketch and reworked to improve it to a high Backdrop standard. I am thinking for example of the Date module and my personal experience of porting it. I am conscious that when I am porting a contributed module I am focussing on getting it to work rather than improving the code. Whether or not we have a 'responsive menu out of the box' it would be good to have a first-class version available - perhaps we have, I have not checked out what is currently available.

Perhaps we need to have some sort of approval scheme whereby contributed modules can attain a Merit Award as a commendation from, say, @quicksketch and @jenlampton , meaning that they are well ported, properly maintained etc. or would this go against the commendable democratic principles of this project?

[klonos]

I absolutely get all this, but the point is that not all mobile/responsive menus or drop-down menus work with every theme that is currently available and it won't be an easy job to keep them working or update them in order to work with new themes as they come out either. From experience, I think that contrib theme developers are more kin on fixing issues that arise with a core feature (say the admin bar for example) than issues that are reported against contrib module x.

So, the plan is this:

1. Since having a drop-down menu is a commonly requested feature, we should consider providing one with core. A bare/basic one with minimal CSS and a well-maintained 3rd party JS library, in order to minimize the overhead (can we reuse whatever we have for the admin bar?). This step is in order to stop comments like "with Drupal, having something as simple as a drop-down menu is like going through hell ...and Backdrop ain't any better either".
2. We'll make sure that this works with all core themes. This will also serve as a guideline of what other (contrib or custom) themes should do. Along with point 1 above, this will ensure that users get a good out-of-the-box experience if all they need is a simple site, with a simple drop-down menu, with a theme that is basically a version of Bartik with a different color scheme.
3. We'll account for the responsiveness of this menu with core themes because mobile devices is a reality nobody can deny.
4. Contrib theme developers will have to account for supporting this because it will be a core feature. Their feature list will simply not be complete unless there is a "Supports core drop-down menus" bullet. Simple as that. Supporting other, contrib drop-down menu modules will be up to them and an extra. It will depend on the popularity of these modules I guess.
5. THIS IS IMPORTANT! ...because we have a frequent release circle, we don't have to be "tied" to using whatever we choose to go with now. If a better(er) solution comes out in the wild (when it comes to 3rd party libraries) or in contrib (when it comes to modules), we can replace the solution in a future major version.

[klonos]

I really liked the introduction of https://backdropcms.org/project/responsivemenus

Responsify your menus! Just give me a CSS or jQuery style selector of your menu and I will make it mobile friendly (when the time is right).

...but then I read a bit further:

Mainly tested to fit Seven and contrib themes rather than Bartik theme.

Hmm, seems like the opposite of what we're after. Seven is the admin theme and Bartik is the user-facing one :disappointed:

[klonos]

An image (screencast in this case) is worth 1000 words:

This is on a vanilla WP installation! No additional modules/addons. No external libraries to be downloaded and then uploaded in a directory on the hosting server. No need for endless fiddling with configuration screens in order to make things work together.

Now, I am not a WP expert - I've just downloaded and installed it say a few dozen times for testing/educational purposes. I was able to pull this off in say 10 minutes! ...surely my understanding of the basic concepts and terminology of a CMS helped, but even if I was a rookie I guess it'd take me less than an hour to figure it out - not days like people complain that similar tasks take them with Drupal.

On top of all, the drop-down menu works decently with the default themes that come with core (I've downloaded a few of the ones bundled with previous versions for the sake of the demo) PLUS it's responsive in most of them!!

I rest my case.

[sutibun]

This is on a vanilla WP installation! No additional modules/addons... No need for endless fiddling

Sounds about right. Not surprising 50% of the market is gravitating towards WP. No need to think: "do I add a drop down menu via a plugin or a theme?". It's just there.

[docwilmot]

Great discussion. We did a PR for better menu blocks months ago: https://github.com/backdrop/backdrop/pull/834. Would be fantastic and also very sensible if there was a checkbox on the config dialog that asks if you want this to be a dropdown.

[biolithic]

I'm pretty sure everyone is on-board with having a drop-down menu, but maybe this thread should be changed into "What kind of drop-down menu?"

Does a mega-menu turn into a drop-down with 40 links or just a few main links (click to drill down into categories)?

Should it use Javascript, CSS, or Flexbox to achieve the drop-down?

Maybe it uses an ontouchstart event for a "nice mobile experience" rather than a click event?

Only the "primary/main menu" or other menus get the drop-down code applied to them?

Holding the device in landscape mode receives menu A, holding the device in portrait mode receives menu B (contextual menus for icons versus text for example)

Should it come down from the top or in from the side?

A person's thumb is often at the bottom of their mobile device. Should they be all drop-up menus (from the bottom where the thumb is)?

Is Hamburger menu cool or not cool?

Does it animate? Or not animate because of older Android devices?

These types of questions shouldn't halt action, but people do ask/argue about them based on conversion rates and so forth in my experience.

Maybe a solution could be a core module enabled providing the basic drop-down that developers/designers may disable if they want to implement their own custom solution that might fit better with the client project vision?

-- side note --

I personally feel that the time has mostly come for large Javascript powered desktop mega menus in Drupal7/Backdrop to be done with unless you are on a very large site (which you probably are not choosing Backdrop at this time).

Because we've learned about:

• site architecture -- don't have 20 top menu categories or drop-downs of 20 items because people don't want to make that many choices anymore
• mobile -- some people are on touch devices these days
• just tell the user where to go on the page itself / "infinite" scrolling
• just use icons and save the extra white space for selling the big idea(s)

We probably won't have to "make sure our drop-down solution works with superfish and nice menus and mega menu installed together because every site needs them" because even something like Starbucks.com could just have the menu items "store locations, buy gift coffee, my points account, other boring stuff" and if you click on other boring stuff you can read how many calories are in a scone and how ethically they source they blah blah but most people are only interested in a few menu items on a particular site.. So I don't think we need to wait to port all the most popular Drupal menu modules and then vote on how to balance drop-down ideas with legacy Drupal/web ideas to just achieve this responsive drop-down.

On Wed, Dec 30, 2015 at 3:27 PM, Steven Villaverde <notifications@github.com

wrote:

This is on a vanilla WP installation! No additional modules/addons... No need for endless fiddling

Sounds about right. Not surprising 50% of the market http://edinburgh.fortuneinnovations.com/wordpress-reach-market-share-50-very-soon is gravitating towards WP. No need to think: "do I add a drop down menu via a plugin or a theme?". It's just there.

— Reply to this email directly or view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1457#issuecomment-168076420 .

[quicksketch]

Good plan @klonos. And thanks everyone for the excellent discussion.

I agree that some kind of responsive, drop-down menu should be an out-of-box feature.

This issue is related in a lot of ways to #845 (Menu block features). It may even be required for us to implement a proper drop-down menu properly, because you may need to choose how many levels deep the drop-down should extend.

Implementation-wise, I would like to see this implemented as part of extending the functionality of menu blocks. In my mind I think this could be done by introducing "Menu Styles" (similar to Views' display styles and Layouts' block styles).

Modules like Nicemenus have worked in the past by making all-new blocks that duplicate the functionality of the built-in blocks, but implement it differently. I would like to be able to use the same existing menu blocks but render them in different ways. So for an upgrade path, we would default to menus being "Simple" in that they wouldn't be drop-downs. Either for new sites or newly placed menu blocks, we might default to "Drop-down" display mode. Contrib modules could provide new menu styles if needed. This would provide for #5 in @klonos's list fairly effectively.

[quicksketch]

I'll take a stab at few of @biolithic's questions. For most of these, we can pick the simpler solution and let the more complex solutions be implemented as different, contrib-provided menu styles (if we go with that idea).

Does a mega-menu turn into a drop-down with 40 links or just a few main links (click to drill down into categories)?

Maybe we save mega-menus for contrib? If we're only tackling drop-downs that might be a bigger problem.

Should it use Javascript, CSS, or Flexbox to achieve the drop-down? Maybe it uses an ontouchstart event for a "nice mobile experience" rather than a click event?

Mobile demands pretty much require JS to do a drop-down. Like Admin Bar, we need to implement both onClick and onTouch events, which you can't do with CSS alone at this point. We will probably need to implement something different than Admin Bar, the menu requirements will likely be different (e.g. accordion-like functionality on mobile).

Only the "primary/main menu" or other menus get the drop-down code applied to them?

If this were decided per-block, then each menu would be decided individually.

Holding the device in landscape mode receives menu A, holding the device in portrait mode receives menu B (contextual menus for icons versus text for example)

Probably leave this to CSS hiding/showing items via media queries.

Should it come down from the top or in from the side? A person's thumb is often at the bottom of their mobile device. Should they be all drop-up menus (from the bottom where the thumb is)?

Maybe? I'd probably say punt it to contrib as different style.

Is Hamburger menu cool or not cool?

It certainly is ubiquitous. If we lack room to fit the entire menu, collapsing to hamburger seems okay to me. The icon should be placed with CSS so it can be removed/replaced with a different indicator of course.

Does it animate? Or not animate because of older Android devices?

Maybe leave this to CSS transitions. So it may be per-theme.

[biolithic]

Thanks for contributing everyone. I have used the responsive/mobile menus modules in the past for Drupal/Backdrop and they have these sort of options already in their configuration screen. So we could borrow from them, Admin Bar, or just code up stuff ourselves.

On Wed, Dec 30, 2015 at 5:30 PM, Nate Haug notifications@github.com wrote:

I'll take a stab at few of @biolithic https://github.com/biolithic's questions. For most of these, we can pick the simpler solution and let the more complex solutions be implemented as different, contrib-provided menu styles (if we go with that idea).

Does a mega-menu turn into a drop-down with 40 links or just a few main links (click to drill down into categories)?

Maybe we save mega-menus for contrib? If we're only tackling drop-downs that might be a bigger problem.

Should it use Javascript, CSS, or Flexbox to achieve the drop-down? Maybe it uses an ontouchstart event for a "nice mobile experience" rather than a click event?

Mobile demands pretty much require JS to do a drop-down. Like Admin Bar, we need to implement both onClick and onTouch events, which you can't do with CSS alone at this point. We will probably need to implement something different than Admin Bar, the menu requirements will likely be different (e.g. accordion-like functionality on mobile).

Only the "primary/main menu" or other menus get the drop-down code applied to them?

If this were decided per-block, then each menu would be decided individually.

Holding the device in landscape mode receives menu A, holding the device in portrait mode receives menu B (contextual menus for icons versus text for example)

Probably leave this to CSS hiding/showing items via media queries.

Should it come down from the top or in from the side? A person's thumb is often at the bottom of their mobile device. Should they be all drop-up menus (from the bottom where the thumb is)?

Maybe? I'd probably say punt it to contrib as different style.

Is Hamburger menu cool or not cool?

It certainly is ubiquitous. If we lack room to fit the entire menu, collapsing to hamburger seems okay to me. The icon should be placed with CSS so it can be removed/replaced with a different indicator of course.

Does it animate? Or not animate because of older Android devices?

Maybe leave this to CSS transitions. So it may be per-theme.

— Reply to this email directly or view it on GitHub https://github.com/backdrop/backdrop-issues/issues/1457#issuecomment-168094991 .

[docwilmot]

@quicksketch do you have a suggestion/favorite for an existing JS/CSS library for dropdowns that we can start working on?

[quicksketch]

I don't have any favorites. It's been a while since I had a site with drop-downs. :confused:

[docwilmot]

Drat, was hoping we could avoid the long discussion about "which one" and just do what you say.

[docwilmot]

@quicksketch here is an approach here: https://github.com/backdrop/backdrop/compare/1.x...docwilmot:menu-blk-styles

• I merged a dropdown menu with the Menu Blocks PR; probably could do this separately.
• Adds a hook_menu_block_style_info() and system_menu_block_style_load()
• System.module implements as follows:

/**
 * Implements hook_menu_block_style_info().
 */
function system_menu_block_style_info() {
  $info['slimmenu'] = array(
    'name' => 'slimmenu',
    'title' => t('Slim Menu'),
    'description' => t('Slim Menu.'),
    'class' => 'MenuStyleSlim',
    'js_folder' => array('includes/slim/js'),
    'css_folder' => array('includes/slim/css'),
  );
  return $info;
}

• Introduces a abstract class MenuStyle, and the default style extends this with MenuStyleSlim.
• The chosen JQuery dropdown in this PR is Slim Menu chosen because it is extemely light, simple to implemnet, and includes both a dropdown menu and is responsive. (the plugins shipped with the Drupal Responsive Menus module only do responsifying; you actually have to get a separate dropdown module.)

This is not quite there yet. Just want an idea if this is a way to go.

@klonos you can test from https://github.com/docwilmot/backdrop/tree/menu-blk-styles. Once you pull the branch, add a system block to the header region (only because I've only checked what the CSS changes would be needed for this region). There will be a section for "Animation settings" (rename needed I know). And I just realised the settings defaults dont stick if you add a block and try to edit the settings. Will fix. And the CSS is still 'needs work'.

[ghost]

FWIW, I once used a drupal theme : https://www.drupal.org/project/metro_zymphonies_theme (there is a demo link in the project page) It has dropdown, is responsive, and uses no external library; there is even no settings ! Unfortunately, the interesting things are in page.tpl.php, so I don't see what I can do with it... If someone can translate the (obviously simple) technology used here in the backdrop layout/theme paradigm...

[docwilmot]

Thanks @gifad, this isn't really about the dropdown, but more about integrating a 'Menu Styles API' which could then implement any dropdown library. Nice theme though. Somebody should port it.

[ghost]

Somebody should port it.

I could try, but who truncates the Primary Navigation Menu to the top-level only ? (Yes, I'm new to backdrop)

[ghost]

I'm sorry if I am out of scope, but the title of the issue is

Provide responsive drop-down menus out of the box.

and I don't get why either "a 'Menu Styles API'" and/or "any dropdown library" is necessary for that... I just started with the stock backdrop contrib theme "Cleanish", 20 lines of js, a bunch css from the drupal theme above, and this terrible hack in cleanish/template.php

 * Overrides theme_menu_tree().
 */
function cleanish_menu_tree($variables) {
//return '<ul class="menu">' . $variables['tree'] . '</ul>';
//dpm($variables);
  static $count = 0;
  if ($count++ == 0)
    return '<ul class="menu">' . $variables['tree'] . '</ul>';
  $output = '<nav id="main-menu"  role="navigation">
<a class="nav-toggle" href="#">Navigation</a>
<div class="menu-navigation-container">
';
  $output .= '<ul class="menu">' . $variables['tree'] . '</ul>';
  $output .= '</div>
<div class="clear"></div>
</nav><!-- end main-menu -->
';
  return $output;
}

(please someone tell me in which function of which module/layout/theme I should have put this; here, it is called for each menu parent, hence the $count...) to get this result : and (image courtesy @Graham-72) This is :

Provide responsive drop-down menus out of the box.

what else ?

[quicksketch]

and I don't get why either "a 'Menu Styles API'" and/or "any dropdown library" is necessary for that... I just started with the stock backdrop contrib theme "Cleanish", 20 lines of js, a bunch css from the drupal theme above, and this terrible hack in cleanish/template.php

We're trying to solve the problem that this should be an out-of-box option, without requiring coding. Though you do make a good point that we could just implement a custom or different drop-down solution in each theme. Then each theme would be responsible for creating their own solution.

On the other hand, you wouldn't have to use any solution core provided anyway. You could just have no menu style set at all and then use a custom in-theme solution like this.

@docwilmot I can't wait to take a look at this. It may be a while before I find some time, but from the sounds of things it's right inline with what we had outlined above.

[klonos]

I personally like the idea of an API but only as long as we have an actual implementation in core. This way we could support various JS drop-down menu solutions. We could choose one for core and leave the rest for contrib. It would basically be the same paradigm as using CKeditor as a rich text editor but still supporting other solutions like IMCE in contrib.

[docwilmot]

but only as long as we have an actual implementation in core

That's the idea. Would be great if you could evaluate the options meanwhile. I think Slim Menu and FlexNav seem like what we'd want, but I'm not sure if I've considered all the need-to-haves.

[mikemccaffrey]

Also, could we perhaps adapt/reuse what we have for the admin bar?

I think it makes sense to support dropdown menus in core, since we are already including a dropdown menu in core in the form of the admin bar.

Unfortunately, the admin bar menu implementation is a bit limited. For example, if a menu item is all the way on the right side of the screen, it doesn't automatically think to expand the submenu to the left side where there is room to display it.

However, whatever implementation we decide on for supporting dropdowns for the primary menu, we should use the same solution for the admin bar, so that we don't have the same functionality implemented two different ways in two different places.

[klonos]

...we should use the same solution for the admin bar, so that we don't have the same functionality implemented two different ways in two different places.

Although, now that I think about it, the admin bar is designed to be placed at the very top of the page, to be (optionally) sticky while you scroll and all that works with elements like the sticky table headers. Very specific solution if you ask me and not a perfect fit for a generic main navigation menu.

[klonos]

I think that the goals here should be:

1. Make sure that we wrap the menu items in the right tags and provide enough classes in order for them to be targeted by the available JS solutions out there.
2. Select one such solution (Slim Menu, FlexNav etc.) and include it in core.
3. Have core themes work with that solution.
4. Document how the JS solution we go with for core can be swapped with others either in the theme level (by say overriding the JS library and any accompanying CSS that comes with it with custom ones) or by using hooks in contrib modules.

If we implement 4 the right way, then people should be able to either incorporate any 3rd party library in their custom/contrib theme or use a contrib menu module that works with all/most themes.

[mikemccaffrey]

Select one such solution (Slim Menu, FlexNav etc.) and include it in core.

I'm not super-excited about the idea of us being dependent on yet another third-party extension, especially for functionality which should not be that large or complicated.

Perhaps we can just fork an existing dropdown solution and customize it for our exact needs?

[mikemccaffrey]

Although, now that I think about it, the admin bar is designed to be placed at the very top of the page, to be (optionally) sticky while you scroll and all that works with elements like the sticky table headers. Very specific solution if you ask me and not a perfect fit for a generic main navigation menu.

A dropdown implementation should not be affected by whether or not the admin bar is given absolute or fixed positioning. All of the menus and submenus should be positioned relative to their parent elements.

[klonos]

Perhaps we can just fork an existing dropdown solution and customize it for our exact needs?

That would add maintenance overhead to us. Having it as a 3rd party lib, we can still contribute fixes and features upstream. Now, if we carefully choose a well-maintained library, I guess we won't have to very often.

[ghost]

The drupal adminimal_admin_menu module is bundled with the slicknav library, which is 13Kb, MIT licensed, and does a nice job to make admin_menu responsive... FWIW

[docwilmot]

There isn't yet an active PR for this issue, as there is just some test code on my repo at https://github.com/backdrop/backdrop/compare/1.x...docwilmot:menu-blk-styles so far. I have a doubt that we will decide on a suitable JQuery library by next month.

So I've pushed the core menu blocks PR that this is based on by itself as a 1.4.0 milestone. If @quicksketch somehow manages to review this issue in time, and we can all agree, then maybe we can try for 1.4.0.

[docwilmot]

Though I'd push what I've got anyway, to get a sandbox going. :smile:

[docwilmot]

Website: http://1326.backdrop.backdrop.qa.backdropcms.org Username: admin Password: o2VTUwfU

[wesruv]

I left a comment on the @docwilmot's PR, the JS library that's being used isn't up to snuff. I've got to finish up basis, but I'd love to help out with this! Hopefully I'll have some time soon.

[ghost]

Found in my mailbox this morning, a nice implementation of responsive drop down menus, touch compatible. Drupalcamp Nantes 2016

Built on Bootstrap, the code is at https://github.com/Drupal-FR/socle-drupalcampfr

[serundeputy]

Moving to 1.5 feel free to move it back if someone has the availability to tackle it.

[wesruv]

I'm working on the front-end for this, don't have any progress to show yet... but FYI :smile:

I'll probably have some questions about the config/back end bits soon.

[klonos]

...assigning @wesruv to this so that we don't duplicate efforts.

[wesruv]

I'm working off of @docwilmot's branch docwilmot/backdrop/menu-blk-styles Diff: https://github.com/backdrop/backdrop/compare/1.x...docwilmot:menu-blk-styles

As I'm not a backend dev, I don't have any insight into the approach so far, but it quacks like a good start :stuck_out_tongue_winking_eye:

A couple of things I'd like to change The current implementation is also using an index js_folder and css_folder, which is loading a whole folder's worth of assets. I think a better approach is to reference a library specified by hook_library_info(). This way the CSS and JS are tied together, and it's alterable in case someone wants to sub in some of their own CSS/JS.

I'm trying to take out the slimmenu implementation and sub in something that works with our system in mind. When I tried to remove slimmenu from code I got a PHP error that it didn't exist, which I believe is related to this bug below:

Need some backend dev help There seems to be a bug right now where menu settings aren't being saved. I tried to examine how the other settings are being saved and come across the lines layout.admin.inc:1289:

  // Save the block settings.
  $block->formSubmit($form, $form_state);

No idea how to examine that method. I don't have an IDE setup and not really sure how to use one, can someone help me figure that out?

Kint in D8 was able to show me methods and some docs for the methods, not sure if that was part of kint being awesome, or some special setup they had. If it's Kint being awesome maybe we swap that in in favor of Krumo?

My progress so far wesruv/backdrop/1457-responsive-menu-docwilmot Diff: https://github.com/wesruv/backdrop/compare/for-comparing-1457...wesruv:1457-responsive-menu-docwilmot?expand=1 I'm thinking that the responsive menu option in menu style should come from the menu module, and I've already done some work making my generic admin tabs JS more generic so it can be used for the tabs and any menus. That should allow us to give a solid default implementation, but if someone wants to provide a completely different theming of the same behavior the styles and behaviors won't be inextricably linked.

[klonos]

Can we get this as a PR against backdrop/backdrop so to have a sandbox available for testing the UI?

[klonos]

@wesruv I still haven't managed to make some time to test things and provide feedback, but I was just doing some reading about responsive/accessible menus and came across http://www.smartmenus.org (https://github.com/vadikom/smartmenus).

It has a keyboard navigation addon and I liked how on their demo page you can choose to have the menu be full width or not, align it horizontally or stack it vertically or even turn it to RTL. I thought that it would be cool to offer these as options through the UI. You should check it out in case you weren't already aware of it.

[wesruv]

@klonos aww man I wish that were FOSS, it looks really slick (although I didn't dig into it after see that it wasn't free).

That's a great find, thanks for sharing! I'll try to make ours as awesome, or close to it :stuck_out_tongue:

[quicksketch]

The SmartMenus example is indeed open-source, from http://www.smartmenus.org/download/ :

The SmartMenus jQuery plugin is open-source software licensed under the MIT license (just like jQuery) and as such is available for free for all kinds of use. We do, however, also offer premium support to anyone who needs.

MIT is GPL-compatible, as it allows us to simply re-license our copy when we bundle it with Backdrop.

[wesruv]

Hah! I was fooled by the support pricing table!

I'll look into this fellow