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:
- Get lots of users!
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):
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:
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:
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!