install experience (compared/contrasted with previous installer experiences)

[ferdnyc]

While this initial post isn't about the webui directly, I promise I will be getting there.

Before I post my feedback on the webui installer (having just tried out the F37-installing preview ISO in the same VM setup I used for this previous experience), I wanted to preface the discussion (#SWIDT?) by first sharing my Ask Fedora post from a couple of weeks ago regarding the old installer. Particularly because I framed part of it in terms of lessons learned, things which might be applicable to the design/development of any replacements.

(And also because I was pointedly invited to take my thoughts and think them somewhere other than Ask Fedora, which I guess might as well be here.)

---

I had cause to install F37 beta into a VM tonight. (Yes, I know final release is due in mere hours, but I'm specifically preparing package builds ahead of it, to [hopefully] be ready at release.) To minimize download size, I used the netinst image, which means the individual packages to apply were downloaded by anaconda during the install process, so there was more than usual going on.

In part because of that, I was able to observe in somewhat more detail than usual how progress is reported during the process. In a word, IMHO, it is... lacking.

Here's what it looks like, mid-download. (Static image... but video/animation would be pointless anyway, for reasons I'm about to explain.)

The progress bar is — as usual and, I assume, intended — a single, global "complete install process" status that stretches from 0% at "'Done' button pressed, starting installation" to "installation complete" when it reaches 100%. (Conceptual labels, it doesn't display that text on-screen. At 100% it actually just shows "Complete!" rather jauntily.)

It's tempting to say the download progress is "included in" or "part of" the overall progress, but that'd be severely overstating things. What actually happens is this:

1. The download starts, at which point the text line shows the number of packages required, a meter of Downloaded / Total bytes transferred, and the percentage completion (the result of that Downloaded/Total calculation)
2. While that's going on, the progress bar starts at 0%, and in fits and spurts moves up to the position it's at in the screenshot, with its movements having absolutely no relation to the download progress.
3. Once it reaches the position in my screenshot (which for me happened when the download was at ~15-20%), it stops there and does not move at all until the download process completes.

So, eventually, the downloads finish and the package installations start. "Ah!", you may be thinking, "now we'll see some progress." While your naïve optimism is endearing, it is misplaced.

What we actually see is a repeat of the previous step: the progress bar sits right where it is and does not move throughout the entire package installation run, with the actual package-by-package progress being reported (again) on the text line as a parenthetical "(number / Total)" counter.

Eventually, Installing... becomes Configuring... and still the progress bar has not moved:

Something like 90% of the total time it takes to perform the installation passes with the "progress" bar sitting in that same ~15% position. And at least 75% of the bar's entire progress occurs in the final 30 seconds of the installation.

I just find myself questioning the point of having a progress bar at all, when it's never used to meaningfully display any progress. (When, in fact, the text status line has to be co-opted to report progress instead of the progress bar.)

I know there are efforts underway to rethink the design of the install process significantly, which may make my current experience moot. Great! Great, that is, if lessons are taken from the current situation.

So, all I can say to anyone involved in that effort is: Do better. Design your worker routines from the ground up to track and report progress in as much detail as reasonably possible. Design your frontend reporting so that it can aggregate and normalize that reporting. From every possible source — including new ones that get bolted on somewhere down the road — and in full detail.

You don't necessarily have to display progress to the user at that level of detail, but you still need every bit of detail. Otherwise, there's little chance that whatever you do present to the user will seem even vaguely connected to reality.

[ferdnyc]

Progress on progress?

So, how does the new webui installer do, in comparison to this experience with its predecessor?

Wellllllllll...

Not so much

This paragraph turned out to be especially prescient:

I just find myself questioning the point of having a progress bar at all, when it's never used to meaningfully display any progress. (When, in fact, the text status line has to be co-opted to report progress instead of the progress bar.)

The webui designers apparently having made the same observation, this is "solved" in the new installer by, in fact, eliminating the progress bar! (Not what I was going for with that statement, for the record.)

While "no progress bar" is most certainly preferable to one that outright lies to the user, it is an inferior option to having the process actually set meaningful expectations for the user about how far along things are, and how much time — roughly — they can expect it will take to complete. That felt obvious to me, but the point is apparently somewhat more subjective than I'd realized.

When even GNOME Software is more forthcoming...

The thing that really irks me about this is, after I finished setting up my account and had been logged in, I headed to GNOME Software — an application I normally wouldn't be caught dead running — to further the experiment by updating packages "the normal user way", instead of running sudo dnf upgrade in a terminal as I normally would.

Even there I was shown progress as the packages downloaded, in the form of a little blue border-line that crawled along the "Download" button after I'd clicked it. During the subsequent reboot cycle, I was shown another nice, percentage-based progress meter on the Plymouth screen, representing the process of actually applying the downloaded packages to complete the updates.

Were I using dnf system-upgrade to install Fedora 37 atop an existing F36 system, I would similarly be shown initial download progress (complete with ETA, a luxury GNOME Software can't be bothered with), and then a 0%-to-100% progress meter representing the actual package transactions once I'd rebooted into the system-upgrade environment.

No packages, no progress? (Worst Bob Marley cover ever!)

Now, I realize that installing from the live media no longer involves individual package transactions. It's not as simple as leveraging the "free" progress information supplied by DNF/RPM, which is all either of the previous examples actually do. And in fairness, progress is displayed while writing the filesystem image to the target disk. The status text during the second stage of the install counts up from 0% to 100% during that operation. Ironically, that part of the process happens so quickly that it's easy to miss it completely.

On either side of that lone "0%-to-100% copied" disk write, the installer sits for long periods, showing the modernized equivalent of a spinning beachball cursor, while "stuff" goes on behind the scenes. This stuff apparently isn't considered very interesting to the user, as they're afforded only very occasional, broad-strokes updates.

(Even the one vague concession to setting expectations, towards the end, was somehow so vague as to be effectively meaningless, and yet also ended up feeling somewhat inaccurate: The "finalizing" step that was claimed to take "several moments" was actually something more like 3-4 minutes. Which of course could be "several moments", because you could claim any amount of time is "several moments". But it still felt like it was presented as being a shorter wait than it turned out to be.)

All in all, this part of my original post was decidedly NOT prescient:

Design your worker routines from the ground up to track and report progress in as much detail as reasonably possible. Design your frontend reporting so that it can aggregate and normalize that reporting. From every possible source — including new ones that get bolted on somewhere down the road — and in full detail.

You don't necessarily have to display progress to the user at that level of detail, but you still need every bit of detail.

I guess, if you're just not going to tell the user anything about what's happening or how far along it is, you don't technically "need" that information for anything.

So we go back to (sadly-)prescient, at the end:

Otherwise, there's little chance that whatever you do present to the user will seem even vaguely connected to reality.

I don't hold out much hope that better progress tracking could be added in after-the-fact. If it's not designed in from the ground up, you're better off rewriting everything than trying to shoe-horn it into existing code. So, alas, that ship has sailed.

I also have some other, unrelated UI feedback; I'll add a followup post or start a separate discussion for that when I can.

[jkonecny12]

Hi, thanks for your detailed feedback.

To explain our intentions. We are not able to tell user how long the installation takes in general (we don't have the data). We definitely could improve the situation by being better in tracking the download and package installation, however, that is not the biggest issue.

If you take the progress bar as "I'm in 50% so it will take about the same amount of time to finish" than you are being lied. The biggest issues of finding out how long they would take:

• system configuration parts
  • lot's of stuff is happening and it's hard and sometimes not possible to track these
  • could varied based on HW and user configuration
• package scriptlets
  • these can't be tracked (these are just scripts) and with some packages it could take even the same amount of time as installation
  • as example kernel package will generate initRAM disk
• initRAM disk generation
  • I'm not aware of finding out how to track this and it happens unfortunately multiple times during installation, each of them taking a few minutes
• storage configuration
  • mostly quick but it depends on your HW, in some situations it could take a while

Because of the these reasons, we decided that rather than lying to a user and giving them false expectations we will give them an overall information about the process with no global bar which wouldn't be accurate.