I recently reviewed Brad Frost’s thoughts on responsive navigation patterns. In terms of mobile widths, I personally have been using the select menu option, utilizing a jQuery script to change out a nav’s unordered list UL for select option tags. I had found it to be a perfect way to utilize a phone’s native function — the act of pulling up the navigation menu a seemingly seamless experience. After reading his cons in that use, I’ve changed my mind.

In a mobile setting, select menu “rolodexes” like in iOS are not a sensible way to display navigation menus because users generally do not know what navigation options there are to begin with. Hence, I agree with him that they are potentially confusing. One must consider the normal, intended use of multiple select menus as a form element that combines many related items. For example in a shopping cart, I want to show color options for a t-shirt. When a user clicks on “select a color”, they expect to find only names of colors like red or blue. In the case of “navigation”, the user might be fairly daunted when presented with many unrelated links in a website. Similarly in my example, someone looking to chose a product color is going to be confused when options like blue hoodies and red jackets appear.

My alternative has usually been the do-nothing approach, essentially restructuring the top nav into a mobile-friendly element. My personal default has usually been a full or half width button with soft gradient, to mimic iOS general styling. The one concern that I have encountered by many clients is that they do prefer the nav to fall at the bottom of each subpage. A jQuery detach/append can certainly do this, but that function is processor intensive and rather clunky with click-happy users. One client was so perturbed that I created an entire mobile version of the site with this layout.

My solution for Urban Bean presents the homepage with just nav and on each page, the nav appears at the bottom.

At the end of the article, Brad linked to an interesting pull down nav solution by Inspect Element which essentially takes a cue from the pull-down-to-update effect by Twitter. I’d call it more of a pull-down-to-reveal since the nav height doesn’t stay anchored atop, rather the page itself pulls down to reveal nav from top to bottom. While the solution is very compelling and presents room for creativity, unfortunately I don’t find the pull down nav to be terribly intuitive. Subducted information from the top of a page tends to imply related content to that page, not to the entire website. Also from a UI perspective, we’re taxing the brain to orient two up-and-down motions. The other motion is iOS Safari’s native inclination to snap the entire browser window when you exceed a page’s maximum scroll.

Facebook introduced the left reveal and it works because natively, iOS apps like to slide progressively right to left. Sliding the current page left to right implies we’ve moved back a step. The home menu is further implied to be a master screen by several important details. First, the menu is generally a dark color and color grades downward, second the current page’s subtle box-shadow floats it atop, and thirdly, the page hasn’t quite moved all the over, implying we’re taking a peek into the master Facebook brain behind everything. A left reveal also lets the thumb do its job of scrolling, only this time for navigation. You could do this with the pull down nav but then you’d be asking the user to track three vertically changing elements all at once. Vertigo would ensue (unless that’s what you want!).

My last observation is that I’ve noticed some designers pushing ridiculously small text scaling for their navigation bars as you move toward smaller screen widths. To keep the horizontal element, they’ll squeeze nav buttons, proportionally might I add, into that 20 to 50 pixel height.