Support for user-created groups of VMs

[ninavizz]

The problem you're addressing (if any) Users from #6573 overwhelmingly supported and asked for the ideas of user-created groups for both VMs and Apps. This Issue is to focus on the development of that capability on the backend and in the GUI, for just VMs.

Describe the solution you'd like The Bessie prototype suggests what an already created group of qubes might look like in the App Menu. The interaction and visual design for how users might create those groups, feels like the strongest outstanding challenge. I've looked into doing this, lightly, in Qube Manager. Not sure if that's the right place, though.

EDIT: This issue is not for discussion around more conceptual needs for which qube grouping might be a solution, or more advanced features grouping could serve w/in a new appmenu. Those discussions obviously should happen though, should contributors feel compelled—just, in the forums, not on this specific issue. This specific issue is only to address:

1. Facilitate intuitive user creation and curation of "Grouped" VMs
2. Display those groupings in the app menu, and consider where else they might be valuable—as a secondary point of value.

Where is the value to a user, and who might that user be? Can pull quotes into here from survey. TL;DR "Make sense of the chaos of too many VMs, rather than just have fewer VMs"

Describe alternatives you've considered Looong, scrolling lists. :)

Additional context The "solution" to the need surfaced in #5677, is #6665

[andrewdavidwong]

Arguably a duplicate of #2646. However, by current standards, #2646 is arguably over-broad and under-defined, so I'm closing #2646 in favor of this and other more specific issues that address the topic.

[andrewdavidwong]

Bear in mind that VM groups will probably have to be supported in multiple places to be fully functional:

• Core internals (possibly piggybacking on VM tags?)
• Qube Manager and widgets
• App menu

[ninavizz]

@andrewdavidwong Yup! I also feel all of what little you just said up above, merits why more user research should be done to learn more about what exactly users want/need from groups—for apps, for VMs, for allthethings. It just came up a lot in the free-text part of the surveys... and "surveys" measure sentiment on the 50/50 bet people see the same things in a video that I do. I feel more affirmation is needed via interviews, to have more concrete hypothesis.

[deeplow]

As I understand it this is closely related to the (confusing) concept of domain (in the qubes-sense -- not like dom0). It's mostly conceptual as nothing in the UI addresses this yet!

For example your work domain can include three qubes:

• work-documents
• work-email
• work-gpg (to safely store the email encryption key)

It would be extremely nice to shut down a group of qubes (or domain) at the same time :)

[unman]

I really don't want to be that person, but could you explain what this means over and above what can already be done both in Xfce and (easily) KDE menus. When I read "backend and in the GUI" for something that is already available, I start to worry. Both here and in #6680 the driving force initially seemed be on the Menu , although (as Andrew pointed out, And Nina agreed) there are other areas that may be affected. At the moment this seems to be as nebulous as the issue that was closed. Is there any point in opening issues like this when they are completely dependent on more user research?

[ninavizz]

@unman Yes. One, I would like things that need User Research and Design to be able to exist in GH as "open tasks." I would love for other designers and researchers to be able to contribute—not just me—but if a developer does want to build something and it's been put on the radar as "Hey, this need user research and design to do well," that feels like it also needs to be made visible, too. If someone really wants to jump in and develop a thing really needing design and research, if they let me or another designer know, I'll also hasten how I prioritize that design and research.

Is the problem you're seeing with these issues, that they impede upon developers finding a thing that is easily actionable for them to contribute to? IF so, would an "In Discussion" or some other such label, help distinguish that?

If the backend functionality does exist to easily support a future GUI grouping of qubes (not apps) within an app menu, today—great! Share what it is, here. If KDE and XFCE do groupings with hacks that may conflict with how @marmarta is building the custom AppMenu for Qubes, that should be surfaced, too, so we know about it.

2646 is more broad than this issue, hence it's closure. This issue is for a specific solution that users expressed a strong desire for, after seeing it demonstrated in a prototype (Bessie) for the App Menu. That interest was captured in the user survey—both in response to a structured-data question, and in open text fields.

