Update "Updater" Iconography

[ninavizz]

Problem

A simpler family of icons needs to exist, so that between the Tray, the Open Domains menu, and the Qube Manager, updater things can be more clearly communicated to and acted upon by users.

Solution

Working solution, open to further exploration

• Numeral between arrows would be dynamic, based on the number of updates to be done. Footprint of widget would need to be flexible in width to accommodate double or single digits.
  • A simpler version of this could be implemented without this dynamic behavior, of course.
• Same solution, to carry over into Qube Manager... but w/o icons breaking. :D

---

Cross-referencing as part of proposed EPIC #5520

[marmarek]

We use similar icon for "restart vm to apply changes made in the template" already. Which BTW I think you confused here - those vms are not templates. so they don't have updates to be applied - only templates (and standalone vms) do.

Also, we don't really keep information "how many updates are there", only "which templates needs to be updated" (aggregated into "Updates available for X qubes" in the widget). Do you think number of updates to be applied in a single template is something meaningful for the user?

[unman]

Do you think number of updates to be applied in a single template is something meaningful for the user

It isn't. It's the type of update that's important and you cant parse that.

[marmarek]

Actually, you can. At least repository metadata in Fedora contains this information. You can extract it for example with:

dnf list updates --bugfix
dnf list updates --enhancement
dnf list updates --newpackage
dnf list updates --security

There are probably more ways to do that too. In Debian, it isn't that elaborate, there is just urgency field in the changelog, but not sure if apt-get has access to it, or even if it's reflected in the repository metadata in any way.

In any case, we currently don't extract this information, so adding it would be more work than just changing the icon.

[marmarta]

As @marmarek said - currently a similar icon is used for "needs restarting". I wonder if this won't be confusing to the user (or how should we change the 'needs restarting icon' to communicate consistently with this). I love how the widget icon looks like!

[ninavizz]

Aaaaah.... see, I did not know that's what the existing icon meant. I'd thought it meant that things need to be downloaded, installed, and then the thing restarted.

WRT the shown numeral as a signifier of something... what matters to the user, is "How long will all of this take, what things need to shut-down, and when can I get back to doing my business?"

If the current integer that is tracked is the number of templates in need of updating, that works plenty well! Thank you for the helpful clarification, @marmarek.

Ok, I need to go and re-think all of this, now that I think I understand it all better. More, later! :)

[ninavizz]

While we're on the clarification-train @marmarta... what do the grayed-out icons mean, next to my disp-VMs?

[marmarek]

Normally it means the template it is based on is running and you'll need to restart the VM after the template is powered off. And indeed sd-svs-disp is running. But in case of DispVM "you need to restart" is somehow less useful...

[marmarta]

@marmarek , do they make sense for persistent/named dispvms? should I make a new ticket to remove them in all dispvm cases?

[marmarek]

@marmarek , do they make sense for persistent/named dispvms? should I make a new ticket to remove them in all dispvm cases?

Yes, they do make sense for named dispvms.

[marmarta]

@ninavizz , I think the best answer to your question is: they should not be there at all and won't be in the future releases

[ninavizz]

@marmarta My brain was just starting to meander in that direction. :)

So, is the consenssus then, that Qube Manager should just not show any restart-y/updater-y type icons? If "no," then what signifiers/actions would bring value to users in the existing Qube Manager design? Not in the scope of this question, of course, wd be all the awesome ways in which a dreamworld's Qube Manager could function. Just working within today's framework.

[marmarta]

okay, so, I've had a look in the code, realized what I forgotten about it, and here's the current state: Qube Manager needs two icons of this sort for two situations:

• this qube needs restarting to reflect the changes that occurred in its template (currently: green arrows)
• this qube will need restarting soon, because its template is running, so when the template is shut down, the icon will turn green (currently the grey icon)

The discussion above occurred because we shouldn't be showing either of those for DispVMs - but for other VMs they are still needed. I'm not that sure the grey icon adds that much, but I may overlook why this is an important information.

[ninavizz]

The second bullet feels very confusing. Like, really confusing.

Can these icons get tooltips?

I'll mull over what more relevant semiotics or other visual cues, there might be. There is a point of diminishing returns on "Too Much Information," and what a user can meaningfully act upon or otherwise needs to know to understand why things may or may not be working as desired, wd be helpful to understand.

Also questioning the value of communicating all this updating information to users so piecemeal, vs in a more unified fashion—tho I suspect its because of how uniquely segmented Qubes is, from other systems... and that this is one of those "Qubes introduces its own paradigms" things.

[marmarek]

AFAIR the main reason for this gray "will need restart after template shutdown" icon is to remind users that changes made in the template that is still running are not applied yet. And it actually has a tooltip already: "The Template must be stopped before changes from its current session can be picked up by this qube." This was added after many users was confused why some package/update installed in the template wasn't available in an AppVM, even after they restarted said VM, but forgot to shutdown the template first.

[ninavizz]

Bigger question: why the green icons at all? If a Qube is not running, but changes will take effect when it runs next time—why does the user need to know this? To know that they'll be delayed in using that Qube next time they go to run it, because updates have to be applied?

Is there a reason to let users know a Template has been updated and that descendant Qubes will only be updated once they restart again? Is there risk in letting a descendant Qube remain outdated for a long time on a user's machine?

The grey icons, otoh, do seem to have a clear value: "Hey, changes need to be applied, you should quit and restart this VM when you can." Or something.

[marmarek]

Bigger question: why the green icons at all? If a Qube is not running, but changes will take effect when it runs next time—why does the user need to know this?

Hm? I don't think there is a case where this green icon is visible next to a stopped qube. Did you get such case? It is possible that grey variant would be there - if the template is still running - in this case, until you shutdown the template, the qube won't see changes made there, even if it's started after you made the change.

