Making Fedora easier to use & the Installer UX redesign

The Point

Computers should change peoples’ lives for the better and software freedom is an essential component in doing that. Making Fedora easier to use, I believe, will help because I think Fedora’s values lead to the right approach in meeting our essential need for software freedom.
Fedora doesn’t follow a model of:

  1. Get lots of users!
  2. ?????
  3. PROFIT!

I don’t think the ultimate goal of Fedora is world domination, either. I think it’s world collaboration. 🙂 The end game isn’t to get as many users as possible; it’s to get as many productive contributors as possible to all free software and free culture. This is pretty well reflected in Fedora’s vision statement:

The Fedora Project creates a world where

  • free culture is welcoming and widespread,
  • collaboration is commonplace, and
  • people control their content and devices.

So this is a picture that I think represents what you work on if you work on Fedora. If you consider yourself a Fedora contributor, you’re involved in enabling other folks to succeed in least one of these areas (My apologies for components which may be represented out-of-scale):

(Inkscape SVGZ source)
The widest chunks are using Fedora and contributing.
Use Fedora is wide because we need to build, maintain, and improve on Fedora the OS itself to deliver free software; this is the day-to-day work of upstream and downstream developers, QA, and packagers. It’s also the day-to-day work of folks who support those who use Fedora; release engineering and infrastructure in delivering updates, the documentation team and folks in the forums and IRC who help users.
Contribute is wide because we need to support the folks who develop, build, test, design, market, and spread Fedora the OS – they need infrastructure to realize their goals, they need communication channels, they need tools, they need motivation and support.
Now, you could immerse yourself in the cycles of using and contributing. You could. Honestly, many folks do this day-to-day and leave the other pieces to other teams (marketing, websites, ambassadors, events, etc.) That’s fine; it’s a large complex system and you can’t worry about all pieces at all times. I do not think you can just drop the outreach portions of this system, though – leaving it to chance and not thinking at least a little about a strategy for which users you want to recruit and why. I worry a lot about this. Without exposure to ideas from fresh faces, without sanity-checks, and without new recruits to replace the turnover, I think you either shrink over time or stagnate. Either in our case would negatively impact our ability to recruit more contributors, our ultimate goal:

(Inkscape SVGZ source)
This idea has been illustrated and discussed previously, in slightly different forms in the Fedora community before. Basically, we should actively and strategically recruit new folks into our community to grow our userbase and thus our potential contributor base.

Achieving the mission sustainably

The Fedora Project Board has over the past few years done a lot of work to define Fedora’s strategy, including its user base and basic goals:

Fancy-pants documents! You might think we then all set them upon the fireside trophy shelf^W^W^W wiki, revel in a job well done and how fancy our pants are, and move on with our lives. Actually, these are documents that we can use to make decisions about how to keep our community sustainable, and how we should pave the way for new users and contributors to get involved in the project. What – how? Here’s a few examples, one hasn’t happened yet, one has, one is in progress and is the topic for the rest of this post:

  • Alex Hudson started the Fedora Welcome SIG initiative, to “work on the ‘new user experience’ for those people coming to Fedora for the first time.” Using the user base as defined by the Board, the Welcome SIG could talk to various members of that user base, get feedback on their initial encounters with the Fedora community, create a list of the issues identified, and start formulating plans to attack them. I could see this SIG acting as a cross-functional group that coordinates improvements on the beginner user experience with the teams responsible for each of the components involved.
  • The Fedora website redesign, which began in 2009 and was coordinated with the Fedora project board, was part of the rationale for designating a user base with which the redesign work could take place. The target user was referenced frequently throughout the design process and understanding who we were designing the page for helped us make decisions about how to structure the site and the kinds of information that needed to be on it (and what didn’t belong there!)
  • The installer UX redesign, to which the rest of this post is devoted. 🙂

Here’s that diagram again:

(Inkscape SVGZ source)
If you want people to try Fedora so they can use it and so they can eventually become a FLOSS contributor, they need to be able to find and download it in the first place. The Fedora websites team and design team, with the website redesign project, hopefully made it easier for our user base to find the right download and to obtain it via our website.
Helping our user base access the installation media isn’t enough, though. They have to be able to make it through the installer to the other side! Those gaps in the diagram – each of those is a bail-out point. If they can’t make it easily through the installer, a member of our user base may well give up on Fedora.
So there is a very long justification for examining Fedora’s installer, but hopefully the backstory and context here gives you a better understanding of the approach to the design process that follows.