As the design brief* highlighted, the primary "Problem" the App Menu seeks to address, is creating one (of hopefully at least a few) GUI tool for a multi-environment system. All existing Linux tooling, exists to support single-environment systems. While it's obviously possible to bend those to work for Qubes, that does not create an intuitive environment for users. Which is ok for security diehards and developers to get past—but everyday users with a high vulnerability who still need Qubes, not so much. So there does need to be a sorting of "What can XFCE or KDE do hackish-ly vs what is an easy way to make it intuitive for all users."

Second, because of the user research and surveys and community asks to participate in all of the above, I want to provide some visibility into the results of what we learn—and the prioritization of those things being made actionable. The GH project I created for the app menu, does much of that. Next week or the following week, I'll be publishing a blog post with the findings from the survey. I want all of this stuff here on GH together, when that gets published, so I can link to it all and maybe community peeps pick-up some features Marta is not going to prioritize for a while.

About half of it is cards that are not yet issues. Things that garnered a high-enthusiasm response on the surveys, though (+800 responses), I want to have open as "Issues" for ppl to go off and build themselves, if they really want that thing created. That will save me and others on the team, email and forum activity with people responding "I know you're doing things like this, but hear me out, they need to be done like that."

@deeplow's suggestion feels very tangential to the core problem the groupings seek to address—which is the user need to help make order from what can today be chaos, in the context of deciding what to open from the app menu. I don't like the idea of projects establishing solutions, without first establishing a central problem that users actually have—that cleanly maps to whatever solution is implemented. Not a problem that only a few users may have, or a theoretical problem that maps to a behavior users are not yet demonstrating at-scale.

---

*If GDocs are not possible to be viewed, I also created a redundant version of the Design Brief's contents in an Etherpad on Riseup: https://pad.riseup.net/p/2YyPPXqakSYIQMjc6jC8-keep

[andrewdavidwong]

Is there any point in opening issues like this when they are completely dependent on more user research?

Is the problem you're seeing with these issues, that they impede upon developers finding a thing that is easily actionable for them to contribute to? IF so, would an "In Discussion" or some other such label, help distinguish that?

People open questionable feature requests all the time. We only immediately close the ones we're presently sure are a won't do.

We leave the others open for a variety of reasons. One reason might be that all the experts qualified to evaluate the proposal are too busy to read it. Another is that it might be a slight net gain if it were implemented, but no one on the core team ever expects to have time to do it, in which case we usually slap a help wanted label on it.

Any issue that has T: enhancement, P: default (or lower), and is on the TBD milestone should be considered essentially "unevaluated." It needs to be triaged and assigned a more specific release (and possibly a different priority) before being worked on. Adding an "in discussion" label would be redundant. Unevaluated enhancements should be understood to be in that state by default.

Also, "in discussion" would fuel the misconception that this is a discussion forum, and I certainly don't want that. Any issue created "for discussion" should immediately be closed as invalid, as it's simply in the wrong place.

As for contributors finding an issue that's "easily actionable," that's what the good first issue label is for, but it can be hard to keep that label up to date, since it usually requires an experienced core developer to decide which issues should have that label, and experienced core developers have no time.

For more experienced contributors who are beyond the "first issue" stage, reading and understanding all the labels and milestones should allow them to sort through the issue tracker productively, and we're always open to further methodological improvements (that we can feasibly implement and maintain).

[ninavizz]

One final point to additionally clarify, @unman @deeplow — I did just more clearly frame this issue as a child issue within #6665.

Instead of having Marta build a feature-robust menu, she's building the most minimally-viable thing she can—because the form-factor itself and grouping of qubes "by type" are tough/big enough problems to get right in implementation, as it is. The grant funding this work also was only scoped to find an initial/minimalist implementation, yet the design and research were conducted against the question "What do users really want/need?" (which is a much more robust solution than any team could reasonably deliver in an initial iteration).