search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
539 stars 48 forks source link

Redesign Qube Manager #5679

Open ninavizz opened 4 years ago

ninavizz commented 4 years ago

Problem

Qube Manager has multiple usability issues.

Solution

What user needs are and how this tool can better suit them—or, a different tool altogether—needs to be explored in user research. Then, a solution needs to be designed, iterated upon, tested with users, iterated upon further, and finally implemented. Implementation funding exists, but does not yet exist for the UX design and research work necessary to craft the best possible solution.

TL;DR, get this funded and happening. This issue will be used to track progress on the design and user research, once funding comes through (and to whatever extent possible, sketches that may be done by the community or before funding is approved) :)

Related Issues

5678, #1870 and related project

ninavizz commented 4 years ago

Question for @marmarek: What exactly are you envisioning for a Template Manager? How could it provide value for users that today's Qube Manager does not? (asking because I don't know and want to learn, not because I question the flagging of it as a need)

marmarek commented 4 years ago

Main (missing) function is easily discover and install new templates. Then, managing which VMs use what template - but this function we already have in the current "template manager".

In addition to general template discovery and install, one common use case I see for it, is to easily update to a new template version. Say, you have fedora-30 and fedora-31 came out - the tool should allow you to easily install fedora-31 (missing step) and then switch your VMs to that template (implemented).

0spinboson commented 4 years ago

Main (missing) function is easily discover and install new templates. Then, managing which VMs use what template - but this function we already have in the current "template manager".

In addition to general template discovery and install, one common use case I see for it, is to easily update to a new template version. Say, you have fedora-30 and fedora-31 came out - the tool should allow you to easily install fedora-31 (missing step) and then switch your VMs to that template (implemented).

Including custom packages that were installed by the user (or specified at the time you do this)? Or do most users not do this?

ioleo commented 4 years ago

I try to keep my Fedora templates up to date. I always upgrade my existing template VMs (not create new ones from scratch). Since I've started useing QubesOS I had gone through 3 OS version updates on all of my templates (each with a diffrent set of packages) and had no issues so far (except once, with qubes-pulse-audio, but that got quickly resolved).

I'd love (as a user) an automated tool to perform the upgrades. It's the same set of commands to run both in dom0 and target VM and if you follow the best practices you have a seperate template for each domain/security concern, which means to upgrade you need to repeat this process for several template VMs (in my case, 8).

ninavizz commented 4 years ago

@ioleo Thank you for sharing the insight! Would you be open to doing a proper user interview to inform future design work, sometime?

ninavizz commented 4 years ago

@0spinboson We "know" nothing, but I'd love to schedule an interview you to hear how you use Qubes and what your needs might be!

Clarification: All knowledge to date about how folks use Qubes, is anecdotal. That's not a dismissive against what Marek and team know of their users—they're deeply, deeply engaged in user communities, which is awesome and wonderful.

The human brain can only retain so much knowledge, however... and when the collection of knowledge can be structured, qualitative data can be much more accurately measured—and quantitative measures to clearly discern value between all the variables, is possible. Conversely, when it's all "Marek remembers these things from 5 years of community discussion" only the vocal minority stand-out in his head... and, some things can be naturally forgotten or overlooked, because—well, the brain is fun like that.

I'm hoping to get some proper user research funded this year, which will pay for "proper" collection of user insights and data. "Proper," meaning it'll be objective and reach deeper into the community of users, than simply who is comfortable piping-up in a bbs, vs who isn't.

0spinboson commented 4 years ago

I'd be happy to help. :)

ioleo commented 4 years ago

@ninavizz Sure. I'd love to help :heart:

mfp20 commented 4 years ago

Honestly I'm happy with Qubes Manager; usually my legs shake when some UI acolyte pops up talking about "usability issues", because that means the current UI made by a developer proceeeding from tech needs/limits to use cases, could be soon reworked by a WebMaster going from eyecandy to use cases while being totally unaware of the inner workings of the underlying tech. Ending up with a shiny, polished, bloated and slow interface unable to accomplish the simplest tasks and control the small details... Gnome&Ubuntu docet (and both left behind bad casualties, like WMMaker and Compiz).

That said, 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). As the list-view can become pretty long and messy, and browsing it multiple times pretty time consuming, without a tree-view or hide/show features.

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 commented 4 years ago

