App menu redesign

[ninavizz]

Problem

The app menu today is overwhelming. It needs a lot of work, and once a design is validated in user testing a custom solution apart from what is possible with XFCE will likely need to be created. Many issues have been filed addressing usability issues around the App menu, and this issue was created to track the design exercise and delivery of assets for creating what is decided upon.

2021 EDIT: A Design Brief to guide this project towards completion, was created as both a public GDoc and an Etherpad.

Solution

2021 EDIT: A modest grant was awarded to the Qubes OS project, to fund:

1. User research and design, for a custom appmenu to better serve Qubes OS users, and
2. A modest/bare-bones implementation.

As such, the #6665 issue has been created to track the first "bare-bones" development of a Qubes custom app menu (nicknamed "Valentina"), that resulted from the funded preliminary design and research. The issue for Valentina is being pointed to as a 'parent' issue to multiple descendant child issues. Descendant child issues, exist to track features that users responded to favorably in preliminary user research—and that we hope to receive community support to implement.

For this issue's initial filing, the below was attached as a proof-of-concept mockup.

Related Issues

#5386, #5676, #5520

[ninavizz]

Icon art for w/in the app menu that @marmarta had previously commented on liking. Pls to post screencaps of what these look like when in code, and I can make adjustments accordingly—unless further tweeks are sought. :)

AppMenu-main.zip
TopBarButt.zip
Qube Colored Settings.zip

[andrewdavidwong]

Have you considered a design that combines the Qube Manager with the Applications Menu? Or would that be a further step beyond this?

[ninavizz]

@andrewdavidwong An "App Menu" is a standard component of any OS that users expect to have, for easy access to "things they need now." The Qube Manager I see as more of a system tool for configuring the orchestration of Qubes, settings for each, etc.

Holistically, both, along with the Domains menu and System Settings, need to be rethought in broader usability work... but this one "thing" I will assert, does need to exist, in some capacity, for users to quickly access apps & such.

[mfp20]

From previous comment

the only thing I feel the lack of ... is to be able to hide/show some of the VMs (ex: hide/show templates, hide/show red VMs, etc)

Side note. The same applies to the system menu: I don't need the templates listed in the menu as templates apps are not meant to be run from the menu (and I usually just "run command in qube" from Qubes Manager, most of the times the only thing needed to run in a template is xterm, gnome-terminal or xfce4-terminal). Moving the files out of usr local share applications (and the same user home directory) is an option but takes long time to identify the correct .desktop file for EACH app of EACH VM.

[ninavizz]

1. I do wonder how often users seek to open/access TemplateVM things, from the app menu. Is there a purpose to them even being listed, there? Same with ServiceVMs.

2. I am also curious: where did the nomenclature "Domain" come into play? I seem to hear it used interchangeably with "AppVM," and that feels problematic. "Domain" has a specific use in Windows-land... and I'm additionally concerned with conflation with what it means, there, here.

3. What does "Run Program" mean? Is it meaningful to anyone not fluent in CLI things? It feels redundant to me, with dom0 Terminal... or, at least, that it provides little value as a thing in addition to the dom0 Terminal (which I do feel has value, where it is).

W/o a proper survey in place, I'd love to hear answers to these questions and other feedback/thoughts on today's AppMenu, by anyone who'd want to chime-in, below! :)

[0spinboson]

1. I do wonder how often users seek to open/access TemplateVM things, from the app menu. Is there a purpose to them even being listed, there? Same with ServiceVMs.
2. I am also curious: where did the nomenclature "Domain" come into play? I seem to hear it used interchangeably with "AppVM," and that feels problematic. "Domain" has a specific use in Windows-land... and I'm additionally concerned with conflation with what it means, there, here.
3. What does "Run Program" mean? Is it meaningful to anyone not fluent in CLI things? It feels redundant to me, with dom0 Terminal... or, at least, that it provides little value as a thing in addition to the dom0 Terminal (which I do feel has value, where it is).

1. since switching to Qubes 4.1 and KDE plasma 5.17 (which works surprisingly well), I alternate between using the app menu's search and the dom0 cli (I prefer xfce4-terminal over xterm because of font scaling, 4k monitor). Same goes for service VMs, though I tend to use cli more there for root login (no sudo in the minimal template)

