[kde-guidelines] Possible guidelines for buttons with menus

[Thomas Pfeiffer]

On 05.08.2013 10:57, Heiko Tietze wrote:
> Am Montag, 5. August 2013, 10:40:50 schrieb Aurélien Gâteau:
>>> But then it has the (in my opinion more relevant) drawback that the
>>> interaction and available features are not apparent to the user.
>>
>> That is true for delayed menu buttons, but not for menu-only buttons: there
>> is a down arrow on the right of the button, which I believe makes it clear
>> that this button is going to bring up a menu. Do you think it is still
>> confusing?

> It's not confusing that there is something (maybe novices do not understand it
> intuitively), but why should funtions be hidden? I cannot imagine any use case
> where menu buttons are really neccessary (okay: useful). They are always
> replaceable by a combination of simple controls.

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.
For example, Kontact offers to to create any PIM element from any 
sub-application (e.g. create an event from within KMail or a task from 
within KJots). This is simply a shortcut because you could always go to 
the corresponding application first, but I found myself using those 
things quite a few times, simply because that was convenient at the 
time. I wouldn't want all those buttons on every application's toolbar, 
though.
Of course Kontact is currently using the horrendous delayed menu button 
for this, which, frankly, was one of the worst UI ideas KDE devs ever 
had (and were never part of any HIG, for good reason), so I'm eternally 
grateful that they are finally going away.

The "reply to" button is another case where most mail clients I know use 
a split button, simply because many of the available variants of 
replying are too exotic to show them as separate buttons in the toolbar, 
but not exotic enough to remove them completely.

I agree that split buttons are not the exactly the best widget ever, but 
there are cases where I have not seen better alternatives to them yet.

>> Heiko and Thomas: Do you think segmented buttons would be a good addition to
>> our recommended controls?
> It would be, perhaps, if we could recommend when it should be used and when
> not.

Yes.
Some ideas on when they should be used:
- When an action is not used regularly, but is clearly related to the 
function of a button on the toolbar
- When there is also another way to execute the action (e.g. in the main 
menu)
- When offering all actions as separate buttons would clutter the 
toolbar too much [when we have an HIG for toolbars which contains a 
recommendation for the maximum number of buttons in them, we can refer 
to that)