[kde-guidelines] Possible guidelines for buttons with menus

[Thomas Pfeiffer]

On 05.08.2013 15:05, Heiko Tietze wrote:
> Am Montag, 5. August 2013, 13:43:54 schrieb Thomas Pfeiffer:
>> Of course a split button should never be the only way to do something.
>> However, I think they can be a good compromise between menu entry and
>> toolbar button, or a shortcut.
> A toolbar is used for fast access to frequently used function and not to
> present all features. Menu buttons are the opposite to this functionality. In
> respect to your kmail example: extra functions are moved to main menu (where
> they already should be available too), and a new contact would be created by
> Alt+N+C, or the like.

The nice thing about split menu buttons is that you don't need a main 
menu to access them. Main menus have been relegated to menu buttons in 
more and more applications recently, and KWin offers menu buttons via 
dbus menu as well.
So for people who want to hide the main menu behind a button to conserve 
vertical space, doing something via menu (with the mouse only) requires 
one more click than using a split menu button.

> But another argument: How do you provide accessibility? I guess the button can
> be reached by tab (if it's not a toolbar button, of course), and then cursor
> down invokes the menu? And again cursor down goes through the items, with
> enter to execute the function? Does it work with a screen reader?

I like the way Outlook 2003 does it (I hate pretty much everything else 
about that application, but they got their split buttons right): When 
the split button is focused, pressing enter executes the main function, 
pressing cursor down opens the dropdown, so it's not seen as two 
separate controls. Seems pretty intuitive to me. I don't have a 
screenreader installed, though, so I do not know how that one describes 
the widget.

In general: Every single email/PIM client I know uses split buttons, as 
does MS Office, LibreOffice, Calligra, Firefox until it switched to a 
delayed menu (probably for the sake of looks, but to the detriment of 
usability), ..., so I assume that at least one of the existing 
applications has sorted out the a11y problems already and we can borrow 
from the one that did it best.