2. I don't know. :p

3. where do you encounter this?

[92VV3M42d3v8]

What about appmenu showing just entries -
dom0
TemplateVM
ServiceVM
AppVM
and similar entries with Side Bifurcation.
This can avoid issues of lengthy App Menu for uses having Multiple App VM and Template VM. (This will be especially helpful for myuse case scenerio as I have multiple Service VM and App VM. I can assume that many users who might be using Qubes for many years might have many Template VM as well.)
Also one more thing I have wondered always that why Qubes Update is not included in Qubes tools entry...

[92VV3M42d3v8]

1. I do wonder how often users seek to open/access TemplateVM things, from the app menu. Is there a purpose to them even being listed, there? Same with ServiceVMs.

2. I am also curious: where did the nomenclature "Domain" come into play? I seem to hear it used interchangeably with "AppVM," and that feels problematic. "Domain" has a specific use in Windows-land... and I'm additionally concerned with conflation with what it means, there, here.

3. What does "Run Program" mean? Is it meaningful to anyone not fluent in CLI things? It feels redundant to me, with dom0 Terminal... or, at least, that it provides little value as a thing in addition to the dom0 Terminal (which I do feel has value, where it is).

W/o a proper survey in place, I'd love to hear answers to these questions and other feedback/thoughts on today's AppMenu, by anyone who'd want to chime-in, below! :)

1. I do use Template VM terminal. I also use Files on Clone of Template VM. So yes these should be there. And also for Service VM. I know not much users use sys-net, sys-firewall and sys-whonix entries from here but what about VPN VM. Those too get listed as Service VM and we have to use at least Files and Terminal entries for them.
2. Domain name should be replaced by AppVM most probably, I'd agree.
3. I am totally agree.

[brendanhoar]

1. I do wonder how often users seek to open/access TemplateVM things, from the app menu. Is there a purpose to them even being listed, there? Same with ServiceVMs.

[My arguments below for defaulting to showing them aren't very convincing, and I'd prefer templates be in a sub-menu, TBH. Or hide/show via a flag in the menu if UX says no to submenu. Or some other way if UX says no to flag in menu.]

I do launch a terminal, nearly daily from each Template. Mostly because a) I haven't learned to trust the built in qubes updater and have disabled it everywhere b) I like to eyeball the updates coming before consenting to installing them and c) I still manually trim each template after each update.

So, typically I launch a terminal for all templates manually, move groupings to separate desktops (fedoras and centosen on one desktop, debians on another, etc.) then do a two part "manual" update in each window.. I've been meaning to script that though, at which point I'd probably never launch templates from there very often.

The above is, of course, likely atypical behavior.

One other thing is that I tend to clone templates to ephemeral pools from time to time. I'll eyeball the menu to be sure I qvm-removed them correctly when done. That can also be done from the command line, so not really important. :)

Above: also atypical.

2. I am also curious: where did the nomenclature "Domain" come into play? I seem to hear it used interchangeably with "AppVM," and that feels problematic. "Domain" has a specific use in Windows-land... and I'm additionally concerned with conflation with what it means, there, here.

Yeah, I can see that. I'd prefer to just say VM.

3. What does "Run Program" mean? Is it meaningful to anyone not fluent in CLI things? It feels redundant to me, with dom0 Terminal... or, at least, that it provides little value as a thing in addition to the dom0 Terminal (which I do feel has value, where it is).

Presumably launch "something" from the Qubes menu under a particular VM.

And don't forget, there's also the alt-f3 dialog in xfce. Type firefox there and I get 28 matches on my system, including for templates. That's built into xfce, I think, so less customizable (perhaps?) than the Qubes menu.

Brendan

[ninavizz]

^ All of this is great y'all, keep it coming! Updated mockups, soon to happen... brain has designed, hands need free time to create.

[ninavizz]

Very sloppy/quick sketch... thoughts? Not to distract from above feedback, pls keep that coming, too!

[marmarta]

