No drop down menu. Designated action performed when the button is clicked.


Opens drop down menu.


Buttons with drop down menu but no indicators


A downward arrow, to me, means that a drop down menu will be open. More that often they don't have any special purpose. For example, the buttons in the first image when clicked perform the action that's designated to them and there is no drop down menu. In the second image button with downward arrow opens a drop down menu. The third image has buttons but no indicators yet they open a drop down menu. How do I tell which downward arrow button perform an action and which one open a dropdown menu?
What is the purpose of these V indicators?

Sudhir Khanger wrote:No drop down menu. Designated action performed when the button is clicked.

There is actually a drop down menu hidden in these buttons if you long click them. Generally speaking i agree that this could be more consistent throughout Applications.

Saabhero wrote:

Sudhir Khanger wrote:No drop down menu. Designated action performed when the button is clicked.

There is actually a drop down menu hidden in these buttons if you long click them. Generally speaking i agree that this could be more consistent throughout Applications.

Dang 2-3 years of KDE usage and I am not sure of basic interactions.

Sudhir Khanger wrote:Dang 2-3 years of KDE usage and I am not sure of basic interactions.

Rather 20 years KDE and still no consistency. The HIG says that menu buttons have to expand for starting a selection and split buttons should provide one default along with alternatives. But both types needs to be visually distinguishable, which is usually done by a vertical ruler for the split button. Depending on where you click you expand the menu or start the default action. Long vs. short press might be an alternative for mobile devices but with a lot of drawbacks. And I have no idea what advantages this approach should have on desktops.

I think we have mixed buttons and spinners. They should be separate. Buttons always perform the designated action and spinners always open drop down menu which takes care of confusion caused by long press.

Button


Spinner


Spinner in Material Design

Hi,

In Qt there are three types of "buttons with drop down menu"

1/ buttons with a default action, and an arrow that opens a menu immediatly when pressed
2/ buttons with a default action and and arrow, for which a menu is opened with a delay, when you press "long enough" on either the button or the icon
3/ buttons with no default action and a menu that opens immediatly wherever you press.

2/ should simply be banned, if you ask me
1/ is in fact two controls: one button next to a spinner. The spinner is indicated by the arrow
3/ is only a spinner. The arrow is not really needed, since there is no other available action than opening the menu. Hence it is also rendered the same way as a button (for which one action only is available too.

3/ is admittedly arguable. The reason why the arrow was removed is, as I said
- because it is not "strictly" necessary
- we do not have a good design for it: arrows rendered in the past tend to either overlap with the icon below in sometimes ugly ways, or to appear separate from the button, break the distribution of widgets and makes them float in the middle of nowhere.

In fact there is even an "open for discussion" bug report on this, at:

https://bugs.kde.org/show_bug.cgi?id=344746

hope this helps,

Hugo

So should we add this to the guidelines? https://techbase.kde.org/Projects/Usability/HIG/Buttons
* Do not use long press events to open the menu of split buttons on desktop apps. The menu of split buttons is accessed via location (the designated area to expand the menu) on desktop apps. For mobile apps it's better to use the long press event, however, in order to deal with the required larger interaction area.
* Take care of a clear visual indication of menu buttons that have a default action. This should be also true for mobile apps where the menu is opened per long press.

(Would be good to have exact Qt names as cues here.)

Yes, I fully agree that those "long press to open menu" buttons have to be "banned".
I don't know why Qt has introduced them and why some KDE applications use them, but they are simply and undeniably bad from an interaction perspective.
They are currently not specifically mentioned in the HIG, but I agree that we should explicitly advise not to use them, and then make KDE developers aware that they should go.

The kind exists because it's the typical behavior in webbrowser history buttons :-P

QToolButton::DelayedPopup
After pressing and holding the tool button down for a certain amount of time (the timeout is style dependant, see QStyle::SH_ToolButton_PopupDelay), the menu is displayed. A typical application example is the "back" button in some web browsers's tool bars. If the user clicks it, the browser simply browses back to the previous page. If the user presses and holds the button down for a while, the tool button shows a menu containing the current history list

QToolButton::MenuButtonPopup
In this mode the tool button displays a special arrow to indicate that a menu is present. The menu is displayed when the arrow part of the button is pressed.

QToolButton::InstantPopup
The menu is displayed, without delay, when the tool button is pressed. In this mode, the button's own action is not triggered.

In addition there are "Arrow Buttons" (ie. the toolbutton only displays an arrow, no matter whether it has a menu or an action assigned)

Imo on the look:
If there's a menu, this always needs to be hinted in some way - whether because the're an explicit menu section (MenuButtonPopup) or because the button simply exposes a menu (InstantPopup), since it's always "safe" to trigger a popup (where an action can be a destructive one)

My personal approach to visually deal with DelayedPopup is to "hide" them, ie. make them appear as if they only had their front action (what happens if you simply click them) and treat the feature as a goodie for experts (what it imo should only be used as, not as relevant UI element)

Firefox shows the menu with the page history on right click, therefore I never tried a long press. KDE (at least KMail and Okular) pop up some kind of toolbar context in this case, which adds confusion. BTW: Okular's single click is either toggeling this function on when in browse or zoom mode, or nothing when you are in the selection mode.

> KDE (at least KMail and Okular) pop up some kind of toolbar context in this case

They do *what*??? Got a screenshot?

luebking wrote:They do *what*??? Got a screenshot?

Just right click the menu button on Okular...

What "menu button"? I've a settings toolbutton and optionally a button to show the menubar. Former shows the settings dialog and latter toggles the menubar. So far so unspectacular ...

luebking wrote:Imo on the look:
If there's a menu, this always needs to be hinted in some way - whether because the're an explicit menu section (MenuButtonPopup) or because the button simply exposes a menu (InstantPopup), since it's always "safe" to trigger a popup (where an action can be a destructive one)

My personal approach to visually deal with DelayedPopup is to "hide" them, ie. make them appear as if they only had their front action (what happens if you simply click them) and treat the feature as a goodie for experts (what it imo should only be used as, not as relevant UI element)

hum. Wasn't bespin *not* showing an arrow for instant popup buttons ? Was this changed ? In bespin ? In virtuality ? I actually remember to make the step of dropping it after seeing it done there.

"needs to be" != "achieved"

In general, I don't want to clutter the toolbar with those arrows at all to begin with, so in virtuality (bespin being unmaintained and the behavior depended on the toolbutton style...)

- DelayedPopup: no indication at all and not intended (as stated, deemed pro feature)

- MenuButtonPopup: arrow fades in on hover

- InstantPopup: no indication - and I'm not happy with that. I neither want to show it all the time, nor make it look like MenuButtonPopup nor cover the icon with the arrow, nor make the indication too weak (or ambigious to the -already weak- toggle indication)
I tried crossfading the icon with a dropdown arrow, but that's too confusing as well; ie. i've no good solution to the problem atm.