Make the installation process shorter

[dgdavid]

While working on a research task about if the UI and UX of yast2-firstboot can be improved, I realized the workflow in the provided firstboot.xml example file does not include a step with the settings summary before finishing its execution.

I missed it because

• It is present during the installation process, and
• It allows a not-sequential navigation among the configuration. I.e., the user can go "back" to change, let's say, the bootloader configuration without going back through all the previous screens, and
• It is annoying to have to go Back Back Back and then Next Next Next just because you changed your mind about the keyboard layout settings.

As annoying as a Next-Next-Next driven installation?

I think so.

That's why I'm opening this issue/discussion: for proposing to rethink our installation process and (almost) start directly it in the interactive installation summary, using the defaults that were set by the product installation control file. Thus, the user only needs to make the desired adjustments and proceed to install the product. Hopefully, this could make it quite some steps short and more pleasant (I guess).

Obviously, some steps cannot be skipped (user creation? language and keyboard? product selection + registration? role?) until reaching the summary but, IMHO, it should not stop us to explore this proposal.

In fact, this is how Fedora's installer looks/behaves like, although with a nicer (arguable if you want; that depends on the beholder's eye) UI. I mean, not using a RichText summary.

Fedora 33	openSUSE TW
Workstation Server

Thoughts?

---

📝 you can find more opinions/discussion at https://lists.opensuse.org/archives/list/yast-devel@lists.opensuse.org/thread/7MD6JME5KVK3XBPW5VNRZIO7M2TNAE6G/

[schubi2]

I would keep the installation steps which we already have. They are almost the same like in an windows 10 installation. But I like the graphical layout of the installation overview. The user gets a better/faster overview about it. As we have already tabs in our current installation overview I would prefer it in the first (default) tab. More information can be seen in text form in the other tabs (like we already have).

[ancorgs]

I fully support the idea. The only steps that make sense to present before the summary are:

• Those that influence the ProductFeatures and the installation workflow itself. That is registration, product selection and role selection.
• Those that are fully mandatory but we cannot make a proposal. Basically root password and/or maybe user creation.
• Those that are needed to use the former. Basically language and keyboard.

All other aspects should be configured to the installation summary. Of course, that could mean we need to have better proposals that need less tweaking (storage comes to mind), but that's something we can improve for sure.

[ancorgs]

About the look&feel. Of course the Fedora one looks nicer at first glance, but I find our format to be more useful.

[joseivanlopez]

Call me crazy, but I find our Summary nicer and more informative.

[dgdavid]

Call me crazy, but I find our Summary nicer and more informative.

No, I'm not going to call you that way 😉 What I meant is that the look & feel looks more up-to-date, but it depends on the user taste. For sure, our summary is more informative, but I strongly believe that we could improve it.

[dgdavid]

For future participants/readers: note that this is being discussed at https://lists.opensuse.org/archives/list/yast-devel@lists.opensuse.org/thread/7MD6JME5KVK3XBPW5VNRZIO7M2TNAE6G/ too.

I'll add the link in the issue description, just for reference.

[jreidinger]

OK, problem e.g. with license is that it has to be the first one to confirm.

What I also miss is ability to shrink/expand configuration in installation summary.
We also should try to compress a bit summary to fit one screen. E.g. software is now really big and maybe it can be like patterns write 3 and then having expand link to see all of them.

[wfeldt]

For sure, our summary is more informative, but I strongly believe that we could improve it.

One of the annoying things of our summary screen is that it is scrollable. With software patterns taking up most of the space (what for, really?).

If we go from the wizard-step approach to a clickable config screen, then why not aligning the items in the left colum to the headlines in the right and making them clickable to get details (much like a tree view)?

[dgdavid]

OK, problem e.g. with license is that it has to be the first one to confirm.

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

What I also miss is ability to shrink/expand configuration in installation summary.

Good point.

We also should try to compress a bit summary to fit one screen. E.g. software is now really big and maybe it can be like patterns write 3 and then having expand link to see all of them.

That's one of the reason I stated that the Fedora summary is nicer. For sure, I chosen a wrong word, but having all the (minimal) information at glance could be a MUST.

[dgdavid]

For sure, our summary is more informative, but I strongly believe that we could improve it.

One of the annoying things of our summary screen is that it is scrollable. With software patterns taking up most of the space (what for, really?).

I fully agree here. As said before, "That's one of the reason I stated that the Fedora summary is nicer."

If we go from the wizard-step approach to a clickable config screen, then why not aligning the items in the left colum to the headlines in the right and making them clickable to get details (much like a tree view)?

