« Controls of the Week: HorizontalPanels and VerticalPanels for basic CSS3 flexbox layouts today | Main | Make web menu bars more usable: open a menu on hover only if another menu is already open »

March 26, 2012


Ian Hamilton

I’d discount 2, 7, 8, 9 10 and 11, that makes the options a bit more manageable –

2. Inconsistent, means that things that contain interactive elements are needlessly different to things that don’t

7. There’s no way of knowing how quickly people are able to read

8. Hovering shouldn’t ever produce pop-ups

9. Applies to right-click contextual stuff, but not modals

10. Open a modal, text is too small, hit alt to get into menu to find zoom control.. modal has vanished

11. Assumes that modals are always smaller than viewable area, which isn’t the case, especially with zoom settings in both mobile and desktop browsers

Jan Miksovsky

Ian: I'd agree that not all of these methods are equally useful or usable across all forms of popups -- although all of these are in use, and for each there's at least some context in which the technique is reasonable or even expected. E.g., in a Windows client app, #10 is an expected part of the platform. I agree it'd be weird in a web app for the reason you specify, which is why I left that behavior out of the QuickUI implementation.

BTW, I'm not sure I'd agree with a blanket prohibition on having hovering produce a popup. A tooltip is a form of popup whose utility entirely depends on opening on hover. And the menu riffing behavior, in which menus *after the first* open on hover, seems elegant and justifiably used across Windows and Mac OS/X. (I agree that having hover produce the first menu is problematic, and I avoid it myself.)

The comments to this entry are closed.