SPEAKER:
Alright. Well one, thanks for having me. This is quite an honor for me. It's one I'm actually probably one of the first presentations I've done in a long time, and one of the first I've done, and I can't work on either way. So, don't (INAUDIBLE) Me too hard and we'll get on with this. So, I've decided to take on one of the most unruly and biggest sort of complications in web development, and that is how to please everyone, or please as many people as possible from very different backgrounds with menus in Drupal and how to come to a decision of basically what type of menu structure you're gonna build, what type of modules if any, that you might be enticed to use. And basically just kind of have a discussion on the types of interfaces that are available, and the types of options that are available to Drupal developers to complete a task based on the requirements of their project. First, I like to say that I have been a Drupal developer for, have been a member of Drupal (INAUDIBLE) For about 12 years, started with Drupal 6.
I've seen a lot of, kind of fads if you will come and go in web development and design. Broadly, not just in Drupal and one thing that always it's always the hardest to do, is to manage content and or if you're working for smaller clients, even get the content, but managing the content in a way that's navigable and easily accessed or accessed by the end-user. That being said. What I've chosen to. (INAUDIBLE) Really today is mega menus. We'll talk about other types of menus as well, but mega menus that involve more than just menu links, maybe there's an image or some sort of excuse me, some sort of interactive part of the menu, that's not just an (INAUDIBLE) To another page, those sorts of things and recently, I've been contracting through esteemed as a contract developer for roberthalf.com on the productivity and vision projects that we're doing now. And one of the things that came up was we would like to use our site by nature of our enterprise sites, and they cater to the business-to-business type of user that's gonna be consuming our website and that's gonna have a lot of data, I mean a lot of content, a lot of pages, tons of blog posts, you name it, site maps that are just you know, huge in nature just because of the basically because of the size of the client and the size of their perspectival market.
So, going from doing boutique type websites where it might be for a small business owner that has a product or a unique niche or something like that, they may have like an About Us page, maybe some products and a few other links that are easily accessed. And then going through something of this size, which is kind of a monster is not something you can just do quickly and easily. And for myself, it takes a lot of, I think, a lot of research and a lot of reflection on past choices and things that I've done to get to where I'm at today. So, this is kind of a growing experience for me, as well as an experience that a lot of other people are probably on that same path and I wanna share what I know and by no means an expert on any of this. This is why I'm doing The Birds of a Feather, because I wanna hear from other people and what made them successful and how they chose to build the menus that they chose on their projects. So, by any means a disclaimer, what I'm about to tell you here is strictly my own personal experience.
It's not an example of best practices or worst practices or how to implement things the best or the worst. It's just a variety of things and what I've found to be usable for my project is what I will share. So, let's get started I have an outline that is on my get web page. I'm going to share that I just created it. And it's got a, let me see, it's got a outline of what we're about today so, I'll share that link here. It's a public link. If anybody feels like they want to add to it later or questions or any of that stuff by all means go for it. So, starting from the top after the biggest decision is making the choice. What are you going to incorporate in your website? Who is it for? Who's going to be managing that website? And ultimately, at the end of the day, who's responsible for making those updates? So, for instance, when you're creating a menu of any sort questions, obvious questions that you should be asking yourself are can a non-developer manage the structure of this website or can a site builder manage the structure, can the content team the marketing team, whoever.
If you're working for a corporation that has a completely separate entity, that does all the PR and marketing and stuff, are they able to use the website well, or is there some sort of intervention from your development team? In our case, specifically when I say our case for (INAUDIBLE) And vision has decided that we, the developers, would ultimately maintain our menu structure by request from our marketing teams. But in some other organizations, you may have a marketing team that wants to maintain the entirety of the content of the website on their own with very little interaction from their developers. In other cases, it might be that you're working with a small business owner and they don't have the resources to maintain the website. So, the trade off is that they would pay you for your time to help manage the website and vice versa. When you nail these kind of questions down on any scale, it helps you to determine how you want to implement your menu structure. The next question that you have to ask yourself, and then you should probably have some testing and feedback from others is, is it usable?
How deep does the navigation need to go? Do you need a (INAUDIBLE) And by the time you get through the menu, you're four or five fly out into it and you realize, did we really need all of that navigation. Is our navigation that granular? And, you know, over some time you may want to reduce the amount of links that are in a mega menu or in a long list. And that brings you to the next item. Is it easier to navigate? We have mobile phones. We have you know, responsive design first, mobile first. You really have to start to think about making that data consumable quicker or because a lot of times people will come to the site and they're overwhelmed with the navigation and they may go to a competitor's website and seek out the same information that you have, you may have the best information in the world, but if you're site not usable, then you're losing potential customers or potential (INAUDIBLE) Or whatever the case may be. So, you have to ask yourself, who is your audience? And I don't need to tell that to anybody that's ever built a website because you are the one that's responsible for gauging your audience.
And it may be through metrics, it may be through you know, polls. It may be through some sort of, I don't know, cooperative effort, aboard, maybe helps decide on who's using the website, that sort of thing. So, make sure, you know, just as a general rule of thumb, that you know who you're tailoring this website or menu to. The other two things that are very important in this and this is something that we are really hacking on quite a bit, that Robert Half is translation. You know, a lot of times people think that they should just make the website in English, and that's good enough then this day and age, that's not just good enough. You need to make sure that your website and your menus specifically were tailored towards several different languages. If that's your audience now, in some cases that may not be your direct audience. But in the case of what we're doing for activity, translation is very important. Jokingly, as I say, is your menu available in Klingon if it's not available on Klingon what (INAUDIBLE) Do it.
You know, you've got to make it where everyone can understand. And what are you doing in your menu as far as right to left based text. There are many languages that don't read from left to right. And sometimes you have to take that into consideration as well when you're designing a website that appeals to multiple cultures, multiple languages all over the world, and then of course accessibility. If you're dealing with an audience that you may not even realize you're dealing with an audience that's colorblind or hearing impaired, and those are the sort of things that people often take for granted when developing the website. And over the years, I've learned that it's much more important to make sure that your site is accessible than it is pretty or there's not really a mutually exclusive term there but just making sure that people that are trying to access the information can get it, can see it, can read it, can hear it. Those are some other things to take into consideration. So, that I'd like to open that up for any questions and comments, I kind of went through that a little quick (INAUDIBLE) I'd like to ask or add to that please do.
You can use either the chat window or you're welcome to unmuted yourself (INAUDIBLE) Yes please. And I'll open the chat here and see (INAUDIBLE) OK. So, (INAUDIBLE) I'm sorry, (INAUDIBLE) What determines the use or not of Mega menus in a project in your opinion? In my opinion, it's just been the sheer amount of content that's to be consumed. You've got some websites that are basically. Let's call them landing pages. They may have like a single service or a product they're trying to sell and a couple of ancillary pages that describe who they are and what they're doing and generally, they don't need more than you know, five to seven weeks, maybe 10 tops. But if you're dealing with the website that is multifaceted, sells many products or has very many different streams of content coming into it, whether it be white papers, blogs, articles, news, press releases and that sort of stuff, you end up with something that's bigger than just five to ten menu links. One of the best examples that I can give in this is from working as a contractor for a library market is a public library website, the public library website that will serve the entirety of its region from age five to 95.
And they have so, many different programs so, many different events going on at a library you know, they have rooms that can be rented at the library and so, on and they end up having a lot of different functionality on one website, and that level of interaction requires having some sort of a mega menu that allows people to drill down based on their interest, based on their research, whatever the case may be. I actually have a good example of one of those. I'm gonna put a link in here, one of that I built working as a contractor for library market. And you can just see how everyone has an option there you go to Handley Regional Library, you can see there's kids sections there, (INAUDIBLE) Sections there's on and on, and there's tons of stuff to do in a library. I mean, they're gonna search account. They actually have three different locations in the library. So, there's a drop down menu for each location to shows the hours and the time that they're at times that they're available. You've got research, you've got streaming media that you can download audio books, that sort of stuff.
And so, in this case it was you know, we kind of had to have a mini mega menu so, to speak. And I think that's I think basically the root of it is the variety of content and the sheer amount of content would determine whether or not I would use a mega menu or not. I'm looking at the chart here. How did I handle menu permissions for a library organizational structure. That one I would have to actually divert to one of my colleagues that I worked with there, I was mainly responsible for building the front end, mostly the Twig and the look and feel of it. But I will say this and interlibrary organization, there's generally a head of department. For each one of these types of interests, whether it's the children's department, it's the the research department, maybe there's someone that's in the genealogy that manages that department and all of the other services that come with the library. Generally, those roles are given and permissions are given a basically role based level. And a lot of multisite libraries, they may only give certain menus to certain departments based on their role and on their permissions list to manage it.
That makes sense. I hope I'm answering your question (INAUDIBLE) It's a very complicated type of thing. But when you're using a basic menu structure with Drupal and a core menu system with Drupal and permissions, as far as I know, there are some other distributed modules that will allow you to have granular control over certain menu items and who is responsible for maintaining those as a site builder. (INAUDIBLE) See here. Tabbing (INAUDIBLE) I'd like to add something. Sure. (INAUDIBLE) My name is (INAUDIBLE) I'm a freelance web designer. I got some very good points there. One thing that I learned on colour blind, a half a percent of women and I think eight percent of men have a red green deficiency. Yeah. So, if you put a substantive aspect of your menu and your cooking on colors that involves red and green, you're gonna be missing some people. Yes, That's a common thing people do. That is true. I know that a good friend of mine, (INAUDIBLE) He does he is like the accessibility king when it comes to designing what he actually does, the color design of a lot of these library websites that I had worked on in the past.
And I bet he spends hours a day, probably half of his day determining and going by guidelines for usability on color, and it's something that a lot of the time falls on your designer if you have a designer, but if not, there's a lot of good resources out there. And I'd be happy to share those resources in this document. I just didn't have a lot of that with me today, if anyone's interested. So, please you know, contact me let me know and I can share some of those resources for sure. Let me open my apple outline back up and let's see. I have one more comment in if I could. Yeah, no problem. Well, I took a look at your library site which is really hard to grasp because of all the content that's there. I think it did a good job with organizing with (INAUDIBLE) Et cetera, and then for the dropdown. So, they made a lot of information pretty accessible. But you didn't go you didn't have all that many things going across it down. And one of the questions that comes up regarding menus, what is better to go have a wide menu or to have a few and go deep?
And this question has been answered by a lot of people doing user experience research and the user experience research has usually said you're better off (INAUDIBLE) With fewer dropdown. So, the reason is the more drop down that you have, the more drop levels you lose people, especially people who are older, they can't follow, they can't follow the fly out. Yeah I 100% agree with that. Generally, my rule of thumb, if I'm doing a magic menu. I'm top level I'm gonna have most of the items across that the horizon there, and if there is a drop down, there's not gonna be another level under that. You've got one level for main navigation. The drop down would be your secondary level. And everything on that panel is gonna be one click away. I do not like digging through menus. Call me old. I don't know. Call me a boom or whatever. I don't like digging through menus just like the next guy. And I think that that usability that you're talking about is very important to keep in mind, no matter what project you're on.
And it's kind of hard. It's an unruly beast. It sometimes because so, many different people have input on what they think is more important than the other. I think that this link is more important than the sub headings and that sort of stuff. You get into some of that sort of, let's call it persuasive dialogue, if you will, and that, you know, that alone is very important as far as usability goes, and that's one of the things I have here is like, how deep doesn't have need to be. This is Chris. I wanted to interrupt and ask you the two things that was made regarding this (INAUDIBLE) Site and then the click on other comment. I think it is very material. I also wanted to mention that you know, I know you didn't have chance because you're presenting. But if you have a moment to take a look at that site, it actually does a fabulous job of exploring a couple of different issues here that are being brought up in subsequent comments, such as the bootstrap levels on click of the bootstrap method Et cetera.
And I wanted to say that. So, that example, though, if you look at the multi category, I think it's under solutions at this (INAUDIBLE) Make a ton of products, I'm sorry, very elegant. The way that was handled you know, it does it handles it in the fly out or second level in a pretty elegant way that I think you might. Yeah, there's no guesswork. You're not like, you're not using your mouse to chase the next element. Yeah. That's, pretty slick. That's, that is. That's a good example of going deep but keeping the menu shallow, going deep with your content to keep the menu actually shallow I like that. (INAUDIBLE) You wanna include a link to that in the chat. Yeah, I think let's see, (INAUDIBLE) Posted a link to that. I beg your pardon it's already in there. Yeah, no problem. Let's see here. So, we've gone through usability, we've gone through translation, I don't have a whole lot of examples of translation if in a menu I just know that at the moment it's for us, it's very important because Robert Half has 16,000 plus employees and it serves many countries all over the world.
But one of the things that I did wanna talk about. With regard to everything we said are the different implementation possibilities so, I've kind of narrowed this down to three, basically, and a bonus with two of them being more or less kind of the same with just a little bit of difference between the two. You've got tweet based menus with entities, and then I have a role your own menus, and then there's the use actually there's four here, there's the use of contributed modules. And then something that I found just today for one of my team members, that productivity of the Drupal core initiative for decoupled menus in Drupal. And so, starting from the top Twig entities is the way that we're going with our current project is basically what that is, is there's a a module called menu item extras and menu item extras allows you to take a normal Drupal menu item so, let's say you create a link in the menu and it allows you to use layout builder and actually create a layout specific to that menu item or the whole menu itself.
You can do either or both. What we've done with it is use let's say we've got a mega menu that's three columns wide, one column we wanna have maybe the drop down, actually, if you wanna take a look at what we modeled after (INAUDIBLE) Website it's not (INAUDIBLE) But it's the site that we've used to model our specific menu (INAUDIBLE) Posted in here and that's a long week should have just kept the. It's (INAUDIBLE) Their business service industry, their mega menus, when you hover over them. On one column, you have what's new, and that's basically their news and blogs, well news and blogs and articles and any kind of other entity aren't necessarily menu items. But if you wanted to put those in your menu, like maybe you wanna have your five most recent blog post menu item extras actually allows you to override the layout of an item itself and placed blocks into a layout around the menu items or within the menu items, and it gives you a lot of flexibility to maintain a true Drupal core menu, but give it an extra feel with layout so, you could do columns of secondary links.
You could do blocks of secondary links. Their possibilities are virtually endless because you can use a paragraph, you can use a block, you can use it is block based if you're using a layout builder. So, you know, it has to be (INAUDIBLE) In a Drupal block. But you can use many item extras to make that happen. And I have several articles in my document that reference that if anybody wants to study up on that, this is one of the many ways that you can implement a mega menu. Now, the trade off on that is, it's more developer centric. And maybe high level site builder, centric so, it's not like something that just anybody with no Drupal experience can just go in and move the menus around and make it look nice. I see here that it complicates things for translation, but we haven't found that to be the case because we're basically using Drupal core menus and they're translatable. But all of the blocks that we're creating that we use in our menus are easily translated as well. And because of choosing Drupal core system with translations, we've not run into a problem with that.
I would like to hear your reasons (INAUDIBLE) For why that would be complicated for translation. But it's actually one of the reasons why we chose to go this way was that it was for us easier to implement translation. So, it's interesting I'd like to see your point. Hey, yeah. So, my point on that would be, yes, it makes everything translatable, but that is a bit of overhead when you're actually trying to keep control of that translation (INAUDIBLE) Because now they have to go through a process of asymmetric translations some instances, yeah so, (INAUDIBLE) The main issue. I see what you mean. And I think that's probably why we chose to keep the menu, any menu edits or any menu changes within our development department. So, you're right, menu item extras and with layout builder. If you're a bit squeamish to the Drupal management, site management side of things and maybe don't have quite the grasp on it, it's not for the faint of heart. It is slick. It works out. And like Josh is saying here, it's like a website inside of a website.
I agree. It truly is like a website inside of a website it's one of those things that. You know, I don't think a lot of people like to create huge mega menus, but then there are a lot of things that are depth by committee as well. So, when you're dealing with what the customer wants versus what you think is best for usability, sometimes there are some trade off there and like places hoping it gets addressed and core, that would be fantastic. And we'll touch on that a little bit. There's the tuples initiative for decoupling menus that everybody should watch the video for it's pretty inspiring. So, but yeah, I have to answer you on translation. We chose it that way, but we chose it that way because we are ultimately the ones responsible for building those menus, whereas in another instance, if someone if you're passing this website off to someone that's got little to no training on it or has no idea what to do, it might be a bit of a learning curve for sure. The other option is to roll your own, and this one is even more of a bear when it comes to translation and accessibility, depending on what you consider to be roll, you're own.
I've seen websites where a menu was written completely in static code and did nothing to address or integrate Drupal's core menus. I don't know why. I think that would be probably the worst case of building a menu, but for some people that have built websites, they felt the need to create basically the most basic navigation possible, and it just goes to links that have been hard coded into the template. Of course, you run the risk of detrimentally compromising your accessibility, manageability and translation if you don't write it to be easily managed or translated or accessible. One of the other ways that people are getting by with and is to use simple Mega menu, you TB mega menu or we-mega menu contributed modules for developing a mega menu. Now, I personally like these. I think they're great TB mega menus is a very ambitious project and. If it works for the end user, it works phenomenally, it's drag and drop, it's you know, there's a lot of guesswork is taken out. You're able to create hierarchies of links pretty easy you know, for the usability side of the site builders it's really good.
The problem that we ran into with contributive modules is purely from a developer standpoint, and that is. We are writing a custom theme and a lot of these contributed modules make some fairly good guess that styling, but at the end of the day, it's more (INAUDIBLE) That we end up having to override or include in some way and (INAUDIBLE) Completely custom theme that we're trying to build. It didn't make sense for us on our specific project that we're on now to use the simple mega menu or TB mega menu or the I think it's we-mega menu which is called like Drupal Mega menu or something like that. I searched all three of those, trot them out. But the requirements for my project required us to use pattern labs and our own custom theming comes along with that. And so, I was running into a lot of cases where I was using exclamation important on a lot of elements that I was trying to style. And we ultimately decided not to use this because the decision was made that our development team would be managing the menus at the end of the day anyway.
And so, for someone that's building a smaller website that needs a quick, nice looking menu that's easy to manage on the back end. I wholeheartedly believe in using TB Mega menu for that, in our case, it just wasn't, it didn't fit our purpose basically. Does anybody have any more input on that on those modules, or I know Paul mentioned there are some fellows here from TB mega menu before we started. Will any of you like to address maybe a solution for us if we were to decide to use TB mega menu instead of embedding entities in our and using (INAUDIBLE) And menu item extras. The only hurdle that was the (INAUDIBLE) That comes with it. That's real interesting to hear (INAUDIBLE) I took a note of that, I didn't see I don't see any of my other (INAUDIBLE) Colleagues that had been directly working with the module. They picked it up. It had been languishing and hadn't been supported for a year or so, and they picked it up a couple of months ago and started addressing the the bugs list within I interestingly, I worked a bit with them retrofitting the D7 version of it.
They're still working the D8 ones. But I'm glad that you're calling them out because it's it was a great module. And now that it's being worked on again, we're hoping to make it even better. More accessible is one of the main points that they're trying to work towards the this next D8 release. But I will take a point that you found it a little bit challenging. I know that it will add quite a lot of markup to do what it needs to do. And if it is not easy to get accustomed thing to work with it. That's an excellent point that we'll take a look at. I appreciate that. I'm gonna address some of the comments you're seeing. (INAUDIBLE) Says in terms of accessibility, the ability to navigate a mega menu with a keyboard is an object that you can sooner will roll your own mega menu (INAUDIBLE) I do agree with that. That's not something that I had considered Jeremy, but that is something that a lot of people may overlook that using keyboard shortcuts and I've been on some websites that have real nice keyboard shortcuts for navigating sites which is supercool.
That's one of those things that I think does get overlooked and we need to consider that in the future. Chris has an article from Phase two Technology. Chris, that's exactly what I was talking about when I was talking about using menu item extras. I actually have that phase two technology article and my reference link at the bottom of the show notes. So. Nice so, I can reset the Internet. Your good. That was very first. (INAUDIBLE) Wrote that article and that's the very first article that I found on my journey to using Layout Builder to build menus. And at first I ran into an issue where I had to patch a menu item extras. There were a couple of modules that were acting a little wonky, but we got it worked out. And now and I believe that that has been committed. So, everything's working fabulously with that. If you're a big fan of layout builder and you're using that all the time, anyway, we've actually designed our mega menu to make it where you can do that, just like the article reads (INAUDIBLE) Layout builders eventually going to become ubiquitous.
Yes, (INAUDIBLE) They could. It might be an easier argument to make to use something driven by it than something custom. It's ultimately you have to train the customer to use you more, just have to point them in the right direction. That that's a good point. And (INAUDIBLE) Coming from a background of building a public library websites. Those guys build I don't know how they build websites so, fast but library market builds amazing website. I was there right before (INAUDIBLE) Started working, and that's when I built Handley and Metro Public Library. I think we did those three websites in about two weeks record time. And then (INAUDIBLE) Came on board as their (INAUDIBLE) I was there (INAUDIBLE) As a contractor. But yeah, you're right. Training the customer at the end of the day, it's about communication as well. So, the customer can use the layout builder, they can build a menu using it. That's great to see. I have to roll my own from. Man, yeah, OK. (INAUDIBLE) Is doing a roll his own.
That's hats off to you man so, that I understand. OK. At the end of the comments, let me get back to what were your talking about. So, you contributed module's this other than TB mega menu, which I've used it in the past because I ended up I can't remember exactly what project I used it on, but we used it a long time ago for Drupal A project. It's, I'm missing it in my head off the top of my head. But those drag and drop contributed models are fantastic for this kind of stuff. If you're just building a website, that's got to be done pretty hastily or you just want easy to use (INAUDIBLE). The last thing I'm going to post a couple of links here that (INAUDIBLE) Work with (INAUDIBLE) And he showed me what DrupalCon Initiative decoupled menus is up to, and Dries state of Drupal presentation from December of 2020, touches on it and then there's a video. And I've also included the document, the Google Docs on the, for the task force that's trying to get all of that together. So, if you guys want a little apocryphal reading or something to check out I've posted those links here in the chat, but I'd like to open it up.
I see a lot of people are posting a lot of different things here. One of the, I can give a couple of other examples where I had to build a menu with a lot of the different subject areas, especially when it comes to commerce, like E-commerce. When you're dealing with lots of product categories, that's another reason that I have to use a mega menu. When I built a home outlet with Brandon (INAUDIBLE) That was one of the biggest feats that we had to overcome (INAUDIBLE) Is to make all of the different departments of products that we were selling, (INAUDIBLE) Company available. And at the time, we had 4,500 different products in several hundred different categories and we tried really hard to pare it down to where we had your main five links about the website so, you could go to the homepage, you got your store locator, and then we had DIY articles, which is basically a blog about home improvement and then the free services that were offered at home outlet. Those were easy because those go directly to a one link page where it got really hairy is when we started getting into the shopping aspect of things.
We were working with (INAUDIBLE) Commerce guys at the time. And when it got to the shopping part of it, we had a lot to overcome. And there's still some room for improvement I'm sure, I'm not on that project anymore. But there was a need there for a mega menu. It was pretty simple. And the fact that we created menus using basically the Drupal menu core system and some custom Twig to render those secondary links in the columns that you see there. But that's an example of doing it without using menu item extras, which wasn't available to us at the time, I'm sure, had we been able to use something like that in the layout builder we might have had a different approach, this site's nearing, I think four years in age or three years since it went live so, that at the time the decision was made to just make every product and every category available from the get go when you hit (INAUDIBLE) So, you can see it all there. But I like this link that (INAUDIBLE) Shared about Adobe accessibility, accessible mega menus that's pretty awesome.
I'll have to keep that one in my hat. Does anybody else have any questions or comments or ask me anything I'm here. OK. I'm actually to keep the server link in place because that is the other way to relate the menu script, which is like eight years old or so, it doesn't work with (INAUDIBLE) So, that's clearly still being reference as a good starting point for all the tab and arrow key navigation or their menus don't have all of that in place. So, somebody (INAUDIBLE) Addressing some accessibility upgrades and then we did a fork of that fork to make it what we take (INAUDIBLE) So, that's the last link I sent there. I see that that's sometimes if (INAUDIBLE) Don't fix it. But man, that's an eight year old project but I guess. That's what you have to use. You have to use it. It's interesting, though, that it's got all the guidelines outlined for accessibility, probably a good resource for anybody that's really obsessive over the accessibility aspect of the menu. Alright. We'll have to share this with a couple of my friends as well.
Yeah. And somebody mentioned in (INAUDIBLE) About clicking menus versus hover we have adapted the script to the hover stuff instead of clicking so, it's simple enough where you can change it that way. Right. And that's another thing to get to. You're right. One of the things that we're working on is click verses hover. Obviously, when you're on an iPad or or tablet and you're not clicking anything you're tap, you're tapping on it. So, you have to make behaviors like that work. You have to make behaviors like that work for different devices and keep that in mind as well. A lot of times, if it's not done right, you end up having a double tap on a menu, on a website, on a tablet that's annoying too. So, a lot of good, there's a lot of good information to come out of that as well. (INAUDIBLE) Anyway, before I sign off here a little bit, I know we're getting close to time. Yeah, I can see that Josh double click (INAUDIBLE) Everybody. It confuses everybody in this day and age 20 years ago. Double click on everything.
Right. If you guys wanna take this conversation over past the hour, you're more than welcome to join us in the esteemed chat room. I'm gonna post a link here to invite anybody that wants to continue to discuss menus, I hope that what have given you guys here today and hope and what you've given me is something that is useful for everyone when you're trying to make a decision on what to use a basic rules of thumb are, keep it unsophisticated, just you know, it's easier said than done, saying keep it simple, stupid, but keep it simple. There's no reason to overengineer a menu, especially now that we have a lot of these different devices that are, that don't really give to that, like there's so, many tablets and things like that, nobody wants to chase two, three, four levels of linked deep on a menu. So, if you can keep everything up front and keep it right in front of the viewer or the user, that's that's the better. Like the link that (INAUDIBLE) They've got deep menu. Deep link levels, but they've done it in an organized way with tabs on the side, that makes it easier because the menu's right there in the view (INAUDIBLE) Above the fold so, to speak and you're not chasing a menu link.
So, that's my best guidance. And I really appreciate everyone for joining today. I hope I didn't bore anyone to death. I'm generally a pretty happy go lucky guy, and I appreciate Mid-cap for having me. It's been an honor. And there's a few people that I'd like to thank as well. One my wife, she's patient with me, work from home and she works at a bank. And a lot of times our hours are not exactly the same. And then I would like to thank (INAUDIBLE) He pushed me out of my comfort zone a long time ago, made me become a better Drupal developer. And I'd like to thank Andre, Angela Tony for believing in me. He hired me on. He was part of the process for hire me on (INAUDIBLE) And then I'd like to thank esteemed the productivity team, library market Drupal Mid-cap, (INAUDIBLE) Company (INAUDIBLE) And phase two. They were all elemental in the decision making that I had to make these mega menus for the project I'm on now and have been a benefit to me in the past. And so, thanks everyone. Well, thank you (INAUDIBLE) That was great.