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?

---

:memo: 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 https://github.com/yast/yast-installation/issues/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: https://github.com/yast/yast-installation/issues/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: https://github.com/yast/yast-installation/issues/915 (Simplify Online Repos Installation Workflow Steps)

[shundhammer]

Added new issue about time zone selection: https://github.com/yast/yast-installation/issues/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 https://github.com/yast/yast-installation/issues/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 :wink: :stuck_out_tongue_winking_eye:), 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)

[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.

Hmm, how can I put it? :sweat_smile:

As time has passed we have realized that it was not a reality in Agama either. Not at least how we envisioned it. Unfortunately, Agama (formerly known as D-installer) is no longer a minimalist, almost AI-driven installer, where the user barely interacts beyond entering a username, password, and clicking on Install. As features grew, we had to change our mind and follow a more classic approach, while still avoiding the use of wizard to avoid forcing users to go through the settings they don't need/want to touch.

Thus, it seems so challenging to change that YaST workflow. Even unlikely to happen. So, let's close the issue since keeping it open doesn't make much sense. It was nice to keep the naive idea alive so long :smile:

[shundhammer]

OS installations are an inherently complex problem, so some additional workflow steps are expected. But it's important not to get completely overboard with this; especially avoiding some product manager's pet project that he wants to be highlighted by having a whole separate workflow step for it; a step that could easily be avoided.

The important part is to keep the spirit of a short installation workflow alive; to keep reviewing and questioning every one of those steps:

• Is it really needed?
• Does it contribute or distract from the user's overall experience to install our product?
• Do we really need to ask the user this particular decision?
• Did we provide enough information so the user can make an informed and confident decision?
• Do most (like 80%) users just leave the defaults and click "Next" anyway? (Then it should probably rather be an "expert" button, and we shouldn't bother those 80% of users with this decision)

It's important to resist people (product managers in particular) who "just want another checkbox" or "just another question for the user to answer". Those are mostly bullshit questions that we shouldn't ask; things that only a very small minority of users ever want to change.

Cater to the majority, not fringe cases.