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]

@0rb677 TY! :) Like user-testing, you mean? I have a few grant proposals in the works to get funding to pay for user testing, yes, from both static-mockups and a clickable HTML prototype.

[ghost]

@ninavizz @marmarek is it possible to make Qubes Menu and Qubes Manager more customizable for average user? It would be really great to have more submenus when you have a lot of virtual machines (40-60+) and 100+ cli applications in each, with current menu it's really hard to administrate them. I tried bspwm but Qubes Manager is hard to customize. All Qubes frameworks written in hardcoded python and not user friendly with a few of documentation and examples. Only devs really understand how to fix some things. I think more suitable DE is Awesome WM with lua and unlimited functionality. but it takes a lot of work, especially in connection with the endless services in the background (/etc/xdg/autostart and other)

[unman]

On Sun, Apr 05, 2020 at 04:26:40AM -0700, 0rb677 wrote:

@ninavizz @marmarek is it possible to make Qubes Menu and Qubes Manager more customizable for average user? It would be really great to have more submenus when you have a lot of virtual machines (40-60+) and 100+ cli applications in each, with current menu it's really hard to administrate them. I tried bspwm but Qubes Manager is hard to customize. I think more suitable DE is Awesome WM with lua and unlimited functionality.

40-60+ qubes 100+CLI applications in each. Awesome WM with lua

"average user" I do not think that means what you think it means.

KDE provides an easily customisable Menu. Xfce Menu can be customised with very little effort.

At this level, Qube Manager probably isn't the right tool to be using.

[ghost]

@unman not sure. Custom menu editors can't create submenus in appvms (i have one large list of applications, not sorted, in each vm) (screenshot attached)

Is it possible to make something like that? AppVm -> Qubes Settings -> Add Menu -> Add Submenu (hierarchical)->add tool or cli script

[ninavizz]

@unman A longer term goal for me, is to not focus on customization but to solve for the much harder problem of simply making things more usable to more people, out of the box. Making things infinitely customizable is the FOSS/Libre software way; but it's very restrictive to who is willing to use a product. Libre Office is painful, because it has taken this approach, as a great example. Does Qubes want to restrict who can use it, to developers? That is for the core team to decide. If growth/adoption beyond hardcore developer types is sought, out-of-box usability has to be prioritized, over infinite customization.

Redesigning Qubes Manager is a high priority item for me. The better solution would be something fully custom in QT, though; as existing frameworks just don't suit something as specific and unique as Qubes. Good UX has to fit mental models, and is holistic to a complete experience. Qubes today is too piecemeal, which is by-design so the project could simply happen, in the first place. Maturing it to the next level, I'd love for it to do.

Things are made more usable for more people, out of the box, by research and design resources being funded to full-time do nothing but sketch, iterate, prototype, test; rinse, wash, repeat, and all in close collaboration with core team members of a project. Only then write code, once abundant data has been collected on what works vs what doesn't, from testing in controlled environments.

[imme-emosol]

So, to keep other desktop environments like i3 in mind.. Perhaps submenus can be used. For the default desktop of Qubes OS, some of those submenu's can be used to display a different 'App menu'. Another thing to take into account is that some people put this icon in a top bar, on the bottom, on one of the sides, or even just somewhere in the middle. The 'fly-out' therefore would ideally support. several directions; from top to bottom (v), bottom to top (^), left to right (>), right to left (<).

Nothing hovered/selected:

+------
| [Q]
+------
| Run Program...
+------
| System/dom0 || Domains || Services || Templates || Disposables
+------

Perhaps selecting dom0 should be the default, or selecting the currently active VM.

System/dom0 hovered/selected:

+------
| [Q]
+------
| Run Program...
+------
| System/dom0 || Domains || Services || Templates || Disposables
+------
| Qubes Management
| Interaction Management
| Other >> "System Tools"
+------

Domains hovered/selected:

+------
| [Q]
+------
| Run Program...
+------
| System/dom0 || Domains || Services || Templates || Disposables
+------
| my-personal-mail     >>
| my-personal-browsing >>
| my-work-mail         >>
| my-work-browsing     >>
+------

Templates hovered/selected:

+------
| [Q]
+------
| Run Program...
+------
| System/dom0 || Domains || Services || Templates || Disposables
+------
| fedora-30          >>
| fedora-31          >>
| debian-10          >>
| debian-10-minimal  >>
| my-personal-fedora >>
| my-work-fedora     >>
+------

Alphabetical order <3

[deeplow]

Hi @ninavizz .

One feature that would be really useful would be a search functionality (and I have some ideas I can discuss later to make search especially useful for qubes, which I can elaborate on later)

And to add to the conversation regarding making a custom launcher:

Whisker-menu alternative

There is also this whisker-menu alternative in xfce (that is just hidden by default), which seems like a better starting point than the default xfce applications menu.

Default Desktop Environment for Qubes