@mfp20 Don't worry, I'm not a webmaster and while visual design is a competency area of mine, my own bias is towards functional usability and empowering users. Qubes users trend towards highly technical security folks, and I enjoy the challenge of making something intuitive enough for my parents but that also delights CLI users.

Anything that could slow the system to support visual whiz-bang would also be a bad thing, as that kills the user's experience. You can have aesthetic polish w/o GPU or CPU strain, overuse of glowy-effects, etc. Order, not chaos, is the goal. Lightening the cognitive load, etc.

Thank you for the rad feedback, it's all inline with where my own priorities are, and with where the Qubes team's (Marek and Marta and Andrew, etc) interests are. :)

mfp20 commented 4 years ago

@ninavizz eheh, I didn't call your name, I didn't know your competency area. I'm more worried now than before :)

(just kidding, not worried at all, I just dropped my two cents; I'm actually happy someone is reworking the UI: after the functional parts are working, there's always the need to polish the resulting UI, and I had myself some thoughts about this on qubes in the past weeks)

About an intuitive/CLI compromise, i3 is already there with minimal (good) integration scripts. A bit more love for i3+dmenu+systray integration scripts and the right compromise could be here without too much effort to be spent. I've been experimenting a bit and doesn't seems too far away, as most of Qubes Manager functions can be triggered from console and the syntax is pretty coherent across all the qubes tools. I'm new to qubes and pretty far from owning it; having a pretty good default UI, moves the i3 wish down my TODO list. I hope I'll be able to contribute back something ASAP...

Having some i3+dmenu VM management scripts makes Qubes Manager less important. And i3 is way lighter in RAM than XFCE. From my perspective, this makes i3 an obvious choice for a RAM-huge system like Qubes OS tend to be.

ninavizz commented 4 years ago

@ioleo ...a friend just shared this, and I thought of your comment. Not sure if you're in the US or not—if you are, and ever on social media, then hopefully you'll get the humor.

image

ioleo commented 4 years ago

@ninavizz Unfortunately I am neither and I don't get the reference :(

3o14r473 commented 4 years ago

About an intuitive/CLI compromise, i3 is already there with minimal (good) integration scripts. A bit more love for i3+dmenu+systray integration scripts and the right compromise could be here without too much effort to be spent. I've been experimenting a bit and doesn't seems too far away, as most of Qubes Manager functions can be triggered from console and the syntax is pretty coherent across all the qubes tools. I'm new to qubes and pretty far from owning it; having a pretty good default UI, moves the i3 wish down my TODO list. I hope I'll be able to contribute back something ASAP...

Having some i3+dmenu VM management scripts makes Qubes Manager less important. And i3 is way lighter in RAM than XFCE. From my perspective, this makes i3 an obvious choice for a RAM-huge system like Qubes OS tend to be.

@mfp20 Sounds like you are looking for something like qmenu.

So far, I think that the propositions made by ninavizz are really great and, in my opinion, there is a lot that can be improved regarding Qube Manager and application menu UX. I would argue that the murophobic crowd can not be satisfied by Qube Manager without the risk of it becoming a design mess, trying to cater to every user while users like me are annoyed because something takes a ms too long. I hope that in the future, qmenu-vm can become a satisfying alternative for these users while Qube Manager can be steadily improved to fulfill its purpose. (Eye candy would still be a terrible sin of course.)

mfp20 commented 4 years ago

About an intuitive/CLI compromise, i3 is already there with minimal (good) integration scripts. A bit more love for i3+dmenu+systray integration

@mfp20 Sounds like you are looking for something like qmenu.

Yep, that's the love I was looking for! Thank you dude!

So far, I think that the propositions made by ninavizz are really great and, in my opinion, there is a lot that can be improved regarding Qube Manager and application menu UX. I would argue that the murophobic crowd can not be satisfied by Qube Manager without the risk of it becoming a design mess, trying to cater to every user while users like me are annoyed because something takes a ms too long. I hope that in the future, qmenu-vm can become a satisfying alternative for these users while Qube Manager can be steadily improved to fulfill its purpose. (Eye candy would still be a terrible sin of course.)

Agreed. I disagree about the "eyecandy sin": I'd like to see Compiz's cube back, Qubes Manager permanently glued on the start face of the cube, and qmenu on the shortcut when that face is in light. The other faces customizable like workspaces. I tried to resurrect compiz a few months ago and kind-of worked but ... it was like soldering a floppy disk cable to an Arduino in order to have an USB 3.5 floppy disk drive.

