Filed under: internet, iPad, iphone, ipod, Web | Tags: android, internet, iphone, ipod, mega menu, menus, pad, touch devices, touch input, touch input problems, Web
I’ve been overhauling a client website and have been implementing the desired Mega Menu functionality, spent a little white crafting the sub-menu content and finally inserted this into the template and tweaked it to ensure it fit the 960 grid, then tested locally using my own test web server. Worked nicely with my desktop web browsers (although I qualify that I hadn’t tested at this point in IE6, the origin of the Mega Menu code stated it does work in said browser, but I never rely upon other coders statements!), so I then went to test its functionality within my iPhone to see how the menu functioned on a touch based device. The menu opened as expected, it was when I wanted to continue browsing the page rather than choosing a menu item, something that isn’t a problem on the desktop as the :hover state disappears automatically, that I discovered that the Mega Menu failed dismally for a touch-based device. There was nothing within the Mega Menu code structures to handle the fact the a touch-based browser didn’t work with :hover states, thus the menu remained open, the page content covered, and a road block hit.
My initial thoughts were that perhaps it was just a fault of this particular mega menu, it wasn’t the only code structure out there, and as such I began looking at how others implemented their’s. Everywhere I turned it was the same, the menu remained open, you couldn’t click the top-level menu item you used to open the menu to again close it, nor could you click outside the menu and it was recognised and the menu closes. Some menus just stayed open when the top-level menu item was clicked, other sites when the top-level item was clicked it actually took you to the area’s web page. It’s disappointing that with the rise in touch-based devices surfing websites, and the increasing use of such mega menus, that touch-based devices seem to have been poorly tested.
My thoughts on how it might be tackled is that the top-level menu item is clickable to open/close sub-menu item. Upon open, create a click event for touch-based devices (using Modernizr tests) such that if you click outside the menu it triggers closing the sub-menu and deletes the trigger.
Who knows if it might work? Anyone else come up with a solution they’d care to share?
Like this:
1 Comment so far
Leave a comment
Continuing on from yesterday’s failed attempts to find a touch-friendly mega menu I began seeking alternate avenues to employ the same sort of functionality. One individual had proposed the use on jquery ui tabs, whilst not my ideal solution since the menu expands the content, pushing page content further down the page, however beggars can’t be choosers. I began trying this, and all went well, although a few of the tabs weren’t to show menu content but rather to go directly to content, thus some additional jquery function code was needed, the widget does cater for this thankfully, though absolute url’s were needed.
In addition I set options such that the default option was no tabs selected (selected:-1), and that the tab content be collapsible as I didn’t want the menus to remain open if not necessary. I now plan to alter the styling provided with the jquery ui stylesheet as I’m not so keen on its look, but at least now I have something that works for touch users.
Comment by g04uld January 3, 2012 @ 10:09 am