
KDE and the Menu Crisis - severine
http://www.ocsmag.com/2017/08/25/kde-and-the-menu-crisis/
======
mixedCase
I don't see the authors point.

Use the menu for discoverability if you even need that, any of the options
work.

For launching just partially type the application's name and press enter.
Don't even need a menu, just use KRunner (Alt+F2, there are equivalents in all
desktops).

My SO isn't confused by menus despite having little to no experience with
desktop computers, and neither am I, but I don't even have a full blown "menu"
because I don't need one; I just have dmenu installed.

~~~
eat_veggies
Can you make dmenu sort by most used? I want to switch over due to it's
awesome minimalism but that's a feature from rofi I can't go without, mostly
because to open my browser I can just go mod-d enter

~~~
mixedCase
I'd say stick with Rofi. I had considered moving to it but dmenu2 just works
well enough for what I want it to do to bother switching. If I was certain I
wanted more features, I'd go with Rofi.

------
bloaf
Question: How do you present the user with a list of all the applications on
the computer?

Answer: With a list (of icons + text) or list (of icon tiles) or a couple of
lists (same as the others, split by categories.)

You can slice and dice things however you like, but you are fundamentally
presenting a list of things, and I don't think we can fundamentally improve on
the process of presenting a list of things above and beyond literally showing
lists of things.

Search-ability is great, but it is only good for people who know the names of
the programs that do what they want. Icons+text are compact, but don't give
any indication of program functionality and don't scale well. Categorized
lists give both names and indication of program function, but require more
user button-pushing to find the program they want.

I think the only real improvement possible in this field is an application
search function that lets user search for what they want to do, rather than
for specific applications.

If the author wants to find a more realistic opportunity for improvement in
the "show all applications" direction, he should look at the "help" command
output, as compared to compgen -c.

------
ChuckMcM
I think this is a good start at looking at some of the human factors issues
with menus but it doesn't even seem to get out of the "known issues" on to
something more.

Menus have been an issue for a long time, ever since XDE[1] at least. The
original Mac "global menu bar across the top" was one shot at it, Xerox (and
XFCE it seems) had the menu popup when ever you hit the right button. Windows
of course had the 'start' button which did a 'menu reveal'. But there are
other interesting ideas in menus as well. One of my favorites in terms of
ingenuity were the pie menus[2]. I saw a demo which I believe was Don Hopkins
work and it demonstrated how quickly and accurately you could select things.
That speed and accuracy derived from converting menu disambiguation using a
bunch of possibly overlapping rectangles, to using only vectors from the
current point.

One of the challenges that has added to the problem has been ginormous
screens. When menu metaphors are attached to the physical screen boundaries
the amount of mouse movement needed is quite large. Of course with touch
screens it is compensated for by just moving your finger, but as we've seen on
iPads and Surface Pros that can limit menu density due to fat fingers :-)

