KDE and the Menu Crisis
ocsmag.com
ocsmag.com
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'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.
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'?
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.
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 :-)
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.
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...
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.
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
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.
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.
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.
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).
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.
Just ctrl+space and start typing in the name of the application you want to launch. Works great. I very rarely use a menu.
Applications:
Text Editor
Terminal
User:
Log out
Restart
Shutdown
Not really. I only use a handful of desktop apps due to the rise of self-hosted and browser apps.