P.s.: I love my mice. But I prefer to pet my mice in games only :)

imme-emosol commented 4 years ago

The main thing that bugs me with the current manager is that I keep on resizing the columns so they fit my names.., I prefix them so I can order them by group.., or by used network.

And a very minor nuisance, is that visually I don't enjoy the 'state' icon being left-aligned instead of centered.

deeplow commented 4 years ago

Just posting here something @bnvk did a good while ago @ninavizz. I'm not sure I dig the design, but since another designer did something around it, it might be worth mentioning. Took it from here. The repo also includes other ideas for the qube manager.

ninavizz commented 4 years ago

Thank you @deeplow! Kinda going to start from scratch by learning more about user needs and problems, before digging in too much.

donob4n commented 3 years ago

Hi, (Not sure if discuss here or start another issue)

I would like to add more functionally to Qube Manager directly handled from the main window, I will put some ideas here like a brain storm before doing anything:

On the other hand it will nice to add some kind of 'Tree View' which will group the the VM's in Templates, Network, System, AppVM's...

Maybe would be nice to define the labels in some levels of trusting instead simple color names. (E.G. black -> Vault, green -> Trusted , red -> Untrusted...) and you could just change it drag&dropping some VM from one group to other.

ninavizz commented 3 years ago

Those are great suggestions @donob4n TY for sharing here! Will totes keep in mind. Yeah, "Template Manager" as a different thing from "Qube Manager" makes little sense to me. If it's a template, it should have the options for managing templates; if it's an app qube, it should have options for an app qube.

donob4n commented 3 years ago

Well I see it as a workaround for changing multiple templates at once when there was no easy alternative.

I will start working on it.

marmarek commented 3 years ago

Change VM names with double click on 'Name' cell (it will show a confirmation dialog for avoid errors)

