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 indicate their relative fullness (white means free space.)
Nicolas suggested a pie chart rather than a bar graph to get users out of the mindset that this is meant to be an accurate representation of how space is laid out on-disk: I will be exploring that in another round but decided not to try it this time.
Puppy Dog’s Tails brought up the point that not displaying partitions based on whether or not their resizing is supported might not be the best idea. I do agree with his rationale and have found myself in the trap he described many times (“Hmm, it’s gone! Is it a bug, or was that intentional, or what?”) so I put an un-supported VFAT partition (yes, I forgot to label it ‘VFAT’ in the mockup, oops) in this round of mockups to represent that. Another concern Puppy Dog’s Tails brought up was “Disks need some free space to operate efficiently. Perhaps some naive user will take all the free space and allocate it to Fedora and be surprised when they boot back into Windows and it complains or runs slowly.” To answer that, the intention here (as achievable as it may or may not be, David Lehman will probably know the answer to that 🙂 ) is to not let the users put themselves in that situation. I’m thinking a 500 MB buffer or so might be reasonable but David will probably know best there; the main point is we shouldn’t allow users to shoot themselves in the foot like that and absolutely shouldn’t take every last drop of free space since it’s probably not practical in most situations.
Okay, so here’s the thinking in this round:
Display partitions that we can’t resize
Display details on resizeable partition
Here we’ve clicked on the ‘BOOTCAMP’ partition and get a little extra information displayed about it below: the max we can make it right now is 50 GB, the smallest we can make it is 30 GB. That max 50 GB comes from the free space available; would it be useful to give it a max based on all free space on the drive (would be roughly 54 GB since there’s about 4 GB free on the ‘Macintosh HD’ partition, it appears.) What do you think? Is the ‘max you could do *right now*’ or ‘max you could do if you squeezed everything else’ more useful (noting this is a UI for making space for an installation of Fedora, not a generic partition manager)?
Deleting a partition
The best way to make space is to delete, delete, delete! This screen is already a lightbox though, and as misguided / foolish as it may be, one of my goals for the Anaconda redesign is that there shall be no more than one level of lightbox or pop-up here. (The current Anaconda suffers from some crazy nested pop-uppage.) But it seems a bit rash to let someone wipe an entire partition in one click without warning when they click that little ‘x’ in the partition’s upper left corner. So why not have a confirm button nested inside the partition’s box with a warning below?
Well, I’ll tell you why not. It’s a bit of a squeeze for smaller partitions. This is where I want to explore Puppy Dog’s Tail’s idea of having two vertical bars – then the graphs will be constrained horizontally, meaning I’ll have consistent horizontal space for a button like this. Maybe…. Maybe…. We’ll see if it works out, that’ll be round 3.
Do note the model here (at least, the intention!) is that you’re queueing up changes to the partition layout, none of which will be committed until you click ‘Reclaim space.’ This means you don’t really delete that partition until you click ‘Reclaim space.’ So maybe the confirm button is overkill. Maybe it’d be better to have a ‘Reset partitions’ button or something to restore the original layout?
What do you think?
Deleting a partition with no room to breathe
Here’s what I mean: the button doesn’t really have enough space… oh and by the way, the stuff under ‘160GB Hard Disk’ in the left list are just me puttering around, I’m not sure if it makes sense to list the partitions there as well (current thinking on that is no, it’s redundant.)
Okay, again, these are all rough and just my current thinking after playing around in Inkscape and reading through your comments for an afternoon. Your feedback on the last couple of posts was incredibly helpful so if you’re willing to give it another go to help fuel this onward, please feel free in the comments! 🙂
(Note on the sources for this: the sources for these screens and the earlier ones are in the main Anaconda index.svg, in the ‘screen-destination-reclaim-*’ layers. )