While I have a strong preference for having a predictable, linear sequence of steps, I'm not sure that the WG independently pushing its own design agenda is the best way forward here.

If the WG felt strongly about it, we could maybe identify some high-level goals and have a conversation with the Anaconda team about what the best path forward might be?

Quite a lot of effort was expended on Anaconda "newui" and at that time they committed to a hub and spoke UI. Unless Anaconda folks indicate their willingness to substantially revise it, I consider the current UI a ship that's sailed.

It's reasonable to have high level design goals, and even evaluate other installers to see if anything better achieves those goals.

I'm curious what the installer UI is going to look like for Silverblue, considering its going to be rebased on CoreOS which uses coreos-installer + ignition, and has no graphical interface at all. To what degree that's relevant vs out of scope, I'm having difficulty grasping. The more conventional Workstation and its Silverblue variant diverge, the less certain I am about the transience vs persistence of today's decisions.

The only reasonable way we'd go back to a linear UI for installation is if we switched from Anaconda to Calamares or ported elementary OS' installer to Fedora.

It is incredibly unlikely we're going to get Anaconda team to switch to a linear UI, and you're certainly not going to get support from me for doing that.

I do not expect that the WG would be even remotely interested in Calamares, as they don't like Qt based applications in Workstation. But elementary's installer might be interesting, provided the Ubuntu-isms can be factored out of distinst and the frontend.

Also, another alternative would be to rewire the elementary OS frontend to use Anaconda as a backend. Anaconda has been working on making it possible to plug alternative frontends on top of the backend code, so that's a much easier possibility.

I'm curious what the installer UI is going to look like for Silverblue, considering its going to be rebased on CoreOS which uses coreos-installer + ignition, and has no graphical interface at all. To what degree that's relevant vs out of scope, I'm having difficulty grasping. The more conventional Workstation and its Silverblue variant diverge, the less certain I am about the transience vs persistence of today's decisions.

The Silverblue plans here are to use Anaconda - to be aligned with Workstation.

The Silverblue plans here are to use Anaconda - to be aligned with Workstation.

https://pagure.io/fedora-workstation/issue/54#comment-619667

If the WG felt strongly about it, we could maybe identify some high-level goals and have a conversation with the Anaconda team about what the best path forward might be?

I'd say we want three main improvements from anaconda:

• Hide the hub when doing a Workstation install, just take the user through the spokes. It doesn't seem hard since the spokes wouldn't really require changes other than to add a mode where we have a Next/Forward button in addition to the Back button, and change the Back button to go back to the previous page instead of back to the hub. This would be a simplified installation path, not a radical design departure and not even something that would have to affect other editions or products.
• Dramatically simplified Installation Destination page (need to ensure nontechnical users never enter advanced partitioning, need only one way to do advanced partitioning rather than two, need to avoid technical terms like "blivet-gui" in the nontechnical path). This will probably be by far the hardest part, since I don't know what the result would look like.
• Nicer final page (installation progress page), #48

I know there's some resentment of anaconda design decisions and some interest in exploring alternate installers, but I really doubt this would be the ideal path forward for Workstation. I think we just need improved coordination between anaconda team and desktop team to ensure we have a shared design vision.

I'd say we want three main improvements from anaconda:

The other major goal I have is better integration between the installer and the desktop session, so that Anaconda runs in a locked-down shell session, and we have a nice smooth process for rebooting after installation is complete.

Yeah good point. It can be very confusing for the user that the live session doesn't end when install completes. You can even start running the installer again!

One issue we have right now is that gnome-initial-setup skips a bunch of steps (language, input sources, etc) if anaconda has run, but we don't have any guarantee that the user has gone through those steps at the installer stage.

My case is that I missed out input sources in the installer, and then found that I couldn't type when I got to setting an account password in initial setup.

I know there's some resentment of anaconda design decisions and some interest in exploring alternate installers, but I really doubt this would be the ideal path forward for Workstation. I think we just need improved coordination between anaconda team and desktop team to ensure we have a shared design vision.

For what it's worth, I actually think the Anaconda installer is fine. Anecdotally, I've seen that it's very easy for people who don't install operating systems regularly to understand. It drastically reduces their cognitive burden and still gives them the opportunity to make choices if need be. My only real complaint with Anaconda is that it's hard to tell what are buttons and what aren't, since there's no gradients, borders, etc. to tell you. Also, having the "next"/"done" button on the left instead of the right for LTR languages is very odd.

