Create "System Health" Tray widget

[ninavizz]

Tracking as child issue within #5807

---

Problem

Two-fold: One, there are too many widgets in the tray, right now. The more there are, the more cognitive burden it is for a user each time they glance up to check something or to access a bit of functionality. Two, it was discussed in Berlin that longer-term it'd be nice to develop a broader "System Health" kind of a widget to have richer functionality than simply what is proposed, here—however what is proposed here, feels like a great starting point. It also nicely consolidates two existing widgets, to fit a more meaningful mental/value model for users.

Solution

Working solution, below.

Merge functionalities of existing Disk and Qube widgets in the Tray, into one, that keeps the read-only stuff at the bottom. Yeah, solution includes some subtle design tweeks, such as styling for category headers, some lines, and a cute/new Qube Manager icon—and the working/updated icons to replace the padlocks.

---

Cross-referencing as part of proposed EPIC #5520

[unman]

Very nice.
I suspect this will be unworkable with many qubes and bar anywhere but top: have you tested that?
In KDE, the list is rarely scrollable as it is, so (e.g) it's impossible to get to the QubeManager launcher with more than a few qubes open. Either your new Disk section will take space at top of list, so qube entries would have to be scrolled, (if that's possible), which would be a pain, or it wont appear at all, and no one will be scrolling to the bottom of the list to keep an eye on it.

[marmarta]

yeah, the scrolling problem is, I think, a huge issue here; with a dozen qubes open, the disk space will no londer be visible. I like the idea of System Health widget, but I think the domains list should be separate from it; System Health should handle things like updates, notification history (not yet implemented anywhere, but we talked a bit about it, and I think it would fit here), any errors such as low disk space and probably even clipboard?

[ninavizz]

Good to know about the scrolling stuff, had not considered. :)

So, the mental-model I kinda worked with for the pairing of the open Qubes and disk space widgets, was "Quick view to see crap burdening my system and likely to cause it to crash." All users of all machine/OS types, often need to see these stats—and the existing two widgets of disk space and open Qubes, just happened to perfectly pair that information together.

"System Heath" then may not be the best moniker for that—as I hear you taking a more holistic approach to the concept of health, whereas mine was more about "How close to crashing or death am I pushing my systems limits?"

I agree, that a notifications tray and updater stuff, could nicely/elegantly work together. Clipboard seems to be needed as a stand-alone functionality enough, that it should remain separate, tho?

[ninavizz]

Ok, the above is all very good feedback.

I'm still keen to wanting to consolidate the Domains and Disk widgets, namely to reduce the number of things visible in the Tray at all times for a user to have to consistently disambiguate.

Taking into consideration the scrolling concerns above, and making the disk widget "closed" as its default state—how would folks feel about this?

Separately: Yes, I do want to kill the little arrows indicating a flyout... namely, because more menus have flyouts, than don't have flyouts, and that pattern as a whole for the App Menu and Tray Widgets, I'd like to holistically re-consider.

[marmarta]

Hmm, it feels a bit off - disk space is, I think, much less often used part of this widget, and it feels off for it to take the space on top, which feels like more important space. (yes, I know, I'm impossible - the problem of designing this so it works with a top system toolbar and a bottom system toolbar is really hard :/ ) What do you think about it @marmarek ?

[marmarek]

Separately: Yes, I do want to kill the little arrows indicating a flyout... namely, because more menus have flyouts, than don't have flyouts, and that pattern as a whole for the App Menu and Tray Widgets, I'd like to holistically re-consider.

Not sure what would be good solution here, but IMO not having any kind of indication about submenu is a very bad idea. Without such indication (be it little arrow or something else) I wouldn't know there are some actions available if I hover over the item (and probably discover it accidentally some months later).

As for combining disk space and domains in one, I also don't think that's a good idea. Current disk usage is rarely useful, unless you are running out of it. And in that case, we already have notifications and changed icon (with a warning sign), to bring your attention. So, I'm with @marmarta here - consolidate disk space, updates and other "system health" things into one - rarely needed to look at and bringing user attention if some issue is detected (like low disk space).

[brendanhoar]

I'm probably an edge case, but I use the disk widget quite a lot to keep an eye on disk space due to layering multiple (loop device/luks encrypted) pools inside the primary pool and therefore looking keenly at staying under 80% disk usage (and with 4.1 metadata usage) at all times.

One argument against* combining would be if the act of "clicking to open the menu" (or "keeping the menu open") triggers data updates (@marmarta - or is that all async?)...if so, by combining both you're potentially stacking more API calls into each menu invocation, possibly slowing down UI interaction.

B

* possibly also avoidable by having lightweight async "background counters style" disconnected from the UI...if not already done. :)

