Responsive Navigation On Complex Websites

Advertisement

Central to a solid user experience is a well-structured, simple navigation system. Over the past few months, I’ve been involved in launching two large institutional websites with complex navigation systems. Maintaining simplicity on such large websites becomes increasingly difficult as content requirements grow and tiers of navigation are added, not to mention the extra complexity added by small screens.

To illustrate the techniques involved in implementing responsive navigation on a large website, I’ll refer to two actual clients of mine. I’ll start with the process and how to get through it with research and mockups, then later get into some of the actual code that was used.

Middlesex-London Health Unit

The Process

The key to success in every project, particularly a large website, is to work closely with the client, keeping them involved in as many aspects of the design process as possible. Before we get into code and how to build a website technically, we need to learn more about the project. At ResIM1, we start with audience research, before progressing through information architecture2, wireframing3 and wireframe usability testing.

In our latest project for a public health organization, the Middlesex-London Health Unit4 (MLHU), we started with audience research to find out the kinds of information that public users look for on health-related websites. Considering that MLHU’s website had over 1300 pages to be overhauled, we needed to make sure that priority content gets the focus it deserves.

As a design studio, we’ve tried different forms of audience research. One of our go-to methods is to bring in users to walk through a wireframe website, seeing how long it takes them to perform various tasks and to find various sections of the website, while video recording5 them. This style of testing doesn’t always yield perfect results because many inexperienced users will have problems understanding a website without graphics, colors, etc. But it still provides valuable insight into how easy or difficult content is to find.

This method works well when the structure and site map are defined, but we weren’t quite at that stage and needed to step back. MLHU has various committees and groups that had to be represented on the website, and we needed to make sure that everyone’s voice is heard.

We started by meeting with all of the committee members who were appointed to work on the website, to determine which parts of the website were most important. After hearing each group state its case as to why its information needed to be prominent on the website, we started to build a proper hierarchy. We realized there were a lot of different sections and areas, and we needed a way to group them into fewer parent items in order for the user to be able to interpret and navigate more quickly. We decided to piece together a lot of similar categories, and we named each of these groups; these would become our four main navigation items.

This was a great accomplishment, but we quickly realized that we needed to call attention to other important pages that weren’t necessarily grouped into those four sections. We created a supporting menu to accommodate and provide access to some of these non-health-related topics. Once we had built this streamlined navigation and worked it into our wireframes, we ran them through a testing period, in which we had users walk through areas of the website, performing tasks and finding information.

Watching people use this streamlined navigation, we noticed that each of them was able to quickly find the section of the website they were looking for and then effortlessly find the particular page and information they were after. These results from real-world users reinforced the decisions we had made in the information architecture.

MLHU site map6
MLHU’s site map. (Larger view7 | Source14128)

From here, we were able to move into the interface design phase, which included mocking up the responsive mobile view. Many clients struggle with the concept that a responsive mobile website is, in fact, the same website they see on their desktop, and not a whole new skin for mobile. Showing these clients a little less in the mockup phase is sometimes valuable.

For this reason, we typically leave tablet views out of this step, to enable us to control how the website transitions from the big “desktop” view down to the small “mobile” view. In the case of MLHU, I realized with the older ages of some of our target users, we couldn’t rely on typical top-right hamburger-style9 navigation.

Feeling that this solution would have been more difficult for certain users, I opted instead for vertical text-based navigation. This gave the second level of navigation a better layout, by allowing users to view all menu options before making a selection.

MLHU website on mobile10
MLHU’s website on mobile. (Larger view11 | Source14128)

Implementation

Our initial concern in the MLHU project was whether we could keep the mobile navigation structure congruent with the desktop version. Typically, one can hide navigation under a hamburger-style button, a common design pattern. However, our target audience included a wide age range, and we felt that displaying the full text of the navigation would be more user-friendly.

If we were to keep the navigation the same and then make some CSS adjustments to wrap the navigation in a box and stack the navigation vertically instead of horizontally, we could achieve the solution we were looking for.

@media only screen and (max-width: 600px) {
    nav li {
        width: 100%;
        box-sizing: border-box;
    }

    nav a {
        background: rgba(0,0,0,0.5);
        padding: 10px 12px;
        text-align: left;
        margin: 0;
        box-sizing: border-box;
    }
}

MLHU Mobile Navigation13
MLHU’s mobile navigation. (Source14128)

