Hello everybody, i´ve been a KDE user and fan since around 8 years now and i am excited with this project to bring good design to our favorite desktop, congratulations to everyone, especially to Jens for the initiative.
Now, more than an idea this is a suggestion, a little detail that can improve KDE´s usability: to use Popup menus instead of Pulldown menus or at least include them as an option in the new theme. We can see Gnome and Mac OS using this kind of menus and is not a simple matter of style. Why?



When a user click on a Pulldown menu scrolling is often needed even if the number of items is not too big, forcing the user to scroll up and down to be able to see the rest of them, adding unnecessary effort.



When a user click on a Popup menu all the information he/she needs is right in front of their eyes taking the necessary space to display all the items. Sometimes scrolling is necessary, however, this is not the whole time just when there are too many items. A quick visual scan then a click on the right element, no extra effort is required.
As we can see Popup menus are more ergonomic, easier to explore and i think users adapt easily. Aesthetically they are more clean as they don´t have scroll bars.
Technically i guess this is possible, Qt added support for this kind of menus some years ago AFAIK, they are also present in Qtcurve. Maybe this needs to be added in the HIGs, don´t know how difficult that would be. Anyway, this is my little suggestion.

Thank you very much for your amazing work .

I know popup menus as different controls that behave like every other menu. It opens on right click and present some options to the user, mostly to execute a function. In contrast to this widget the dropdown must not be used to start an action and is a good choice for single selection out of a limited number of items. But the content list opens in the same way. So I understand the different appearance as a bug since your second screenshot hides the background. E.g. I don't perceive easily where it has been started. Furthermore you run into trouble with long list that present all options to the user. On high resolution screens it might be up to 50 items, I guess.

Some refs to the HIG:
Dropdown control: http://techbase.kde.org/Projects/Usability/HIG/DropDown
Popup or context menu: http://techbase.kde.org/Projects/Usabil ... ontextMenu
List view: http://techbase.kde.org/Projects/Usability/HIG/ListView

Ok, maybe the names i used are not accurate, although i know them as Popup menu in Qtcurve you can find it in the Combo section as "GTK Style" i think, but they have nothing to do with Context menus. The popup menus i know are mentioned in the Fitt´s Law: https://en.wikipedia.org/wiki/Fitts%27s_law. The behaviour of hiding the background is intended that way.

I couldn´t find anything from Gnome but here are some screenshots from Mac:
https://wiki.mozilla.org/images/7/73/Ma ... p_menu.png
http://www.reed.edu/cis/help/print/imag ... t-menu.jpg
http://www.oreillynet.com/mac/blog/imag ... tHTML3.jpg
http://storage.uxguide.net/wiki-imgs/ma ... popped.jpg
https://support.apple.com/library/APPLE ... rinter.jpg
I´ve had checked the HIG already that is why i wondered if this kind of menus might be included.

Thank you.

I just tested the Next QtCurve theme available and you know what? I realize that it uses this "GTK-Style" Non-editable Combo (that's the description for this widget in Qtcurve). Maybe this will actually be in the new theme after all, i know is an early preview, but i hope it will be present at least as one more option as i said in my first post. And sorry for the names confusion.

Thank you.

juang wrote:I just tested the Next QtCurve theme available and you know what? I realize that it uses this "GTK-Style" Non-editable Combo (that's the description for this widget in Qtcurve). Maybe this will actually be in the new theme after all, i know is an early preview, but i hope it will be present at least as one more option as i said in my first post. And sorry for the names confusion.
Thank you.

The final widget style will not use QtCurve, so it won't get this kind of combobox behavior unless we consciously decide to do it that way.

Personally, I don't see a big advantage, though. That not all items are shown without scrolling in the dropdowns is on purpose, in order not to overburden users with a too long list. If we have evidence that people can easily scan longer lists at once, that number can be increased so the only limit would be the screen size (which, in the days of ever-increasing screen resolutions shouldn't be too much of a problem, at least on desktop/laptop screens). The only case where a dropdown naturally can show less items without scrolling is if it's in the center of the screen (of it's near the bottom, the dropdown automatically becomes a "dropup").
So, the scrollbars are not really a dropdown-specific thing.