And that's why I like to see people involved here. Because the ideas arise much better.

Thanks!

[jreidinger]

OK, problem e.g. with license is that it has to be the first one to confirm.

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

What I also miss is ability to shrink/expand configuration in installation summary.

Good point.

We also should try to compress a bit summary to fit one screen. E.g. software is now really big and maybe it can be like patterns write 3 and then having expand link to see all of them.

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

I worry it is not our decision but company layer and I think requirement is to show license and explicitelly confirm it.

[dgdavid]

...

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

I worry it is not our decision but company layer and I think requirement is to show license and explicitelly confirm it.

The user has to explicitly check the checkbox, which will contain a link to open the dialog holding the license. If the user read it or not is another story. Almost the same than using the wizard approach.

Anyway, I still think that at least we could provide a proof of concept / mockup / whatever. Sometimes changes look better when you can visualize them.

[wfeldt]

I worry it is not our decision but company layer and I think requirement is to show license and explicitelly confirm it.

The user has to explicitly check the checkbox, which will contain a link to open the dialog holding the license. If the user read it
or not is another story. Almost the same than using the wizard approach.

I'm not sure if a checkbox without forcing the user to at least have a glimpse at the text is enough. But I think we might reduce the space the license text takes up on the screen quite drastically. Other professional companies have set the bar quite low
on the readability of the text, afaik.

[dgdavid]

I worry it is not our decision but company layer and I think requirement is to show license and explicitelly confirm it.

The user has to explicitly check the checkbox, which will contain a link to open the dialog holding the license. If the user read it
or not is another story. Almost the same than using the wizard approach.

I'm not sure if a checkbox without forcing the user to at least have a glimpse at the text is enough.

Then, let's add the neccesary logic to only activate the install button if

• the user checked out the checkbox, AND
• the dialog holding the license has been shown (if license acceptance if required, of course)

Another alternative (apart from what you mentioned) could be to display the license dialog just before proceeding with the installation. I.e., (the last step) after the installation summary.

[wfeldt]

Another alternative (apart from what you mentioned) could be to display the license dialog just before proceeding with the
installation. I.e., (the last step) after the installation summary.

That's a good question (for a lawyer) - IIRC it is where it is today on purpose. Presenting a list of relevant licenses and
agreements you have to accept at the summary screen would be much nicer indeed (to me at least).

[shundhammer]

See also #912 : Switching the Language is Hard in the First Installation Dialog

[shundhammer]

@hellcp might be interested in this.

[hellcp]

Interested in this, yeah, surprise surprise ;)

I will be using a lot of GNOME's supplementary material because they have some useful design patterns and I'm not feeling like drawing things from scratch right now (I recommend having a look from time to time, nobody does this much in-depth work around sadly)

Obviously, some steps cannot be skipped (user creation? language and keyboard? product selection + registration? role?) until reaching the summary but, IMHO, it should not stop us to explore this proposal.

There is no escaping product/role selection I feel, that may actually have to show up first, having it be an option in summary is problematic because of how much of the system those influence.

As for the rest, how about using YaST Firstboot/GNOME Initial Setup/KDE Initial System Setup? I think for the desktops it would be better if they had full authority on how they are supposed to be set up.

For non-desktops: how about user setup while the system is installing. That config is saved as last anyway, so just showing a progress bar under the user setup screen while user sets those things up may be enough.

About the look&feel. Of course the Fedora one looks nicer at first glance, but I find our format to be more useful.

I don't see how they contradict. Let's explore some mockups though:

Very old GNOME mockup

That's a little limited in scope though, it can contain more diverse information than the Fedora one, and is even more neat, but we can do better.

My mockup from a long time ago:

I could do better than this, especially since I explained better what I meant instead of drawing it ;)

Here a good supplementary material is the rundown of list patterns https://gitlab.gnome.org/Teams/Design/os-mockups/-/blob/master/lists/list-design-patterns.png

You don't want to overwhelm the user, it may be a good idea to on the first glance only show the critical information and only go in depth if the user clicks on a list item. Icons aren't necessary, just nice to have, but having an explicit edit button would go a long way to make it easier for the user to understand they can edit an item.

I realize this won't work in the ncurses mode too well, but also I think people using the ncurses mode will be way more comfortable seeing the existing summary than others.

[shundhammer]

Screenshot sequence for a TW installation: #914

[Conan-Kudo]

OK, problem e.g. with license is that it has to be the first one to confirm.

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

What I also miss is ability to shrink/expand configuration in installation summary.