Currently it's XFCE. But QubesOS is supposedly migrating to gnome, so whatever ends up begin the final design here, should integrate well with that desktop environment.

Though I'm afraid integrating these things in gnome will be way tougher. The only way I would see that work is with something like indicator-synapse or synapse.

XFCE fits much better with any custom app menu, I think. I would advocate for it, but it seems that decision has been made long ago. (and it was decided for usability reasons)

Indicator-synapse example

Synapse example

[deeplow]

From @ninavizz 's comment on https://github.com/QubesOS/qubes-issues/issues/6007#issuecomment-719993025

Template VMs, App VMs, and Disp-VMs, would also be grouped, and their groups collapsible, so the user is not forced to see all available qubes in the app menu in a single view. Curious what others might think of that?

@ninavizz have you though about letting users do their own AppVM groupings?

I was thinking the concept of domain (work, work-gpg work-vault, etc.) even though mentioned in the glossary is not supported by any features in the interface.

So my proposal is for think about giving people the freedom to choose their own groups and thus embracing the use of domains:

• work - user defined group (which represents the work domain)
  • work-vault
  • work-gpg
• Disposable Qubes
  • whonix-dvm
  • fedora-dvm
• Template Qubes
  • fedora
  • debian
  • whonix

[marmarta]

I'm a bit scared about user-defined groups - mostly about the complexities of configuring it.

[deeplow]

I'm a bit scared about user-defined groups - mostly about the complexities of configuring it.

Fair point. A drag-and-drop approach could make this simple. Like the iPhone's dynamics for creating an app folder. But this might be a phone dynamic and not so much a desktop one.

Anyways it's just an idea which could address https://github.com/QubesOS/qubes-issues/issues/2646

[ninavizz]

Drag-and-drop works great on Apple devices; not so much, on Lenovo and other PC devices. Also, the iPhone is a touch interface; and its desktop is a very different experience from a menu. Generally with menus, drag-and-drop is a really bad idea. Any editing of a menu outside a designated "Edit this" experience, is an anti-pattern.

[100111001]

I'd like to support the idea of customizable grouping. My use case is having 8 messangers having in 8 different AppVMs. This makes the current menu quite long without any need. How about possible alternatives:

1. AppVMs with the same prefix are grouped?
2. What about having an optional group name in the AppVm settings?
3. Allow advanced users to group AppVms by qvm-prefs? 4 ...

[andrewdavidwong]

This might be an opportunity to leverage the existing (and no doubt highly underutilized) tag functionality (qvm-tags):

https://www.qubes-os.org/doc/qrexec/#qubes-rpc-administration

[ninavizz]

If a new App menu allows users to customize it, I'd rather there be a unique UI just to customize the app menu, vs requiring users jump through CLI or rpc/qvm brain hoops. All of that is very brain-hurty and not intuitive to non-technical users... and while the current userbase of Qubes is like 2/3 developers, it is an ulterior motive of my own to help shape its core UX functions to make it easier for less techy people with high security risks, to adopt.

Super curious to read about qvm-tags, though—TY for sharing, @andrewdavidwong In fact, I should read about that tonight, instead of drooling over Twitter's US election results returns drama.

[unman]

On Thu, Nov 05, 2020 at 05:18:45PM -0800, Nina Eleanor Alter wrote:

If a new App menu allows users to customize it, I'd rather there be a unique UI just to customize the app menu, vs requiring users jump through CLI or rpc/qvm brain hoops. All of that is very brain-hurty and not intuitive to non-technical users... and while the current userbase of Qubes is like 2/3 developers, it is an ulterior motive of my own to help shape its core UX functions to make it easier for less techy people with high security risks, to adopt.

Super curious to read about qvm-tags, though???TY for sharing, @andrewdavidwong In fact, I should read about that tonight, instead of drooling over Twitter's US election results returns drama.

Is that "2/3 developers" based on the results of the user survey?

[andrewdavidwong]

If a new App menu allows users to customize it, I'd rather there be a unique UI just to customize the app menu, vs requiring users jump through CLI or rpc/qvm brain hoops. All of that is very brain-hurty and not intuitive to non-technical users... and while the current userbase of Qubes is like 2/3 developers, it is an ulterior motive of my own to help shape its core UX functions to make it easier for less techy people with high security risks, to adopt.

Super curious to read about qvm-tags, though—TY for sharing, @andrewdavidwong In fact, I should read about that tonight, instead of drooling over Twitter's US election results returns drama.

Oh, I wasn't suggesting that the interface be qvm-tags, just that it might be useful to leverage that under the covers. Certainly the interface should be much less brain-hurty. There's a reason qvm-tags is probably highly underutilized! :slightly_smiling_face:

[deeplow]

Generally with menus, drag-and-drop is a really bad idea.

Ok. You're the expert here.

