[kde-guidelines] Possible guidelines for buttons with menus

[Aurélien Gâteau]

Le lundi 5 août 2013 13:43:54 Thomas Pfeiffer a écrit :
> 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.

Sorry for ruining your party, but while delayed menus have been removed from 
QPushButton (they were actually not provided by Qt but added by KDE), 
QToolButton (the one used in toolbars) still features those menus, as provided 
by Qt :/
> 
> 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)

Those are good guidelines for a SplittedMenuButton, what I mean with segmented 
buttons is a bit more generic. For example a set of buttons to pick font 
formatting (bold, underline, italic), could be implemented as 3 segmented 
buttons which would look like so:

	( Bold | Underline | Italic )

And the SplittedMenuButton is a particular usage of segmented buttons which 
would look like this:

	( Do Something | v )

Does this make sense?

Aurélien