It's a big overwhelming for me: I'm not sure about putting status info in the menu, although perhaps this is just me being used to how things are. I'm afraid of making a huge, unwieldy beast that makes things more difficult to find and is very bug prone, like the R3.2 and before Qubes Manager.

[ninavizz]

I intentionally over-packed it with every idea I had, to see a) if folks find it to be overwhelming, and b) what folks find to be extraneous about it.

I really like Ubuntu's use of a drawer, instead of a flyout, for their secondary menu. It's much more user-friendly wrt dexterity concerns... and could help present apps in a much cleaner/larger footprint. That also opened-up some opportunity to stuff more info about the VM there, and if it's TMI—that's good to know! If it might be useful, that'd be good to know, too.

All of this is why I love inexpensive user testing with cheap-o tools like InVision. No code investment, to get clear insight from folks.

Also: please know, I am ALWAYS interested in honest feedback. If something sucks, let's get that out of the way asap. I'm fast as hell with mockups and wireframes, so that iteration can happen easily and quickly.

[mfp20]

1. I do wonder how often users seek to open/access TemplateVM things, from the app menu. Is there a purpose to them even being listed, there? Same with ServiceVMs.

Yes, there is. Despite the high number of resulting entries (ie: every app for every domain), it's the only place where it is possible to get a visual representation of (most of) all the binaries ...
That button is kind of mandatory as is ("all in there"), as we are using XFCE. XFCE used to mimic window in order to make windows users comfortable with linux. It dates back to Windows95 "Start" button and ... Van Halen's "Jump" cover (named "Start") used for the launch of Windows95 :)
You can organize the elements in a different way, but can't remove those! If you want something radically different, you must move out of XFCE. Example: i3.

2. I am also curious: where did the nomenclature "Domain" come into play? I seem to hear it used interchangeably with "AppVM," and that feels problematic. "Domain" has a specific use in Windows-land... and I'm additionally concerned with conflation with what it means, there, here.

It's Xen's nomenclature. Xen calls "domain" every virtual machine: dom0 is the administrative one, domU one of the "user" one. And I find it appropriate. "Virtual machine" is a general term, not that appropriate in case of (example) PV domains, as they are without Qemu so there's not a full machine emulation. They aren't "machines", they are more likely ... "domains".

3. What does "Run Program" mean? Is it meaningful to anyone not fluent in CLI things? It feels redundant to me, with dom0 Terminal... or, at least, that it provides little value as a thing in addition to the dom0 Terminal (which I do feel has value, where it is).

It means "execute a given binary" and it's cool as is. It is the fast version of opening window menu, type "cmd", and then do something in windows console. To make an example, you can type in there

qvm-run work firefox

to run a firefox instance in the "work" VM, without the need to keep a dom0 terminal open and it's prompt blocked waiting for the firefox process to close.

W/o a proper survey in place, I'd love to hear answers to these questions and other feedback/thoughts on today's AppMenu, by anyone who'd want to chime-in, below! :)

Here you have it. By discussing here, we are giving you random ideas and some answers. Just pack those in a file :)

[ninavizz]

A longer-term option is to make something totally custom; possibly in QT, but it'd be M&M's call. Initially, I'm just wanting to solicit from folks what's working and what's not; agnostic of implementation concerns. It's easier to iterate from that direction, as it separates "user needs" from "reality constraints."

[mfp20]

@ninavizz there's a huge amount of "totally custom" previous projects out there. Some of them are dead but the code is still available (for brave people): Emerald, Compiz, Enlightenment, WMMaker. Those were there before the Gnome (GTK) vs KDE (QT) war, but they are unlikely to be used because of their exotic libraries (EFL, step, ...). Today, developers go for GTK for performance or QT for peace of mind while developing.

I think the next usability big thing on desktop commercial computers after the "Start" button have been Apple's "Spotlight", then seen on Ubuntu Unity as well. Probably you should have a look at things like dmenu, a way to customize and integrate in XFCE. Dmenu sports "operation modes" so that can be a thin compositing-as-you-type bar or a full fledged menu to be customized in order to appear the way you like, in the spot you like. You might have a dmenu that looks like the prototype you posted up here, and a "start button" inside there with the traditional dconf menu we have now (just in case we need it), and place the dmenu button on the bar, in place of the dconf one. It's probably the easiest route (ie: less work).

