What do you call those hover-revealing layered-on-top contextual menus?

Jared Spool

February 20th, 2011

Greg wrote:

I’m interested in finding information about “On Object UI”. To me, this term means displaying controls on or near an object after the user has interacted with the object by hovering over or clicking on the object.

For example, in Microsoft Word, after highlighting/selecting some text, a Mini-toolbar appears near the text with choices that the designer thought the user was most likely to want to choose next.

Another example from Word: click on the File Tab from the ribbon (Office 2010) to enter the “backstage” of Office. Then click on the Info Tab. On the right hand side of the screen there is a “Related People” section. If I hover over the author name, or the “Add an author” text, additional controls appear offering functionality related to managing the author information.

This technique seems to work well, but what are the recommended best practices for its use ? What has been learned about this technique that is to be avoided ? Etc. And what is it called ? I know it by “On Object UI”, but a Google search of “On Object UI” finds very little.

If there is another name for it, I would love to know it. If there is not another name for it, then this seems like an area that User Interface Engineering should research and capitalize on by selling that information back to suckers like me.

Well Greg,

I think there’s a lot of thinking that’s gone into what you’re talking about. The broad term is pop-up menus, though people also call them context menus or on-hover menus.

Chapter 4 of Bill Scott & Theresa Neil’s Designing Web Interfaces talks about these as Hover-Reveal Contextual Tools. (Their book is a great resource. It should be within reach of everyone doing web design.)

I expected to find something similar in the Yahoo Design Pattern Library, but a quick glance didn’t yield anything.

That’s a start at least. We’ve looked at creating UIE pattern libraries, but it’s a hard challenge, as interfaces are constantly in flux. Just look at the recent patterns emerging from iPad apps and you’ll see that any library would have to double in size. I think they only way to do this would be wikipedia-style, with an army of folks trying to keep up voluntarily. That doesn’t lend itself to the making-money-off-of-suckers model.

Hope that’s helpful.

Jared

