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 them, but not in this, ‘check off the partitions you want to shrink across disks to get a grand total you shrink in one go’ shopping cart kind of pattern. If that makes sense. I got hung up on this, so I fell back on old reliable tree list.
“There must be a better way,” I told myself. This tree-list thing looks very 1998, and I think that’s being kind.
Click-and-drag approach
We had poked around with draggable partition blocks early on in the mockups for custom partitioning, so I thought maybe revisiting a clicky-draggy interface here might make some sense.
One issue here is when Chris looked at this, he assumed it was meant to represent the layout on disk. See I was thinking the ‘Free’ block could represent all free, unpartitioned space on the disk, and it would grow as you dragged the Firefox-textbox-style drag handles inward on any partition that was shrinkable. Is it a big problem if the diagram doesn’t represent the physical layout of space on the disk? I’m wondering if there’s some way to make it look, um, less ‘accurate’ or representative in that way so we don’t have any kind of cognitive dissonance screwing up how folks read this screen.
Click-and-drag approach with more block data
I think Chris very rightly classified this one as TMI. However, the idea here is you click on a block in the diagram and you get extended information about it below, in this case, that there are 3 blocks of particular sizes contained in the ‘free’ category.
Click-and-drag approach with less block data than before
An attempt at less TMI.
Where to go from here?
Well, what do you think? Is this approach generally the right one? Have any ideas on how to make the graph feel less like it’s representational of the actual layout of blocks on disk? Overall impressions?
We’ll probably be discussing this in #anaconda on Freenode tomorrow.
Ok in the example above.. the person is installing on what disk? It looks like a partition that isn’t shown.. so I am guessing a different disk. So in this case you are creating a partition on another disk.. how will it be mounted with the ones on the previous disk? The reason I ask is that seems a logic issue that would need to be dealt with in the screen design also.
In the images.. is there a way to overlay how full each partition is in say the last #9-1-8 so say [=== ] so that the person has a visual reference of how far they could pull a partition down?
I’m afraid this is perhaps all too confusing. The person has chosen three disks, a 320gb, a 160gb, and an 80 gb disk to use for their installation. (maybe they want / on one, /home on another, /var on another. we don’t know their intentions yet.)
however, they don’t have enough space to install all of the software they opted to install. so this dialog is offering them the opportunity to shrink the pre-existing file systems on the disks they selected for installation. optionally they could also wipe them all.
this isn’t a UI for creating partitions. it’s only for shrinking them. if you look at the diagram at the top of the post, it shows the next step from the yellow block is either custom partitioning or autopart.
does it make sense now or did i totally screw it up?
Ah ok. I didn’t follow the flow chart you provided as closely as I should. You clearly show that after this I go to partitioning if I changed stuff.
Ok on the second part to better show how much empty space they could get my comment got cleaned up by white space removal :). Lets say = means used space and / means empty space and + means some sort of empty. If you can make the last picture look like
[==/////////////][====//][++]
then a person grabs a corner they get.
[==//////][====//][+++++++++]
that gives them a visual clue of how small they can make a partition and how much space they gained?
Yep, that’s exactly the intention of the bar chart in the last mockup there. There’s little grabby handles in the lower right they can drag to do that. The ‘+++’ is the “Free 8GB” in the diagram…. so I guess you’re saying with the === vs //// to show the used vs free space rather than have a big block they have to drag to understand how much they can squeeze it. That’s a good idea, I’ll try it out and see if it works.
This may be a rather dumb question, but how dificult would it be to make the last representation display the the on-disk layout with partitions to be ignored greyed out?
Why ‘not NTFS’? We can shrink NTFS partitions.
You’re exactly right, I pushed this one out too quickly to make the shuttle bus –
What my notes say:
Shrinkable:
– NTFS
– non-journaled HFS
– ext*
– LUKS encrypted (?) if prompt for password (?)
Not Shrinkable:
– Anything encrypted that’s not LUKS / e.g. truecrypt
– VFAT
– Reiser
– XFS
Does that jive with your understanding? I also s/NTFS/VFAT in the post to correct.
If you want to show bulk allocations, use a form of pie chart (possibly with multiple circles)
Anything bar-like will be seen as as a layout since that’s how all disk partitioning tools (and windows) use it
I considered pie charts but I think they are a little more difficult to handle… it’s much easier to drag on the wrong partition with them. But I’ll play around with them some more. I do agree visually you couldn’t confuse a pie chart with an accurate physical mapping of a drive.
I agree pie chart handling is non-trivial
Another solution is to have an horizontal bar-graph, with one line per partition, and a separate free pool (vertical bar for example)
Drag a partition and have the watch bar grow or shrink
Though if you’re displaying partitions, you really want to display a layout (partitions needs to be contiguous)
If you wan bulk allocations, you need to display logical volumes not partitions. An LV can be assembled from discontinuous pvs
Regarding “Partitions which can’t be shrunk aren’t even displayed at all” — I find this style of interface incredibly frustrating, and it’s increasingly common. Here’s a scenario:
You’ve used the Fedora installer previously to shrink your Mac partitions. You come to install a new version of Fedora, and unknown to you in the meantime Mac OS has upgraded the disk format and we are now unable to resize them. The installer shows some Linux partitions you can resize. Is this because:
1) the installer is broken and can’t find your Mac partitions, I should report a bug;
2) this feature was removed, maybe because of patent problems, or because this is a power user feature and not for grandma;
3) the feature is still present but I’m looking in the wrong place.
Saying nothing is not an effective way of communicating a negative. Sometimes you just need to say: I understand what you’re saying, you can’t do that.
Another example might be: hardware blacklists for drivers, where it’s not that we don’t understand what you’ve got plugged in, but we understand very clearly that we do not support it and you should not waste your time trawling support forums. Maybe you should buy an Intel wifi card or an ATI video card?
Anywho, regarding your partition layout problem, how about arranging the bars vertically like a bar chart. Order them by size, with the free-space bar on the right and slightly separated.
If you color code the bars (shades of green say), when you drag one of the bars lower then a blob of green will appear stacked on the free-space bar — a stacked bar chart. In the end you will be able to see that your free-space is comprised of: free-space, free-space from partition a, free-space from partition b. You will be able to compare it to your other partitions.
I agree with the comment above that the bars need to also show how much data is in the partition to show you the limits of the possible resize. If I could see that one partition was 50% full and another 85% full, I wouldn’t even bother resizing the second one, creating too many small fragmented partitions.
Another important point here is that if a Windows partition is 50% full, that does not mean that there is 50% free space available. 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.
btw. you’re doing a great job with your technical blogging recently. You’re asking the hard questions and demonstrating that progress is being made. One of the most uplifting things to float across planets fedora/gnome. Keep it up 🙂
[…] with some great feedback and great suggestions from you, I’ve been iterating more on the partition resize screen for […]
The view 9-1-8 seems dead clear, while the addition of information to other views doesn’t seem to enable better choices of display information the user needs. I suppose somewhere a button to shrink what you can and use LVM to stitch the needed space into a volume would be useful, with a warning that performance may suck.
I admit the existing fc16 custom install seemed satisfactory to me, fancy is the enemy of clarity, it’s not something the user will need often, so it need not be “aesthetically pleasing.”