edit: I'm not a fan of freedesktop.org but they were born to develop specifications common to all distributions. Earthflatters. That's why all the distros today look the same and more radical approaches have disappeared. You probably can find all the previous art (about needs/constraints) in there.

[ninavizz]

@mfp20 Thx... I'm not a developer, tho, I'm a designer and researcher. Just learning about user needs from existing Qubes users; and then M&M will decide tech stuff. Linux is famously un-usable, and I'm not keen to work towards solutions packed w/ existing Linux quirks (or art from existing distros, for that matter). Qubes needs to not alienate Linux users, but it also needs to not alienate everyone else, too.

[mfp20]

@mfp20 Thx... I'm not a developer, tho, I'm a designer and researcher. Just learning about user needs from existing Qubes users; and then M&M will decide tech stuff.

Well, the point is: if you refuse to build on top of giant's shoulders, you'll fail because of (your underestimation of involved) complexity. Beware the "make something totally custom". There's a long history of many fails and some huge success behind us. That's all.

Moreover, in order for a designer to design an UI, the designer needs to make his hands dirt once in life, on a personal project... just to sip&taste a bit what's the other side of the work. Find the time to write some code yourself about a proof-of-concept (not necessarily functional) UI. So you'll have an intimate understanding of the subject. If you use QT won't be too difficult. Once you decide to have enough, take some time to look back, account the time spent to go up there, and estimate the time needed to complete the project. You'll probably find the "packed quirks way" very attractive...
Even in the case you are part of a big enterprise entity (having enough resources to go from Windows95 to Windows10), your analysis and the resulting design rules will be much more effective once handled to a developer, just because of your "hands-on coding experience".

Linux is famously un-usable, and I'm not keen to work towards solutions packed w/ existing Linux quirks (or art from existing distros, for that matter). Qubes needs to not alienate Linux users, but it also needs to not alienate everyone else, too.

A couple years ago my friend's girlfriend came home and saw my consoles on my monitors and asked: "Oh, is your computer broken?". I literally exploded laughing, she didn't understand what was going on, my friend spent the next 10 minutes explaining the point to her (while I was cleaning my laughing spits on the monitor with alcohol).

That's wrong. I could say Linux is famously usable, as it doesn't force you to use a mouse. I like the keyboard/mouse combo, but I can get rid of one or another, whenever I need to. It's just a different idea of "usability". Some people use dwm because find more usable to patch dwm's C-code instead of search for the right form, entry the right value, and click on the right configuration buttons. A bit too radical for me, but it works; I mean, I was able to use a graphical computer interface with dwm. The main reason I dropped dwm was: I didn't have the proper code management facilities in place. The same applies as an example for people with disabilities: a friend of mine have one arm/hand partially impaired, but he is faster than me in maneuvering a spaceship in a game ... because of his pedals.
Look at PC-mouse (3 buttons) vs Apple-mouse (1 button): they are both usable, in a different way. Or, even more, look at ideograms vs letters (ex: chinese vs latin), different, both usable. Ideograms can be quite complex to write, and the ideograms alphabet is HUGE, but a single symbol can tell you very complex concepts (ex: philosophy) that would require pages of latin text to tell... on the other side latin (21-34 symbols alphabets) can be much more exact in defining the same thing. Korean language maps phonemes to simple lines&circles, then letters are composed using those basic symbols: it's alphabet is much smaller than the latin ones, but very usable still.
I can't use chinese ideograms, I've disability, and I'd be an alien in China. You consider linux not to be usable, you have your disability as well, and you're pretty alien :)
But after a bit (or a lot) of time, we both would develop new habits, feel comfortable with a different language/UI, and stop being aliens.

I've to clean my monitor once again.

[marmarek]

That's wrong. I could say Linux is famously usable, as it doesn't force you to use a mouse. I like the keyboard/mouse combo, but I can get rid of one or another, whenever I need to.

"Linux is user friendly. Its just very picky about who its friends are"

Anyway, we're certainly not about to take away ability to customize your environment however you like, with tools scripts etc how you like. There will always be an option to choose different window manager, desktop environment, different settings etc.