Is there a reason to let users know a Template has been updated and that descendant Qubes will only be updated once they restart again? Is there risk in letting a descendant Qube remain outdated for a long time on a user's machine?

Yes, until you restart your qube, it won't use updates applied in the template. This may mean for example you're running a web browser with known vulnerability (that is already patched in the template).

The grey icons, otoh, do seem to have a clear value: "Hey, changes need to be applied, you should quit and restart this VM when you can." Or something.

I think you confused grey and green icons here. This is what green arrows icon means.

The main difference between green and grey variant is whether the template is still running. If it is (grey icon), you first need to shutdown the template - which will make the icon green. Then, green icon means you need to restart the qube marked with this green icon.

[ninavizz]

Something I finally figured-out this AM while working in Qubes: clicking on the green icons, does nothing. Traditionally, a green icon w/in a UI means "click on this to make the implied action happen." In the open-domains menu (from the Tray) it's more confusing, that "Restart" isn't an option—when the point of the icon is to tell the user that they should restart a Qube so updates can be applied.

Ok, I guess this Issue began as a little idea of mine to address one icon that seemed confusing, and also had some related icons that could use updating... and devolved into a thread about how required and pending updates are communicated to users?

All good stuff to work on—but clearly more of a design inquiry issue, than a solution ready to implement. :)

[imme-emosol]

So, recap; there are two visual elements; one to notify the user of available updates (in the tray) and the other to inform the user about the state of the software of a qube/vm/template.

That second element can have several states, depending on the type of qube involved.. Something mentioned in #5661 is that the "update icon" for VM's means that there have been changes to the template the VM is based on. And there are two versions there, one meaning that the template has not yet been shutdown and the changes can therefore not be applied. The other meaning that the template changes can be applied by restarting the VM.

Perhaps this should be added to #5679 ; make the sorting work different; instead of sorting on columns, sort outside of that display-area, with another control (a dropdown or buttons). That would also enable the option to change a property of a VM by using drag and drop. So, I'd sort on template, the list would show the VM's grouped "underneath" a template.

my-personal-template
   my-personal-mail
   my-personal-browsing
my-work-template
   my-work-mail
   my-work-browsing

I could then drag 'my-work-browsing' underneath 'my-personal-template', to change the template property of that VM. The same goes for other properties, network, colour. Of course there are restrictions, just like there are when you right-click on a VM and open 'Qube Settings'.

[ninavizz]

Ayy, just now noticing this is slated for the 4.1 release. @marmarta What part of this exactly, is desired to be included in the release?

I recently Had Thoughts about the green-circle-arrows icons being used in the context of menus (signifying the VM needs to be restarted). In all the contexts I've looked at since I created this issue, typically the icon signifying that is a triangle/caution-bang, or a circle-bang; not the circley-green icon.

I'd love to get an update to this whole family of icons (things pertaining to updates) in 4.1, and don't want this to fall off the radar.

Perhaps discuss this upcoming Monday in a Qubes UX Things call?

[marmarta]

Perhaps discuss this upcoming Monday in a Qubes UX Things call?

sounds good to me!

[tabbyrobin]

I think one useful approach might be to segment dispvms into their own tab of the manager UI. They are actually quite different from other qubes in a lot of ways, many of them subtle and with potential security implications. I think the selection of what indicators are appropriate should maybe be done somewhat from scratch per category:

• template
• standaloneVM
• dispvm template (technically a type of AppVM)
• regular appvm
• persistent (named) dispvm instantiation
• ephemeral dispvm instantiation

The second bullet feels very confusing. Like, really confusing.

Can these icons get tooltips?

I'll mull over what more relevant semiotics or other visual cues, there might be. There is a point of diminishing returns on "Too Much Information," and what a user can meaningfully act upon or otherwise needs to know to understand why things may or may not be working as desired, wd be helpful to understand.

Also questioning the value of communicating all this updating information to users so piecemeal, vs in a more unified fashion—tho I suspect its because of how uniquely segmented Qubes is, from other systems... and that this is one of those "Qubes introduces its own paradigms" things.

[ninavizz]

Noting here: A few requests in the AppMenu survey, to let users know when there are, specifically, security updates that need to be run.

Re-reading through this Issue a year later is wonderful. I'd totally forgotten about Marek citing the four different types of updates that exist.

Also, this issue currently has a 4.1 tag on it, and I nominate it to receive a 4.2 tag. We've also gotten comments about the proposed updater icon with the number of updates identified in it, on the survey. So, yeah—I'd love to come back to this. :)

[DemiMarie]

Also, this issue currently has a 4.1 tag on it, and I nominate it to receive a 4.2 tag. We've also gotten comments about the proposed updater icon with the number of updates identified in it, on the survey. So, yeah—I'd love to come back to this. :)

Moved to 4.2, but you should really be able to do this yourself 🙂. @marmarek would you mind granting @ninavizz the permissions needed for this?

[marmarek]

Moved to 4.2, but you should really be able to do this yourself slightly_smiling_face. @marmarek would you mind granting @ninavizz the permissions needed for this?

Already did earlier today :)

[ninavizz]

@marmarek FYI, I still cannot change the release milestone in the web UI here, nor add cards to the Updater project. Only an FYI, as I know you have bigger fish to fry, Marek! Thx @DemiMarie !!

[marmarek]

You need to accept the invitation

[DemiMarie]

@marmarek FYI, I still cannot change the release milestone in the web UI here, nor add cards to the Updater project. Only an FYI, as I know you have bigger fish to fry, Marek! Thx @DemiMarie !!

You’re welcome!