Updater: Add disabled-state buttons

[ninavizz]

Problem

When things are happening on the backend before a user is able to act upon UI actions, disabled-state buttons being visible to a user are an important visual affordance to manage expectations and possible anxiety when other things are broken. Such persistent attention to manage user expectations is not common in Linux-land, but is common in Mac and PC environments.

Disabled buttons are cues to a user for what to expect, next. When we are wholly unfamiliar with a flow and don't see them, we're just left in the dark and don't know what either we're supposed to do, or what the system is supposed to do. Again: the absent white-glove of expectations management is common in Linux environments, but I fear will trigger anxiety and frustration for users acclimated to Macs and PCs.

Without disabled-state buttons visible, am I supposed to be doing something I don't know about? Is the system?

This was something that only came onto my radar, when I ran the updater on my Qubes laptop today during breakfast. I couldn't remember what the following screens in the flow were supposed to be, when on the "Updating DO NOT CLOSE or things will break" screen was running.

Because of the 100%-for-too-long bug, the anxiety and frustration were especially high. Had the buttons been visible in a disabled state, at least that affordance would have suggested to me that I just need to wait a few minutes more. Not that I was supposed to be doing something I couldn't remember, or that things had broken.

Solution

Add in the Continue/Cancel and Reboot/Cancel and Cancel buttons on the "Updating DO NOT CLOSE or things will break" screens, as disabled button graphics. This is more of an anxiety/user-expectations-management device, than anything else.

An alternative option for pre-beta, would be to add a line of un-bolded text just below the bolded "DO NOT CLOSE or things will break" line, that would simply state Once the updates have completed, you will be prompted what to do, next.

Erik's eyes hurt from rolling back in his head so far

I know, I know. Just pls to prioritize as best as can be, is all I ask. :)

[eloquence]

#418 which fixes the progress bar just got merged, which should help with the anxiety factor for beta.

I agree it's worth looking to environments journalists are familiar with. Here are some update screens from Mac and Windows:

I don't see explicit disabled cancel actions on either of those screens. The Mac dialog has a nice subtle detail with the "x seconds remaining", which provide an additional hint to the user that work is still pending. The Windows screen has a spinner which, I am guessing, at least has the benefit of not freezing up. Are there other example dialogs worth looking at? The ones I've been able to find with a "Cancel" button had it during the "Checking for updates" stage, enabled.

I think the most likely cause of anxiety is the kind of frozen progress bar without any visible update that you're experiencing. I'm open to adding the buttons (most likely post-beta) but I'm not sure they actually solve the core issue, and I suspect updating the progress bar more frequently (so the user sees small increments of progress, rather than large blocks) would be a bigger win.

[ninavizz]

I spent some time studying my Mac's updaters, when making my initial recs to Mickael. The initial idea to not have disabled state buttons, came from those studies. That said: my Mac is a very stable, very predictable machine (most of the time).

Qubes lacks stability. Linux distros lack the consistency wrt event and task duration timing, that Macs have. In some areas a Linux OS is disorientingly snappier than a Mac, because it doesn't get bogged down with drawing gradients and dropshadows on everything.

TL;DR, my thought to put the disabled-state buttons on the screens, is precisely to address the myriad of things we want to control and improve, but ultimately may not be able to control as much as we want to. I know we want to improve performance, but really—can we? Trying to adapt my own design inclinations, towards being more realistic with what we can expect from a Qubes/Linux machine. I love your $.02 on these things @eloquence, and appreciate your thoughtfulness and patience when fielding what may seem like flaky indecision on my end. We need insight from users to guide us, bottom line.

On that one screen, it's a fatal error to reboot... and this AM I found myself ready to just re-boot, assuming it had frozen. A common and easy assumption in Qubes, and more difficult to gauge with a brain trained to expect a Mac's timing with task execution. And, before coffee.

Maybe we should really make it a point to set-up the pilot users to expect an at-times slow experience that will need a coffee sharpened brain.

[eloquence]

TL;DR, my thought to put the disabled-state buttons on the screens, is precisely to address the myriad of things we want to control and improve, but ultimately may not be able to control as much as we want to.

I understand; I do think however that the "is this broken / what's happening?" scenario is possible to address with small, iterative changes we may be able to make, not to the performance itself, but to the perception that the updater is still running. Some ideas to spitball:

• smaller increments to progress bar
• textual updates to what is happening ("Installing updates in VM 1 of 8"), perhaps under progressive disclosure
• seconds estimate like in the Mac updater
  etc.

Any of these may be too complicated to do right now, but if we think that they're more likely to solve the actual problem of the user thinking that the system is frozen than adding buttons, then I'd rather tackle one of those after the pilot, than make a change that does not appear to be consistent with prevalent system conventions, and which may only provide limited mitigation for the perceived UX issue.

I'd also reiterate that it's worth re-testing with the progress bar fixes in place, which should significantly mitigate the issue you experienced.

[ninavizz]

I really like all the spitballed ideas, up above—and to clarify, would much rather see those things take priority, over adding-in a mirage to ease a user's mind (what I feel the disabled buttons are).

We don't have a place right now to file "Not awesome, but worth considering" ideas... and I consider the disabled-state buttons, to be exactly that.

Looking forward to seeing the updates in place, and the full experience to evolve over the weeks ahead!

[eloquence]

💯 , it's worth considering the various different options, and I fully agree that the "is the system frozen?" scenario is one of the most likely ones -- perhaps the most likely -- under which a user might reboot during an update or take other actions that could have destructive side effects.

[eloquence]

The current version of the updater does indeed disable the "Cancel" button during updates, so closing this old issue.