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:

• Defined the mission of Fedora.
• Documented the values of the project.
• Defined the objectives of Fedora.
• Formed a vision.
• Defined a user base. (I do worry that different folks interpret the user base differently, I have my own interpretation.)

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:

• A screen-by-screen walkthrough of a typical DVD install process
• A screen-by-screen walkthrough of a typical Live Media install process (quite different from the DVD)
• An analysis of the screen-by-screen walkthroughs, comparing the DVD install process to Live Media and raising questions that came up about each process with the answers documented.
• notting catalogued the various timezone sources available to us and wrote up some of the issues in the current timezone dialog; I put together some mockups for some idea on how to lay the screens out which I kind of don’t like very much anymore. Both are on the Anaconda Location Whiteboard.

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
  https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion
  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:
  https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Discussion
  
• 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
  https://fedoraproject.org/wiki/Anaconda/UX_Redesign
  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: git.fedoraproject.org/git/fedora-ux.git

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!

The problem

Background

See the screenshot above? Scary little bugger, right? Yep, there’s a few issues with this screen. We’ve received bugs on it requesting that the text be changed to be more accurate. There’s bigger problems than that, though.

Let’s go a bit into the background of this dialog. It occurs early on in the screen flow:

[ lang selection ] => [ keyboard selection ] => [ basic or special storage ] => [ REINIT DIALOG ] => [ hostname selection ]

Here’s the full order of things in the anaconda code.

The screen that asks if you have basic or specialized storage must come towards the beginning of the screen set, because it is at this point anaconda has to scan to see if any pre-existing installations are on the system in order to know if we can upgrade a pre-existing system or not. However, we don’t want to scan specialized storage devices which may be mounted to the machine if we know for sure that the user isn’t interested in using them as part of the install – it’ll take a while, it may spins up a lot of devices that were not active using more electricity, putting wear on equipment, etc. hitting a lot of networks.

• If you pick basic, anaconda just scans local devices.
• If you pick specialized, anaconda scans local devices & network storage devices. This route also gives you the option of adding iscsi and other kinds of disks that require user input to be able to discover.

There may be a false assumption here – someone may want to use specialized storage devices as install targets, in which case scanning them for upgradable bits makes sense. However, someone may also simply want to use specialized storage devices as mounted data storage, in which case we shouldn’t bother scanning them for upgradable bits.

Anyhow, once we know which devices to scan (local if basic, local+network if specialized), they are scanned and if any of them appear to have missing partition tables, this dialog is popped up.

Anaconda may not know how to read the partitions on the drive, another operating system may be able to. There *could* be data on that drive, but we just don’t know because we don’t know how to read it. The drive may very well be blank (if it’s brand-new / baremetal) or it could be a virtual drive and have no data either. So our dilemma is:

• we can’t mount the drive as a data drive if we can’t read the partitions, so it’s useless.
• we can’t use the drive as an install target unless we completely format it.
• there may be data on the drive, we just don’t know. if we reinitialize a drive that was only meant to be a data drive… we’re erasing data for no good reason.
• there may not be any data at all in which case popping up the dialog instead of just reinitializing the disk and being quiet about it without causing so much bother.

Problems

Here are the problems you can see just looking at a screen surface level here:

• The titlebar says warning. The text says error. The icon indicates a question. These are all in conflict with one another. This dialog is more of a warning dialog than anything else.
• The metadata about the drive in question is strewn all over the dialog and hard to read.
• The dialog uses the word ‘reinitialized’ and ‘re-initialized’ multiple times without explaining what it means.
• THE DIALOG USES ALL CAPS
• The dialog says that re-initializing will cause all data to be lost, but actually, it will only cause data on the drives being reinitialized to be lost, and only if there was any data in the first place (which there might not have been.)
• Four buttons across the bottom of the screen is a bit of an overload, yet if we had say 100 such devices attached to the system (slices of a network drive maybe) then we would see this dialog 100 times without those extra ‘all’ buttons.
• What does ignore do? Ignore what? Ignore this warning and go ahead an re-initialize? Wait a minute… (It actually ignores the drive in question, removing it from the set of drives considered in the install process)
• Overall, the dialog is scary, and this fright is brought up in situations that should not be frightful – e.g., you’re simply installing on a virtual machine with a virtual disk. No need for the scare!

Design Challenges

Here’s some of the things that make resolving these problems a bit dicey:

• Two classes of users who simply don’t care about this dialog and for whom it’s a waste of times / click effort are users installing virtual machines and users who have brand new hard drives. The default choice of reinitializing all soothes these folks.
• This dialog might come up towards the beginning of the installer screenflow, or closer to the partitioning screen. There are two storage device scans that happen – because some drives (like iscsi drives where you need to manually input address information) can’t be scanned for until you hit later screens.
• We need to prevent users from clicking next-next-next and destroying a drive (That they might not necessarily own if it’s networked!) by accident. This is one reason the dialog is currently a dialog rather than a regular screen. It’s difficult to remove the next & back buttons in the middle of the screen flow.
• There’s a big difference between what this reinitialization thing means for data drives vs install targets. Data drives are added in anaconda so automounts can be set up. We can’t mount a drive that we can’t read. While it sucks, it’s far less sever than the other case, in which an install target can’t be used unless we wipe it.
• We can’t move the basic vs. specialized selection screen to be with the rest of the storage device screens, because it’s the scan that takes place here that determines if an upgrade is possible (it examines the drives, looking for pre-existing & upgradeable installations.) The problem here is that it’s really not smart to just go scanning any network drives available for pre-existing installs unless we know for sure the user intends us to do that.

