Three Ways to Implement a Global Menu in jQuery Mobile

Navigation is the hardest thing to get right in any application. Mobile only compounds the issue. jQuery Mobile doesn't (and shouldn't) have a pre-built global navigation structure. This leaves room for flexibly and creativity on the part of the designers, but also leaves some scratching their heads and wondering what to do. So, here are what I believe to be the three best ways to create global menus and the reasons why you might choose each.

This post is not about setting fixed position headers and footers. If that's what you're looking for, check out the touch overflow or fixed toolbars. However, in general, I would discourage this practice because it just takes up space and usually doesn't add any real value. That being said, let's get on with the meat of the post. Here are the 3 ways...

1. The home screen IS the global menu
2. The global menu is a sub-page
3. The global menu lives at the bottom of each page (my recommendation)

Option 1 -- The Home Screen IS the Global Menu

This option makes a lot of sense on its face. Mobile makes you focus very tightly on what's important, so naturally, most of the things that you would put in a global menu should probably also be present on the home page. It's not a far stretch to make it fully official. This was the approach taken by Stanford University. I think we can safely assume that smart people made this site.

Pros & Cons

• Pro: Simple & focused
  This implementation further enforces the mobile imperative of keeping your site well focused on what's important.
  Chances are, if it doesn't belong on your home screen, it's probably not worth putting on your mobile version of the site anyway.
• Pro: Good UX
  This will feel natural to your users. As developers (and some power users) we realize that you can click on a logo and it will always take you back to the home screen, however, not all users realize that. Having an explicit home button removes the uncertainty.
• Pro: Speed
  Because your users likely hit the homepage first, there's a high likelihood that it will stay in the browsers cache and thus be quickly accessible.
• Con: Too many stakeholders in the kitchen
  Almost inevitably, unless you have a UX department with a strong backbone and senior management to back you, the homepage will likely be made to serve the many departments of your organization who feel they have an equal stake in the real estate of the homepage. When that happens, your mobile site will lose its user centered / task based focus and you'll wish you had a separate menu.
• Con: Loss of contextual opportunities
  You'll see what I'm talking about later.

Option 2 -- The Global Menu is a Sub-Page

This option leads to the cleanest interface and the most flexibility. To implement this, use the multi-page example from the jQuery mobile docs (view the source to see how it's done). This is still maintainable as a single file using server side includes.

Pros & Cons

• Pro: Scalable
  Your main menu can be as large as you like without polluting the homepage with things it may not need.
• Pro: Context
  Since the main menu is actually built as a sub-page to each "page", it gives you a great chance for some contextual relevance. For example, if you're on a list page of your contacts, it might make sense for their to be some sort of controls around those contacts embedded in the menu for that page followed by the usual main menu content.
• Pro: Native Feel & Speed
  Sub-pages have zero load time, only transition time. This will give your page a more "native" feel. This is especially true if you have the menu button at the top of the page and the menu itself is brought down from the top in a "slidedown" fashion.
• Con: Questionable UX
  Users have a tendency to first look for what they want on the page. There's a fair chance they may even scroll through the page looking for what they expect before they figure out that you must have thrown it into your menu. User may give up and start looking other places or just leave if they don't think to look in your menu. This approach is learnable and once users get what the menu can do for them, they'll probably be fine. It is a very common approach, it's just may not be the most obviously useful to the user.

Option 3 -- The Global Menu Lives at the Bottom of Each Page

This is actually the approach that I have adopted after noting that Amazon was. When Luke Wroblewski created BagCheck, it was also the approach he used.

The menu button is up at the top where one might expect. The global menu itself is present at the very end of the pages. This approach has all the benefits of Option 2 without the drawbacks.

In a normal website, this would be simply executed by using in-page anchors like index.html#menu. For jQuery Mobile people, this indicates a change to a sub-page. To get around this, you can code the menu button like this....

<a href="#" onclick="$.mobile.silentScroll($.mobile.activePage.find('.mobileMenu').position().top)" class="ui-btn-right" data-icon="grid">Menu</a>


At the bottom of the page, you can implement the back to top link like this...

<li data-icon="arrow-u"><a href="#" onclick="$.mobile.silentScroll(0)">Back to Top</a></li>

Pros & Cons

• Pro: Scalable
  Add as many options as you like (within reason) and it's not going to feel unnatural.
• Pro: Speed
  It's already on the page. You don't even need a page transition to get to it.
• Pro: Context
  This version actually supports page relevant context even more than option 2. It's presence in the page itself only serves to strengthen the contextual options (if you have any).
• Pro: Excellent UX
  Provided you have made a page that doesn't suck, the user is likely to start reading the content immediately. When they reach the bottom, you can immediately present them with a link back to the top, other relevant options along, and your main menu.
• Con: There's no pretending
  Apps typically do not use this interface. If you're planning on using PhoneGap to compile your HTML interface into a native app, this will make it feel less native. That being said, it might actually be a good idea anyway.

Now, go be brilliant!