Anaconda Crash Recovery

Whoah! Another anaconda post! Yes! You should know that the anaconda developers are working hard at fixing bugs, improving features, and adding enhancements all the time, blog posts about it or not. 🙂 Today Chris and I talked about how the UI might work for anaconda crash recovery. So here’s the thing: Anaconda is completely driven by kickstart. Every button, selection, or thing you type out in the UI gets translated into kickstart instructions in memory. So, why not save that kickstart out to disk when anaconda crashes? Then, any configuration and customization you’ve done would be saved. You could then load up anaconda afterwards with the kickstart and it would pre-fill in all of your work so you could continue where you left off! However! Anaconda is a special environment, of course. We can’t just save to disk. I mean, okay, we could, but then we can’t use that disk as an install target after restarting the installer post crash because we’d have to mount it for reading the kickstart file off of it! Eh. So it’s a bit complicated. Chris and I thought it’d be best to keep this simple (at least to start) and allow allow for …

RAID Re-do for Anaconda

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 …

Refreshing storage in Anaconda

Remixed version of bottles by Tomas Arad on OpenClipArt. You must be thinking: “What do you mean by refreshing storage? I didn’t think you could drink storage?” No, sad to say, this blog post isn’t about the type of refreshment you get from a crisp cold glass of Anaconda Cola (yum!) It’s about the action of manually refreshing anaconda’s view on the storage configuration it’s working with. Why would you want to do that? Let’s step back a second first. The custom partitioning tool in Anaconda (Fedora’s installer) still has a lot of rough edges to the design in Fedora 18 GA. The Anaconda team has been putting a lot of work into improving it in their Fedora 19 branch. We’ve got a ton of bugs, thoughtful (and some not so thoughtful 🙂 ) comments from forums and blogposts, and some preliminary anaconda usability test data! (You’ll be hearing a lot more about that last bit soon, don’t worry! 🙂 ) The team has pored over all of this information and has had a number of brainstorming sessions and discussions on how to address the identified issues, both over IRC, the mailing list, in bugs directly, and in person. The …

Storage from a UX designer's perspective

Designing interfaces to deal with storage technologies is not only hard, it’s terrifying. This is especially true if you aren’t familiar with the storage technologies involved and have to learn how they work on-the-fly, even if you don’t have easy or any access to work with some of these (typically quite expensive) technologies first-hand. After we redesigned the storage UI for Anaconda around Fedora 12 or so, I gave a short talk at the Linux Plumbers’ Conference in 2010 to share my storage UX ‘war stories.’ We very happily have an interaction design intern, Stephanie Manuel, who will be working on putting together a usability test plan for the new Anaconda UI, courtesy of the the Outreach Program for Women. Since I need to get Stephanie up to speed on how some of the storage technologies Anaconda deals with work, I decided to provide a summary of that Linux Plumbers’ talk to make it a bit easier to access. Storage for Desktop Users So if you’re a general desktop user, there’s a few kinds of storage devices you’re pretty familiar with. Your laptop has a hard drive, perhaps an SSD (solid state disk), you likely have at least a couple …

Anaconda Bootloader, Reusing /home, Assigning partitions to disks

Bootloading So this is what the Fedora 16 bootloader configuration UI looked like: It allowed you to do a few things: Opt out of installing a bootloader at all. Specify whether you want the bootloader to install to the MBR or to /boot on the first-order physical disk. (You could go back to disk selection and change the order if you wanted to install the bootloader to a different physical disk.) Set a password for your bootloader. There’s a few use cases for why you’d want to configure the bootloader: I have three disks in my system, but only two are bootable – that’s all my BIOS will support. These folks need to know which disk is set as the boot disk, and they need to change it in case a non-bootable disk is set as the boot disk by default. Sure, they could crawl under their desk and play with hard drive jumpers if they can’t change the boot disk, but what if they don’t have physical access to the system? Or if it’s hardware made by a manufacturer who doesn’t make it easy to open up? (I won’t name names.) I want the thing I just installed to …

Reclaiming space from partitions during installation Round 3

