End hover abuse now | Hacker News Reader

End hover abuse now

cennydd.co.uk

37 pointsjoshuacc24 comments

The worst (for me) current example of hover abuse comes from Google Images.

Try searching for something on Google Images, then click the search field and try to refine your query. Didn't work? Well, that's because you moved the mouse away from search field (so that it doesn't cover what you type), but Google then accepts hovering over an image as a sign that now you want to use your keyboard(?) to move through images.

The problem is that (probably) about 95% of screen are images that activate this (keyboard) mode on hover. So, to do a second search on Google Images you have to be extremely careful about where you park your mouse before searching.

See also: Techcrunch.

Their combination of "Snapshots" hover boxes, and autoscrolling widgets is so dreadful that I recently disabled Javascript entirely for the TC domain.

That was the first time in nearly 15 years of using the internet that I felt compelled to do so.

I have to agree with this one. I went round and round, with a (top of the industry) UX designer on a project we where working on. All of the profiles where called out to pop up a user summary when the user hovered over the profile thumb. While it was still usable it is annoying, especially for persons with disability (one of my UX specializations) screen readers like JAWS. I had to develop an entire library to trick JAWS into reading the site correctly because of these things. To me, if a user wants to see a summary of the profile, they can click, then provide an extender to show the full profile. They wanted to reserve the click for taking them to the profile. To me it is silly to kill usability because you think that a click is reserved for displaying the full information. When a link could be provided in the summary to accomplish the same task.

"if a user wants to see a summary of the profile, they can click"

Or much of the benefit can be had through the title attribute, with the bonus benefit of working with screen readers ( http://www.w3.org/TR/html401/struct/links.html#h-12.1.4 )

Do any of the Accessibility laws require designers to spend a day using a screen reader? I'd love to see that.

I always use JAWS on any project that I work on, if it does not work correctly it gets scrapped and reworked. Many times the UX designers I work with do not, are ignorant of the fact and combative about it. So in the end the onus falls on me to make the damn thing work which can require some pretty involved JavaScript tricks and browser hacks. I have thought about releasing a library of all of these accessibility helpers. As I have never really found one that focuses on accessibility.

Take a look a lt Dojo Toolkit's UI widgets (Dijit) - they at least advertise full accessibility compliance, and the set of widgets is rather comprehensive. Might save you some time in the future even if you just use them as a starting point for your own UI.

Yes I use Dojo extensively, It is my toolkit of choice for a plethora of reasons, but accessibility is one of them.

Thankfully, as touch screen devices such as the iPhone, iPad, and upcoming palm or windows touch devices come out, hover states will be forced to fade away as it becomes cumbersome to design interfaces for both touch and non-touch computers.

I still worry that one day apple devices will start tracking where your eyes are looking...

There are companies already doing this. With the front facing camera on the iPhone4, you could track eye movements and even have a cost-per-glance model.

If anyone from GazeHawk is reading this, they totally should be using iPhone 4 owners to generate heatmaps of mobile sites like they do already with desktop users.

That is quite scary. And to dig even deeper would be the ability to predict what a user is just thinking in his or her head. Or reacting or showing customized options based on a user's mood, which could be used for both good and bad purposes. Good if it's a system that's intention is to be purely helpful to a user, such as in that computer in the movie Moon. But bad if it's system meant to manipulate users into doing things they won't necessarily want, such as convincing people that they "need" to have a McDonald's Big Mac.

I don't know an answer but I actually miss hover states on my iPad.

This site in particular I tend to end up hitting the wrong link (usually when trying to go to comments) because I have no visual cue prior to hitting the link of what I'm hitting.

I think designers will just have to compensate going forward with the understanding that touch controls should have a bigger hit area than pixel-precision mouse controls. We're likely far from figuring how and how long this will play out, but I often make the same mistake as you, hitting the wrong link because they are too small or too close together.

This, incidentally, is the major problem I have with Google's latest Image Search interface. Most of the screen is tiled with hover-sensitive areas, and it's not safe to leave the mouse pointer where it is while you browse the images because something will expand into the foreground, blocking out other stuff nearby.

I think it's called Midas Touch Syndrome.

I follow this maxim: Small actions should have small consequences. The best UI should allow for arbitrarily small actions that result in arbitrarily small consequences (e.g. the scroll bar, multitouch, drag/drop). We live in a continuous universe† and this makes for the most natural and easily discoverable interface (i.e. the user can tentatively test things).

†At least it appears that way on the macro level.

I rely on the hover ability heavily on virtually every website on every device I use. The reason is that I always look at the link's url that pops up at the bottom before I click on a link. Notice that this is a browser feature & not a page feature and I depend on it heavily.

I think using hover is perfectly acceptable for displaying information on a site that users don't need but very well might want. I will concede just as quickly as anybody else that there is definitely a lot of sites that abuse this ability. But I think is is unnecessary to suggest abolishing it completly.

The difference between this case and other uses of hover is that displaying the URL doesn't impact the page itself (usually). Instead it is displayed in an otherwise unused bit of the browser chrome.

Maybe I should be more specific. All mainstream desktop browsers do this not just chrome. In Chrome it pops up, in Firefox/Safari/IE they call it the "Status Bar" and this is what I'm referring to.

On my mobile browser (Android) It highlights the links for me on mouse over and highlights phone number in a different color when I use the trackball from time to time.

The point is that I don't think of this as interference but as something I have grown to depend on.

I understand that. The term "browser chrome" means "all the stuff your browser shows you outside/around the web page itself." Google's browser was named Chrome because it has very little browser chrome.

In the days before the DOM and AJAX, JavaScript could only really do two useful things: form validation and mouseovers. As "dynamic HTML" came into use, advanced UI elements were conceptualized simply as more elaborate mouseovers. Web developers failed to make the association between HTML and GUI long enough to establish this antipattern.

With more and more people using touch-screens even for non-mobile sites, it is a bad decision to store information on hover.

Personally, I never liked hover. I think it is one of the most abused functionality. I agree with the author that if the information is important, it should be on the screen already.

I don't fully agree, you can have a dropdown menu that works for both hover and click. If it's a desktop user he gets the menu for the hover otherwise he has to click/touch whatever.

The twitter incident had nothing to do with the overall message.

For a second I thought that robots would finally start to fight for their rights.

Reply on news.ycombinator.com