Remix of Cartoon Rattlesnake by Sirrob01, Spray Paint in Action by Guillaume W., and Tango Drive Hard Disk by Warszawianka on OpenClipArt.
Yes, that is a snake spraying RAID onto a pile of disks.
So I think out of all of the feedback we got about the Anaconda UI redesign, the one piece of the UI that’s received the most negative feedback is the RAID configuration piece of the custom partitioning UI. The designs for how this UI ended up getting implemented in Fedora 18 was posted to this blog in December 2011. I really wish we’d received the level of feedback we received post F18-Beta and post F18-GA at that point, so the design could have been modified before it was implemented! That being said – I’m not placing blame with anybody but myself – I got this design wrong, and for that I am sincerely sorry.
The initial design
The idea behind the initial design was to not have a simple dropdown with a list of RAID numbers, because we found in our research even trained sysadmins don’t tend to remember what every single RAID level means or which one is best for which situations. When you don’t have RAID on the brain, and you’re trying to make a decision (not just looking for a specific RAID number because someone told you to, which is a fair use case), such a dropdown as shown in the bottom left might read like the one on the bottom right:
So I wanted the design to have some more contextual guidance as to why you’d turn on a particular option or not for a given situation, for folks who have a lot on their minds and don’t have reference materials handy to look up which level they need. This is what that initial design looked like:
This design didn’t work on a number of levels. The first issue is that the most common nomenclature for RAID configuration is the RAID number, and while there is an indicator on the screen that updates depending on which RAID ‘features’ you check on or off, it’s not very visible/apparent and needed some more prominence so it was visible. The other issue with the design is that in trying to keep the text sparse (and not being able to make changes past string freeze), some of the terminology is confusing. For example, many folks missed that the ‘distributed’ and ‘redundant’ checkboxes referred to how parity was handled. Higher up there is a ‘redundancy’ checkbox meant to refer to mirroring – the ‘redundancy’ and ‘redunadant’ checkboxes ended up causing confusion.
The design seemed to fail for two important types of users – junior sysadmins who were told (perhaps by a superior or by a policy document) to set a certain RAID level by number (e.g., RAID 10) and who didn’t totally understand all that meant and just wanted to set ‘RAID 10’, and RAID experts who knew what they wanted but found a lot of cognitive dissonance in the way the checkboxes were arranged and the terminology used for them.
Stephanie and I first decided to think about redesigning this by providing a way to select a specific RAID level in addition to the feature-based checkbox system. Stephanie put together some mockups to show what that might look like.
Here’s her mockup showing how it would look for the by-feature part:
And here’s her mockup showing how it would look for the by-RAID level part:
We sent these mockups with a bit of a background of what we were trying to do to Doug Ledford, who is Red Hat’s resident RAID expert. He came back to us with extremely useful and detailed feedback as to how the feature-based portion of the UI conflicted with how RAID experts think about RAID, and gave us some suggestions for a better hierarchy and contextual information to organize the features by in the UI. I took a lot of the points he made in his feedback and transcribed them to a working wiki page for the redesign effort here:
Last week Dave Lehman and I went through Doug’s feedback and walked through how it might translate to actual UI. Doug suggested the following tree structure for organizing the RAID levels:
- Redundancy-Based Fault Tolerance
- Drive Mirroring (RAID1.)
- Drive Striping with Redundant Copies (RAID10.)
- Parity-Based Fault Tolerance
- Single Disk Failure Tolerance (RAID4 or RAID5.)
- Two Disk Failure Tolerance (RAID6.)
- Non-Fault Tolerant Array (RAID0, or striping.)
He also suggested that we should include options for the following essential things:
- Drive selection – we actually already did this; you have to press the ‘settings’ icon when you have the RAID device selected on the left-hand-side of the screen to select disks. Since selecting disks is important to RAID configuration though, we decided to provide a place to click on right in the RAID UI as well that would bring up that same disk-selection screen.
- Spare allocation – this had been possible in previous versions of Anaconda and had been left out of the new design, so we agreed it needed to be added back and we added it back in the mockups.
- Array name – this actually was already possible to set; there is a ‘name’ field on the right-hand side of the screen where you work on the RAID device. Our assumption was that the mockups we sent Doug didn’t have this field (Dave had added it and we forgot to update the mockups before sending them to Doug.) So no change on this one.
So I came up with a set of new mockups based on Doug’s feedback. I’ll walk you through each:
Redunancy-Based Fault Tolerance
- So the main pivot point in this UI is a drop down where you pick the type of fault-tolerance (if any) you want in your RAID array.
- The mockup above shows what the UI looks like if you pick redunancy-based fault-tolerance. There are two RAID configurations under this category – RAID 1, which is simple drive mirroring; and RAID 10, which is mirrored striped disks. Each configuration has a name to indicate what it actually is with the RAID level in parenthesis following the name. It also has short (as short as I could make it, but we’ll probably try to tighten it up further for our German-speaking friends :)) descriptions of the pros and cons to the individual RAID levels, and a note showing how many disks are required for the setup.
- You’ll notice in this first mockup, we have 2 disks selected for the array, so we can’t select RAID 10 – it’s greyed out because it requires a minimum of 4 disks. The 4 disk requirement is also marked in red so it grabs your attention – that’s why the selection is greyed out.
- The notification that you have two disks selected for the array is a link, and if you click on it you’ll get a summary of the disks that are part of your array with the option to add or remove other disks.
- In the lower right corner has an area to set a particular number of spares. Since this mockup shows a scenario when you have 2 disks only, this area is greyed out because you don’t have any spare disks to configure spares.
Parity-Based Fault Tolerance
- Here in that dropdown you can see ‘Parity-Based’ fault tolerance is selected. There are three RAID levels that fall under this category – RAID 4, RAID 5, and RAID 6.
- In this scenario, you can see from the link in the bottom left corner that we have four disks selected for the array. Since the 3 RAID level options we have all require 3 disks, the spare configuration widget is now lit up: we can configure up to 1 spare using it.
No Fault Tolerance
- This mockup shows what the screen looks like if you decide to not have any fault tolerance. This gives you basically one option: RAID 0. One thing Dave and I talked about with this one is whether or not it should have a radio button. Dave felt it was more clear you were making a selection with the dropdown to show the radio button there, as vestigal as it may be. I’m a bit on the fence – my initial mockup of this screen didn’t have the radio button. I think we’ll try it in practice and see what kind of feedback we get and go from there.
- RAID 0 doesn’t support the concept of spares (you’re just striping data, there’s no mirroring) so instead of showing the spare configuration widget here, there’s just a note saying that you can’t do that. 🙂 The note is where the spare widget normally is so hopefully that’s where the user would look if they, for some reason, found the need to set spares on RAID 0 and didn’t know you can’t do that.
Disk Selection Screen
This is the same screen you get today in anaconda if you click on the ‘settings’ icon in the left-hand pane of the custom partitioning screen. Just showing it here so you can see what it should look like when you click on the link in the lower left corner of the RAID UI – basically, that same old disk selection screen.
What do you think of this latest redesign of the RAID screens? The one negative side I will put out there on it is that it is an awful lot of text. We do have a lot of room on the anaconda screens, though (although we’ve been talking about potentially capping the screen resolution since travelling miles from one side to the other on nice graphic hardware isn’t fun.) I’m worried about translations for this text too since it’s pretty technical and it may balloon a lot once translated.
Other than that, I don’t see any huge downside to it. What do you think? Is this an interface you think would work well for when you want to configure RAID?