I would rather avoid it. Changing a VM name is a heavy operation with many side effects (changes to menu, VM disks, references in other VMs), some things may even be lost on rename (for example currently qrexec policy - https://github.com/QubesOS/qubes-issues/issues/5147). There are also non-trival rules when VM can be renamed - for example it cannot be running, but also for TemplateVM, none of VMs based on it can be running. So, I'd rather discourage from renaming, than making it simpler.

As said: #6169 (comment) Directly backup single or multiple VM's using context menu

There is one important details about the current backup format: regardless of what VM you choose to include, the backup archive always contains metadata of all the VMs. Having a "backup this single VM" option may suggest otherwise and lead to unwanted information leak - as it may suggest it is the right way to share a VM with another person. It is not. Details: https://github.com/QubesOS/qubes-issues/issues/1747#issuecomment-226048972

If previous works fine, totally remove current Template Manager

In the current form of "Template Manager" - yes, I agree, it very much makes sense to integrate this functionality into Qubes Manager.

There is also upcoming "Template Manager" that does more like its name suggests: manage (install, remove, update etc) templates. It's here: https://github.com/QubesOS/qubes-manager/pull/258

Otherwise, those are great ideas, and I'm really grateful about your contributions to the Qubes Manager!

andrewdavidwong commented 3 years ago

Change VM names with double click on 'Name' cell (it will show a confirmation dialog for avoid errors)

I would rather avoid it. Changing a VM name is a heavy operation with many side effects (changes to menu, VM disks, references in other VMs), some things may even be lost on rename (for example currently qrexec policy - #5147). There are also non-trival rules when VM can be renamed - for example it cannot be running, but also for TemplateVM, none of VMs based on it can be running. So, I'd rather discourage from renaming, than making it simpler.

I agree that double-clicking on a qube's name should not prompt to rename. It would be more intuitive if double-clicking on a qube's name started that qube or brought up the Qube Settings window for that qube. (It currently does nothing.)

However, I'm not sure I agree about discouraging renaming. There are many situations where I find that I must rename a qube, and there is no other good option. For example, If I need to re-recreate a qube and keep the same name, I have to rename either the old qube or the new one. However, in such situations, the fact that RPC policies and launcher shortcuts don't change when I don't touch them is actually a feature for me. It's more convenient, because it allows me to re-create a qube, reuse the name, and not have to mess with the RPC policies or launchers.

If previous works fine, totally remove current Template Manager

In the current form of "Template Manager" - yes, I agree, it very much makes sense to integrate this functionality into Qubes Manager.

Agreed!

marmarek commented 3 years ago

Yes, there are cases when rename is useful, sure. I'm not proposing removing this feature. I'm proposing keeping it where it is (VM settings), and not adding it to the main window.

donob4n commented 3 years ago

Change VM names with double click on 'Name' cell (it will show a confirmation dialog for avoid errors) I would rather avoid it. Changing a VM name is a heavy operation with many side effects (changes to menu, VM disks, >

Ok. @andrewdavidwong idea seems better, start or open settings dialog.

As said: #6169 (comment) Directly backup single or multiple VM's using context menu There is one important details about the current backup format: regardless of what VM you choose to include, the backup archive always contains metadata of all the VMs. Having a "backup this single VM" option may suggest otherwise and lead to unwanted information leak - as it may suggest it is the right way to share a VM with another person. It is not. Details: #1747 (comment)

Well, this could happen with standard way too (I had no idea about it). Maybe we should warn in some backup dialog.

Otherwise, those are great ideas, and I'm really grateful about your contributions to the Qubes Manager!

Thanks, I'm glad to help.

andrewdavidwong commented 3 years ago

Well, this could happen with standard way too (I had no idea about it). Maybe we should warn in some backup dialog.

I wouldn't want to end up a hundred obscure warnings all over Qubes that only a fraction of users will understand. Perhaps just a general warning to keep your backup passphrase secret (which precludes using backups to share qubes, along with a bunch of other things).

fepitre commented 3 years ago

Is redesign also means possible switch from Qt to Gtk? :innocent:

donob4n commented 3 years ago

Uff do you think it would suppose some important advantages? Ask @WillyPillow , he started the new 'Template Manager' with gtk and rewrote to qt :crying_cat_face: .

fepitre commented 3 years ago

Uff do you think it would suppose some important advantages? Ask @WillyPillow , he started the new 'Template Manager' with gtk and rewrote to qt :crying_cat_face: .

Well..less Qt because Qt!? Ok this is not an argument just less libraries just for Qt stuff for Manager :)

ninavizz commented 3 years ago

I'd LOVE to see QubesManager redesigned, but it's also important to do design iterations via wireframes, critique iterations, do user testing, and to consider ways to make things intuitive w/ best practices abreast factoring-in necessary impact checks (such as how to archive or rename a qube).

I also feel that what is currently done in "QubesManager" should be part of a broader settings/management experience/framework that would include a policies GUI, a way to make mass template updates, etc.

Changing libraries/codebases entirely at this point, doesn't feel prudent—unless a design direction merited it. I'm not a huge fan of GTK, but if its library could meet the needs of what's considered a solid design direction for Qubes Manager, than awesome!

I'm currently working on an AppMenu redesign, and somehow unifying more of the Qubes OS unique UI elements also seems like it'd be a good idea. The Devices and Whonix widgets (the latter, I realize was done by a Whonix contributor and is technically their code not Qubes') as well as the Updater widget, seem like the other primary Qubes UI touchpoints. Am I missing anything?

Mebbe instead of beginning this with code, post/share wireframes and mockups of what such an experience could resemble, and also to expose interactions that need a lot of love? Maybe schedule calls to do critiques, too?

donob4n commented 3 years ago

Well I think that the biggest problem of Qube Manager is handling a very big group of AppVM's, Templates, etc... Even having search, show running/halted/etc filter... it looks very messy.

When I talked about the 'Tree View' I was imagining something like this: (It's also pyqt hehe)

The (Playlist/ My Computer / Devices) could be used in the future for remote Qubes handling (https://www.qubes-os.org/news/2018/01/22/qubes-air/) and inside each entry you could have AppVMs/Templates/Network...

andrewdavidwong commented 3 years ago

Well I think that the biggest problem of Qube Manager is handling a very big group of AppVM's, Templates, etc... Even having search, show running/halted/etc filter... it looks very messy.

Related: #2646

ninavizz commented 3 years ago

Ok, the need to "manage custom groups of VMs" arose from my explorations with the App Menu, and then the below happened. Adding to this thread for feedback.

It's not a "redesign" of Qubes Manager, in that it doesn't fundamentally challenge the list-view/segmentation of information or functionality. Intent was only to make it much easier to visually parse what's "going on" and to surface information and functionality to both be more easily discoverable and acted upon.

The broader UI framework of "Q Manager" I created #6483 to address.

Qubes Manager 2021

Qubes Manager 2021 - menus

ninavizz commented 3 years ago

^^ Note: the above is a first-iteration by me. Not intended to include/demonstrate "everything." Wd love ideas, requests, critique, etc. Wanting to fold it into some App Menu user testing, in a light capacity.

DemiMarie commented 3 years ago

Ok, the need to "manage custom groups of VMs" arose from my explorations with the App Menu, and then the below happened. Adding to this thread for feedback.

It's not a "redesign" of Qubes Manager, in that it doesn't fundamentally challenge the list-view/segmentation of information or functionality. Intent was only to make it much easier to visually parse what's "going on" and to surface information and functionality to both be more easily discoverable and acted upon.

The broader UI framework of "Q Manager" I created #6483 to address.

Qubes Manager 2021

Qubes Manager 2021 - menus

Beautiful!!! Looks very usable, too.

Two suggestions:

ninavizz commented 3 years ago

@DemiMarie Thanks!! :)

One of the primary drivers, was to use a table-y format optimised for human brains viewing and processing this specific content in the context of QubesOS specifically; vs any 'ol generic table. Not everything needs or should get it's own column, and what's most important for a user to see with a Template VM is usually not what's most important to see for an App VM.

All of these ideas are young, anyway, and you're the first person to give me any feedback on the Qube Manager (other than Marek and Marta both going "Ooh, lovely!" and then the topic changed, lol). :) Hoping to learn A LOT more from App Menu testing.

A "bigger" redesign of Qube Manager does feel like it should happen at some point. All of this, is to just apply classical design wisdom to present the same information/functionality in a more consumable table.

DemiMarie commented 3 years ago

@DemiMarie Thanks!! :)

You’re welcome!

  • "Whether or not it's included in backups" and "When the last time it was backed-up is" are both shown together in the second-to-last column for both app and template/service qubes. 17 Feb is when the last backup was run on this person's computer.

I meant in show/sort :smile:

  • For the Templates group, the second column from the left shows when a template was last updated. The Fedora 31 Template had an error when last trying to update, and Debian 10 has an available update to download.
  • "Group VMs to one or any types" Ugh. Yeah, I agree with you, completely. Only "problem" is with the App Menu; how often do folks care to open things from a Template, within the app menu? Almost never; Settings for that Template or its Terminal, potentially notwithstanding.

What if we had multiple types of rows within a group?

One of the primary drivers, was to use a table-y format optimised for human brains viewing and processing this specific content in the context of QubesOS specifically; vs any 'ol generic table. Not everything needs or should get it's own column, and what's most important for a user to see with a Template VM is usually not what's most important to see for an App VM.

That is absolutely true.

All of these ideas are young, anyway, and you're the first person to give me any feedback on the Qube Manager (other than Marek and Marta both going "Ooh, lovely!" and then the topic changed, lol). :) Hoping to learn A LOT more from App Menu testing.

I would love to see a better Qube Manager. Right now I mostly just use the command line for everything because I can use it more efficiently. Something efficient enough to make me switch would be awesome.

A "bigger" redesign of Qube Manager does feel like it should happen at some point. All of this, is to just apply classical design wisdom to present the same information/functionality in a more consumable table.

Agreed. Also, we really need to improve the startup time. A lot. That’s not your job, though.

marmarek commented 3 years ago

Also, we really need to improve the startup time. A lot.

For any claims related to larger changes (not backportable), please use development version as a reference point. I'm not saying qubes manger is lightning fast in Qubes 4.1, but its startup time is way better.

ghost commented 3 years ago

Why limit the groups to VMs of only one type? Personally my qubes workflow has groups of VMs of different types template/appvm/disposable that all fit into one group/workflow.

What is the --none-- next to what appears to be the netvm column?

Where are the table headers? As a user I normally attempt to use the headers to dictate sorting order

Should hidden be collapsed by default? Is "Hidden" a custom group, or are you pulling from the internal qvm-feature?

Shouldn't the icons be aligned vertically? (a simple yes would do, you don't need to painstakingly align them in your mock-up software)

What are the icons preceding the template and netvm columns? Are those links to scroll to the VM?

Where is the button launching the per-VM settings (qubes-vm-settings)? Some settings such as assigning devices/firewall config/ect are just there.

Will columns/sorting be consistent across all groups? I'm not sure which I would prefer honestly, there is some value in having them all consistent (less fumbling). But as you stated before the use case of each type of Qube is different, and a different set of volumes might be valuable.

ninavizz commented 3 years ago

@ctrlaltf24 The design is not intended to reflect traditional tables in web/software. Traditional tables are great for flowing batches of any kind of data into, and for coding databases. They're optimised to engineering needs. This table is a jab at optimising the presentation for human needs. As such, different interaction patterns are employed to facilitate sorting and view options, so the page can be more visually scannable for quicker comprehension. Per that, granular per-vm controls are available on right-click. The visual mess they create would need a lot of validation in user testing as necessary, to justify, in my mind.

"Why limit the groups to one type of VM" was not exactly intentional, but more a reflection of the concept of grouping having coming from a different project (the app menu). I'm hearing from you and others, that such an assumption is not inline with user interests. Noted! :)

ninavizz commented 3 years ago

@ctrlaltf24

What is the --none-- next to what appears to be the netvm column?

There's a setting in each app VM's Settings, to allow net access; yet in each Template, there's a default NetVM designated to the template. That's an attempt to somehow show that relationship, without hogging the horizontal space needed by two columns that could each fit the max-allowable-characters name for VMs.

As with the backups stuff ("Is this included in backups; if yes, then when was the last?") those two pieces of information felt best paired together—but obvs the pairing needs to read more intuitively. Why lots of iterations are always necessary, and lots of feedback, too. :)

imme-emosol commented 3 years ago

"Why limit the groups to one type of VM" was not exactly intentional, but more a reflection of the concept of grouping having coming from a different project (the app menu). I'm hearing from you and others, that such an assumption is not inline with user interests. Noted! :)

The "Create New Group" window seems to suggest otherwise with the question: "For which type of qubes" ?

ninavizz commented 3 years ago

@imme-emosol Yes, it was my intention at the outset; but it was not a researched or well-thought-out component of the broader idea. Hence, sharing an early sketch to solicit ideas—and now quickly pivoting to exploring how users may desire to group VMs, in our forthcoming round of user testing. :)