[1] The Xerox Development Environment -
[https://web.archive.org/web/20041204132344/http://www.apears...](https://web.archive.org/web/20041204132344/http://www.apearson.f2s.com/xde.html)
(no doubt kens can fire it up on the Alto :-)

[2]
[https://en.wikipedia.org/wiki/Pie_menu#History](https://en.wikipedia.org/wiki/Pie_menu#History)

~~~
int_19h
It may be a rather weird test case, but one instance where I've seen radial
context menus used really well was Neverwinter Nights (the 2002 Bioware RPG).
It uses context menus to provide a variety of actions when applied to objects
in inventory and in the world (including the character itself) - e.g.
inspect/open/bash/lockpick the chest. Once it gets to spells and magic
abilities, you often have to go through many nested levels to pick the right
spell and parameters.

The beauty of their design was that the same action always had the same
position in the radial, regardless of how many actions were there overall, and
how many were not available in that context. Thus, picking the right item in a
series of cascade radials always took the same path. Eventually, your muscle
memory picked it up, and a frequently used action became a mouse gesture,
performed without even looking at the menu itself. But for those things that
are rare, you still retained the advantage of discoverability that menus
offer.

Here's an example, with someone showing off the gestures that they remember
(it stacks the actions up, so the character continues to perform them even
after the player stops providing further input):

[https://www.youtube.com/watch?v=uFevVjeawaY](https://www.youtube.com/watch?v=uFevVjeawaY)

One interesting thing that you might notice is that the subradials actually
replace the main radial, instead of the more usual expanding mode. I suppose
this is to allow essentially arbitrary nesting level without worrying about
screen estate. Every subradial had a "Back" command in the center.

~~~
sfRattan
It's interesting to look at how BioWare---back when it was BioWare---used
radial menus to great effect in multiple games. In addition to Neverwinter
Nights, the radial conversation menus in the original Mass Effect trilogy come
to mind. By assigning "Paragon" and "Renegade" dialogue options to standard
directions on the wheel, the system made it possible to pick a conversation
choice so quickly that the scene would run at a dramatic pace without the
awkward pauses in many other games as you scrolled through dialogue choices.

------
nol13
my win95 clone menu works just fine, thanks. go reinvent something else.

~~~
majewsky
This is being down-voted, but it's a relevant point. The cascading-menu style
of application launchers is from the 90s, yet is still very common for lack of
a better method of offering access to a potentially very large number of
applications.

If you think about it, even the homescreen of Android or iOS is basically the
same, although of course optimized for a touch interface. You have a long list
of apps, and you can group them into folders that open when you tap on them,
same as how a cascading menu opens when you hover its entry. The only
difference to the launchers included in Plasma is that folders on Android/iOS
are created and managed entirely by the user, whereas Plasma _insists_ on
using the application metadata to group stuff together.

Is there any other way? The only thing I can think of right now is search
(either via text or voice; all launchers in Plasma have text search over name
and description, so they're good there) and whatever the commandline does...
Stack Overflow, I guess? :)

~~~
pbhjpbhj
>all launchers in Plasma have text search over name and description, so
they're good there //

I find this a bit lacking, for example there's a lot more apps listed under
"audio" than "sound" yet for menu purposes, particularly discoverability, they
should be treated as synonyms; one can't be expected to remember the precise
adjective/noun used in an app description.

The thing I'd most like for the plasma menu is just to be able to alter it's
size, corner drag hasn't existed in KDE menu for a long time now. I do a
config file fix, which gets overwritten every update.

~~~
majewsky
This should work in Plasma app launchers. (If not, file a bug.)

A .desktop file (which, among other things, registers apps with these
launchers) has a GenericName field for precisely this purpose. For example,

    
    
      Name=Firefox
      GenericName=Web browser
    

A possible source of error might be that the application developer did not
enter a GenericName (or one that is not helpful, like "KDE clone of
$gnome_app").

~~~
digi_owl
Ugh. That gets me thinking about how Gnome seems to play games with this.

Take File Roller for example. Their git repository is names thus, the tar-
balls are names thus, even the resulting binary is named thus.

But the desktop file insists on calling it Archive Manager.

~~~
majewsky
Haven't checked, but that's probably the GenericName. The question is what the
launcher displays.

------
sandworm101
I require menus. I dont want dozens of icons and i certainly dont want to
employ a keyboard. I dont care that the full menu is ten layers deep. Ill move
the dozen programs i use every day into a top layer. i dont judge a ui on
simplicity or artistic merit. Let me launch my software via my mouse and then
get out of the way. Everything beyond that is overthinking.

------
oelmekki
Plasma is probably not the best example to illustrate this problem : should
everybody be happy with menus, you would probably still have 3 alternatives in
Plasma, because it's all about offering highly configurable experience.

Personally, it's extremely rare that I use the menu. I do everything through
Krunner, which is way more integrated and useful that it may look at first
glance. You can look for application by their name, of course, but also for
application by their description, for file by their name, for windows by their
running program or window title, etc. One cool underrated feature : you can
try to launch applications you haven't installed yet, and it brings up package
manager to install it (on KDE Neon, at least, not sure for other distros).

------
StillBored
The first comment in the article hits the nail on the head.

The start menu's are broken because everyone is trying to fix a non-problem
with the old win95 style hierarchical menu and creating things with worse
problems. Particularly, once the half dozen programs the user clicks
frequently are pinned in a quick launch area or at the top level of the menu.
For touch screen users, just bump the clickable area size for each menu and it
would present a better solution than iOS, Android or win10 currently provide.

------
lima
I've been using the Kupfer application launcher for years. Haven't touched the
KDE menu since :-)

~~~
abrowne
Same here, but Albert on Ubuntu MATE.

------
aembleton
I use Kupfer -[http://lifehacker.com/5344158/kupfer-launches-linux-files-
an...](http://lifehacker.com/5344158/kupfer-launches-linux-files-and-
applications-quickly)

Just ctrl+space and start typing in the name of the application you want to
launch. Works great. I very rarely use a menu.

------
saagarjha
On macOS everyone I know uses some sort of search, be it Spotlight or Alfred
or QuickSilver, to open apps. This generally works well–I can open most apps
in under a second.

------
mmphosis
Too many menus. Too many applications.

    
    
      Applications:
    

Web Browser

Email

Text Editor

Terminal

    
    
      User:
    

Switch User

Log out

Restart

Shutdown

~~~
aidenn0
Plasma's default setup starts with the favorites tab, which for me was
prepopulated with web browser, e-mail, and file manager (no text editor nor
terminal, which is sane for non-programmers). Pressing left goes to the
"leave" tab which hass all of the options you suggest, plus suspend and
hibernate. Pressing right goes to the "all applications' tab which is ordered
as a hierarchy.

------
tomxor
If you hate this stuff try dmenu... although it's not really target at DE
people.

------
jcrben
> However, as hard drives became larger, users had to scan more and more
> applications to find the one they wanted.

Not really. I only use a handful of desktop apps due to the rise of self-
hosted and browser apps.

------
bitbang
/molehill/mountain/g