I also wanted to bring to your attention @ninavizz something that I've brought up before but hasn't been addressed yet and I think may be important.

It's that Qubes OS is supposedly migrating to gnome (currently blocked), so whatever ends up begin the final design here, should integrate well with that desktop environment.

The Gnome "menu" is a lot more Mac-esque and very different from any XFCE/windows7 menu. Currently your designs (which look gorgeous, btw) seem to be more for an XFCE interface. Any thoughts on this?

[ninavizz]

@deeplow Thx for the additional context and suggestions, they are always helpful and appreciated!

Not a lot right now, tbh—but I like the idea of migrating to Gnome. Mostly, because of how modular and much more well considered its UX is. That said, there are so many things in the cooker right now, as possibilities for an app menu... and user testing as well as implementation resources, will determine what gets "done" in the end.

[ninavizz]

Sooo... this is a current sketch that I'm working with, towards getting a user-testing prototype together. Prototype = done in a visual prototyping tool, so no code.

The only outstanding major thing I have yet to wireframe, is a Search feature; and @deeplow I appreciate you mentioning that, above! Thus far it seems like groupings are the most valued enhancement opportunity, with the additional option for users to create groupings that are then entirely hidden from the App Menu (implied via "Settings" screen at right), a near second.

Each grouping is sortable via A-Z or RUNNING and functionality from the Domains menu is pulled-in, too.

Thoughts?

NOTE: This prototype will also a great opportunity to test the usability of "qube" vs "VM" as nomenclature.

[marmarta]

Oh, I like it! My one comment would be that template and sysnet seem to need a label? Because it took me a while to understand what they mean :) Other than that, I really like it!

[DemiMarie]

I really like it too! The two suggestion I have would be that right-clicking on an entry could expose settings related to an entry, and that a button in the menu to toggle between “order by app” and “order by name” might be useful.

[ninavizz]

@DemiMarie By "settings" you mean what, precisely—and when you say "entry" you mean in the primary or sub-menu?

Trying to keep the menu itself as clean as possible... and also just not sure what it'll look like being sorted by apps, right now, lol. Looking forward to finding out, though!

@marmarta Yeah, I'm questioning just HOW valuable it might be for users to see sys-net on every dang VM, if they're not doing much with connectivity compartmentalization. Maybe just the Template for each VM? Moving into an interactive prototype so we can see what things look like when clicking and hovering, is my next step and will help!

[DemiMarie]

@ninavizz I was thinking that right-clicking on “App Qubes” might open a menu with options to do things like toggle sort order, filter by name, etc.

I have several dozen qubes and there is no way that they can all fit on a screen.

[ninavizz]

@DemiMarie Is there a reason you'd need all those dang qubes in the App Menu? An ongoing thought in my noggin, is that developers, especially, will have dozens of qubes just for testing stuff; and do those always need to be in the app menu, or would accessing those via the CLI suffice?

The (squint) 'lil up-arrow/down-arrow to the right of the words "APP QUBES" is to do that sort-order toggling. I'd thought with M&M to just do A-Z and Running to re-sort against those criteria, but could see Recently Used or Frequently Used added to that... unless those might work against a security model.

Also, you + @marmarta... made a widdy tweak to this, per 2 comments above feedback. Need to pivot to begin making something interactive, but wanted to see if this perhaps resonates a bit better with ya for the flyout? Incorporating UI feedback to indicate the template needs to be restarted to apply an update could be a nice improvement to add later on, too.

[DemiMarie]

@ninavizz “Recently Used” would be fantastic. Indeed, access via the CLI would suffice for many of the qubes.

[brendanhoar]

@DemiMarie Is there a reason you'd need all those dang qubes in the App Menu? An ongoing thought in my noggin, is that developers, especially, will have dozens of qubes just for testing stuff; ...

One additional reason for a lot of VMs: I make backups of the repo-delivered templates before customizing them, so that I can return them to “known fresh” state if necessary without having to rely on a working network connection or salt. With the defuault LVM they don’t take up much room.

[marmarta]

@marmarta Yeah, I'm questioning just HOW valuable it might be for users to see sys-net on every dang VM, if they're not doing much with connectivity compartmentalization. Maybe just the Template for each VM? Moving into an interactive prototype so we can see what things look like when clicking and hovering, is my next step and will help! As we could see through the survey, lots and lots of our users at least use Tor - I think being able to easily see "oh this one goes through whonix" "this one does not" is quite valuable.

[GWeck]

Great! One more idea: Not only the VM lists might get long. Some types of VMs (e.g. ubuntu, Windows) come with long lists of apps, which are grouped hierarchically if these systems are started natively. If technically possible, the app menus should contain submenus built according to these hierarchies, thus reducing the app menu lengths dramatically.

[imme-emosol]

Perhaps the launch button could also be moved to a less prominent location..? Clicking any of the apps will also start/launch the vm if it is not yet started.