Sorry, async solicitation of feedback among a community of folks I'm not well acquainted with, is still a new thing for me. Y'all have been very patient entertaining my newness to how developers communicate as versions of work are shared, as I am here working among y'all. :)

ninavizz commented 3 years ago

Coming back to this Issue (which is about Qubes Manager, not Groups—which is #6679): What is the order of effort that would be required to redesign the layout of information to better align with the design principles reflected in this proposal?

Qubes Manager 2021

9ao9ai9ar commented 6 months ago

Coming back to this Issue (which is about Qubes Manager, not Groups—which is #6679): What is the order of effort that would be required to redesign the layout of information to better align with the design principles reflected in this proposal?

* Abandon traditional table format (topical columns each showing a single point of data and are sortable with header clicks) that uses a visual table that is not a literal, development-coded table.

* Does show/hide and sorting of information with menus (detailed menus shown in screens above)

* Removes most controller icons (outside from right-click menus)

* Visually demonstrates status with typography weight/color (and possibly a subtle animation, tbd)

Qubes Manager 2021

The table must include a header to not confuse users of what each column represents. For example, looking at the first row of the table, what is 145.7MB? RAM usage? Allotted disk space? Used disk space? I don't want to spend even 1 second guessing what the values mean.

Why are some app qubes in bold? I know after using Qubes OS for a few weeks that app qubes in bold are currently running, but that is just bad UX in my opinion, and I haven't seen ones in red yet, so I don't even know what's up with the AppVM (or is app qube its new name now?) Reactors-0411.

Similarly, Yes - 17 Feb 2021 is being unnecessarily vague. I know you want to keep things as concise as possible, but a simple "Last backed up on 17 Feb 2021" is a lot clearer than what you have in that last image.

A note on style, the SI prescribes inserting a space between a number and a unit of measurement, so even though storage size has no SI units AFAIK, having a space separating the number and the unit makes more sense and looks more pleasing to me. Also, capitalize "Q"ubes to be consistent with the casing of the other tabs?

Lastly, I am not a savvy technician by any means, but in my mental model, the common important system resources, allotted CPU, RAM and disk space, should be displayed adjacent to each other in the table. If it gets too cramped, maybe place them under each qube in an expandable row, with a disk usage in percentage as a summary at the top?

These are my suggestions. Take them or leave them.