10 Responses to “What do you call those hover-revealing layered-on-top contextual menus?”

  1. James Schend Says:

    Just keep the poor tablet and touchscreen users in mind– both on the web and on your native OS apps. Without a mouse or trackball, there’s no concept of “hover” and the menu will never appear.

  2. Cliff Tyllick Says:

    Jared, I believe the general term for this on-hover interface might be “modal dialog.” And they’re a tough issue for accessibility, although they might become less of a barrier as more browsers and forms of assistive technology grow to support the coding techniques behind them.

    As for the specific example of Microsoft’s minitoolbar, I think the technical term for that is “PITA.” At least that’s what it is to me as I try to get thousands of people who to produce accessible content with Microsoft Word.

    None of the controls provided in that toolbar mark up content properly for accessibility. It’s the electronic equivalent of kindergarten tools — fat pencil, crayons, construction paper, safety scissors, and paste — when we need people to be using the powerful, accessibility-supporting tools of a third-millennium word processor.

    I don’t have a ready understanding of the ways modal dialogs can be coded and which of those ways are less of a barrier to accessibility, but I hope I can inspire others who do to join this discussion.

  3. James Schend Says:

    @Cliff: You might be thinking of older versions of Word, which indeed had a modal dialog version of the font/styles. (In fact, Word 2007/2010 do as well, if you click the ribbon control to produce it.) The “on hover” font controls are certainly non-modal, though.

    I don’t know exactly what you mean by “mark up content properly for accessibility”, but in the Word 2007 example, it’s a non-issue because the hover controls are duplicated in the Ribbon, which is accessible. It’s only an issue where the hover control is the *only* way to perform the action.

    I used a webapp some time back where “delete” was implemented as a hover control over the item you wanted to delete. While using my Windows 7 tablet, the control was entirely inaccessible and I actually send them a support email complaining about the inability to delete an item– it never occurred to me to plug-in a mouse and look for hover controls.

    Not only could I not use it with my preferred computing platform, I didn’t even know it *existed!*

  4. Cliff Tyllick Says:

    James, I am thinking of Word 2007 and 2010. As a person using the software, I find the only difference between the on-hover modal dialog and the older modal dialogs is that the software decides when I get the on-hover interface and I decide when I get the older modal dialogs.

    Clearly you misunderstand what I mean by not being able to mark up content properly for accessibility. I’m referring to the fact that as an authoring tool Word does not conform with the W3C’s Web Accessibility Initiative’s Authoring Tool Accessibility Guidelines in that it does not support the task of creating accessible content.

    The minitoolbar, which appears as if from the mists of a primeval swamp whenever I select a bit of text, lets me change the way text looks. It does not let me tell Word why I’m making that change in appearance. To give Word that information, I would have to apply an appropriate style.

    The minitoolbar lets me make headings look big and bold or italic and put them in a different font, if I want to. And I can use the idiot’s tool, the Format Paintbrush, to make all headings of the same type look alike. But it doesn’t let me assign a style to the selected text.

    When I make headings look like headings but don’t apply styles to them, Word can’t automatically produce a complete and correct outline of my document on demand. (Word calls that feature its Document Map — a tool that can be used not only to confirm the outline but also to rapidly navigate the document.) And Word can’t produce a complete and correct table of contents for me, either.

    For Word to help me in either of those ways, I have to create my headings using styles — styles that have the correct outline level as one of their attributes.

    And when Word can help me in those ways, people who can’t even see my documents can skim through them as quickly and reliably as I can. We can have real-time discussions of whether the current wording of the second step under “Resetting the Gonculator” in Chapter 17 is correct. That’s part of what the accessibility of electronic information is all about: Making sure that everyone, regardless of the technology they need to gain access to information, can get equivalent access to that information.

    The minitoolbar from the mists? To me, it’s an annoyance, not a feature. It undermines my workplace’s efforts to ensure that all of our electronic information resources are accessible to everyone.

    Come to think of it, the way that minitoolbar appears is appropriate. Because there’s a good name for an annoyance that is spontaneously generated by Microsoft Word and fades in and out of view like a specter:

    Ghost of Clippy

  5. James Schend Says:

    @Cliff: The major, by far most significant, difference between the older modal dialog and the hover controls is that the hover controls *aren’t modal*. I don’t know how you could possibly think they are… or what you think the word “modal” means… and it’s throwing me off.

    Nice tripe Clippy reference. Did you come straight from Slashdot to post that?

  6. Jan-Hendrik Spieth Says:

    Half-officially, there is something like that on Android, called ‘Quick actions’:
    http://www.androidpatterns.com/uap_pattern/quick-actions
    http://developer.android.com/videos/index.html#v=M1ZBjlCRfz0
    http://developer.android.com/videos/index.html#v=M1ZBjlCRfz0 (ff to 15:40)

  7. Brendan Regan Says:

    I’ve always referred to that sort of interaction as a “tool tip.” http://en.wikipedia.org/wiki/Tooltip

  8. Jared Spool Says:

    Brendan, a tooltip typically is just a label or title. It’s not a separate, interactive menu. Moving your mouse makes the tooltip disappear, which means you can’t select anything on it.

  9. Greg Phillips Says:

    Thanks for the replies. I emailed the original question to Jared and got a quick reply via email, not realizing that he was also posting the question on his blog. 9 months later I just stumbled onto this blog, by accident while once again looking for best practices for this kind of control…

    I’m surprised by some of the confusion regarding my original question. Modal dialogs? Tool tips? Ummmmm. Haven’t you ever used an application that used the context of what the mouse was hovering over to temporarily “reveal” some additional UI controls that gave you access to functionality without having to go search through a menu? When it works well, it is as if the software is reading your mind, and nicely suggesting some functionality for you to consider. Kind of like: Hey – you’re hovering over a graph, lots of times when people do that, the next thing they do is click to select the graph and then they go in search of the print button (or delete button, or whatever). Therefore, every time the user hovers over a graph, let’s automatically display a print button near the graph so they can easily access that functionality. Maybe that would be nice and efficient for the user. Maybe that would be annoying for the user, because they didn’t want that stuff popping up at them. Anyway, that’s the general idea. I think it works well sometimes, but not always, so I’d like to know when I should hover/reveal and when I shouldn’t.

    A good example from Apple (since there seem to be some Microsoft haters in here) is the Mac Mail app. When a mail message is open, hover near the gray separator line at the top of the message and – voila! – four buttons appear that let you delete the message and move quickly among your other messages.

    I was just looking for some best practices, some of which are probably common sense, like:
    1) Use it judiciously.
    2) Use it only for very common, or frequently used functionality.
    3) Fade the controls into view (don’t “pop” them up in an annoying fashion)
    Etc.

    My particular application of this kind of control that I’m considering is to reveal controls over a splitter control that lets users quickly move the split all the way to the top or bottom. Some in my group think this is bad, and that the controls should always be visible, or not visible at all. I like the idea of only revealing the controls when the mouse is over the splitter, under the assumption that the user has shown their intention to move the split. But I’m not sure. (So we’ll test of course.)

  10. Greg Phillips Says:

    Oh. And by the way, Jared’s answer was on spot. The book Designing Web Interfaces, by Bill Scott & Theresa Neil does a great job of explaining the design trade-offs (discoverability vs. visual clutter, etc.) Thanks Jared!

Add a Comment