[marmarta]

@brendanhoar depends - disk usage is not async, domains are async

[brendanhoar]

@brendanhoar depends - disk usage is not async, domains are async

Right...so combining may lead to additional UI stalls for presenting data that did not stall before...until the back-end was rewritten to be entirely async.

B

[ninavizz]

@brendanhoar Nobody knows if you're "just an edge case" unless all users are heard from. I appreciate your feedback very much!

It'd be wonderful if larger changes could be made, enabling more customization of the Tray. That'd be a massive refactoring, though—so user feedback from everyone to learn what the broader needs of folks are, is extra important.

For this... hmm. Would it work for you if when the arrow is opened or closed, the system remembers that and always shows the menu opened or closed as default whenever the cube icon is clicked-on? Would that then super slug on the performance of the proposed unified widget as a whole?

Worst case: Ok, I could just make a nicer disk icon.

[ninavizz]

@marmarta @marmarek Qubes is kind of impossible, which is much of why these design problems are fun for me to work on. Thank you both for your feedback. Short-term, I'll make a cleaner disk icon... and we'll all put our heads together on how to get a proper "System Health" thingydoo funded. :)

A big "issue" for me with the little flyout arrows right now, is that for both the domains widget and the devices widget, they're on the wrong side of the menu.

Why I question their necessity, is if a user would just hover over the item, anyway, and discover that functionality, anyway. Flyouts should be invokable on hover, not just click. But, those are things that would need to be validated in sit-down user testing... which we can't really do with this silly pandemic thing happening. Not easily, anyway.

[marmarta]

@ninavizz why on the wrong side? a cursory look through programs I have running right now shows those arrows almost everywhere and in every case on the right, too.

[ninavizz]

@marmarta The arrows should go in the direction the flyout menu goes; and when the arrows are on the right and the flyout extends to the left, it's wacky.

[marmarta]

@ninavizz , ok, I see now - my username is 'marmarta', not the default 'user', and it takes up just enough space in the top right o make all of my flyouts go right as they should. They do try to do that in all situations, but presumably with shorter usernames they don't have enough space. Still, I wouldn't like to completely get rid of them - without them, it's harder to distinguish between 'this menu option does something' and 'this menu option just shows a flyout'.

[ninavizz]

@marmarta Of course, totally agreed wrt "kill them" vs "keep them" unless a system-wide redesign for visual affordances/behaviors to remove XFCE dependence wd be possible. My lone kvetch with the arrows, is that a different solution is preferable when everything has a flyout—or, more of the things have flyouts than don't. Happy to table that for far-future chinrubbing, though, when a small army of developers are available to custom code everything. Make cars fly, etc.

Ya... instituting a rule so the menus always fly-out to the bottom-left if the Tray icon is located in the top-right of the screen, would be preferable to the dynamic behavior you describe... namely, because then text layouts & positioning of visual affordances (what the arrows are) can be standardized according to behaviors. If the tray icon to trigger a menu is in the lower-right, then a flyout menu should open to the top-left, etc. Does that make sense?

[andrewdavidwong]

how to get this theme

This is about creating the thing you're seeing. It doesn't exist yet.

[ninavizz]

I'm actually going to close this, as the generalized concept for this as a "stand alone widget" was nixed via the above (and awesomely insightful!) discussion.

@brendanhoar I'd love to chat with you synchronously sometime, about the comment you made above regarding pools. I'm working on some redesign options for the App menu, and want to provide users a way to see which Qubes are already open and the memory impacts to opening something new, in one of my directions. If you'd be up for that, ninavizz at gmail or riseup, and my GPG key (gmail only) is on my website at bigwheel dot net if that's important.

Note: Before my mention of the above begins a lengthy discussion... I'm creating multiple directions, all as visual-mockups and w/o code. I'll be sharing them, here, as a "Task" to solicit feedback on, once they're in a good place for that. FYI. :)