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 tree view (too clunky!), clickable & draggable partitions (difficult with a complex disk layout, and non-representative of the physical layout of the disk. We also don’t want to get into the business of repositioning partitions, which this kind of interface seems to encourage.)
• Reclaiming Space from Partitions During Installation Round 2

– Using the feedback from the first post, some adjustments to the click & drag model. First, space that can’t be resized is displayed but greyed out and demarcated as not being resizeable – while I don’t like having useless chunks taking up precious real estate, they do help the user identify the disk they live on I think.) Then, little clicky widgets to show the current space usage of a partition with its smallest potential shrunken size. A delete mechanism with confirmation.

Okay, so the reason I mentioned Garrett above is because he was in Boston for the Red Hat Summit and offered to sit down and go through the anaconda (Fedora installer) mockups with me and give me some feedback / critique. When we came to this screen, his initial reaction was that it was too complicated. I explained some of the concerns that had been brought up about it here in this blog’s comments and in IRC, further adding to the complication. He suggested having a single slider to shrink each physical disk. While my brain is still a little upside-down trying to figure out how this might work, it does seem a more simple and easy-to-understand approach.
Here’s the general scheme:

• You need X amount of space and you don’t have it in a single partition chunk. We tell you how much you need.
• We figure out how much we can squeeze the pre-existing partitions per device.
• Per device, you get one slider. The more you slide, the more you squeeze down the partitions on that disk.
• The anaconda developers (understanding the technology and its limitations, reliability / lack-thereof, and support) dictate a scheme by which space is made that they feel comfortable supporting (rather than the user having to be as intimately familiar with all of the schemes and pitfalls involved themselves):
  1. Any free unpartitioned space is grabbed first.
  2. Next, any free space in a pre-existing file system that is adjacent to unpartitioned free space is grabbed.
  3. Beyond that, we venture into logical partition territory. We add in any other slots of free and unpartitioned space on the disk.
  4. Finally, we squeeze the remaining file systems in pre-existing partitions, in order of most-free-space to least, and add them in to the logical volume as well.

So what might this beastie look like?
Here’s what it might look like when you first enter it and click on the second device in the list on the left:

And here’s what it would look like if you dragged the slider from 8GB free to 10GB free, meeting the requirement of 10GB you had for installation:

So the story behind the numbers in the slider there:

• 8GB – this is a freebie. You started out with an 8GB chunk of free, unpartitioned space.
• 10GB – you get this in the second mockup by squeezing down the BOOTCAMP partition.
• 12 GB – you get this by making a logical volume and added the 2GB of free, unpartitioned space to it.
• 18GB – you get this by shrinking the Mac partition and adding the freed space to the logical volume.

Random points:

• The diagrams of the partitions on disk are no longer clickable. Maybe you could hover over the partitions for a bit more data on each in a tooltip.
• The diagrams of the partitions now reflect reality in terms of the physical layout on disk. This was a big problem with the earlier mockups, because obfuscating the underlying physical layout means you miss out on stuff that’s kind of important if you know what you’re doing. If not, I guess you can ignore the diagram. <= maybe a glaring weak point in the design here. Should diagram be under a disclosure area?
• The slider doesn’t make sense right now because it starts in the middle. You would have 8GB in this scenario to start since you have that nice 8GB chunk of free and unpartitioned space there.
• We’re thinking of reserving 10% of the free space in any partition to lessen the chance we render it unusable, especially if it’s an OS partition.
• Yeah, that’s HFS+ being shrunk. Won’t work if it’s journaled though.

The general approach here

I will keep saying that an operating system installer is complex. It presents the user with a great deal of risk and in some cases, necessarily deals with some complex situations (wouldn’t it be lovely to only have to support ext4 on physical partitions?), especially when you add in enterprise storage support (see my ranty runthrough of this from the Linux Plumbers’ Conference a couple of years ago; it makes better reading with Rufscript installed.)
While on the one hand it pains me to design something that I know is complex and in a rainbow pony world would not be, there is a balance between presenting only a simple & clean interface to all users and enabling those users to get their jobs done. Sometimes there’s a serious tension between the two. When simple & clean design treads in the “oh crap, I’m making it really difficult for an entire class of users to get their jobs done!” territory, I think there’s an approach we’re veering towards in a lot of the anaconda designs that might be a good general solution for these kind of dilemmas:
Pair a simple interface with a method of enabling the subject matter experts (in this case, the installer developers) to dictate a sensible and dynamic scheme that will have the best chance of success for the user, based on the experts’ intimate knowledge of the technology and its limitations.
Maybe better said in other words, unpacking the ‘dynamic’ bit somewhat:
Between a completely open-ended, training-required interface (e.g., kickstart) and an overly simplified UI (left to your imagination), you can establish a system where experts dictate several possible scenarios that are shifted between based on a user’s task-oriented preferences.
Two examples of this in the anaconda redesign:

• This disk space reclaiming tool, where depending on how much space the user wants, we go from creating a new partition from blank space up to adding non-adjacent partitions together in a single logical volume (the latter being the last resort since it’s preferrable to have a real physical partition.)
• The custom partitioning tool, where we present a clean default filesystem layout and enable the users to just accept it or modify it as needed. We also ask the user how much disk space they ultimately want for various places in their filesystem, and we figure out which opt-in technical features would be available to them based on how much they requested so that goal isn’t undermined by choices that don’t seem related.

If I’m terribly wrong in any of this, I continue to encourage those who know better to please leave a productive comment. 🙂