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.
I mostly agree, but think the main issue is /discoverability/.
I had no idea I could get back to a traditional menu mode (in KDE Plasma) if I wanted (I'm unsure if I do).
The menu doesn't educate me what the 'short command' for a program is, so it can't teach me how to find it or launch it directly by typing in that shorter name (but searching for the literal executable name does work if you happened to know it).
The tasks and other features are things I haven't noticed.
Maybe a built in 'demo / training' application could show me the intended workflow, and then ask me to replicate it within a test 'desktop window'?
Right. Quick accessibility with a keyboard shortcut and partial name typing is the way to go. The trick is ensuring you have the right name (so a slight learning curve).
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
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.
This entry just seemed like an elaborate, well-written, well-documented complaint.
I've been reading so many articles lately that say "Stuff's on fire, yo." But they don't go into why, they don't mention alternative solutions, or who is trying to do something about it. They are the journalistic equivalent of a tweet saying "Hey, my nose itches."
Don't keep me in suspense, did you develop a new means of itching said nose? Have you interviewed other itchees to find out if there's a new trend?
There's an entire half of this article missing where discussion of alternative methods of computer interaction are offered up. Voice launch, context-sensitive palettes, random launch lottery with an I'm Feeling Lucky button...
But it's not there, just an "I hate menus" kvetch.
Sigh.
Tell me a story, while you're complaining, and make sure you have an ending. Otherwise it's just a far-too-long bumper sticker.
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).
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? :)
>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.
> "audio" than "sound" yet for menu purposes, particularly discoverability, they should be treated as synonyms
The answer for that has been staring us in the face since the 80s: good icons. I shouldn't have to navigate words, I should be able to navigate concepts and intuitions through icons that work at subliminal level. But good icons require good icon designers, which are few and far between; they require icon designer to work closely and in harmony with UI designers and developers, which is challenging; and they require a shared body of iconographic culture that is often impossible to achieve (e.g. a "rescue" concept could use a red cross in Europe / Americas / Australia, but it would have to be different in other continents).
That brings you to the mess that is mobile app launchers.
The problem is not whether the cue is visual or textual, the problem is that were cannot all agree on how to categorise thousands of apps in a way that is useful to all of us.
In the big picture, we've only been trying to do mobile launchers for about 10 years. 10 years after C, we were still very far from getting Python; it doesn't mean we should have stopped trying to make better high-level languages.
I still think a purely-icon-based approach, possibly augmented with optional search, is the best option. IMHO Apple got it almost right with desktop Launchpad. Yeah, it takes the whole screen, but the human mind is single-task oriented - while you are launching an app you are not trying to also type out a document exactly at the same time, fullscreen is fine as long as it's dealt with it quickly enough to reduce the overall interruption to a minimum. Where launchpad fails is in having groups shown as a collection of miniaturized icons with associated (small) text, which is hard to grasp at a glance. It would be better if I could associate an icon to the group, maybe having it automatically suggested when you create the group.
> the problem is that were cannot all agree on how to categorise thousands of apps
I partially agree, but realistically speaking we've been failing to solve the taxonomy problem with documents for 50 years and we're still nowhere near having a solution (folders, tags, views, colors, whatever - someone will always disagree). I don't think we can (or should) wait for that to change before we can attack this problem.
IMO tags with filters is better than trying to create an applications hierarchy, particularly if you only place one link for each app in that hierarchy.
Tags for function, and major alternatives are probably needed if you want a high degree of discoverability.
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").
My point is more that the approach (this isn't a good example, but i think it shows the problem) of having a single generic name is insufficient. Perhaps someone coming from another OS types "explorer" when looking for a browser, "zip" when looking for an archiver.
That gets me thinking. The touch screen launcher system is a throwback to even before Windows 95, and to Windows 3.x or even earlier, never mind the likes of Mac or Amiga.
Back then you didn't have menus, you had nested folders (kinda made more sense on the Mac and Amiga where you were browsing actual floppy content rather than a HDD).
The Windows 95 menu was basically a translation of that folder tree into a menu (you could even right click the start button and have explorer open the root folder of that tree).
Never mind that back in Win95 the root menu would cascade in columns rightwards based on screen height (and resolution). I think it was either the IE addon pack or Windows 98 that gave us the scrollable single column pr depth menu.
Indeed. Reading this makes me suspect someone is planning to 'fix' KDE with something that will inevitably end up being awkward, expensive and take five years to mature. Unless there is a demonstrably better solution in mind leave the menus alone. Every attempt to supplant traditional menus that I have experienced has only created obscurity, added weight and fueled no end of animosity.
I hate to take a bad attitude towards someone's inspiration and well meaning intentions, but the users of open source desktop environments (and proprietary ones for that matter) have endured a lot of iconoclasts, and I don't see that it has achieved much. If your plans are demonstrably better they'll take hold among the enthusiasts and spread beyond without writing think pieces to promote them. Otherwise, should you instead choose to foist your plans on the innocent, be prepared to live in a furnace for about a decade. Right or wrong that is what you can expect.
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.
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 :-)
Pie menus are great for selecting from a small number of options quickly; I'm not sure that they are any better when chained than rectangular menus though.
I used a radial menu extension in the early versions of Firefox that I thought was fantastic. I assume they don't have more widespread use because it typically depends on symbol memorization, and people are already used to long lists of things?
I suspect i tested the same one, and best i recall it didn't mix well with other extensions that added stuff to the right click menu.
Best i can tell, radial works as long as you have a small, fixed set of action that you want to do repeatedly.
But once you have a situation where the user can add arbitrary new actions it breaks down because it relies on the actions being sorted and fixed in location.
The result, as best i recall, in the Firefox extension case, was that extension added menu entries would dangle of in some "misc" entry at the bottom right of the radial. Effectively turning it into a traditional menu dangling off a radial one...
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):
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.
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.
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.
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.
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.
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.
45 comments
[ 10.5 ms ] story [ 102 ms ] threadUse 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.
I had no idea I could get back to a traditional menu mode (in KDE Plasma) if I wanted (I'm unsure if I do).
The menu doesn't educate me what the 'short command' for a program is, so it can't teach me how to find it or launch it directly by typing in that shorter name (but searching for the literal executable name does work if you happened to know it).
The tasks and other features are things I haven't noticed.
Maybe a built in 'demo / training' application could show me the intended workflow, and then ask me to replicate it within a test 'desktop window'?
I've been reading so many articles lately that say "Stuff's on fire, yo." But they don't go into why, they don't mention alternative solutions, or who is trying to do something about it. They are the journalistic equivalent of a tweet saying "Hey, my nose itches."
Don't keep me in suspense, did you develop a new means of itching said nose? Have you interviewed other itchees to find out if there's a new trend?
There's an entire half of this article missing where discussion of alternative methods of computer interaction are offered up. Voice launch, context-sensitive palettes, random launch lottery with an I'm Feeling Lucky button...
But it's not there, just an "I hate menus" kvetch.
Sigh.
Tell me a story, while you're complaining, and make sure you have an ending. Otherwise it's just a far-too-long bumper sticker.
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).
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? :)
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.
The answer for that has been staring us in the face since the 80s: good icons. I shouldn't have to navigate words, I should be able to navigate concepts and intuitions through icons that work at subliminal level. But good icons require good icon designers, which are few and far between; they require icon designer to work closely and in harmony with UI designers and developers, which is challenging; and they require a shared body of iconographic culture that is often impossible to achieve (e.g. a "rescue" concept could use a red cross in Europe / Americas / Australia, but it would have to be different in other continents).
The problem is not whether the cue is visual or textual, the problem is that were cannot all agree on how to categorise thousands of apps in a way that is useful to all of us.
In the big picture, we've only been trying to do mobile launchers for about 10 years. 10 years after C, we were still very far from getting Python; it doesn't mean we should have stopped trying to make better high-level languages.
I still think a purely-icon-based approach, possibly augmented with optional search, is the best option. IMHO Apple got it almost right with desktop Launchpad. Yeah, it takes the whole screen, but the human mind is single-task oriented - while you are launching an app you are not trying to also type out a document exactly at the same time, fullscreen is fine as long as it's dealt with it quickly enough to reduce the overall interruption to a minimum. Where launchpad fails is in having groups shown as a collection of miniaturized icons with associated (small) text, which is hard to grasp at a glance. It would be better if I could associate an icon to the group, maybe having it automatically suggested when you create the group.
> the problem is that were cannot all agree on how to categorise thousands of apps
I partially agree, but realistically speaking we've been failing to solve the taxonomy problem with documents for 50 years and we're still nowhere near having a solution (folders, tags, views, colors, whatever - someone will always disagree). I don't think we can (or should) wait for that to change before we can attack this problem.
Tags for function, and major alternatives are probably needed if you want a high degree of discoverability.
A .desktop file (which, among other things, registers apps with these launchers) has a GenericName field for precisely this purpose. For example,
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").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.
Back then you didn't have menus, you had nested folders (kinda made more sense on the Mac and Amiga where you were browsing actual floppy content rather than a HDD).
The Windows 95 menu was basically a translation of that folder tree into a menu (you could even right click the start button and have explorer open the root folder of that tree).
Never mind that back in Win95 the root menu would cascade in columns rightwards based on screen height (and resolution). I think it was either the IE addon pack or Windows 98 that gave us the scrollable single column pr depth menu.
I hate to take a bad attitude towards someone's inspiration and well meaning intentions, but the users of open source desktop environments (and proprietary ones for that matter) have endured a lot of iconoclasts, and I don't see that it has achieved much. If your plans are demonstrably better they'll take hold among the enthusiasts and spread beyond without writing think pieces to promote them. Otherwise, should you instead choose to foist your plans on the innocent, be prepared to live in a furnace for about a decade. Right or wrong that is what you can expect.
Just ctrl+space and start typing in the name of the application you want to launch. Works great. I very rarely use a menu.
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... (no doubt kens can fire it up on the Alto :-)
[2] https://en.wikipedia.org/wiki/Pie_menu#History
Best i can tell, radial works as long as you have a small, fixed set of action that you want to do repeatedly.
But once you have a situation where the user can add arbitrary new actions it breaks down because it relies on the actions being sorted and fixed in location.
The result, as best i recall, in the Firefox extension case, was that extension added menu entries would dangle of in some "misc" entry at the bottom right of the radial. Effectively turning it into a traditional menu dangling off a radial one...
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
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.
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.
Email
Text Editor
Terminal
Switch UserLog out
Restart
Shutdown
Not really. I only use a handful of desktop apps due to the rise of self-hosted and browser apps.
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.