Full page menu navigation: UX pro’s and con’s and tutorial with fixed un-scrollable body underneath.

By Geoff Muskett

Full page menu’s are a popular design pattern recently. Whether they slide in, pushing the content out, or overlay the content from the top/left/right/bottom. Whichever, I get it, and I’ve dabbled in the past:

Full page menu screen grab from Hampsons of Hayle website by Geoff Muskett

See it in action at hampsonsofhayle.co.uk (on big screens).

With this site you’re on now I’ve applied a hybrid approach, more on that further down.

Lets discuss some pros and cons:

Pros:

  • A full screen menu on a phone requires little-to-no further css to to get the same behaviour on a big screen. You might need to flip from one column to two, but nothing major.
  • Once the menu is open there’s nothing to confuse the next step for the user: click on a link, thats all you can do.
  • It can clearly define main sections of a site.
  • It gives you the ability to design the menu creatively, like KLM.
  • Allows more space, potentially to describe each section.
  • Not having navigation available on screen by default saves real estate and can simplify the UI. You only need a hamburger or the word ‘menu’, or both.

[Aside] Whatever you think of hamburgers, don’t mess about with other icons if you’re hide/showing a menu. It’s better to stick to what people know.

Cons:

  • The menu is hidden behind a click. We used to say that if you can’t get anywhere on the site within three clicks then the site architecture is wrong. Well, a full page menu adds an extra click no matter what. But the web has moved on, and people know to click on things and interact with sites. So as long as it’s fast, an extra click doesn’t worry me.
  • But there is a speed issue; it may be fast to open if it’s a lightweight menu. But it might not be fast to physically navigate to. Using a Trackball, a touchpad, or even a mouse, it’s an effort to navigate up to the top corner, then back into the middle to click on a link. OK, first world problem, but we want to craft pleasing UI’s, right? Full page menus can be kinda tiring on a site that requires a lot of navigating.
  • No visible navigation (obviously). Visible navigations can provide clues to the type of site and content it offers without any prior knowledge. Of course there should be clarity in the design of the UI anyway, but still.

Fixing the content below the menu

You’ve decided the pros outweigh the cons and you’re headed down the full page navigation route. A nice UX win is to keep the users position on the page before, during and after the menu is open. There’s nothing more annoying that clicking a menu button and it scrolls you back to the top of the page. Loosing your place in a long article. Grrr.

A quick story.

During my last few weeks at Made Open (Sea Communications, at the time), I was teaching and mentoring Luke Meyrick. He’s a talented young designer.

He wanted to go down the full page menu route with madeopen.co.uk. Which is fine, he decided the pros outweighed the cons. I find it’s fairly common for agencies to do have full pagers. One thing he was keen to do was to fix the content under the menu.

Me, being busy trying to get everything done before I left, said “Yeah maybe, it’s a nice-to-have”. Knowing that it would take a bit of figuring out.

Which usually means “no”. But to his credit he persisted and we found half an hour to sit and figure it out.

See the Pen Full page menu with non-scrolling fixed body by Geoff Muskett (@geoffmuskett) on CodePen.6289

Benefits of fixing the content:

  • The user maintains their position on the page.
  • It avoids double scrolling weirdness. This happens if you’re overflow is set to auto (it should be) on the menu overlay, and the viewport height is less than the height of the menu. If that happens the user could scroll the bottom of the menu, and then the body content would start scrolling.
  • If the menu has a transparent background it looks neater if the page can’t scroll.

OK, only three, but they’re pretty compelling.

A hybrid approach to full page menus

Often I’ll go for a hybrid approach. Which means a full screen menu for small viewports which slides out or over. Generally, I like to show the main menu where possible. As soon as enough screen real estate is available I change up the styling so the menu is showing. This avoids any of the cons listed above.