Do you have any evidence supporting your claim that popups are "more ergonomic" than dropdowns? If so, I'd be interested to read about it, so I can learn something new (this is not meant sarcastically, I'd really like to learn about the reasoning behind that change in OSX and GNOME).

I noticed that some people can get lost in long lists, which they have to scroll, regardless how big elements of those lists are. So If they have long list on long space (in popup) and they have to scroll, they won't get lost because of huge amount of reference space. So in this case it would be helpful.

Leroux wrote:I noticed that some people can get lost in long lists, which they have to scroll, regardless how big elements of those lists are. So If they have long list on long space (in popup) and they have to scroll, they won't get lost because of huge amount of reference space. So in this case it would be helpful.

Have you observed those same people search for something in a long list that is completely visible? I'd like to know if they indeed do not get lost there.

I actually really like the idea of the pop-up menu. It makes all options visible at once and makes scrolling unnecessairy.
Also, and that's what I like most about it, is the fact that it effectively halfes the distance/time to reach a certain option, since you are in the middle of the list. I think this division also makes it easier to scan, becasue you have an upper part and a lower part, and you actually have a reference point. This would explain @Leroux statement, and I fully aggree with it.

On a side note: Not needing to scroll is IMO making it a bit less "complex", and for me who has a broken scroll whell (and I think this is a rather common issue), it is obviously a relief not needing to use the scroll bar.

And then, I actually see no reason for not using a pop-up menu...

The problem with the GTK-style popup menu is that it harms "muscle memory". The position of the options will depend on which option is currently selected, thus you can't "learn" as easily where a certain option is placed when you use a particular menu repeatedly.
Also, for long lists, it potentially covers large parts of the screen. As long as it's <10 entries it's fine, but if it's 300 it's horrible -- then the variant with scrollbar is much better. Of course, you shouldn't use a dropdown list in this case anyways in theory, but many programs still do.

For an example where it doesn't work well, try gedit. Especially, clicking it twice will change your selection to something semi-random which is ugh.

Anyways, I think this is one of the typical things you can never agree on, and which should simply be configurable in the theme. I'd favour the old variant staying the default though.

"Muscle memory" is a perfect argument against GTK style. Furthermore, KDE provides auto complete that can be used for navigation in long list. Is there anyone who scrolls to the country name? And finally, dropdown or menu lists must not exceed a certain extend. It is useful in cases with a few options, that are known to the user. Otherwise a list view should be preferred, basically.
But my main concern about use of control A instead of B is that you never get it consistently implemented. If some dialogs makes use of popups (or whatever you call it) solely and others apply dropdowns in similar cases, users get confused about the reason. The right way is to enhance an existing control and to define situations in which the new property is set.

colomar wrote:Have you observed those same people search for something in a long list that is completely visible? I'd like to know if they indeed do not get lost there.

Actually I observed that if they have such opportunity, they resize view space of long list so they can get some orientation.

Leroux wrote:Actually I observed that if they have such opportunity, they resize view space of long list so they can get some orientation.

That might still be because they're used to that, what I'd be most interested in would be if a longer list would actually allow them to find things more easily. I'm a psychologist, such things make me curious

There's probably a limit but for short lists that is certainly the case -- if only one element is displayed at once it will take you a very long time to find the one you want. Especially if the elements are not sorted by what you're looking for. We could easily make an experiment though ...

scummos wrote:We could easily make an experiment though ...

Indeed, this is something which can quite easily be tested empirically. We really should do that instead of discussing based on assumption

I did this now, and the results are quite surprising. When finding words in an unordered list, I'm fastest when the list is of medium size. A very large list actually has a negative effect. Look:


Different results arise when the list is sorted (I used the hotkeys here to jump to a section):

But also here, it looks like the 100 px list is quite good.

You're invited to do more statistics on this, it's quite noisy. The program does everything, complete with plots n stuff (look at how much you can do with 92 lines of Python! Do that in C++ ... )
main.py: http://paste.kde.org/paxgirdoa/pjzzit/raw
lists.ui: http://paste.kde.org/pwstcvfzy/xuvigg/raw
lists.py (or pyuic4 lists.ui > lists.py): http://paste.kde.org/pbwpkrpwq/pojx8y/raw

Have fun with it