Good point.

We also should try to compress a bit summary to fit one screen. E.g. software is now really big and maybe it can be like patterns write 3 and then having expand link to see all of them.

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

I worry it is not our decision but company layer and I think requirement is to show license and explicitelly confirm it.

The default workflow for CentOS/Fedora/RHEL is that the license confirmation is done on firstboot rather than prior to installation. It can be done the other way (similar to openSUSE), at which point you get another item in the "Software" column that you need to click through and accept before it'll let you begin installation. (cc: @jkonecny12 who can confirm this).

(Fedora has this completely disabled as there's nothing to materially show)

[shundhammer]

The default workflow for CentOS/Fedora/RHEL is that the license confirmation is done on firstboot rather than prior to installation. It can be done the other way (similar to openSUSE), at which point you get another item in the "Software" column that you need to click through and accept before it'll let you begin installation. (cc: @jkonecny12 who can confirm this).

(Fedora has this completely disabled as there's nothing to materially show)

Actually, that makes a lot of sense to me.

Not only does this shorten the real installation workflow; it might also be a different person who accepts the license. An admin might prepare a machine until the point where it is about to reboot, and then leave the rest to the end user who will actually work on that machine. It would be that end user who accepts the license, not the admin.

I just wonder if our corporate lawyers would be fine with this approach.

[Conan-Kudo]

Here's the screenshot of this happening in RHEL 8:

[Conan-Kudo]

And this is how the hub looks like on RHEL 8:

[shundhammer]

Added new issue about simplifying the online repos workflow steps: #915 (Simplify Online Repos Installation Workflow Steps)

[shundhammer]

Added new issue about time zone selection: #916

[why-not-try-calmer]

The best candidates for simplifications I can see so far:

1. as Neil suggested above, license acceptance could be done outside of the installer
2. System Analysis is for me thematically related to Network Autosetup; perhaps the two could be done in a single pass / screen?
3. I think just by resizing and moving things around, we could gather language & keyboard layout, clock & timezone on a single screen / view

Doing 1-3 might spare the user some clicks, but I doubt it will make the overall UX much better. My doubts are grounded in the following considerations.

Left-hand side list
The "flatplan" / table of contents list we currently have in the left-hand side panel is a Good Idea, as it allows the user to focus on what matters instead of determining the order in which they want to set things up; it also creates a uniform sequence easier to reference and document later, especially if the sequence is long.

The problem however is that the names of the items in the list don't always match every displayable view, which creates a bit of confusion.

If we made it clickable, we could spare the user some tedious "Back" / "Skip" actions

Skipping, going back state management
Navigation with buttons is a bit erratic as of now: throughout the Yast installer, 'go back' rarely means 'go back to the previous screen'. Instead it often means 'cancel and go to previous screen' (your current view's state will be lost). This is a problem when it applies to defaults.

So for example when going back and returning to List Of Online Repos means you will get 0 box ticked when you return.

But if views stored their state, and had a Reset to defaults button, this would be adverted.

Partitioner
Even though it is not as bad as Fedora's our partitioner is tedious to work with. The differences between Guided vs Expert are not very clear (and in fact the "Guided Partioner" does not provide much guidance, it just enforces many defaults).

Even though I cannot prove it right now, I suspect that the partitioner can be simplified by using a unique screen displaying a graphical view of submitted changes, i.e. a view of original partitioning scheme together with a view of the proposed partioning scheme (think: "after vs before"). Then the difference between Expert and Guided would be that, on this very screen, the Expert mode enforces no sequential action, offers less inline documentation, and offers more granular options.

So at the end of the day, what is the strategy we want to adopt for improving the Yast installer? Do we want to reduce steps by implementing something like (1-3), or do we want to overhaul the whole thing to accomodate these together with other shortcomings?

[jkonecny12]

OK, problem e.g. with license is that it has to be the first one to confirm.

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

What I also miss is ability to shrink/expand configuration in installation summary.

Good point.

We also should try to compress a bit summary to fit one screen. E.g. software is now really big and maybe it can be like patterns write 3 and then having expand link to see all of them.

But, why? I mean, just having the "By installing the product you accept the terms & conds" checkbox in the summary that enable/disbable the Install button I think it is enough.

I worry it is not our decision but company layer and I think requirement is to show license and explicitelly confirm it.

The default workflow for CentOS/Fedora/RHEL is that the license confirmation is done on firstboot rather than prior to installation. It can be done the other way (similar to openSUSE), at which point you get another item in the "Software" column that you need to click through and accept before it'll let you begin installation. (cc: @jkonecny12 who can confirm this).

(Fedora has this completely disabled as there's nothing to materially show)

Yes, you are correct. In Anaconda you can do the installation and accept EULA in the first run, or use pykickstart command when doing kickstart automated installation.

[Conan-Kudo]

Even though it is not as bad as Fedora's our partitioner is tedious to work with. The differences between Guided vs Expert are not very clear (and in fact the "Guided Partioner" does not provide much guidance, it just enforces many defaults).

I think this is subjective. In my experience, the less experienced users are with installing an operating system, the happier they are with Anaconda's partitioner, because the mount point oriented view makes more sense than the disk oriented view. People who have more ingrained expectations of what a partitioner is supposed to look like tend to not like Anaconda's mount point-oriented partitioning view. Even with that, Fedora (though notably not RHEL) also offers a disk oriented view for partitioning. YaST manages to make this the worst of all options by smashing both mount points and disks into the same view, making it terribly confusing to figure out what is happening.

[why-not-try-calmer]

Even though it is not as bad as Fedora's our partitioner is tedious to work with. The differences between Guided vs Expert are not very clear (and in fact the "Guided Partioner" does not provide much guidance, it just enforces many defaults).

I think this is subjective. In my experience, the less experienced users are with installing an operating system, the happier they are with Anaconda's partitioner, because the mount point oriented view makes more sense than the disk oriented view. People who have more ingrained expectations of what a partitioner is supposed to look like tend to not like Anaconda's mount point-oriented partitioning view. Even with that, Fedora (though notably not RHEL) also offers a disk oriented view for partitioning. YaST manages to make this the worst of all options by smashing both mount points and disks into the same view, making it terribly confusing to figure out what is happening.

Just to clarify, it is our partitioner in which the Guided vs Expert partioner modes could be improved. I was mentioning Fedora for contrast: Fedora's partitioner is very confusing (try setting up LVM subvolumes for Silverblue on a disk with already preexisting subvolumes: an absurd mess), and the overall installer also is questionable.

However, even though our partioner is pretty good, there may be room for making it more user-friendly. It's quite difficult for me to give more details using just words, so I hope I can find time to sketch a concrete proposal for improving the UI of the partioner specifically.

But before I take the time of doing this, I crucially need to know if that's worth it. OP started this Issue to discuss specifically shortening the installation process, so is making concrete proposals for trying to improve the installer way outside the scope of this Issue? And relatedly, what sort of programming and designing effort it is reasonable to expect from people working on the Yast installer in the near future?

[shundhammer]

Huh? Show me any partitioner, no matter for what OS, that can do nearly as much as ours.

Partitions, LVM, RAID, encryption, BCache, Btrfs in all its variations, you name it: We have it, and other partitioners support only a tiny portion of that. Few go beyond simple partitions and maybe one simple auto-setup with whole disk encryption.

And yes, every single one of those features was explicitly requested over the years by users, business customers, product managers.

The initial storage proposal and how the "guided partitioning" works may be an area that deserves a discussion about an easier or more accessible approach. The real partitioner not so much.

[why-not-try-calmer]

Huh? Show me any partitioner, no matter for what OS, that can do nearly as much as ours.

Partitions, LVM, RAID, encryption, BCache, Btrfs in all its variations, you name it: We have it, and other partitioners support only a tiny portion of that. Few go beyond simple partitions and maybe one simple auto-setup with whole disk encryption.

And yes, every single one of those features was explicitly requested over the years by users, business customers, product managers.

The initial storage proposal and how the "guided partitioning" works may be an area that deserves a discussion about an easier or more accessible approach. The real partitioner not so much.

I agree. The version of the partitioner in the Yast installer is good! It's just that the UI could be improved (IMHO).

[shundhammer]

I agree. The version of the partitioner in the Yast installer is good! It's just that the UI could be improved (IMHO).

Believe me, we gave that a lot of thought, and we discussed it for a long time.

With all the different technologies and features we need to support, this was our best shot. There may be some small things that can be improved, but nothing really substantial; or some features will no longer work (or work in very surprising ways).

[why-not-try-calmer]

I agree. The version of the partitioner in the Yast installer is good! It's just that the UI could be improved (IMHO).

Believe me, we gave that a lot of thought, and we discussed it for a long time.

With all the different technologies and features we need to support, this was our best shot. There may be some small things that can be improved, but nothing really substantial; or some features will no longer work (or work in very surprising ways).

... and it is an excellent best shot. What I think could use some improvement is rather the workflow in the [Guided Setup | Expert partioner] views.

[Conan-Kudo]

Huh? Show me any partitioner, no matter for what OS, that can do nearly as much as ours.

Partitions, LVM, RAID, encryption, BCache, Btrfs in all its variations, you name it: We have it, and other partitioners support only a tiny portion of that. Few go beyond simple partitions and maybe one simple auto-setup with whole disk encryption.

And yes, every single one of those features was explicitly requested over the years by users, business customers, product managers.

The initial storage proposal and how the "guided partitioning" works may be an area that deserves a discussion about an easier or more accessible approach. The real partitioner not so much.

Yes, but you lack a good basic mode for people who don't understand all that stuff. Most folks don't know what all those words even mean. The guided partitioner doesn't actually guide people to setting up storage based on their intent.

[shundhammer]

Yes, but you lack a good basic mode for people who don't understand all that stuff. Most folks don't know what all those words even mean.

Well, the expert partitioner is for experts. In the installed system, we even explicitly post a warning when starting it: "Use this only if you know what you are doing".

Right, there is no simple mode. During installation, that was what we hoped to achieve with the "guided partitioning".

The guided partitioner doesn't actually guide people to setting up storage based on their intent.

I agree that the guided partitioning is an area that deserves further discussions.

[why-not-try-calmer]

Probably as for web things all this conversation should be centered on concrete UI examples. Otherwise we're going to be sucked into a theoretical debate.

[ancorgs]

Just for clarification, it looks to me like some people are using the word "Partitioner" with slightly different meanings. We, the YaST developers, usually use that word only to reference the Expert Partitioner with the full-featured table-driven view. We usually do not include the Guided Setup as part of what we call "the Partitioner".

That being clarified, I agree there is a lot of room to improve the Guided Setup. The current approach was our first attempt to have a very generic system while implementing storage-ng. The current wizard was never meant to stay as the final solution to the end of all times. If fact, we didn't even implemented the whole initial idea - it was supposed to have hyperlinks to change individual settings without re-running the whole wizard. But since most corporate users use the Expert Partitioner and they have requested several new features for it, we have not invested much time evolving the Guided Setup from its initial form (apart from creating a completely alternative Guided Setup for SUSE Manager).

I personally would like to rethink the Guided Setup for Leap 15.4, if other YaST priorities permit. And I think this effort to re-think the summary screen and to reduce the number of installer steps is the perfect excuse for doing that Guided Setup overhaul.

Regarding the Partitioner (in its strict sense), the whole approach of the UI could of course be more intuitive for newcomers, but we have a big base of old-time users that are really used to its current disk-driven approach and actually like it a lot. Even moving some actions from buttons scattered all over the UI to a menubar was already a disruptive change for some of them. I guess it's one of those love-it-or-hate-it cases. We still need to iron up some details for 15.3, but I'm generally quite satisfied with the current Partitioner UI, taking into account is an advanced tools for traditional (open)SUSE users who appreciate its device-driven view and its integrated management of LVM, RAID, btrfs and whatsnot.

We could try to do some things to reduce the number of situations in which newbies need to run the Expert Partitioner (like a better Guided Setup or any other alternative), but I would NOT do any big paradigm change to the Partitioner as it is in Tumbleweed/15.3.

[shundhammer]

Added separate issue #917 Installation Proposal: Software, Patterns, Roles.

[dgdavid]

OP started this Issue to discuss specifically shortening the installation process, so is making concrete proposals for trying to improve the installer way outside the scope of this Issue?

Exactly, I originally opened this issue to discuss how the installation process can be improved by taking advantage of defaults to make it more straight. Of course, it doesn't mean that we are aren't open to evaluate whatever small or big idea that might help to improve the installer. However, I confess that I like the @shundhammer's approach to open a new issue for elaborating further on a specific topic and link it here.

Regarding the Partitioner I think the @ancorgs' comment should be beard in mind.

[jreidinger]

@ancorgs one thing that I often need to go to expert partitioner even if I do not need tricky setup is when re-installing system. As only in Expert partitioner is that import mount points that basically do what I need.

[dgdavid]

Just for the record, although starting the installation in the summary is not a reality in YaST2 (yet 😉 😜), we took the idea for the D-Installer project.

Read more at https://yast.opensuse.org/blog/2022-03-31/d-installer-first-public-release (and some previous bits at https://yast.opensuse.org/blog/2022-01-18/announcing-the-d-installer-project and https://yast.opensuse.org/blog/2022-02-23/start-2022#dinstaller)