Anaconda is getting a new suit and a wizard

News & Announcements Community Blog
1

Originally published at: Anaconda is getting a new suit and a wizard – Fedora Community Blog

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.

cAKP89lGbZClOLQGr5Icw9cG8ocjTvGAjcv9AC4YKI5H_taA5R-eKwj3YLVmO4M6YT8HX4buxlJEXXjYI2I-QkNHM1mCbqlPuKuhcFZ9Frf9D5hFvav3uUKArhT31L4_NhN7kESh.png1024×768 86 KB

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.

2RvA4TMwSFx-I1sxrpQ5Eh9xU7TSaDMcaGMzbmk5JSI2eW_QsK0txSAKV_1gXngQHqNrulpAoywNfm1t9RSiUPoDKam892AefgPt4zCsjt1AGeWJucf-a5WYK_Q7Oe15mZyz5lUc.png1110×846 37.2 KB

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.

9 Likes
2

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?

3 Likes
3

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.

1 Like
4

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.

3 Likes
5

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:

  • How to avoid the same problem we have now where people feel like they need to make sure all of the options are explored?
  • How do we avoid presenting options that you need expert knowledge to know if that’s even a thing you need to care about?[1]
  • Even when we’re able to present choices clearly, if there are branching paths, how do we keep progress clear?
  • How can we make sure that this isn’t tedious for people who do many installs frequently? I’m thinking particularly of our QA team and release-time testing volunteers, but maybe also at install fests and other situations.

And… I didn’t mean to turn this into an interrogation. I’m genuinely curious. :classic_smiley:

  1. 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. ↩︎

6

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!

7

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.

8

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.

1 Like
9

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.

1 Like
10

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.

1 Like
11

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? :classic_smiley:

3 Likes
12

I think the hub-and-spoke system should definitely be kept.
But for new users a “Guided Installation/Step-by-Step Installation” option should be put as the very first option (or even as a banner to grab their attention).
This should satisfy both types of users, although we could have the problem of too much bloat.

1 Like
13

It’s hard to overstate the value of simply providing a clearly-visible “Skip” button, enabled (perhaps even defaulted) from the moment you arrive at a screen, for communicating that something is optional. If It’s there and it’s prominent and it’s inviting and reassuring, people will click it. Often with a quick sigh of relief.

Whereas, by the time someone has drilled down into a screen “manually” (like from the hub-and-spoke landing page) because they felt (correctly or incorrectly) that’s what they were supposed to do, the train has sailed on them just ignoring that part of the process as optional.

There are also various models of wizard-esque design that facilitate complete optionality. Presenting a (succinct, minimal) page of “I want to configure this extra thing myself” checkboxes, for example, all of which default to disabled. Someone who knows they really want to customize something can enable the extra step for that feature, but the standard experience makes it clear that part of the process is safely ignored.

Yeah, there’s really no reason any form of wizard interface can’t still provide an “expert mode” interface that’s just a menu of all the wizard steps, pretty much exactly like the current hub & spoke, so that they can be accessed ala carte. Just because there is a linear A-B-C-D path through the interface, that doesn’t necessarily mean everyone has to be forced down that one path.

The difference can be as simple as just swapping out the “Next” button with one for “Save” or “Back”, if the user arrives at a step from the expert menu instead of the/a previous step. (The responsibility of ensuring they remember to hit all of the steps they need to is on them, implicitly, when opting into an alternative/expert mode that abandons the pre-set path.)

14

This may be an oversimplification on my end, but the way that I envision a redesign of the installer is as follows.

You start with easy to follow steps that take you through the basics of getting Linux installed, similar to the other popular installers that often come up. Then at the end of the simple process you get an option to reevaluate the settings you selected or go deeper. If you choose to do that instead of just installing Fedora, it takes you to the hub and spoke screen we’re all familiar with. At that point, the user would understand that they’re looking at a menu of options and not feel like they have to decipher steps for themselves.

So you start with a step by step design for the majority of use cases and stick with the current design at the end for all the rest of the configuration options users have come to expect. I think this is relatively similar to what others have suggested.

15

Long ago, there was an “expert / advanced” mode, and we found that this has essentially the same problem as people feeling they need to check out all of the spokes: those with the least confidence would be most likely to choose that path, and then be confused, frustrated, overwhelmed, and overall negative about the experience.

16

I have no good answers for that, except the suggestion that we rename the installer to anacondunning-kruger. It’s a lot to type, but worth it!

1 Like