In January, we published “Anaconda is getting a new suit” to let you know that we’re looking to modernize and improve Anaconda’s user experience. Before starting the redesign work for the Anaconda installer, the team reviewed user feedback and usability study data that we’ve gathered over the years.
The old “hub and spoke” suit
In the current installer, the “hub” is the Installation Summary screen, represented in Figure 1. Spokes are the specific tasks that users access from the hub screen, e.g. “Language Support.” Setting up the installation requires repeated trips to and from the hub screen.
We sorted the feedback into high-level groupings. One of the larger groupings focused on the current installer navigation model, often referred to as “hub and spoke.” In a “hub and spoke” model, the summary screen, known as a “hub”, is the central point. Individual configuration screens are known as “spokes”. The phrase is commonly used today for airport connections because passengers often have to change flights at a central airport—or hub—instead of flying directly between two airports.
Figure 1. Example Installation Summary screen.
Users let us know that using this navigation model to complete the installation setup is confusing. People are having difficulty understanding the selection options on the hub screen and determining which spoke steps to take to complete the installation setup.
The new wizard suit
We want to make sure that the install experience is easy and approachable for anyone to use. After reviewing the pros and cons of alternative solutions, we determined that a wizard could offer the type of workflow guidance that users expect. It supports a guided, step-by-step, workflow that allows users to focus on discrete tasks. A wizard helps to break down otherwise complex tasks into a series of small, simple steps. Another advantage to using a wizard navigation model is that users generally understand that model. Wizards use used widely in a variety of software packages.
To create the wizard-based installation experience we’re using PatternFly, an open source design system. You can learn more about PatternFly and see an example of the wizard component in the documentation.
Figure 2. Example draft Installer wizard screen.
We’re still in the early stages of design, but we wanted to share this fundamental decision with you. There will be more updates to come, and we’ll keep you informed of those as well.
Finally, we plan on conducting a usability test of the installer. If you would like to participate and help influence the install experience, sign up for Red Hat’s user research opportunities.
Just a quick q - the underlying model is still kind of queue based right, so the user can go back and change things and nothing is commited until they get to the final step?
It’s my understanding that the basic architecture is the same, with a first part which generates the configuration and the second which executes it. I think it’d be a big regression otherwise.
Yes, as Matthew said.
We are looking on a way how to make most of the steps optional so you would be able to skip them and make the wizard shorter for you. It should be also possible to revisit your steps and change them as needed. Of course we have to sort out raised issues like dependencies between screens.
Yeah — one of the key ideas behind the hub-and-spoke idea was to make it quick to skip things that you don’t actually need to go through. My observation has been that in practice many people don’t actually realize this, and feel like they are asked to do more work by visiting each screen manually.
I’m sure that could be improved with hub-and-spoke still, but I also think that hub-and-spoke makes more sense when there a lot of different possible options. A ten-page wizard is a terrible experience, and (once people understand the “visits are optional!” concept) hub-and-spoke clearly better. But (in Workstation in particular) we’ve steadily removed options, which I think tilts things towards the linear approach.
I’m curious how optional steps will be presented in the new UI. Particularly, I’m interested in these problems:
And… I didn’t mean to turn this into an interrogation. I’m genuinely curious.
In the current setup, I’d suggest “Root Account” definitely falls under this, as does the not-pictured-above “Which partitioning system do you want to use?” page. And Installation Source, Software Selection, and Network & Host Name might too for some of our audience. ↩︎
Sorry if this is a dumb question, but I couldn’t find the answer anywhere online. With Fedora’s often upstream-first approach, why is not an existing installer being used and improved - for instance Gnome OS’s installer or Calamares?
Is it something to do with remote install requirements and CoPilot?
New installer looks awesome though either way. Just curious and thank you!
The draft only shows the language selection and compares to the hub-and-spoke main interface. It will be great to actually show the current language selection (with the keyboard selection) for a fair comparison and then propose the new interface.
Hi, I would say there are two important reasons to that.
First, Anaconda is much older than these two so it’s a bit of inheritance from the past.
Seconds, our users are depending on features which are not covered by the alternatives.
It would be hard to switch because of what the users are used to use mainly.
As I wrote, we are currently looking on a way how to implement that correctly. So I can’t really answer your questions but they are definitely valuable feedback.
Thank you for the clear response! That makes a lot of sense. Hadn’t thought of the long tail of features that Anaconda implements that others never built, but users depend on.
I might even put it this way: Anaconda was first released in 1999, and it’s been open source ever since. The big re-architecture/rewrite started in 2013 and landed a year or so later. That’s got some quirks, but is a nice, flexible design that the upcoming “new suit” is still built on top of. Calamares was started in 2015, and I think the GNOME OS installer even later. Why didn’t those projects use the existing Anaconda?