-
-
Couldn't load subscription status.
- Fork 53
Description
The problem you're addressing (if any)
First, I want to thank you for this great effort. The new app menu is a huge improvement. My favorite thing about it is that it hides / filters qubes from users based on whether you want to see App / Templates / Services qubes.
Hiding irrelevant qube menus is probably the best features because it reduces the mental tax on a person having to see things that they currently are not interested in. It is good design.
problem to solve I think the filtering / hiding can be taken one step further. Many users have a lot of qubes that are used in different contexts. For example, I have several qubes for different "identities" like my personal life, work at Company1, Company2, etc. Each one has a vault for sensitive files for each one along with a general net-connected qube along with some other utility qubes. This is just my setup many other people have different setups. Such as simple a Personal set of qubes along with a Work set of qubes
Improving the filtering will enable all these qubes to be managed better.
The solution you'd like
The solution to this context problem is making the menu filterable on a tag. Each qube can be assigned one or more tags. By default All qubes are shown in the menu. However, a person could select the tag filter to only show "Work" tagged qubes. This would filter out all the various App / Template / Service Qubes by that tag. Each qube can have more than one tag, so for example networking may have all the tags if designed. Upon re-opening the menu it would remember the last filter setting.
The design of it could simply be a like this
--------------------------------------------------------------
| [[Drop Down Tag Filter Header]] |
--------------------------------------------------------------
| Apps | Templates | Services |
--------------------------------------------------------------
Currently you already have the Apps / Templates / Services filters on the menu. This would place a box above each those three filters ("Drop Down Tag Filter Header ") which when clicked would just be a drop-down box where a tag could be selected. When a tag was selected it would alter the visible Apps / Templates / Services.
addendum: in addition to user-defined "tags" the same box could include special tags. Probably the more useful or perhaps only useful tag would be "State: Currently Running". This way ONLY running qubes are visible in the menu. 90% of time (all cases except starting a qube) that is what a user wants, so it would be a useful tag. If you don't want such a "Filter" in the "Tag" box or even if you reject the Tag filter it might be useful to enable Filter by currently running state.
This could even be expanded later to a more comprehensive filtering UI like many menu search boxes have:
--------------------------------------------------------------
| [[Search Box]] | [[Tag Filter]] |
--------------------------------------------------------------
| Apps | Templates | Services |
--------------------------------------------------------------
This design would create two new filters compared to the current one. "[[Tag Filter]" is the same tag filter drop down box as described in the last section. However, the "search box" would enable filtering the menu display based on the search keywords. So, basically it would filter the menus by both the search text + tag.
Tags would be defined in the normal Qubes Manager. It doesn't need to be anything complex. Simply a "Tags" field that is comma separated list of tags. I imagine stored in the Qubes preference database
The value to a user, and who that user might be
Filtering out content not useful to the current context is very important to reduce mental load. This filtering mechanism based on tags will allow a flexible way for users to define their own Qubes filtering contexts that make sense for their own use-case. A typical and simple one would be assigning "Work / Personal" tags to qubes and therefore when they are in Work-mode not have to see Personal related qubes in the App Menu. This reduces mental burden, reduces mistakes, etc.
Unrelated to this, but if Qubes are assigned tags it also enables more powerful QrExec policies. Just as an example, denying Copy / Pasting between qubes of certain tags ("Personal" tagged qubes cannot paste into "Work" qubes, etc). Not related at the app menu but I just thought I would add that having qubes be taggable could be useful meta-information for other future qubes ideas.