See the Pen Hybrid full page menu with non-scrolling fixed body for small screens by Geoff Muskett (@geoffmuskett) on CodePen.6289

 
//click menuToggle button
$('#menuToggle').on('click', function() { 

  //change the text in the button
  $(this).html('hide menu'); 
  
  //data-click-state is set to 0 by default in the html
  if ($(this).attr('data-click-state') == 0) { 

    //show the menu (probably better to do this with classes)
    $('#menuPanel').css('display', 'table'); 

    //get the distance from the top
    $position = $(document).scrollTop(); 
    
    // apply the class that fixes the wrapper, and give it a negative top position that matches the distance from the top
    $('#wrapper').addClass('fixIt').css('top', -$position); 

    // tell the button it's been clicked
    $(this).attr('data-click-state', 1); 

  // data-click-state is 1 so that means it's been clicked already, this is closes the menu
  } else if ($(this).attr('data-click-state') == 1) { 
    
    // change the text in the button
    $(this).html('show menu'); 

    //hide the menu, again better to have a css class that does this
    $('#menuPanel').hide(); 

    // take off the fixed class and reset the top value
    $('#wrapper').removeClass('fixIt').css('top', 'auto'); 

    //scroll to the position it was before triggering the menu
    $(document).scrollTop($position); 

    //return click state to 0, therefor unlicked
    $(this).attr('data-click-state', 0); 

  }
});

//the breakpoint
$whatever : 500px;

//basic resets
* { -moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
    margin:0;
  padding:0;
  line-height:1.5em;
}
p {
  margin-bottom:1.5em;
}


.wrapper {
  font-family: Helmet, Freesans, sans-serif;
  padding: 2em;
  margin-top:4em;
  @media only screen and (min-width: $whatever) {
   margin-top:0;   
  }
}
.menu-toggle {
  position:fixed;
  top:1.5em;
  right: 1.5em;
  padding: 0.5em;
  font-size:1em;
  z-index:100;
   @media only screen and (min-width: $whatever) {
    display:none; //menu button isn't needed
   }
}
.menu {
  position:fixed;
  z-index: 99;
  top: 0;
  left: 0;
  width:100%;
  height: 100vh;
  background-color: rgba(red,0.8);
  display: none;
  text-align: center;
  overflow:auto;
   @media only screen and (min-width: $whatever) {
    display: block!important;//show the menu
     // this overrides the inline css that jquery injects. I don't like to use important, but it's probably better performance than using jquery to check screen width, unless you're already doing that, in which case, definitely do that.
     position: relative;
     height: auto;
     background:0;
     padding: 0 0 2em 0;
   }
}
.menu-inner {
  display: table-cell;//or use flexbox to centre
  vertical-align: middle;
   @media only screen and (min-width: $whatever) {
     display:block;// parent is no longer display:table so this doesn't need to be table-cell anymore
     vertical-align: auto;
   }
}
.menu-inner-link:link {
  color: #fff;
  text-decoration: none;
  display: inline-block;
  padding:0.5em;
   @media only screen and (min-width: $whatever) {
    color: red; 
   }
}
.menu-inner-link:hover,
.menu-inner-link:hover,
.menu-inner-link:hover {
  text-decoration:underline;
}
.main {
}


.fixIt {
    position: fixed;
    left: 0;
    //top is set by jquery
    overflow: hidden;
	  width: 100%;
    @media only screen and (min-width: $whatever) {
      //reset it to be ineffective
      position: relative;
      left: auto;
      overflow: auto;
      top: auto!important;// this overrides the inline css that jquery injects. I don't like to use important, but it's probably better performance than using jquery to check screen width, unless you're already doing that, in which case, definitely do that.
    }
}

Like this site for example. Although, the sidebar isn’t a menu (hence it’s not a hamburger icon), the same technique applies. If you’re on a large screen, shrink the width of this window and click the little arrow in the top left.

Benefits of the hybrid approach:

  • The menu will fit on the screen no matter how small.
  • Looks pretty cool, in my opinion, when a menu slides in on a small screen, especially when it pushes the content out. This is app-like, which is becoming more important as users become familiar with common app behaviour.
  • On larger screens the menu is there, viewable, clickable and consistent.

Comments

mynul islam
January 3, 2017

please, can you give an idea how I can make a full screen Menu with icons in the bootstrap.

the navigation will show on the screen as different apps show on a mobile screen.

please help

thank you

Geoff Muskett
January 4, 2017

You'd probably use the bootstrap grid system...

Leave a Reply

Your email address will not be published.

Join my newsletter

If you’re looking for insights into web design and development, and crafting a successful presence online, then you should join the smart folk on on my newsletter. I discuss my thoughts on an issue relating to the web, then provide and teach effective solutions.