So you’re getting a blog post on this because I missed having something to show Garrett before he finished work for the day (he’s several timezones ahead of me and I was overly slow.) 🙂 This may be crispier than it would have been had I caught him. Let me catch you up on where we are with reclaiming space from pre-existing partitions during installation. First of all, what is this design meant to address? Well, if you’ve selected what you want to install and selected disks to install it on, and don’t have enough free space in any single continguous free chunk but you do have enough latent space to cobble together enough space to install to – this is the screen that tries to guide you through shrinking your pre-existing partitions to make that latent space useful. This is not the custom partitioning screen design (just to make that clear. 🙂 ) So where were we?: Rough Thoughts on Reclaiming Space from Partitions During Installation – We walked through the lightbox dialog that appears when you’re in the situation described above, and then a few possibilities for what the actual space reclaiming dialog looks like. We tried a …

More Anaconda Custom Partitioning

We’ve been having a bit of a Anaconda custom partitioning UI thrown down the past couple of days in #anaconda to try to make some more progress on it. You may recall, the direction we’d most recently taken the mockups involved a UI centered around the mount points that are / will be created on the system: We hashed out some issues to address with this approach. Some we have addressed over the course of our discussion, some we haven’t. Here’s how it broke down: Issue #1: If you have more than one mount point of the same type on the system, you have an odd name clash. See, we let you select whatever hard drives / storage devices you want as part of the installation. Now, the drives you select may not be blank / nicely-formatted. Rather, they may have pre-existing OS installations on them, and some of those you might want to keep around – maybe you just want to install in the available empty space on the drive(s). The UI above assumes you’re only displaying mount points for one OS. What if I have a Fedora 16 installation on a 1 TB disk that I want to …

Reclaiming space from partitions during installation Round 2

So with some great feedback and great suggestions from you, I’ve been iterating more on the partition resize screen for Anaconda. I started out by poking around with the visual design of the drag handles, and Robin had the idea to make the space between partitions draggable and to use a model where you only drag between two partitions at a time. I think it will make more sense to do it that way, at least in this iteration. Initially I wanted there to be a free bucket on the right side that would grow as you shrank the partitions, but I think that makes it a little confusing as to how you would re-grow that partition if you changed your mind. Non-intuitive in the manner that the affect of your dragging can be displaced by more than just the next box over and it might not be immediately apparent to you that you can grow your partition even though it isn’t immediately adjacent to a block of free space. Smooge had the idea that there should be a clear indicator of how much you can squeeze down a given partition, so now the partitions have a lightly-colored graph to …

Drag / resize handles

In my last post about Anaconda’s UX redesign, there were a couple of mockups that featured draggable diagrams for managing space on a disk, allowing you to shrink its partitions as possible: I’ve been thinking about the best way to make the partitions look draggable. They only need to be draggable horizontally; the mockup above shows a diagonal drag handle making it seem as if the space could potentially be dragged upwards as well as horizontally (it can’t.) I’ve looked around different UI patterns for this; it seems a lot rely on the mouse hovering over the area to be dragged and the pointer changing to indicate draggability. I’m not sure that’s enough; I think there should be more visual clues that something is draggable that don’t require you to mouse over them to determine draggability. So here are some mockups I did just experimenting with different looks; some are definitely more successful than others, I think. What do you think?

Rough thoughts on reclaiming space from partitions during installation

So there’s a path in the storage flow of the Fedora installer redesign where if you don’t have enough free disk space to complete an install right now, but you have enough latent space available in your partitions if you were to shrink them. We offer to let you shrink them to continue the install in this situation. (This is highlighted in yellow in the flow chart above.) A partition should be considered shrinkable if it has at least one 500 MB+ of contiguous space within a shrinkable partition (not HFS journaled, not VFAT, not EFI, etc. etc.). Here’s the screen you get should you end up in that situation: So we’ve been talking about what happens when you click on that ‘Reclaim space’ button. Tree list approach First I took a tree list approach. While I hate tree lists, my brain was hurting around the concept that the general ‘list of parent items on the left, click on one, and details about its children are present on the right’ pattern that I find everywhere in the GNOME UI is typically only used for viewing details and not acting on them. There are some cases where you can act on …