Do you like the tabs used in http://www.msn.com ?
They can be activated by both hovering or clicking. There is a short delay on hover to prevent accidental activations, while clicking works immediately.
I kind of like them.
2
-
5Could you focus your question a bit? "Do you like" questions aren't really appropriate for StackExchange. Try rephrasing it to "Are the tabs on MSN.com usable?" or something like that.– RahulSep 2, 2010 at 18:52
-
2You kinda like them, I don't. With those I can no longer pause for thought without my UI possibly changing of its own accord because I happen to pause my mouse over a hover-tab... Yuck.– Marjan VenemaSep 3, 2010 at 19:45
Add a comment
|
3 Answers
They are neat, that's for sure. However, the function of interface controls should, in the very least, be
- plainly apparent by their appearance (or, conform with user expectations) and
- consistent throughout an interface.
These hover-to-activate section tabs are troublesome for a few reasons.
First, their appearance likens them with other click-only interface objects on the page, masking their actual function. They have an underline, similar to the top navigation and the hyperlink schema in general. They change on rollover, becoming bold, for that brief second before the tab changes, further suggesting that they are links. Then the interface changes without the user having made an interaction. Links and menu items don't "click" when you hover over them, and the easily mistakable resemblance will be confusing or slightly alarming.
Secondly, the hover function is not consistent with other tab-links throughout the site. This article, linked from one of the hover-tab boxes, has a similar related-content area below the article. Said box, however, only changes tabs when the user clicks on an unselected tab (no hovering action). Similar issues exist in other sections.
To sum it up, while they are cool in a Web 2.0-gimicky way, the novelty is overshadowed by usability problems, the cost of which may be greater than the benefit from having unique interface quirks.
Some reading:
-
-
Disagree about the need for consistency throughout. If a button is important on one screen but less important on another, it's acceptable to display it differently based on the context. More: gettingreal.37signals.com/ch09_Context_Over_Consistency.php– RahulSep 4, 2010 at 12:54
-
I disagree with your assertion in this specific case, but do agree in the more general sense. From 37Signals: "Give people just what matters. Give them what they need when they need it and get rid of what they don't." Users don't need a hover&click tab that looks like a click tab and can function as a click tab; just make it a click tab. While I certainly agree that "Adding superfluous nav elements, just because they're consistent with the rest of the site, is just silly," certainly you'll agree that adding superfluous nav elements, just because they make the site "cool", is just as silly.– MatthewSep 8, 2010 at 4:34
-
Agreed; I was commenting on the broader scope, not this specific case. :)– RahulSep 9, 2010 at 8:39
-
I predict that the answer to this question will change as people get used to the new schema of tabs that respond to a hover.
I remember asking a developer not to autoselect the text in a box, just after some browsers started doing this. My reason was "Nobody expects this behaviour." Since then, it's become common, so now I would pat the developer on the back, saying: "Thanks for contributing that idea."
Stick to the standard or push the envelope with something new? That's an interesting question. We have to remember that, as communication technologies go, web and graphical user interfaces are very young. I'd like to point to a different mass technology to explain my comment. Consider the cues we understand in printed books, such as footers or page numbers, which are primarily about orienting the user and finding/navigating to specific content. It took ages to develop these cues. We can liken those cues to controls, online and in application GUI. The schemata that help us navigate a printed book took generations to stabilize on an accepted norm; the controls that help us navigate through online content will also take time to develop and stabilize on a norm. Print books have dropped certain design solutions (such as repeating the last word on a right-hand page onto the top of the next left hand page, so the word is there when you flip the page — a cue that helped people read books aloud). Similarly, online controls are bound to change over time. It's unreasonable to expect that we got all the interaction details correct within the first few years of designing the navigation of online media.
Tabs that work only on click made it to market first, and people learned that schema. The nature of schemata is that our brains automatically adapt them to new experiences. Could the hover-tab work? It depends on how far it falls outside the schema of tabs, how useful it is, and how strongly users resist modifying their schema of tabs. Designers can help users to adopt this control by suggesting—Matt Lutze is indirectly asking for this in his answer to this question—ways to make the new control fit the existing schema more easily. Matt said: "their appearance likens them with other click-only interface objects on the page, masking their actual function." What's needed is a way for users to predict the action of these hover-tab controls.
I wonder why MSN implemented these controls inconsistently across the site. Is this an experiment? If so, I think it's an interesting experiment, and I'll reserve judgement on how usable this type of tab control is until the concept/design gets iterated to address the issues people are raising here.
-
Great followup Jerome - I certainly agree that contemporary function will change, and I hope change a lot (Minority Report, anyone? :-] ). It seems to me that change is perhaps more desirable if it comes from need rather than capacity. Click-only came first because we didn't have AJAX and jQuery to seamlessly support non-Flash interactive web elements. But having the capability doesn't mean it needs to be exercised—tell the king what he ought to do, not what he can do.– MatthewSep 8, 2010 at 4:40
-
1You indeed ask a question I'd intended: how could MSN alter the design of those tabs to indicate their different function? Finding an easily internalized schema for hover buttons would go a long way in increasing adoption, though we'd run the risk Christopher Scott identifies: the conceptual model for some interfaces simply doesn't support all features. It's great that you raise the idea of schemata. Matured schemata are a reason using standards when possible is important—the user's epistemology needs time to adjust when stimuli don't fit existing schemata.– MatthewSep 8, 2010 at 4:51
Not sure if you've considered this, but mobile browsers won't recognize hover. Since the mobile web is growing at a tremendous pace I think you could probably make the case to at least support click if not both.
However, if its part of the main navigation of the site (as it commonly used), opening the drop-down on click will eliminate the possibility of using that same link for the "section" page.
A couple possible solutions could be:
Hybrid approach, where the main link in the navigation still links to the "section" page, plus another link (down arrow) that will activate the drop-down on click. (examples: LJWorld, Flickr -- nav when logged-in). Personally, I've always liked this approach and wonder why more sites don't do it.
Use some sort of detection to serve hover-to-open to desktops, and click-to-open for the mobile folks.
