Forum Moderators: open
You can perform an isometric test with this maneuver and you might notice that you hold the mouse with a stronger grip than you normally require.
More than half of third level students who are forced to use cascading menus during an hour's class will stand up from their seats and leave behind telltale stress marks, including warm mice, wrist cramps and sweat on seats.
If you are tied to a cascading menu structure for your online documents, you might check the research because a body of evidence is accumulating that provides a causal link between RSI and repetitive cascading menu selections.
I wonder if the WAI have any info on this? i certainly couldn't find any.
I mean, after all, window's start bar also doesn't require you to hold down the mouse button.
The best interface (IMO) requires a FULL click (down and up - not just mousedown) to trigger the cascade -- and then a mouseover to explore the revealed cascade.
Another full click should be needed to make a menu choice. A click outside the entire cascade can vanish the whole thing. Or, as an alternative scheme, a mouseout of the area of cascaded divs can turn it off.
I haven't done any full usability testing of this scheme - it is based on informal small scale testing/interviews. However, it is similar to the behavior we see in the Windows Explorer GUI and many apps and browsers as well. The familiarity of this behavior alone works in people's favor.
In the Windows GUI, once a first click reveals the cascade for that item, then a mere mouseover to any other menu choice also reveals the cascade for that item. However, on a website where large areas of information are revealed in the cascade, it may be better to vanish the whole thing onmouseout and require a new click to explore other menu selections. If the cascade reveals too large an area of information, then some users with smaller screen resolutions may have difficulty finding a non hot-spot to click on.
One of the challenges of cascaded menus is that the user is presented with a large number of choices from one screen. In an app, where the user is presumably devoting time to learn the interface and functionality, this makes sense. But I question whether it doesn't hurt a web site's stickiness. Too many choices often means the user will make no choice.
It's the Information Architect's job to set up an intuitive structure. It's often just the "easy way out" to make every choice available at once. However, cascades do eliminate those weird little "landing pages" for the top level of site sub-sections.
No, I'm afraid that I have no info on whether it's the click or something else that is the problem.
I agree completely with Tedster, in his suggestion of using a full click to trigger the menu spawning. The one thing I would comment on is that do most web surfers now expect mouseover menu spawning? Will making them click to see the menu just add another layer of useability problems?
As Tedster said, the Windows menu system uses a click-to-spawn and the mouseover - however, don't Mac users need to hold down the mouse button, releasing the button to make their selection? And are web users now expecting menu spawning on mouseover? Three similar systems, each employing a different method of menu cascading.
I do like cascading menus on large sites - but people need to be very careful about their Information Architecture on them. Too unwieldy a list can be very off-putting.
However, on the topic of RSI, I think that the use time for web users is significantly less than desktop application use, so the RSI implication is much diminished.
