Meet the new boss, same as the old boss...

Stephanie Rieger has a plea for Progresive Enhancement here.  Its long, and well worth the read.  But (But!), when I read it, all that gets hammered home to me is how this is exactly the same crap that we went through back in the 90s, and how ridiculously painful the whole process was.

Everything old is new again.  Mind you, the complexity associated with the solutions has gone up drastically), but it is, stil, the same damn problem.  (Remember, Complexity never goes away, it just moves up the food chain).  The following is what she did...

First, we built the menu to fail gracefully. In this case, it meant building a menu that was open by default, and only closed once the page had loaded. If the JavaScript failed, the menu would simply never close. It might not look terribly graceful, but it would still be fully usable (to navigate…not to slide open and shut triggering fancy animations…that’s not the menu’s actual job.)

Secondly, we built the menu using ‘normal’ JavaScript rather than jQuery, as we’ve found jQuery still doesn’t work reliably across devices (in particular for tasks such as DOM selection). We also tested the JavaScript based functionality all the way back to dinky, underpowered little phones like the Nokia N95. This served as a reality check and helped further minimise our points of failure. If it works on a 5 year old browser, it’s considerably less likely to fail on today’s devices.

And finally, we identified browsers with inadequate levels of JavaScript or DOM manipulation support and served an entirely different menu to this group. We swapped this out server side to ensure these devices didn’t receive the JavaScript at all, and newer devices didn’t have the client-side burden of negotiating the switch from one menu to the other. Incidentally, we also built the site ‘mobile-first’ (i.e. for the simplest device first…and no, that device is not the iPhone), so the ‘fancy’ menu doesn’t even kick in until you reach a screen size of 320 px (regardless of whether JavaScript may be supported). This may penalise the tiny number of devices that happen to be below 320 px in width, and have awesome JavaScript, but also minimises the chance that weaker, older devices will try to load the menu accidentally.

Despite all this, we still had issues, namely with general DOM manipulation flakiness and inconsistencies caused by device-specific events such as zooming, reorientation, or adjustment of Zoom settings (especially on Android…and especially on HTC). For this reason, we found that the calculations required to correctly trigger and execute the animation sometimes failed, resulting in an only partially open menu. So in the end, we removed the animation altogether (especially as this problem wasn’t limited to lower-end devices so it wasn’t possible to simply conditionally load the animation based on say…the browser version).