Redesigning the UI for something as complex as an OS installer has the potential to be disruptive to some classes of users, so in designing and re-designing and re-re-designing the partitioning screens for Fedora’s installer, we’d like to make sure you’re going to be covered.
Do any of these cases describe you, and if not, can you let me know how you use the partitioning functionality of Anaconda or really any OS installer so I can account for your use case?
The partitioning UI thus far
What are we doing to the installer’s partitioning UI to bring us to ask such questions? What is all this redesigning that’s going on? Well, let’s talk about partitioning as it works today in Anaconda.
Note that this is a screenshot of Red Hat Linux 8.0 from 2002, almost 10 years ago now. Aside from the online help / release notes pane on the left which has long since been dropped, this partitioning screen does not look much different today.
Our partitioning UI is currently very technology-centric. I suspect users care a lot more about the mountpoint layout of their OS with the technology underneath having a less primary role for them. (What the technology does for them, such as give them redundancy for their data via mirroring or increased performance via striping, I think they *do* care about, though.) Above is a screenshot from Fedora 15 showing part of the workflow in creating a partition. Before you can create a mountpoint layout or configure your filesystems, you have to create partitions and choose what technology to use with them.
Creating partitions is a means to an end of staking out some space for your files; if what the users really want to do is arrange their filesystem as they’d like it, why don’t we let them do that first, and guide them amongst the technology choices based on what it will do for them and their files later on?
“Wait,” you may ask, “are you trying to say that the goal of a user in a partitioning UI isn’t to create partitions?” Yep, basically I am. An illustration of how configuring RAID in the current UI may help explain:
Say I did a bit of reading and decided that for me, the best way to store the data in my home directory would be to set up RAID mirroring and striping between two physical disks (AKA RAID 10). If I set out to do this, what kind of workflow would seem most natural? Would it make sense to create my home directory, dictate the (when-all-is-said-and-done) capacity I want for it (let’s say 100GB), and apply the appropriate RAID level to it afterwards?
That’s what I thought. That’s not how it works in our UI right now, though. Right now, here’s the
basic convoluted workflow:
- Delete the auto-part layout since it’s all LVM and you want to use RAID on top of physical partitions. Click click click click click click click!
- Create a RAID Partition; Give it the capacity you ultimately want (100 GB). Make sure it’s on hard disk #1.
- Create another RAID Partition, identical to the other, 100GB. Make sure it is *not* on hard disk #1 but is on hard disk #2.
- Create a ‘RAID device’, and add the two RAID partitions you just created to it.
- Set ‘/home’ as the mount point of your ‘RAID device’ and set the RAID level you’d like.
That seems a little backwards to me. You create the partitions first, then the device. Why can’t the partition manager create the partitions for me based on my specifications for the device? It also seems a bit error prone, because I think it’s pretty easy to forget to create the two partitions on two separate disks. If you don’t, your mirroring doesn’t make sense since if the hard disk fails (what mirroring is meant to protect against), both of your copies are dust in the wind! The RAID device creation UI doesn’t state which physical disk each partition is in, either, so it’s easy to miss if you did make the mistake. The other thing this doesn’t protect against is that you could quite easily, without any complaint from the interface, mirror RAID together a 1 MB partition with a 1 TB partition, and lose 1 TB – 1 MB worth of space since the partition with the least capacity dictates the capacity for the device in mirroring. Sigh.
So a while back I went over in detail our buffet-style, technology-based mockups for partitioning – we had a sense that it was not the right approach but had whiteboarded and wireframed the mockups so I thought posting them would generate some feedback on a better way. And it did, of course, because the folks who find the time to read this and provide feedback are smart and helpful. Here’s a quick snapshot of one of those mockups as a refresher (the technology-focused tabs across the top is what I consider a ‘buffet’):
A new, mount point-based hope?
This is kind of what we’re leaning-towards now. After a few iterations, I call it the RPG partitioning UI. On the left, we give you a sane default mount point set up (dictated by either your particular spin or the install class, so if you’re using a desktop you get a desktop-focused one; for a server, a server-focused one; etc.) and let you modify as you like. By default for Fedora, we’ll have a btrfs set up (not reflected here.)
Notice how there’s selectors for each mount point where you can choose the partition type (physical, btr, LVM) and you can add on options, choosing the technology you’d like for each. RAID and LVM both offer mirroring. If you have a preference as to which one you’d like to use, there’s a spot for you to dig into that. However, we present mirroring as the feature you can opt into; we don’t present the technology at a primary level anymore here.
There’s also a cost associated with some options. If you choose to mirror a 100 GB home directory, for example, you’re going to need 100 GB x 2 or 200 GB to have that 100 GB mirrored. So there’s a ‘cost’ in terms of capacity for different options. What makes this the ‘RPG’ design is that as you add or remove features from how your file system is set up, the cost (or savings) in capacity are outlined right next to each option.
The general idea we have here is that if you don’t have sufficient hardware / capacity to choose a particular option, it will not be presented to you at all. No bait ‘n switch by offering it up front and then erroring out later.
Where this mockup needs work is how we allow the user to hook up their mount point setup and filesystem configuration to physical drives in their system. And that is why I’m showing the personas to anybody who will listen to try to make sure we understand where users are coming from when they do that hook up, so we don’t lock anyone out of essential functionality they need.
So that’s that.
OMG you’re redesigning the anaconda installer?
- Why oh why are we doing this? Learn here.
- You can read lots more of my scribblings about the project in this blog’s ‘anaconda’ category.
- We also have a Fedora wiki page for the project.
- Drop by #anaconda on irc.freenode.net if you’d like to get involved or simply voice your opinions.