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 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

Here we’re showing a tiny EFI partition that can’t be resized. It’s small enough it doesn’t have a label on the graph, so you must click it to get a little label to pop up below it.

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. )

6 Comments

  1. Robin N

    First, I agree that the list of partitions on the left is redundant; unless you can somehow select them independently and do stuf with them.
    It doesn’t look like the partitions sizes are proportional; I gather there’s a minimum width, which can be made to be “the width of the Delete button plus a little bit”.
    Regarding the partition order, it looks like the algorithm is “resizable partitions (in order of size?), then free space, then non-resizable partitions.” Correct?
    How about make the “message” area pop out a bit, with a border or different background color? Also the font for it seems a bit small for the “importance” of this info.
    I think I like the way you’re confirming delete; also, assuming no destructive changes are made until I hit “reclaim space”, that’s another safety measure. Will “N partitions deleted” appear in the summary section above the “Reclaim Space” button?
    What’s the difference between “Reclaim space” and “Continue”? I guess “Reclaim space” does the action, then “Continue” continues with the install?
    Random: So you’re selecting the drives on the left side, and then “stuff” happens on the right side. What if you changed the paradigm to more like an “accordion” model, where the entire horizontal space is taken up by:
    –HEADER AND INFORMATION MESSAGE–
    –ACCORDION LIST OF DRIVES AND FREE-SPACE-ERIZER–
    –SUMMARY OF CHANGES/”YOU NOW HAVE ENOUGH FREE SPACE” MESSAGE/ACTION BUTTONS–
    Make sense?

  2. justin b

    I think you’ve got a lot going on in this mock up that might frustrate some users. I like the idea of the x button on the top left to delete, however I think warnings and confirms are the domain of modal dialogs. You’re doing something important, you need to get the user to notice. Pop up dialogs get in the way for a reason, so long as you use pop ups for only that purpose, you’ll do fine.
    If you need to show something that won’t actually happen until later, a good scheme to use is to dim/fade something. It makes it look like something is still there. Once reclaimed do something to let users know it isn’t coming back. Going with the fade idea, make it fade completely away.
    The stuff on the left is useless repeat. It should really go away. I love the way you show free and used space per drive. The show down labels that appear below when something is too small is an amazing idea. If you’re going to keep that idea, stay with it the whole way through, it’s a trick others don’t use so people aren’t going to be looking for it to begin with.

  3. shaiton

    “I’m thinking a 500 MB buffer” in fact this free space should depend of the filesystem type, and the partition size. Ok, the 10% rule is rude now with some Tera hard drive.
    Just one concern, I see the cross button to delete a partition, we won’t *NEED* a mouse on this Anaconda process, right?
    I agree, the “reset partition layout” button would be helpful, without having to “cancel” the current task.
    “Cancel” is just canceling the resizing step, right? Not canceling the intallation.
    Then I don’t understand the use of “Continue”, continue without resizing=canceling the resizing step…
    Also on the bottom right corner should be the “next step” button, and the step here is “Reclaim disk space”, then this button should be “Reclaim space”.

  4. Nyawade S

    The mockups are looking great and would definitely make installation easier to navigate.
    In regards to the representation of free space for each volume: What if the drag handles could be used to take the free space of other volumes? The user would tug one end of a volume to the right, eventually eating up all of the free space of the adjacent volume. Then, this other volume itself would be pushed to the right and force the absorbtion of its right neighbor’s free space (automatically allocated to the growing volume). Alternatively, as soon as a volume loses all of its free space, it could teleport to become the rightmost volume and the next volume would take its place.
    To indicate that another volume’s space is being taken, a red just as soft as the used-space blue could be used.

  5. Feedback from gholms in #anaconda today:
    mizmo: Is “round 2” the latest mockup you have for drive space reclamation stuff?
    gholms, yep that’s the latest thinking
    Where can I key in what size I want a partition to shrink to?
    we’ve got to have a custom partitioning throw down here real soon. it looks to be the only part of the new ui not really progressing.
    gholms, i was thinking about moving the bars to be vertical, having a bar for partitions and a bar for free space
    gholms, ive been away at LGM for a week tho
    If I was doing that in Disk Utility, for instance, the size indicator is also a text box.
    * mizmo takes a look
    Useful example: http://www.creativetechs.com/iq/tip_images/DiskUtility-Resize.gif
    If I were to type something into the box it would shrink the partition to match.
    And likewise, that box gets updated when I release the drag handle, IIRC.
    well, gholms, this dialog’s mission is to shrink things to get you space, not necessarily to set up your partitions, you know?
    Of course.
    that’s the main diff with the os x disk utility
    I just don’t see a way to tell that GUI, “shrink this partition to N gigabytes.”
    are you concerned about exact space units when resizing to get space?
    (im not asking facetiously)
    Right now it’s just “shrink it to around this much.”
    Yeah
    okay, so maybe we need to add some kind of text field for each one
    that might be easier to do with the vertical layout
    When I’m working with $huge_disk one pixel at that resolution may end up being a lot, but…
    yeh understood
    ill note this down for round 3
    Thanks!
    thanks for pointing it out 🙂

  6. mairin

    More notes –
    mizmo: How will it handle chunks of free space that are separated by partitions?
    (Sorry; just bouncing ideas off you)
    gholms, i was going to treat all free space as free space and not get into its position
    gholms, the rationale being either of the two candidates for default filesystem (lvm and btr) are logical anyway
    but maybe that’s bad?
    That depends on how much you care about partition-only use cases. 🙂 seems pretty limiting for the tinkerer, or anyone who doesn’t care about lvm/btr what if you showed each partition and free region on a separate line. shrinking a partition adds new potential territory at the end of the adjacent partition(s). likewise, growing a partition shrinks the adjacent free region(s)
    * gholms nods
    might not be intuitive/easy enough
    If I shrink a partition in Disk Utility I’ll get some grey space between the end of the shrunken partition and the beginning of the partition that follows it.
    * gholms hopes shrunken is a word
    * mmello is now known as mmello|class
    * vgoyal (vgoyal@nat/redhat/x-uqgfbbixkeyhxbrj) has joined #anaconda yeah. putting them on separate lines is an attempt to solve the problem of large disk and/or many partitions (gpt in particular) perhaps there’s some other way of associating each free piece with whatever partitions it is adjacent to as an alternative to actually having to reveal the disk ordering in full
    * gholms hrms
    You could probably lump three things together if you wanted: occupied space, free space inside $slice, and free space outside $slice that lies before $next_slice.
    (where $slice is partition/LV/another abstraction you decide upon)

Leave a Reply to shaiton Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.