Questions

So looking all of this over, here’s some questions that might come to mind:

• Is the default choice of ‘reinitialize all’ the right choice? (Not sure. We make a choice here between making life easier for virt installs or making life easier for folks who don’t want to lose data. We don’t know how large these populations are relative to each other.)
• This dialog is separated from other storage-related screens. Can we move it closer to the partitioning screen? (Maybe.)
• Reinitializing currently affects all drives scanned, without any filtering by the user (besides the local or local+network drives selection). Can additional filtering be added?
• Reinitializing currently affects drives meant to be part of the install target set AND drives merely meant to be automounted to the system. Can we limit it to only install-target drives?
• If a user really cared about the data on a drive, would they really select it as an install target? (Probably not.) In that case, do we need to warn them that data might be lost if they use a drive with an unreadable partition table as an install target? We already warn them that any drive used as an install target will be wiped!

Mockups & Ideas

The radio-button approach

In this approach, we think about the different types of users who might encounter the dialog and offer those users who have any data to lose an easy way to avoid the entire reinitialization screen and its related stresses.

We only display the radio button dialog If one or more missing partition table drives are detected. If the user says the device is virtual or blank, we reinitialize it without asking. If the user says the drive had been used before or they weren’t sure, we give them the scary reinitialization screen.

Some issues with this idea is that it’s not very scalable – you have 100 drives you can’t read, you get this radio button dialog for 100 drives. Ouch. We could potentially provide a list view of all unreadable drives, but right now anaconda pops them up as it goes. It may be possible to poll all the drives first, cache the data, and then present a list, though. It’s simply not possible in anaconda right now. But with a list of multiple drives, the multiple choice selection won’t work any more – each drive might be different. Um, so maybe not the best idea – or at least, this approach needs more work.

If you remove all the drives from the install to protect them you get the last dialog – we can’t install if there’s nowhere to install to. :)

The text-massaging Approach

This is a less-weighty approach to apply in the meantime, without a lot of underlying code change. Except, oops, it does require too many underlying code changes. Right now there’s no caching of drive data, so the dialog pops up as anaconda scans drives and detects missing partition tables. So anaconda doesn’t know, until it knows, that a drive is unreadable. So the multiple list view won’t work here.

It’s a better approach than the next one though, which is more compromising to the current state of anaconda’s functionality. One thing to note here – if you have one drive that can’t be read, you see the first screen. If you have more than one drive that can’t be read, you see the second screen. So the mockups in this screen are either/or, they are not a sequence.

The text-massaging approach – simpler

This approach caused the least code churn so it’s the one we’ll go with in the meantime we figure out the larger problems here.

Note the button text has been changed – it says ‘Yes, discard any data’ and ‘No, protect any data.’ We say any data because there may not be any data at all. Saying ‘discard data’ makes it sound like there actually is data to be discarded. We say ‘discard’ rather than ‘destroy’ because it’s a little less frightening of a word I think.

Rather than having four buttons along the bottom, we have two that apply to the single device in question. For our virt-installing friends, we have a checkbox that will enable the button to apply to any such devices.

So while we have a new layout and new language, the functionality is unchanged.

Where to go from here

One idea could be to show the list of drives and ask the user if there is any data they care about on those drives, because we can’t read them and will need to erase them to use them in install. Then give users the options to remove them from the install process / protect them one-by-one with the option to check off the drives they care about the data on. (or vice-versa, check off which drives they want to use for the install.)

We originally had mocked up the latter during the Anaconda storage UI redesign – showing all the drives we found and allowing users to check off the ones they wanted. This was removed at the last minute because of complaints that we ask for too much information about storage devices in the UI. I think part of the problem is because we only worked on the storage UI, not the entire anaconda ui, so there was some redundancy or at least the appearance of such. This time around hopefully we’ll get this right since we’re looking at the entire UI.

• It can be a little difficult to identify these devices. Depending on the interconnect and depending on what information the administrators of the storage devices provide you with, different types of information are useful and some are not. For example, the vendor’s name of a RAID BIOS array may not be all that useful since multiple types of hard drives may be part of the array, but whether or not a SAN is EMC or QLogic may actually be a useful distinguishing characteristic.
• These types of devices, if there are enough of them on the network, can take too long to load into the UI.
• It can be a little bit scary to be certain of which drives are merely being mounted post-install and which are getting formatted as part of the install.

The Anaconda UI redesign mockup work is still in progress, but I’ve got a pretty good set of mockups for the first half of installation. If there are any multipath / other advanced storage device users out there, I would *love* to hear your feedback on these. Here’s a sampling to entice you to visit the full set of mockups: