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.
They are neat, that's for sure. However, the function of interface controls should, in the very least, be
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.
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.
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.