Beyond that, I think we actually have the best installer experience.

My case is that I missed out input sources in the installer, and then found that I couldn't type when I got to setting an account password in initial setup.

You went through anaconda without typing...?

Beyond that, I think we actually have the best installer experience.

FWIW I agree that anaconda is pretty decent when compared to almost all other distros' installers (with the exception of Ubuntu IMO), but historically there have been a lot of complaints from desktop developers about the hub/spokes model. If the WG doesn't want to pursue a simplified installation path, we can just close this issue. More important is simplifying the storage configuration page to avoid user confusion there.

We also need to ask about a mechanism to customize the "full disk" encryption option in the default partitioning path. Maybe hide it? Maybe redefine it to mean "Google fscrypt+ext4" with master key sealed by the TPM? We don't know yet what we're doing with encryption, but all the alternatives to Anaconda's current option cause a conflict of some sort.

What's the next step? Invite Anaconda folks to a future meeting once we have an agenda? @jkonecny

Hi everyone.

I'll start from the beginning.

cataranzo wrote:

I know there's some resentment of anaconda design decisions and some interest in exploring alternate installers, but I really doubt this would be the ideal path forward for Workstation. I think we just need improved coordination between anaconda team and desktop team to ensure we have a shared design vision.

First step in this direction would be to have at least one of us (Anaconda developers) in the discussion from the start. You can save a lot of time that way.

aday wrote:

I'd say we want three main improvements from anaconda:

The other major goal I have is better integration between the installer and the desktop session, so that Anaconda runs in a locked-down shell session, and we have a nice smooth process for rebooting after installation is complete.

We're just discussing a possibility to use gnome-shell instead of metacity for Anaconda installation environment. That way we would be closer to the workstation. This transition may or may not work, nothing is decided since we’re still researching this and it may require changes from Anaconda and Gnome Shell too. Using Gnome Shell for net installations should improve the current situation.

To all:
The current UI was created by the UX expert who published all the research and mockups on her blog so the community was able to help and react to the design process at every step.
We are investigating options of introducing a new UX in the future, but this is not a short-term goal right now.. Reasoning around this is because new Anaconda backend will allow us to control Anaconda remotely. We don't know yet how the UI will look or when it will be done but right nowthere is no reason to change the current one if it works and there are plans to deprecate it.

If you are interested in the process of UI creation we want to follow the same steps as before. Publish everything around the process and give that to community to find the best solution. Please be assured that the community will be involved.

We also need to ask about a mechanism to customize the "full disk" encryption option in the default partitioning path. Maybe hide it? Maybe redefine it to mean "Google fscrypt+ext4" with master key sealed by the TPM? We don't know yet what we're doing with encryption, but all the alternatives to Anaconda's current option cause a conflict of some sort.
What's the next step? Invite Anaconda folks to a future meeting once we have an agenda? @jkonecny

We can definitely meet. It would be great to also involve @vtrefny because if I understand it correctly it is a new storage requirement for Anaconda.

What's the next step? Invite Anaconda folks to a future meeting once we have an agenda?

My suggestion would be:

1. WG discusses this and agrees on what its own priorities are
2. A subgroup of the WG then has a call with some people from the Anaconda side, to discuss the priorities and any future work that we want to plan
3. The subgroup reports to the WG as a whole

Issue #85 could be relevant to this issue...

Based on the feedback from Jiří, and given that WG members not left much feedback regarding the hub/spokes design in this issue, I suggest we close this issue. If more WG members feel strongly about this issue, then it would make sense to continue tracking it, but I'm not sensing that here. And changing this doesn't seem like a high priority relative to the issues below. Thoughts?

Dramatically simplified Installation Destination page (need to ensure nontechnical users never enter advanced partitioning, need only one way to do advanced partitioning rather than two, need to avoid technical terms like "blivet-gui" in the nontechnical path). This will probably be by far the hardest part, since I don't know what the result would look like.

This is important. I've just created for #132 to track this separately.

Nicer final page (installation progress page), #48

Already tracked in #48.

Agreed: WG to close this issue, let anaconda designers decide how to design anaconda. But #48 and #132 remain open.