A JavaScript-based solution for our desktop navigation interaction was in place, using the hoverIntent plugin15, but we needed to adjust it to work properly on mobile. Our solution was to add a condition to check the screen’s size and, if small, to switch to a toggle slide instead of a hover fade in/out. A toggle slide gives a more native feel to the website, making it fit in and feel quicker on a mobile device, whereas a fade can feel slow and unresponsive when interacted with on a touchscreen.

function navIn() { 
    [...]
    } else if($(window).width() < 600) {  /* Here's where we check for the screen size and do a slide instead. */
        $(this).children('ul').slideDown();
        $(this).addClass('hovering');
    } 
    [...]
}

Seneca College

The Process

A second instance of our process was the design and UX overhaul of Seneca College16’s public website. We couldn’t reduce the main navigation as we did with MLHU because of different content requirements and organizational constraints. We didn’t need to work through an information architecture phase because the navigation was already set for us by the client; so, we moved right into wireframing and interface concepts. Similar to MLHU, we also mocked up a responsive mobile view and explored ways to display the navigation in an effective format.

Recognizing that this target audience is much younger, I felt strongly about using a streamlined navigation that is revealed via a hamburger-style vertical side menu. The hamburger icon has become popular through its use in many mobile applications, and it frees up space in the website’s header for the logo and search icon. A lot of sublevel pages needed to be displayed on Seneca College’s website, and showing them all at once in the header navigation would have been a bit too much.

My solution was to display sectional navigation at the top of every inner page. This secondary navigation would allow the user to quickly move through sections of the website without having to scroll through a long menu. With the complexity of a large website, making it navigable before showing the main content on the inner pages is sometimes necessary.

If you’re unsure of which route to take, try doing some extra audience research using mobile wireframes, and get a feel for how real-world users respond to the solutions.

Seneca website on mobile17
Seneca’s website on mobile. (Larger view18 | Source242119)

Implementation

Seneca’s navigation system is more complex and its mobile and desktop versions more different from each other than MLHU’s. We needed to find a way to replace the main navigation with a hamburger icon once the screen reaches a certain size. We started with a div for the mobile navigation that sits inside the header, but we didn’t want it to show up in the desktop view, so we hid it with CSS.

<div id="mobileNav">
    <a id="searchIcon" href="#"><img src="/images/searchIcon.png" width="24px" height="24px" alt="" /></a>
    <a id="mobileNavIcon" href="#"><img src="/images/mobileNav.png" width="38px" height="20px" alt="" /></a>
</div>

Seneca Mobile Nav DIV20
Seneca’s div for mobile navigation. (Source242119)

#mobileNav {
    display: none;
}

For screens that are big enough, we display the aforementioned hidden div using media queries.

@media only screen and (max-width: 600px) {
    #mobileNav {
        display:block;
    }
}

At the same time, we restyled the navigation and hid it. Feel free to get creative with restyling the navigation for mobile. I wanted full-width navigation that slides down, pushing the rest of the content, but you could instead absolutely position the menu to overlap the main content, or achieve an off-screen push effect using something like PageSlide282622. Many different techniques are possible; experiment with what you like and what feels best for the website.

@media only screen and (max-width: 600px) {
    nav {
        display: none;
        width: 100%;
        background: #000;
        margin-left: -20px;
        padding-right: 40px;
    }

    nav li {
        display: block;
        margin: 20px 0 20px 20px;
        width: 100%;
    }

    nav a {
        color: #FFF;
        margin: 0;
        width: 100%;
    }
}

Lastly, completing our toggle is simply a matter of adding some JavaScript, similar to the example above.

$('#mobileNavIcon').click(function () {
    $('nav').slideToggle();
    return false;
});

Seneca mobile navigation opened23
Seneca’s mobile navigation opened. (Source242119)

It’s imperative to make design decisions that enhance the user experience by considering the results of usability testing, the perceived skill level of all user sets, and the general characteristics of the audience. As demonstrated in the cases above, even though a hamburger-style menu icon has become the industry standard25, it might not be the best approach given the age or competency of the target audience.

Other Techniques

I’m always looking for new solutions to the problem of complex navigation. Below are a few examples that could be really useful, depending on the requirements of the project.

PageSlide

I like that PageSlide282622 follows the current mobile app trend with a pull-out side menu. Users are getting more comfortable with these menus and how they work. The benefit is a much taller scrollable menu that doesn’t push content too far down.

Responsive Multi-Level Menu

Responsive Multi-Level Menu2927 is great for a few reasons. It mimics normal drop-down navigation, which is usually triggered by mouse hovering, and implements it effectively for touchscreens. It also makes it easy for users to jump down a few levels without forcing new pages to load.

Conclusion

Making design decisions based on your users should be paramount. If you aren’t involved in the initial design phase, then at least try to get involved in the responsive portion of the project. You need to help make sure that the direction taken is in the best interest of users, based on their comprehension of the systems you plan on using and their ability to access content.

Next, determine what code is needed to make a smooth transition from desktop to mobile. Does it require some JavaScript to animate nicely? Does its orientation need to change from horizontal to vertical? What can you do with the initial CSS to allow for an even smoother transition that requires fewer adjustments to media queries?

Lastly, don’t let a complex navigation system or information architecture intimidate you. There’s always a way to simplify it to its core and to provide those layers to the user in a way that is non-threatening and easy to understand. Take on the challenge and have fun with it!

Other Resources

You may be interested in the following articles and related resources:

(al) (ea)

↑ Back to topShare on Twitter

Jon Rundle is a senior interface designer and front-end developer at ResIM; a Canadian web and mobile development shop. He has experience working with a wide range of clients including Samsonite Canada, 3M, and Seneca College.

  1. 1

    A nice article showing the theory behind doing responsive menus.

    Maybe something you should look at though is the implementation of the menu on MLHU website, its really not user friendly.

    Clicking to close a menu item actually jumps you to another part of the website, then trying to click another menu item when one is open, does something else entirely.

    To me, getting these things right are far more important than anything else, you get that wrong, people just leave the website being pissed off.

    1
    • 2

      Great point Alan. To be completely honest I spent a lot time just working on using the navigation to jump through the pages and not on looking at opening and closing the navigation. That’s something I’ll be sure to implement in future projects. Thanks!

      0
    • 3

      that’s right. the transitions are too slow or too much I believe.

      0
  2. 4

    Quite informative and very well written article.

    0
  3. 5

    Thanks this was really interesting! I do have a question about your approach, in the text you state the following;

    “Our solution was to add a condition to check the screen’s size and, if small, to switch to a toggle slide instead of a hover fade in/out.”

    Why did you make the choice of checking for the width of the screen instead of using feature detection(touch)?

    0
    • 6

      Thanks David! Great question, normally using a feature detection for touch would be the way to go but in this example I was using it to change how the navigation animated to reveal the navigation. In my experience and testing the hoverIntent plugin does a great job of handling the touch vs. non-touch/hover events. Because of this I only needed to check the size to change to a slide up and down instead of fade in and out based on the way the design changed below 600px. Again great question though and something to keep in mind for future projects and implementations.

      0
      • 7

        Good answer, thanks!

        0
      • 8

        You can’t detect touch screens correctly anymore: http://www.stucox.com/blog/you-cant-detect-a-touchscreen/

        I have yet to try this technique, but I think it would work… Basically the big difference for touch devices is when a link has a sub menu, the first click needs to open the menu. Then if they click again, they are taken to that page… Since we can’t detect touch devices correctly, why not use the hover detection instead.

        My idea is to have an invisible button over links that have a sub menu and with CSS, you put a display:none on them on hover. That way, on desktop they just wouldn’t be clickable. On touch devices you put JS that will toggle the sub menu on first click, and then a second click would click on the link.

        I’ve been really frustrated with nav plugins. In my opinion, out of the box, they should support mobile, be cross browser and easy to style and allow multiple levels. If anybody’s interested, I started to make such a plugin and would love to have some more people to help out: http://rogertheshrubber.github.io/boringNav/

        0
  4. 9

    For the Hamburger menu icon, instead of using a Rasterized PNG you could use the character ‘TRIGRAM FOR HEAVEN’ (http://www.fileformat.info/info/unicode/char/2630/browsertest.htm)

    Also look into the Icon font IcoMoon (http://icomoon.io/app/) as it contains both a Magnifying Glass icon and The ‘Hamburger’ style icon. You can build a web-font just using the two characters you want which will bring the file size down. This will make them scalable on any browser that supports font-face.

    0
  5. 10

    Great insight, Jon. Thanks for repping London on the WWW!

    0
  6. 11

    This is a very helpful article — but I have a question about the second technique mentioned, which involves building 2 nav structures on each page (one for mobile, one for desktop) — this seems redundant. Instead of building the nav twice, couldn’t you have found a way to use one consistent block of HTML for the nav and just restyle it based on media queries? This part felt like it was going against the “spirit” of responsive. If I misunderstood what you did, feel free to correct me. Thanks!

    0
    • 12

      Thanks Michael. Maybe I didn’t fully explain what I was doing there but it’s not in fact another navigation structure per say. What I’m doing is creating a HTML block that includes just the icons for the mobile hamburger and search. I’m using the same navigation block that is used in the desktop view just restyled to fit mobile better via media queries. I am open to suggestions though on finding a way to nicely add in those icons at the smaller size using just CSS.

      0
  7. 13

    I wonder how many companies have done studies on responsive navigation. We’ve done our own and what we found is that the majority of people over 50 can’t find navigation on responsive sites because the people that build them condense it down into three or four little lines without any text describing what those lines mean.
    They miss it entirely and just click on images in the main content area. If there are no images or buttons of any kind, they don’t know what to click on.
    Just something to think about.

    0
    • 14

      Definitely! Exactly why with the MLHU we wanted something that wasn’t just a hamburger icon and was the exact text navigation. Great point.

      0
  8. 15

    Great stuff. I’ve been working on massive small screen navigation solutions for Drupal for a few years now. You can never really get the perfect solution it seems, and there is always a different implementation to try out.

    A few things to keep in mind..

    1) On some phones, when you look at the main navigation (I’ll use the Health Unit as an example) you see some arrows that symbolize a drop-down. The assumption when you click on this is that you will be presented with a sub menu, but in reality, what happens is it takes you directly to the page (Chrome on Android)

    2) Another thing to keep in mind is the use of transitions. Obviously great for leading a users eye as something important happens, but the problem arises if the animation is too slow, or if it just doesn’t perform well on a device. It actually ends up becoming a hinderance for important content or UI (like navigation) and creates “eye work”. Your eye needs to dance around to orient itself because of inconsistent movements.

    3) As for the hamburger icon / navicon / trigram (There are a number of them that look similar) there have been a number of articles talking about the usage of this over the past year and it’s popularity. I think a number of organizations (Google, for example) use this icon to use as a navigation cue.

    Thanks for your article!

    0
  9. 16

    Another point to mention is the lack of a fall-back when no JavaScript is available. Now, most will say “Who doesn’t have JavaScript support these days?”. Well I read a nice article that tells you all you need to know…http://www.punkchip.com/2011/03/why-support-javascript-disabled/. I am a firm believer that you should always support JavaScript fall-backs.

    0
    • 17

      That post was made 2 years ago… A lot has changed since then. Maybe you should cite a more recent article?

      0
      • 18

        Technologies change a lot faster than user habits do. People don’t upgrade browsers, or use devices with browsers that do not support javascript at all. There are also plenty of plugins that allow users to block JS — I have been using NoScript since its earliest incarnations to make my browsing experience more pleasant.

        0
  10. 19

    Jon, it was quite interesting hearing about how you guys walked through two different mobile UI projects.

    I think the patterns you chose for MLHU are particularly interesting. Changing the navigation to display the four main sections large and up front is (likely) a huge help for folks on a small screen who want to find something fast. Swiping through the locations/phone #’s at the top is a nice touch, too.

    I’ve been looking at many of the resources you listed above (This is Responsive, Codrops) and think there’s some good ideas in your work. Thanks again for the write up.

    0
  11. 20

    This might be OOT, but I think there is a typo in this paragraph you might want to correct it. The MHLU supposed to be MLHU, right?

    “A second instance of our process was the design and UX overhaul of Seneca College’s public website. We couldn’t reduce the main navigation as we did with MHLU because of different.”

    0
  12. 21

    Great article. Such large sites can be very daunting and I like how your solution first involved organizing the information before starting the designing process.

    When I was a pup, I always wanted to get into the meat and potatoes of a design, only to learn in time, that when I kept having to change my designs over and over again, I could have bypassed all that misery if I had taken the time and planned projects out ahead of time.

    Now, with common SDLC in place, it’s only natural to plan, design, develop, publish and support the project. Also, I love that Responsive Multi-Level Menu! Great find!

    0
  13. 22

    Hi Jon,

    Great piece, and having been through the same process myself – I ended up rounding up all the different responsive navigation solutions I could find (others may find this useful):

    http://exisweb.net/incredibly-useful-list-of-responsive-navigation-and-menu-patterns

    Two of these navigation patterns I have used in production sites. The one thing I’ve noticed in researching this: users click on navigation menus FAR LESS than what you presume they do. One one site with an overall bounce rate of around 60% I did A/B testing and found that only about 1% of visitors even clicked the menu icon. When we used the word “MENU” instead of the hamburger icon that click rate lifted to about 1.5%

    0
  14. 24

    Totally agree with the main points here: get users involved early and often, and keep the client in the loop at all times, but also control that loop.

    I’m not a fan of working desktop to mobile, as it looks like you have done. It seems counter-intuitive, and I think starting at your smallest size and working up, and making decisions that way makes more sense. But to each his own.

    The Seneca site is nice, although the navigation animations seems a little slow to me, the dropdowns and red hovers especially. They feel cumbersome and those few tenths of a second really drag. The Seneca homepage also seems to break entiely with JS turned off. Is this intentional? Did Seneca’s analytics suggest that suppoting non javascript users was not important?

    0
    • 25

      Hi Mazurka,

      Thanks for the feedback, I appreciate it and I should probably dig further into the analytics on non javascript users. As for the mobile first approach I can appreciate where you’re coming from and in a lot of cases that can be the best way to go. For me on both of these examples I was able to see in the clients analytics that mobile, while still very important, doesn’t have near the amount of traffic that the desktop views. Because of this I decided going with a desktop to mobile approach was better as that would represent the bulk of the traffic.

      0
  15. 26

    Good article, I’m in the process of using different navigation systems on mobile devices. It was good to read your strategy and implementation process.

    0
  16. 27

    These comments so far are great! Awesome resources, questions and techniques being posted. Keep it up!

    0
  17. 28

    Thank you Jon Rundle for this beautiful article!

    0
  18. 29

    Duplicating entire menus simply so you can hide/reveal one of them for mobile desktop is far from ideal.

    Why not just transform the appearance and positioning of the same menu?

    Watch a screen reader user trying to make sense of multiple, duplicated, menus and you’ll see one important reason to not do this.

    0
    • 30

      How about “aria-hidden” for the duplicated content?

      0
    • 31

      Hi Seth, Not sure if didn’t explain this properly in the article but the duplication isn’t really a duplication. It uses the exact same navigation menu as the desktop version and nothing is copied. I’ve just added a hamburger and search icon in a hidden div that’s displayed at mobile size as a means of activating the navigation menu. The menu is changed in appearance and position from the desktop version down to the mobile version. The menu itself isn’t duplicated so hopefully that confusion won’t cause a problem.

      0
      • 32

        Thanks Jon,

        I probably didn’t explain myself properly, I was referring to #subNavContent and #subNavMobile…

        0
        • 33

          Ah, right, sorry about that. Ya there’s different ways that could be accomplished and you’re right it should be done in a way that doesn’t have to duplicate the content. I’ll keep that in mind. Thanks!

          0
  19. 34

    Great job. Those websites do not seem like they would be an easy task to finish. Couple of comments:

    For the MLHU website – the horisontal slider on the homepage is *exceptionally* slow on iPhone 4. May I suggest you add

    -webkit-overflow-scrolling: touch;
    transform: translateZ(0); /*(with browser prefixes)*/

    ?

    For the Seneca website, a design/aesthetic observation: the blurred header image makes perfect sense on the desktop version since it is a background for the whatever promo material comes on top (this is a very powerful and beautiful way to display content, I use it a lot on my websites). But on the mobile version – blurred background is all I see. It gives me no content, it feels as if the website content is below the fold. Something needs to be on top of it or it has to go.

    0
    • 35

      Hi Dmitri, thanks for the feedback and suggestions! I’ll definitely look into that option for the slider and try it out. For the Seneca project the client has access to a CMS to make changes to the banner and other parts of the site. They’ve changed a little bit since we first launched the project and maybe this is something I can bring up with them to keep in mind for mobile. Thanks again!

      0
  20. 36

    Great piece. I have learned a few ideas from your design/project process. A few issues with the navigation of MLHU.

    I’d expect a dropdown when i tough the arrow but i get very confused because the it actually drobs down and then takes me somewhere else where I need to use another dropdown. I’d suggest the dropdown drops down and wait for a click from the user. On devices that have a hover-ability, once you hover it drops down and waits for the next action but most smartphone will not be able to do that. (Just a thought).

    Seneca – Good for me. I like the flow.

    But all in all, a great piece and a good process… Cheers

    0
  21. 37

    On MLHU “Sub Navigation” is really poorly thought out. You might as well have just called it “miscellaneous stuff here don’t bother clicking me”. I’m curious if anyone actually uses that. I sure wouldn’t.

    On Seneca the menu is only a couple links, why even hide it at all. I don’t understand why you’d want a homepage with nothing but a photo and force people to click the menu every time before moving further into the site.

    2 bad examples of responsive menus.

    0
  22. 38

    Inspirational Pixels

    September 13, 2013 2:48 pm

    I think this article really highlights just how important responsive nav design is and shows just how much consideration it deserves in the context of mobile content.

    0
  23. 39

    Yesterday i wrote CSS3 Menu Slider https://github.com/b3ckstage/CSS3-MenuSlider
    Much better approach then PageSlide.

    0
  24. 41

    Nice work on the Middlesex-London Health Monile site.
    My only suggestion would be put a link “back to top” at the bottom of then page. Not every user is aware of that you can tap the browser’s top bar to scroll back to top.

    0
  25. 42

    I’ve just tried the MLHU website on chrome (resizing the window) and then my Nexus 4. Can’t say I think much of it – it’s jerky and the way it works on the phone is pretty disorientating, when clicking a link the drop down (sort of) opens and then the page jumps down. The background also changes position/size, is that deliberate? Don’t get me wrong, it’s better than the select list solution, but I don’t think this is as good as it could be..

    0
  26. 43

    Hey Jon, currently working on a responsive drupal site and am very impressed by your healthunit.com design. My website is similarly a bilingual en/fr website, so I wanted to point out that when I clicked “FR” on the healthunit.com website, all of the main content and the inner nav menu translated appropriately but your entire header including your main navigation stayed english. Just a head’s up – and thanks for the design inspiration.

    0
  27. 44

    Great Article!

    My only issue here is:

    I’m met with a wall of navigation (Mobile and Desktop). I see the super nav, the “corporate-esque” nav and the main navigation. That’s three rows of navigation. At first glace, it’s a lot to take in. I feel as if the top most row of nav items could have been omitted or made into a fifth nav item.Also, the placement of search seems like an afterthought and a bit “unnatural” to the flow of mobile site patterns…

    see how this responsive site handles their search placement if visual prominence is a motivating factor…

    portal.ehawaii.gov/

    Other than that, you’ve made some solid points.

    0
  28. 45

    Very nice article! The main navigation on the Health Unit site is unusable on mobile or at least it seems to jump to pages responding as a clicking behaviours when I tap and drag on the screen. This might be annoying for the intended user if all I want to do is tap and scroll. Sub Navigation works as expected.

    0
  29. 46

    John, great job on the Seneca website. As an Alumnist of the institution and who used to use the site everyday, this is a massive improvement.

    Well done.

    0
  30. 47

    Latelly I saw an other trend that is similar to the iOS lateral menu, for example this one: http://demo.quirkyfoxlabs.com/tmpl/#silhouette
    In this website they have a lateral mobile menu that they show only on mobile/tablet screens and that can be toggled with the fixed menu icon at the top right.

    I think that it an interesting “new” way ;)

    0
  31. 48

    I’ve created a jQuery plugin for responsive revealing menus and content. Its called Slidebars.
    It’s ultra light-weight at 1.5kb (js and css), has huge browser support (including IE7/8, Android 2.*, Firefox 3), and uses css transitions and transformations where possible, falling back to jQuery .animate() on un-supporting browsers.

    Check it out at:
    http://plugins.adchsm.me/slidebars
    https://github.com/adchsm/Slidebars

    0
  32. 49

    I tried the mobile-navigation on desktop just by changing the browser-size (google-chrome).
    toggling menu points (can’t use sub-menu as you used the word different), are shown for short time but are hidden then, the space for these sub-points is shown, but just empty.

    Concerning “Sub Navigation” I’d choose another word, is’s really questionable for visitors if it’s changing something in the navigation above or if it’s doing something else. Call it “corporate links”, “About” or somehow else but use words that show that there is still content.

    Technically, I’ll adapt the idea but reduce JS and use CSS instead.

    Nevertheless, as concept your results are nice and after debugging and adjusting it will be a cool solution.

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top