Using hover-overs on the web when the goal is to allow rapid clicking

Question

I'm working to design a webpage where users are presented with a large number of product options, most of which will be irrelevant. Each product will appear as a tile and the tile will disappear upon clicking "X". For products that are more relevant, there is a separate user flow.

The products we present come from a recommendation engine and we'd like to refine the engine over time. The primary way we will identify irrelevant products is by measuring their clicks on the "X". However, there are several different reasons why a product may be irrelevant to a user and we'd like to also record that information to improve our recommendation engine. There is strong resistance for including any buttons other than the "X" on the tile -- and yet capturing the "irrelevancy reasons" is very important.

Our proposed solution is to popup a menu immediate when the user hovers over the "X". We'd like for the menu to have 3-4 items but are worried that this would be burdensome to users. If we opt for this option, there are a few decisions we are thinking to consider: 1) Should the user be able to click directly on one of the menu options after hovering over the "X"? or should the user be required to move her mouse slightly to select one of the options 2) If some variant of this design is chosen, what is the burden to users of having 2, 3, 4 options?

This is our best thinking so far, but I imagine there may be better and more creative solutions. Please let me know if there are any more details needed.

Answer 1

We don't have detail about the scenario for which you ask this question, so I hope this answer is relevant to you. Otherwise, just mark it as irrelevant to ensure that no-one else will benefit from the topics I discuss below, for their own scenario, for example.

(Did you see what I did there?)

You're mixing two goals:

1) Provide user with a list of relevant products

2) Improve the relevance of products shown

And your solutions for trying to achieve both is surely going to result in such a tight coupling of dependency and non-traceability, that you won't be able unravel it later.

Goal number 1 - you are by your own admission providing the users with mostly irrelevant results which isn't doing the user any favours in trying to efficiently find products of interest - which is all they care about. No-one likes to have to do work in order to get rid of the rubbish in order to find what they do want.

Goal number 2 - Essentially you are using your users to crowdsource irrelevancy data.

What is irrelevant to one user may be of interest to another and you will never capture the full spectrum of information that will allow you to provide perfect results for all users. You will end up providing only the products in the list that are deemed of interest by the majority of people, and omit those products that have been marked as irrelevant by the most number of people. This can skew results according to number of previous shows; positions in the list on previous showings; geographical interest; colour interest; male/female relevance; cost relevance etc etc (depending on what your products are and who your users are).

This is all gearing up your algorithm for determining relevance to be irrevocably tied in to data that has no hard evidence based reasoning for the majority of decisions it makes.

Let's compare the situation to looking at email:

Most of my email is spam. I get lots of spam. I have filters but they don't catch 100% of spam. I manually delete lots of spam so I can see the wood for the trees and deal with emails I actually want. There's also email server filters that delete 90% of email before it even gets downloaded - except occasionally it very annoying traps an email I did want to see.

Imagine if every time you deleted an email you had to say why it was irrelevant: It's spam; it's no longer relevant; I saw this earlier; I know what this is but it's not for me right now; etc etc. There could be any number of reasons why an email is irrelevant to me, but just because I deleted it, doesn't mean it wouldn't necessarily have been relevant to me last week, next week, if I weren't in a hurry, or just to someone else.

There is one thing that is the saving grace for email - I don't want to receive more of it - it's so annoying. But I put up with it because I need to receive my email. The ones I do receive and read make up for the ones that are irrelevant. So this can act as a spur to mark an email as spam before I delete. For me this means clicking on the 'toggle as junk' column in Thunderbird, before I delete. But even then, this is rare step compared to just hitting delete.

On the other hand I'm quite prepared to mark email for why it IS relevant - I'll add it to a folder according to its relevance (sender, project, pending action etc).

In short - I'm prepared to do more work where I have a positive feeling towards something, but less work for that to which I feel negative.

So consider these questions:

• Are you providing enough value to the user in the few products that are relevant for them to be prepared to put up with the work of dealing with all the irrelevant results?

• Is your relevancy algorithm going to be testable: Is there going to be a way that you can validate your algorithm - and verify that result inclusion or exclusion is right or wrong.

• Are you considering making the user work too hard on things towards which they feel negative, rather than on things to which they feel positive - such as dislikes rather than likes; deletions rather than wishlists and favourites; 'mark as irrelevant' rather than 'just leave alone'; negative actions rather than positive ratings;

• Should you be perhaps be relying more on pre-filters: good search; user filters; sorting mechanisms; well implemented faceted search, and generally better structure and organisation of data to show and control what the user sees, rather than getting them to weed out that which is not of interest first. Should you back this up with post-filters: favourites; wishlists; ratings; save for later; users also liked, etc etc.

Can you make it all a positive experience rather than a negative one - and still achieve your goals.

Answer 2

I agree with your concerns that a menu appearing on hover or click would greatly slow down the users. When the menu appears, even if they have seen it many times before, it forces them to readjust their focus on the new available options. If they need to go through a large number of products, this additional time and effort would cause them to lose interest more quickly, while clicking a single button allows them to go through rapidly, significantly increasing the average number of products that users will view.

Therefore, I would strongly suggest a row of small tile-like buttons. Constantly seeing the same options will allow the users to click them almost as rapidly as they would be able to click the "X", but without having to move their focus to the "X" and then move their focus again to the menu options. I understand the resistance to clutter this tile with more options, but if they are well-designed, I think they can appear just as minimal but increase users' efficiency.

However, as I write this, I realize that I am picturing a single tile appearing at a time, and when you close it another on appears. If by tiles, you mean that there is a grid of them with the instructions to remove the ones that the user is not interested in, then I think you could create an alternate workflow for these actions. Assuming that the user removes all of the ones that they are not interested in before dealing with the ones that they are interested in, I think you can remove the "X" altogether and simply instruct the users to click to remove the ones they do not like. When they click on a tile, a pop-up dialog could display the options with key commands (i.e. Type the number that most accurately describes the reason you have removed this product: 1 - Reason A, 2 - Reason B, etc.). After a few products, they will become more familiar with the options and, with one hand on the mouse and one hand on the keyboard, they will be able to click on products and select a reason quickly without much effort required. Focusing the mouse on the "X" and then clicking on a reason is too much mouse movement to expect a user to accomplish quickly, and I don't think their speed will improve over time as much as it would with my keyboard suggestion.

If you still feel that the hover menu will be your best solution, let me actually answer the questions you asked. If the menu will appear on hover (rather than onclick), remember that many users (and almost all first timers) will expect to be able to click on an available button. Therefore, if a menu option appears in that location, they will inadvertantly click on that option if it appears before they are able to notice it. Also, its possible that the convenience of that option may skew your statistics. For this reason, I think the options should have some offset so the user has to move the mouse to reach any of them. The most familiar placement would be for the top left corner of the menu to be aligned with the button (i.e., where the user's mouse is - same as right-click menus).

I don't think 3 or 4 options would be unreasonable. More than that would require too much effort from the users, though (in reading all the options, remembering all the options, and moving their mouse farther). If you decide on only 2 options, then ignore my placement suggestion and rather align the center left with the mouse (so they the options are equidistant from the location of the mouse). I'm going to stop writing here as I think I went into a bit too much detail... I hope this helps and please let me know if I can provide any additional feedback or clarification.