I sit in an “open office,” which is sometimes code for cheap, as in: shoving as many people and desks together in one area before you break fire codes and accessibility laws. Sure, yeah, it’s a collaborative environment, which can also be mistaken for unintentional eavesdropping or creative drive-bys. (BTW, I blame Herman Miller for the open office space concept. Even if they are never implemented the way HM originally designed them. I may devote a post to my experience about a poorly designed green building and it’s open office space).
Anyway, earlier this week a project manager approached an art director I sit next to, and asked him if there were any hover states on a particular page he was responsible for designing. Naturally, as part of the open space concept, I inserted myself into the conversation. Long story short, No–there were no hover states. But we started discussing what exactly is the state of The Hover State these days? The Answer, “it depends.” (I think this is one of Jared Spool’s favorite answers.)
Back in the early days of the web design there were basically three, common visual states of a clickable link, button, image, graphic): 1) at-rest or default, 2) hover- or over-state, and 3) visited-state. (You could argue four, if you count on-click, but whatever.) The hover-state was used to visually indicate the “click-ability” to the user when her mouse “hovered” or “moused-over” a link/button/image. A UX professional would tell you that for an optimized user experience, clickable objects, more specifically links or imagery, should be visually differentiated from content to avoid confusion with lists, copy, captions, static images; the hover state was an immediate visual confirmation that the object could be clicked.
Fast forward to June 29, 2007 and again to April 3, 2010. The introduction of the iPhone and iPad. Hello touch. Hello it doesn’t sense my finger “hovering.” Hell, now what?
So far I’ve only mentioned clickable links or buttons. Touch interaction revealed: 1) there is no “hover-state” (as we know it) on a touch device and 2) what do you do when you have navigation menus or drop-downs that reveal (open) themselves “on-hover” in a desktop environment? Tapping on an nav menu or drop-down that had a hover-state attached to it resulted in a variety of visual and/or interactive responses, my personal favorite being a nav menu opening while simultaneously navigating to the corresponding navigation page before I even had a chance to look at the menu options to decide if the menu contained what I was browsing/looking for. And it seemed that no two menus acted the same in the touch environment, which meant that not all hover-states were created equal in the desktop environment.
Fast forward to now: responsive, adaptive, hybrid, mobile site, app design, and all things future friendly. With queries and style sheets we can do a better job targeting viewports and devices and delivering a more appropriate interactive experience. However, I’d recommend a little interactive strategy planning up front. A quick audit of the topic reveals like minds; it seems that there are three logical options to start with:
1) Design hover-states for mouse events, and display everything on mobile
2) Design hover-states for mouse events, and gesture equivalents for touch.
3) Don’t use hover-states.
Note that #2, the key to implementing this approach is hover-state equivalency. In other words, if a rollover reveals a menu, ensure that a single tap reveals the menu, but no other functionality. A second tap (conceivably to make a selection from the menu) should result in the site/experience behaving accordingly. Similarly, tapping outside of the menu, implementing a close button, and/or time-out should close the menu, just as if the user had moused away from the open menu.
Obviously, with a “Mobile First” approach, how elements and objects work in a “mobile” scenario (as in viewport/breakpoint size) would be addressed first, and therefore would be more top-of-mind throughout the design process, instead of an afterthought.
Regardless, it would appear that the Hover State is here for now, but perhaps needs to be redefined in order to address the wider range of interaction capabilities that exist today. Google Glass anyone?
ittybittyusability 