What we want to achieve here, is to provide easily usable default environment for all those users who are not comfortable with changing any of this. Something that doesn't require going through all the documentation to even start using it. Maybe a 5-10min intro video, but that's top. Like it or not, forcing using console is a big usability issue - in console you need to know what and how you want to do a thing, before starting doing it (reading command help, manual page etc doesn't change this - you still need that knowledge, you are simply provided some tools to gain some of it). With (properly done) GUI, you can explore possible options while doing the thing, and common actions should be prominently visible with intuitive description. And BTW GUI should also be usable with a keyboard. This way, the GUI should guide you through the thing you are doing, while you are doing it. And ideally, you don't need to learn how to fully utilize 9 other tools, before finding that right one.

Let me give you example: you're running out of space in some VM. The proper GUI should:

1. Inform you about that fact.
2. Give you possible options, like "increase VM's disk", or "show me what files are using that space, so I can decide what to remove".

In this case, with a console, you first need to learn that VM has different disks attached, then how to check their size and also that the size can be changed. And only then, how to change that size. Similar for finding what file(s) use your disk, leaving alone traps like "."-starting files being hidden by default (including ".cache", which actually may be a thing you want to remove).

---

As for custom or not-custom menu - lets have some final goal first. Then we can think about how to achieve it. Depending on that, we can evaluate what are possible options, what are similar existing projects, etc. This process will most likely also include some compromises, if a small (usability-wise) change would make the implementation significantly easier.

[ninavizz]

@mfp20 I've been doing this for 20 years. I'm quite capable of coding, and have coded. I'm terrible at it, and it makes me cry—but I've done it enough to understand it. Counter to your assertions, it's not easy for all people. Just like a lot of things aren't easy for a lot of people. I also build motorcycles and IC engines, and from that have my appreciation for the necessity of things being modular and maintainable. OS coding is far out of my league, though—and it's other peoples' jobs to do that, and to do it well. Just like it's my job to make icons, and to make them well. And, to research user needs to make products, and to do that well.

Needs-finding w/o technical constrains, has to be a first-step exercise. It's a first step, of many. Many, many steps.

Compromise always, always, always will happen... but in order to evaluate risk/reward on everything with adequate information, you have to get the human needs-finding done, and done right, first. Unfortunately, that needs to exclude technical things. Then later on, once technical constraints and opportunities are being looked at—deeply and in earnest, abreast a team's resourcing and maintenance realities—you will have an honest read on "what's nice" vs "what's nice to have" vs "what's essential," for users, to guide compromise with. Make sense?

To date, I've learned that the cognitive burden of today's App menu is simply too high. The semiotics of the lock icons are also confusing. The simple move of grouping things and reducing the total number of characters a user's brain has to parse, is so far the biggest win. A "favorites" section, seems to be the second. In addition to icons that aren't confusing.

I'd love to see the whole thing be able to interact as Ubuntu's OEM menu does, because the drawer model is far more usable for dexterity-challenged users than the Xfce flyouts. And to Marek's point above... the power-users still need to be able to customize things. Where will the middle ground be, I don't know—but I do want to get the human needs-finding figured out, first. Then the technical. Then we marry the two. Make sense?

[ghost]

@ninavizz very cool work. Is it possible to test pre-alpha version?

[ninavizz]

After reviewing all of the feedback from Bessie and Jackie in the Survey, I put together an updated design that I am calling Valentina—after Valentina Tereshkova, who became the first woman in outer space as a Soviet cosmonaut in 1963.

Valentina is based on the Cinnamon and Arc Menus as form-factor and central interaction model starting points. Both of those menus employ a 3-column layout (in design terms, not css/code terms), with a "drawer" interaction model similar to Bessie's... except the drawer is always open.

The Valentina design direction also now has its own issue, #6665, for use with tracking its implementation. Please discuss particulars with its approach, over on that issue. If folks believe there are problems with Valentina as a design direction, that discussion is great, here.

Per my initial scoping comment, I've suggested 4.2 as an RC to target for an initial deployment so that we can get the new menu into users hands asap for feedback to inform further developments.

[marmarek]

@marmarta this issue can be closed as done, right?