| Thursday, March 4, 2010 |
07:08 - My :hover class is full of eels
|
(top) |
A lot of people have been talking excitedly about how the iPhone/iPad paradigm has brought about the apogee of Flash's penetration into the web for basic site structure and navigation. What with the imminent ubiquity of HTML 5 and CSS 3, and the video delivery and animation effects they herald, and what with major media sites backing away from Flash content in order to cater to mobile users, it's been quite fashionable lately to claim that Flash is soon to be relegated to the web pages of history alongside clickable imagemaps and the blink tag. What's more, the same people are eagerly expecting that the iPad will usher in a shining new era of post-Flash web design, one where all the best and newest features are vibrantly supported and every site looks and works great.
But I'm not so sure. Apple claims that the iPad's web experience will be the "best" you can get. And Flash aside, it's probably not far from it: intuitive tactile interaction, smooth zooming, pleasantly antialiased text, and cutting-edge HTML/CSS support.
But my question is: what about mouseover effects?
A lot of the web these days depends on a mouse pointer's ability to hover over an interface element, whether to activate a navigational element or to provide visual feedback. Menu systems the world over pop open submenus when you roll over them. Links glow different colors (and telegraph their destinations in the status bar). Content panes slide open; contextual menus pop up. And while there are plenty of evil uses for hover effects (those horrible popup ads with embedded videos that come up with you mouse over a certain word, for example), for the most part it's not obnoxious or invasive—especially to developers—because it's not based on any proprietary technology: just perfectly standard, broadly supported HTML, CSS, and JavaScript. (Plus it's useful.)
Whole libraries have been developed to help build page elements that depend on you having not only the ability to click on a link, but to hover over it too. JQuery and Prototype and the like (libraries that are in such widespread use that Google hosts them on high-speed code servers to ensure every site will be able to access them quickly and load them before subsequent locally hosted libs) are specifically designed just to make it easy to do stuff like that, and in a well-understood, de-facto-standard manner. But how do things like the MooTools ImageMenu or this popup image viewer work if you can't tell the browser where your pointer is without actually registering a click?
(I'm not saying there aren't solutions available. But Apple sure doesn't seem interested in going down that road, which is probably for the best. And not just because it's—heh—patented.)
I seem to remember going through this once before: the 3rd generation iPod.
You remember the one: the first one with a Dock Connector, the first one with rounded edges... and the first (and only) one with a row of indistinguishable round control buttons that responded to a touch by interpreting it as a button press.
I seem to recall, though my mind might be playing tricks on me, that the subsequent generation of iPod ditched these buttons in favor of the integrated "click wheel" largely because Apple realized that the buttons were a user-experience nightmare. You could no longer control your iPod blindly, by groping for its sides and finding the raised edges of the distinctly-shaped buttons you wanted and pressing them only when you were good and ready. Now, not only could you not tell which button your fingertips were fumbling over, just the act of fumbling over it caused the button—whichever it was—to be pressed.
That was one of the main reasons why I was so skeptical of the rumors of a full-length touchscreen iPod, back in the days before the iPod touch and iPhone. How on earth could you replicate the classic dial interface of the iPod on a smooth, featureless touchscreen where to touch is to click? How do you expect to run your fingertip around in a circle without any physical guides? It was hard enough since the physical rotary wheel of the 1st-gen iPod was replaced with the capacitive, static one of the 2nd-gen, making it that much harder to rotate without the help of stiction between your fingertip and the dial surface. What kind of sense would a full touchscreen make?
Of course, what I failed to intuit was that Apple was prepared to design an entirely new UI for their touchscreen devices, one that's uniquely suited to a 100% soft interface layer and that integrates natural gestures like pinching and flicking rather than clinging to the rotary gesture that had by then become a legacy. But it also meant the days of using your iPod without looking at the screen were over.
I worry that Apple's about to discover the same kind of thing with the iPad's web experience. An awful lot of the web depends on hover effects for basic navigation, and the iPad won't only not present the "best" web experience on the market, it'll present a fundamentally crippled one, one where many sites—sites that have "done everything right" in the eyes of the style nerds, sites that use strict standards-compliant XHTML and totally separate the style from the scripting from the structure, sites that not only eschew proprietary technologies but themselves advocate against them and in favor of industry-standard, semantic JavaScript/CSS-based UI elements—won't work.
People have put up with these limitations on the iPhone till now because they intuitively recognize it as a limited platform; Mobile Safari is awesome, but only in an "it's amazing the bear dances at all" kind of way. Nobody would choose Mobile Safari over any desktop web browser for serious surfing. But Apple's billing the iPad as every bit the equal of a desktop web experience; and it's going to be subject to every one of the iPhone's browser's limitations except size. I don't know if everyone is quite prepared for the ramifications of that.
I can imagine Flash losing popularity and eventually being used only in the rare and specialized instances where you still find things like Java applets and custom plugins, and for indispensable (but also iPad-phobic) resources like Homestar Runner. But I'm not prepared to believe that every site that's savvy enough to build a nice user experience around hover effects is going to happily rebuild it without those features just to make it easy for iPhone/iPad (and other touchscreen device) users. Surely that's every bit as bad as asking people to forgo transparency-supporting PNGs because 10% of the web still uses IE6.
|
|
Brian Tiemann