The Anaconda UX redesign – some history

The basic gist

So Fedora’s installer, Anaconda, is something we talked about a complete UX redesign for this past January at FUDcon Tempe. While we ended up getting a little stuck on the spins aspect towards the end, Will Woods brought up an idea during our brainstorm that led us to this:

I think is pretty brilliant of him to have led us this way, which is essentially a hub & spoke model for the UI. (Since I’m telling this tale in chronological order, you’ll have to wait for more details on this brilliance later.)
After FUDcon Tempe, I thought it would be a good idea to both understand where the installer is at today, and explore a bit about where we might want it to go.

Where the installer is at today

The installer today is a linear, wizard-style interface with many screens (depending on the path you choose, and if you count the firstboot and TUI screens you might encounter ~30 screens). Once you accept the partitioning scheme, you’ve gone beyond the point of no return and you can’t go back in the installer. So there isn’t a way to get an overview of all of your choices before pulling the trigger. Below is an (quite aged at this point) diagram of the installer flow sans firstboot from Fedora 11 so you can get the gist:

To understand where it was at (which was at the time, pre-F15), we did a couple of things:

Some early design work happened as well:

  • Looking at some of the things that came up about syslinux, I put together some mockups for improvements in the syslinux layout that precedes the installer, and hpa from syslinux upstream helped me figure out how to theme it all to have a clean look. There’s a pretty in-depth writeup here.
  • The Anaconda Comic (part 1) was put together. The thought was mocking up a potential user experience for Anaconda in terms of a comic strip with a user’s narrative and goals could help us think through the experience without getting bogged down in individual screen layout and details. I’m not so sure it turned out to be a useful tool, though.
  • Luya worked on some visual design ideas.

So leading up to and since FUDcon Tempe, a bunch of exploratory kind of design work and thinking has been going on, but we didn’t really reach a full coordinated design effort yet.

Kicking off a coordinated design effort

So the installer UX redesign is currently planned for Fedora 17. Fedora 15’s out – time to get cranking. Maybe 2-3 weeks ago, Chris Lumens told me we should ramp things up again, so I’ve been working with the design team (including a couple of new UX recruits!) on an overall plan of attack with some execution thus far.

The Anaconda UX redesign plan

The hub & spoke model

