Button flyouts behave differently (and much less efficiently) than menu flyouts
Button fly-outs require *six* steps to obtain a clear description of what they do (vs. 2 steps for menu fly-outs) = frustrating for any user who hasn't memorized every button flyout, and probably frustrating even for users who have.
Menu flyout: click->every option is visible and named->click what you want.
Button flyout: click 1)-> nothing is named, and no tool-tips appear until you 2) -> hold down your click, drag 3) -> release 4) -> move off the button area 5) -> move back onto the button area 6) -> tool-tip appears that says what it is (for example, "use pivot point center") 7) -> oh rats, that wasn't what I wanted 8) -> start over at 1) -> 9) -> if button fly-out option B) wasn't what you were after, start over again 10) -> AD NAUSEAM . . .
This is POOR button-fly-out menu design. I hate it! These should behave just like traditional menus: 1) -> click the button 2) -> A flyout of all the buttons appears and stays without the necessity of holding down the mouse click, so long as your mouse stays over the area of the fly-out 3) -> hover over any button in the fly-out, and a tool-tip for what the button is appears (the tool-tip should also list any keyboard shortcut for the button, re another suggestion!) 4) -> click the button for the desired feature/function.
This design would cut 9, potentially 10 or 18 or 20 or 27 or 30 steps out of selecting the tool you're looking for!
1 comment
-
Alex Hall
commented
I think many applications solve this with a triangle overlay on the corner of a button. Click the triangle and what I suggest happens (you open the fly-out, etc). Click off the triangle (on the button) and you've clicked the button/selected the tool.
Also, re step 5: necessary because no description/tooltip for the button appears while you are holding down your click to keep the menu open. Problem with my proposal: you don't always want a button to bring up a fly-out.