The end of :hover?
andycroll.com
andycroll.com
Some comments here mention media queries, those are folks who are with the times, and care enough about their design to target it for a specific class of devices.
A few years ago, one could be either a print designer or a web designer. Web designers have worked hard for standard design systems like CSS for a couple reasons; the first is that we all lived through IE and Microsoft in the late '90s, and it sucked; embrace and extend soaked millions of man-hours out of the economy, and designers are still pissed about it. The second is that it just made sense to use conventions when really all that varied about web use for the first 20 years was bit-depth and resolution.
I'm a little bit of an early adopter, but I don't think my web browsing yesterday was totally unusual: I used a 1280x800 laptop, a 1920x1080 monitor, an 800x480 touchscreen device in portrait and landscape, and a 320x480 touchscreen device.
Each of those requires its own design attention; a conscientious design would probably have separate design work for the laptop, the monitor, and the devices. An OCD designer could have more like five.
Standards can't legislate away usability, usage needs or user interest in a device's capabilities.
All that to say is that :hover works great for some design needs, and frankly, it would be cool to have it on a capacitive touchscreen, but we don't. Or at least, we don't right now; that doesn't minimize it's possible uses on other platforms.
Pretty much spot on. I don't like when people say that one change for a new kind of device will dictate how everything else will be used. Yeah, mobile devices with touchscreen capabilities are here to stay, but that doesn't mean desktops are going away. Designing for the common features between the two only is doing the users a disservice for anything that could benefit from additional UI features.
http://experimentgarden.blogspot.com/2010/02/touch-based-web...
So theoretically on touch devices such as the iPhone/iPad a touch is the same thing as a hover in cases where there is no onclick handler, but in elements that have both an onhover and an onclick handler the onhover handler will execute extremely quickly, then the onclick handler will be called, so hover effects could be missed completely.
The best bet is clearly to avoid using onhover for important things.
I think the real solution is focus on the most basic browsers. Most websites work just fine as a simple web 1.0 website and while you can add optional features from there which fail gracefully. Rather than the normal approach of starting with the feature rich site and try to be useful as you strip away pieces.
Simply pressing down and holding for a half second could reveal a menu. And instead of a dropdown, I see the popularity of submenus expanding in a circle outside of the press, similar to Autodesk Maya, if anyone knows how that program's submenu system works. In this way, all of the submenu options are equally close distance to access rather than having to drag or move past unintended options, and would also help with the muscle memory of an intended option if the user knows that a particular item is always up or down, left or right.
Keep in mind, that (used correctly) there is a usefulness of accessing a submenu of items that allow a user to go directly to a desired page or screen without having to drill through a series of screens.
Apparently, the device is not capable of presenting a normal web site properly. In this case, the limitation is a little ironic. The original MacOS menu system, which required click-and-hold and used a single mouse button, was an excellent example of giving the user feedback as they navigate a system. Use of hover effects on interactive elements on web pages has a similar purpose.
The linked blog post suggests that the end of this story is the demise of :hover. There is at least one possible alternative ending: it turns out that mobile browsing on devices with small screens and automatically reformatted pages, with limited interaction possibilities and no support for widely used technologies, simply isn't as useful as having a fully capable browser on a fully capable device.
Mobile browsing has a lot of potential, but no-one says that current generation of smartphones is the best way to do it. The iPhone is still a relatively new product, Android is even newer, and despite all the hype these still represent only a relatively small share of the smartphone market between them. Analysts have started to question Apple's closed infrastructure and whether it will stand up to competition as the market develops [1]. Maybe in a year or two we will wonder what possessed anyone to think that trying to have a mobile phone and a browser on the same device was a good idea. Time will tell...
Time has already told that one. In certain areas of the world, like Japan and other parts of the “Far East,” phones and browsers have been the same device for years, if not decades. Japan especially never had a fully blown PC culture, so they standardized on text messaging over e-mail, “emoji” instead of emoticons, and q-codes over URLs. Web browsing and telephony are both communication activities more than computational ones, so there is a certain logic and cultural precident in place to move the communication activities away from computers to more dedicated and portable appliances.
I've actually been thinking along those lines for my next phone upgrade. Instead of getting the HTC Desire, I'm now seriously considering getting a Dell Streak as a portable browsing platform (I know it is technically also a phone) plus a simple solid dependable phone that is optimized for making calls, only needs to be recharged once a week and is cheap enough that I don't have to be too worried about it. Since very few apps actually make use of or enhance the phone calling abilities of smart phones, it seems unnecessary to have everything on one device. Am I a freak or have other people had the same idea?
Or just hold out a couple more years when hovering your finger half a centimeter above the screen is detected and then all will be back to normal event-wise.
Perhaps a drag gesture across an area can work as a hover? Probably won't work great if context stuff pops up directly under your finger.
Better/crazier plan: the new iPhone has a user-facing camera. How hard is it to get some eye-tracking software going?
Compatibility modes are confusing and user hostile, and two different methods of interaction increasing testing requirements.
Why?
There are places where :hover triggered behavior is beneficial, but these tend to be vastly overwhelmed by the examples where :hover behavior is abused to the point of degrading usability. I'm aware that designers tend to loooove hover menus because they are shiny and cool, but from a usability standpoint we'd be better with a lot fewer of them.
For example, while I completely agree that nested hover menus implemented naively (as many sites do) can be very annoying, single-tier menus with large areas can be an effective way to provide navigation of larger sites without cluttering the main page with dozens of links that most users won't care about. Likewise, while the "falling off the edge" problem is a real one, there are tools like jQuery's hoverIntent plug-in that can make the UI feel much more natural.
OT: Also, thanks to the rest of HN for modding me down. I've got hundreds of karma points to burn, so do your worst. I'll cry at first because nothing means more to me than my HN karma, but then go have nasty sex with my hot girlfriend to make myself feel better.