This article should be renamed "the end of one-design-fits all." Or maybe, we could rename it "double your design staff."
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.
This article should be renamed "the end of one-design-fits all." Or maybe, we could rename it "double your design staff."
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.
I wrote an article about this a few months ago, and wrote a little code test to see whether the iPhone touch based system correctly handled touch events by triggering both onhover and ontouch for touch events:
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.
The solution to this problem is really simple. Don't use onHover for anything important... But, the same could be said for flash or even plain old JavaScript etc.
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.
The end of hover will simply transfer to "onmousedown", which can be used for the same purpose of revealing a submenu.
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.
Why wouldn't you use two separate sites for desktop and mobile browsers? The common layouts for both are very different and require different designs to use each affectively.
Because it takes more resources to make two sites instead of one. Also on the iPad why would you want a crippled "mobile version" of a website, when the device is capable of displaying a normal website?
I understand taking more resources to create two sites, but an iPad and iPod Touch can't really show the same page. So, just have the iPad show the desktop version and the iPod show the mobile.
> Also on the iPad why would you want a crippled "mobile version" of a website, when the device is capable of displaying a normal website?
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...
> 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.
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.
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?
You're certainly not the only one questioning the trend. I've been looking into phones like the Desire myself over the past few days, but having finally had chance to try one at the weekend, I was a bit underwhelmed: the screen really is very nice, but the UI you see on it is just full of junk stuff I would never use: millions of apps I don't care about, integration with social networking services I don't use, and the like. I'm also discovering that the battery life and, crucially, the mic and speaker seem to suck on all these new smart phones with big screens compared to a phone from a couple of years ago that is just designed to be a good phone, and that I hate typing anything with the touch-sensitive screens. Maybe they're just not the kind of device for someone like me, but I'm not sure anyone has made what I'm really looking for yet.
Everyone needs to learn about media queries. http://robot-or-not.com/ - Resize your browser window and the CSS changes. Check it out on an iPhone too. Works great and can be hacked into IE.
One possible issue with this is that in terms of page size/layout, iPad and other tablets are probably more likely to fall into the 'desktop' category.
My question would be why would you use different sites if it's only the presentation layer and not the content layer that needs adjusting? UA targeted CSS or XSLT transforms should do this sort of work surely.
I've had this thought every time I've tried to read The Economist on my iPad -- their homepage features a rolling set of four lead stories which are accessible via hover-and-click. Since hovering doesn't work, I have to wait until they roll around naturally. It's quite irritating.
10 years ago, users could identify a link from underlined blue text or a highlighted blue border around pictures. We did so much visual progress since, and hover (especially in css) is good design and a good interface tool, in that it lets people know something might be clickable. For any user, hover means 'link', so i wouldn't start digging its grave anytime soon.
Do we really need to break something that works here (mouse+display) because it doesn't work there (touchescreen)? somehow it doesn't make a lot of sense, and probably calls for more thinking
Ideally, a user should not have to hover over something to know whether it is clickable. It is a designer's responsibility to make sure that a user can scan the page and know exactly what parts are clickable, so the user can quickly perform his or her desired action.
Ideally, yes, i agree with you. But when the site's users are not necessarily computer litterate, a few hints can prove helpful (sometimes it is also a designers responsibility to take people gently where they have to go). And for some playful designs, rich on graphics and taking the conventions a bit further, it can be complicated. <br>
Hover also works as a confirmation: mouse pointers turning into a finger, that means 'yes, click'. This has been conventional for a very longtime, and it works. Watching touchscreen users tapping blindly on their ipad, checking what works and what doesn't, will probably become a frequent spectacle :)<br>
But you know what would really annoy me with the disapprearance of hover? It's slightly like the bit.ly scenario, only worse, and it's unrelated to css or submenus: The mouse over a link have since ages showed the link's url. A reasonable part of the website-reading process is made of avoiding bad or irrelevant links, not speaking of nastyspamsite.com/fakeapp.exe addresses, and hovering hover links is capital. How do we do this on a touchscreen?
If the hover functionality is important then perform it on click if it occurs before hover, for example in a drop down menu. If just visual then don't worry about it.
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.
When I first heard of capacitive touch screens (as opposed to resistive touch screens), I thought they would be able to detect hovering fingers. Perhaps some future version of touch screen technology will include smart hover detection.
Increasing testing requirements on what? I meant adding it to the browser (or the window manager/X/whatever), which would not require a massive effort to test. The websites themselves already have to support (at least) three modes of interaction if they want to have all main browsers supported (mouse, touch, keyboard).
I abhor the use of hover in webdesign and I'm glad that devices like the iPad may spell doom for that particular design idiom. It's bad UX in general, if touch computing pushes it off the cliff into oblivion then good riddance.
Because it's easy to trigger accidentally (the false positive rate for triggering hover behavior is usually incredibly high), because it requires excess precision to navigate correctly (nested hover menus can easily become a mini-game of "don't fall off the edge or you'll have to start all over"), because onMouseOut is flaky and can result in dangling hover menus that obscure content, because it's often more difficult to make cross-browser compatible, because it's more difficult to gracefully degrade a hover menu system when scripting is turned off, etc.
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.
The problems you mention are certainly real, but are they problems with hover effects in general or with specific uses of hover effects that may not be appropriate?
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.
While I don't agree that it denotes bad UX in all cases, I acknowledge that it can be overdone to the point of annoyance (ala the new YouTube, which is a hover-fest)
I have to say I quite like YouTubes latest incarnation with all the hover elements because I have no interest in using anything other than the play button (I only use it for listening to live versions of music) and so a cleaner "first impression" UI suits my persona very well.
I understand that it can be a horrible experience for a persona which is specified to be 'low-tech knoweldge high-functionality use' though.
The nature of the iPhone and other touch devices makes :hover irrelevant in that context? WELL FUCK!!! BETTER THROW IT IN THE TRASH THEN AND QUIT USING IT ENTIRELY!!!!!! HOLY SHIT LOOK AT ME I'M A FUCKING INTERNET PUNDIT!!! HURF DURF HURRRF
That's great, I found it amusing too, but I'd rather keep the tone at an adult level here rather than dipping into the, admittedly sometimes more amusing, levels of reddit and 4chan.
I agree with you, but I think part of what made it funny was that it was so unexpected.
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.
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.