So our current thinking, right now (which generally occurs both in the #anaconda IRC channel as well as the on the anaconda-devel mailing list) is that we would use a two-hub hub & spoke model for Anaconda’s UI:

  • Since the UI is rather useless if you can’t read it, we would start out with a language screen where you can pick out your language in its native name.
  • Next, you’d be brought to the install summary hub (hub #1). This hub will have sane defaults everywhere where possible (we’re not sure on the storage section yet) with the goal that you could just skip diving into any of the options, press continue, and get a usable install (again, not sure on how storage works there 🙂 ) The spokes of hub #1 are choices like keyboard layout, storage, date & time, install source, and Fedora flavor.
  • Once you click continue on hub #1, you’ll be brought to the install progress screen which is also the personalization hub (hub #)2. This hub has an install progress bar along the bottom, and a series of rotating banners (‘ransom notes’) above that. The hub will have personalization options in it by default – the stuff you get asked in firstboot like if you want to register for smolt, what you want your user name to be, etc. It could also have OEM or other custom modules. You can completely skip filling any of this stuff out and go get a sandwich (or hot dog.) When the install is complete, you may reboot.
  • When you reboot, if you filled none of the personalization hub options that we need to know, you’ll be presented with them again as a firstboot experience (we kind of need to know your username to make you an account, for example.) If you did fill out what we needed to know in anaconda, we won’t show you firstboot and you can get straight to business using Fedora.

What is pretty cool about this model is that if we’re able to pick the settings for hub #1 right (and yet again, not sure if that’s possible without breaking storage out into another screen), you could skip all of the options in the hub, click continue, and get a sane install. It essentially lets you skip multiple screens in one click. It also serves as a review or inventory of everything you’ve chosen, making it easy to skim over everything and dive down and modify something before pressing go. To change something you already selected in the current linear installer interface, you have to go “back… back… back…. back….” and sometimes you hit a, “back… back… oh crap, I can’t go back past this point” type of situation.

We also have a tension in designing for Anaconda that it does not only serve as the installer for Fedora, it serves as the installer for other distros with different user bases such as CentOS, Red Hat Enterprise Linux, and Scientific Linux. Users of those distros are more likely to care, for example, about specialized storage devices that most Fedora users probably don’t even have access to or care about using in an install. The hub and spoke model is a compelling approach here I think because we can serve Fedora’s users who might not care to tweak EVERY knob available by providing clear overviews with the option to dive in a level deep where they have interests. For users who must access very particular granular knobs to achieve their goals, though, they still have access through progressively deeper dives down a particular spoke.
Well, that’s all of our latest thinking. It could change. It’s a design. 🙂 If we discover through some user research, for example, that some idea here is problematic, or if we run into a technical snag, the gist of our design described thus far may change. That’s okay. We want our installer to rock!

The design process

I´m serving as the lead designer of the project, with some help from other Fedora design team members:

  • Joseph Reni (gejoreni on IRC), has put together a draft user research plan for both an informal study interviewing users and a more formal observational study sitting in front of a system running through an actual install. Please send him your thoughtful feedback and encouragement!
  • Owen Coutts (ocoutts on IRC) has started working with us on the mockups and developing user stories. He’s spent some time surveying several OS installers including Windows and Apple’s to help inform the design process and to see how other OSes handle the process.
  • Elad Alfassa (elad661 on IRC) who is already a rockstar on the websites team and a
    Hebrew translator for Fedora; he´s been reviewing the mockups from a localization POV as well as helping with the storage section. He’s been cranking out some serious hub & spoke mockups with me and asking the Anaconda devs tons of questions and generating a lot of great discussion.
  • Luya Tshimbalanga (finalzone on IRC) who has done some good work on visual design for the installer on the past and is going to help us with that aspect of the process.

This is a huge project and I think a lot of issues and edge cases will come up as we least expect it. The approach I’ve proposed to the team is:

  • Myself, Owen, Elad, and Joseph as he has time/interest will continue building out a full set of screens in the hub and spoke design. This is the latest PNG mapping of the screens; the SVG sources are in the same directory.
  • As any of us designers run into issues/questions or need feedback on our mockups, we´ll pop into #anaconda for discussion/brainstorm.
  • As discussions / brainstorms happen in IRC and here on-list, I´ll try my best to distill them into notes that will be added to so we don´t lose any of the decisions we make / rationale discussed (and I’ll save the IRC logs to the ‘Notes’ directory in the repo)
  • Once we have a complete set of mockups, the set will be marked draft 1 and we’ll start writing up a spec / design document for it (<like what was done for the storage UI mockups).
  • Joseph will continue working on a user research plan and as his data comes in all of us can pull it in and apply it to our latest thinking & designs.
  • As necessary, we’ll compare the list of user complaints gathered on the main Anaconda UX Redesign wiki page, potentially also going through Bugzilla, to make sure the mockups cover or at least have a story for
    the user issues, noting issues we still need to work on.
  • As necessary, we’ll also print out the mockups and do additional user testing on them (likely using a paper cutout method), noting identified issues.
  • As necessary, we’ll also blog the mockups & design process to get additional feedback from you all!
  • As we address issues uncovered in user testing and user complaint review, we’ll release additional drafts of the mockup set. Based on the storage mockups process, we may hit 6 or 7 drafts.

Following the brainstorming and the overall process

So the action is taking place here on a number of fronts.

  • Anaconda’s IRC channel has been having many pretty lively discussions about this design; both myself and Elad have been pestering the developers with lots of questions and we’ve all been brainstorming together. We’ve been trying to keep a summary / distillation of these discussions available in the wiki because we want our decisions well-documented for later reference:
  • Anaconda’s development mailing list has a thread that was started last Friday that’s still going on, so you might want to follow along on that list.
  • Our main UX redesign wiki page (at is a bit messy at the moment but I’m hoping over time we’ll get it in order. It has many of the documents referenced in this post and more, and is really the main hub of our design documentation.
  • We have a design repo which is a shared file space Elad, Joseph, Owen, Luya, and I are using to collaborate on mockups (via Sparkleshare). Mockups will land here first, before we use them to put together spec documents (like this one.) If you’d like to use git to pull it down, you can clone:

Okay, okay. Wow, that was long. But it sounds cool. How can I help?

If this sounds like an interesting project and you’d like to get involved but aren’t sure how, here are some ideas. These are all things that would be very helpful for us that are probably a good way to get started in on the project:

  • Review Joseph’s user research plan and give him some constructive feedback and encouragement!
  • Send Joseph any questions you think he should be asking folks in Fedora’s user base. Send him your research questions as blog comments and he’ll be happy to integrate them into his plan.
  • We need ideas for good ransom notes. We’re going to try to bring back the concept of ‘ransom notes’, little rotating banners that display while the install progresses. An oldie-but-goodie beloved by many is shown below as an example. We’re looking at potentially a 750 x 120 px format.
  • Participate in our brainstorms on the anaconda-devel list or in the anaconda IRC channel, but please, keep it civil and constructive!


  1. bochecha says:

    One thing that might make the Anaconda UI drastically simpler (at least when installing a Gnome Desktop) is the fact that Gnome is trying to integrate a "first time setup" in GDM:
    – Feature page:
    – Discussion:
    – Design:
    This means you could remove:
    – The hub#2 customizations
    – Firstboot
    Of course, this would still be needed for other desktops and other types of install.
    On the mockups now, that really looks great! Choosing sane default and making it optional and easy (rather than mandatory and painful) to review and change them is a huge win.
    I only have one minor nitpick: I don't like the "Register system" button label. The term "register" is IMHO too much associated with this thing you have to do when you use proprietary software, where they ask you a lot of information and make sure you use a genuine and legally obtained copy.
    I'm a bit worried that users might think this is what is going on. :-/

  2. […] mairin Posted by Bez kategorii Subscribe to RSS feed […]

  3. Hi,
    Can't the images be SVG so they could be scaled depending on the display size? Will adjust well to tablets and desktops.

  4. Ho, the new Anaconda design really rocks. You are geniuses. Great works.
    The new Anaconda design is clear, without unnecessary points: just brilliant!
    I have some comments, to you to judge if they are relevant or ridiculous:
    – For the first screen, I think we can have a less width list of language and a second list, on right to the lagnuage list, to sellect the country. So we can have a better default setting for keyboard layout and time zone if Anaconda know also the contry.
    – For the drive setting, in the Install hub:
    – If it are multiple disks, default settings sould be install Fedora on the fastest disk (HDD >= 7200 rpm, SSD, etc) and users folders (/home) on other disk.
    – If they are 2 identical drives (same speed, same size), default settings sould be RAID 1 (one seeing by OS, but two drive in mirroring)
    – If they are 2 drives with same speed but not same size, default settings sould be RAID 0 or combined with LVM
    – If it are other OS already installed, default setting should be keep other(s) OS and install Fedora with them.
    – Able to choose between personalize on the installation process or on the first boot is great. That's exactly what I expected. But in the solution exposed in your article, you need to explain to user that if he don't personalize during the installation process, it's can be done in the first startup.
    – For the Personalize hub, If the computer have 16/9 or 16/10 screen, it would be great to have options and installation progress bar on the left side and rotating banners on the right side. With this, we can have more big banners and the options zone is not too small on narrow screen.

  5. DDD says:

    I think that it is worth checking out the competition. Both Windows 7 and MacOSX have really nice installation interfaces these days. Fewer features of, course, but it would be useful to see "side-by-side" experience…

  6. Roger says:

    One thing that struck me is that the scrollbar appearance differ between the language selection list in page #1 and the hub scroll list in page #2 and page #3. But I guess that is why they call it mockup 😉

  7. Long but informative.
    A feature you might want to copy from Pardus is the one that allows the installer to be rebooted if there is a problem without rebooting the computer. It's really nice.
    See my post about it at

  8. Jerome Haltom says:

    Awesome post. But Andrea is smarter than most people I've ever worked with. I work with people who don't have a 401k, because the rapture is right around the corner.

    1. Jerome Haltom says:

      To clarify. Andrea seems to know that Windows is on her computer. She in fact seems to know what Windows is. Or at least have some idea. The majority of people I deal with could not even make that leap. That she has some concern that she won't "delete her data" shows that she has some conception of what her data is. Or where she keeps it. Most of my people hit Save, and leave it in whatever the default location is.

  9. "Fedora doesn’t follow a model of:
    Get lots of users!
    You're too funny 😀

  10. I fear all this emphasis on hot dogs will turn down potential vegetarian contributors 😉
    The concept looks great, though! Keep up the great work!

    1. The meaty secret is that it's actually a veggie dog 🙂 I'm a vegetarian!

      1. rolandixor says:

        thats it! I'm switching to Haiku! 😀

    2. I'm not a vegetarian, but my vegetarian friends have never complained :)…

  11. One obvious improvement would be to integrate the "back up my files" step into the installer. It don't imagine it would be all that difficult to mount the Windows disk, display a selector between "Everything", "Only user files", "Let me choose (-> dir browser)", and "Don't backup anything" and prompt to insert a USB drive > space-used…
    Obviously you'll need a CYA warning on "only user files," and future versions could trawl the disk and pull in anything interesting (PDF, XL, Word, savegames, etc.)

    1. It would be cool. An entry on the Install Hub. No backup by default, but if Anaconda detect anorther OS already installed, the entry have a warning logo.

      1. The problem is, it's hard to implement such thing, because users would want to backup their files before doing any partitioning changes (because that's the only place with data loss risk). Now, if we didn't set up partitions, we don't have space we can keep the backed-up files in, unless the user connects another drive which he isn't going to use for the installation, but just as a backup space.

  12. John Vilk says:

    I originally wrote a novel-length comment with a bunch of suggestions/etc, but decided that I was being too nitpicky and missing the bigger picture.
    This is a great change. I've always felt that the installation process was a huge barrier to entry for new Linux users; after raving about Linux to friends, when it came time for any of them to try it out, I would inevitably drive the installation process for them.
    Here are my main concerns right now:
    1) The instructions on Fedora's website on what to do with the ISO file are (what I consider to be) a wall of text that users may be hesitant to read through.
    2) If the installation process shows Grub like in the comic, I am worried that users will not understand and will be intimidated by the menu.
    3) Install Source, while necessary flexibility for some users, may be confusing when presented as a prominent installation category. Could this be relegated to an 'advanced' option?
    4) I'm personally confused about the Synchronization category in Hub #2. I don't know what it configures, and what user data it would be syncing, and where it would be syncing to… but maybe the user would figure it out by exploring the category.
    I have some suggestions for some of these, but I figure I shouldn't overencumber this comment.
    Other than the concerns above, I'm pleased with this. I'm especially looking forward to seeing how you deal with selecting the installation destination, and software selection, since those are tough to get right imo. 🙂

  13. […] doing a UX redesign of Anaconda. All the details are in that post. You’d like to help? AWESOME. Check out the UX redesign of […]

  14. […] doing a UX redesign of Anaconda. All the details are in that post. You’d like to help? AWESOME. Check out the UX redesign of […]

  15. Raghu Udiyar says:

    Syncing user data during installation!
    That is going to be gold! Thank you

  16. […] been working on non-Fedora projects for the past few weeks, and I just started digging back into the Anaconda mockups this morning. Coming back to UI design from a slight break seemed to magnify issues that I feel in […]

  17. […] a set of concept sketches that will be used as a part of Fedora’s installer in Fedora 17, as part of our installer UI redesign effort. That’s right, your designs will be part of the operating system […]

  18. […] have a set of concept sketches that will be used as a part of Fedora’s installer in Fedora 17, as part of our installer UI redesign effort. That’s right, your designs will be part of the operating system […]

  19. […] growing more contributors for Fedora is to increase the user base from which we gain contributors. (See more discussion on this here.) A path worth pursuing in gaining more users is bettering the usability of Fedora itself, so a […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.