Máirín Duffy

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 keep around, and I just want to give Fedora 17 a try in my 500GB of free space on the same physical drive? Well, if I have my Fedora 16 partitioned with /, /home, /var, swap, etc., those mount points will show up in the left bar in the mockup right alongside the new /, /home, /var, etc. that I’m creating for my new install. Oops.
• What if I want to blow away that Fedora 16 install and install Fedora 17 fresh in the same space? When those F16 mount points show up, how do I know if they are the F16 ones that I should delete/format, or if autopart already handled that and they are my new Fedora 17 ones?

So we thought through a few ways to accounts for this:

A dropdown between OSes

(Ignore the emblems, we were playing with them for another idea.)

It’s uncluttered since you only see one OS at a time. You know which OS you’re looking at so you know what the mount points are for. It’s not super-discoverable, though; it’s also a tad clunky visually – I’m not sure it’s very common to have a dropdown embedded in the left sidebar of a screen layout like this. Generally I don’t like dropdowns as a main navigation elements like this because I think they are physically harder to target than alternatives (a made more crystal clear to me than ever with spending the past week wearing a brace on the wrist of my primary hand. Sigh.)

So, meh.

A Nested Tree

You know, I’m sure there is a time and place for nested trees, but I try to avoid them like the plague. Depending on the implementation of course, sadly they often depend on targeting an area that is on average 12×12 pixels in size – not cool. Implemented properly, clicking either the [+] or [-] icon will toggle opening up a section of the tree, but this isn’t always possible. For example, in Nautilus’ list view, you can only click the [+] or [-] icon – clicking on the name of the folder opens up that folder fully in an icon view. Ick.

We didn’t bother mocking this one up. Don’t mean to hate on you nested tree luvas out there. If I’m nuts for this attitude, school me (*politely*) in the comments.

Ditching the system vs data labels and using those labels to demarcate OS

This one is pretty clean, but it will likely require a scrollbar. Also! It means the system vs. data slider up at the top will make a lot less sense and probably will need to be ditched as well. :-/

Cell-phone style nav of the mount point list

Yeah. I put this mockup in a subdirectory called ‘crackrock.’ I have actually never seen this done before (have you?) It seems like an interesting way to separate out the different OS mount point listings without using a tree view, but it’s kind of an odd pattern and would probably confuse people.

Accordion-style nav of the mount point list

This is the one that Chris is working on today. (Thanks ebassi for helping figure out how!) The Accordion menu is a common UI design pattern, and while for some installs it will require a scrollbar, I think it maybe solves the problems in the best manner here.

What do you think?

Issue #2: When do we do autopart?

David Lehman and I also talked about in which scenarios do we auto-partition a device for the user vs. let them decide what to do. If you have a disk with a contiguous chunk of space that meets the minimum space required for autopart, we *can* do autopart – it doesn’t require a completely formatted disk/device. We decided that we should allow you to autopart a disk and then customize it; you might want to use the autopart scheme as a guide to start from in your customizations.

One idea on the table is that instead of doing autopart on the free space that’s available by default, we’ll leave it blank and have an ‘empty list message’ that says something like, ‘you have no partitions; create some below or click here to have us create them for you.’

Here is a mockup showing this:

Issue #3: How can we make it less confusing to understand which partitions are getting wiped and which are safe / going to be left alone?

(Not sure on this one.)

I think we should think about what should the default behavior be – wipe it all and opt-in to preserving select partitions, leave everything alone and opt-in to wiping select partitions, or install side-by-side and leave what’s there alone.

One thing to consider is to have a flag users could set when they choose to disk to indicate that if it’s okay to wipe the whole thing, and by default preserve the data. Maybe? Or maybe use the settings (‘gear’ icon) in the custom partitioning screen’s left nav bar’s bottom to let them do this, although at this point we are speaking in terms of mount points/partitions and not devices so I believe this is too late.

Issue #4: Will we support mounting the same mountpoint from different OSes?

I think we decided not to support that since mounting the same home from different OSes is not an advisable thing to do. For example, if you have different versions of the same app sharing the same .config directory, odd things can go down. Mounting simpler stuff than /home, like a /srv across OSes/ is simple to do post-install so there isn’t a lot of advantage of doing it in the install. (And you could always script it if you wanted to in a kickstart post. Remember, at least the plan is to support inheriting settings from detected KS files when you use the Anaconda UI.)

Issue #5: Can people remove devices in the custom partitioning screen?

What if their disk is full and all they want is to reformat a root device and assign some mountpoints — no device removal/creation?

The two cases where someone ends up in custom part are:

• (A) They opted in *before* the disk space reclaiming UI – they already had plenty of space so the space reclaim UI wasn’t offered up to them.
• (B) They did disk reclaiming and still came up short.

Issue #5 here is clearly case B. To reformat a root device and assign mountpoints, they could one-by-one hit the ‘-’ icon in the bottom of the left sidebar in the custom partitioning screen to remove partitions from the device and re-add them. How do we know to format it? Should we always format if all partitions are removed from a device in our custom partitioner?

Issue #6: Is the intention that the interface will be pre-populated with all the filesystems on the devices selected for installation?

Yeh, I think it’s a good idea. If you had a disk/device you wanted to preserve the filesystem of in its entirety, you wouldn’t have selected it on the device selection screen. This means that if a device you selected has a filesystem present on it and you’ve made it as far as the custom partitioning screen, you either want to blow it away or keep it around. If you want to keep it around, you’re likely to be a bit anxious (especially with a re-vamped installer ) about whether or not the data is going to make it, especially if you are lazy like me and don’t do backups in this situation AS WE OF COURSE RECOMMEND THAT YOU ACTUALLY DO! (Do as I say, not as I do!!) To see that the data is there on screen I think maybe helps with this anxiety. Although to be honest, maybe thinking about storage this much has made me focus too much on anxiety-aversion.

But yeah, nobody wants their data to get blown away so I do believe being able to see it there safe and sound (maybe with some further reassuring indicator it won’t be touched – one idea is to grey out the options on it unless you explicitly say yeh I want to blow it away, see mockup below) is a good idea.

Thoughts?

So…

That’s where we’re at right now with the custom partitioning UI. Do note that the custom partitioning UI is opt-in only, except in the case where you don’t have enough space for install and the space reclaim UI wasn’t able to squeeze your filesystems small enough to make room. (And honestly in that case, it is too, although the default option in that scenario is ‘Sorry Charlie, time to quit the installer.’)

As you can see, we have a number of open issues or directions we’re starting to explore, so if you have thoughts, (polite) admonitions, or brilliant ideas, let us know in the comments! We also have these discussions very informally in #anaconda on irc.freenode.net, and your (polite) participation is certainly welcomed there.

OMG you’re redesigning the anaconda installer?

Yes!

• Why oh why are we doing this? Learn here.
• You can read lots more of my scribblings about the project in this blog’s ‘anaconda’ category.
• We also have a Fedora wiki page for the project.
• Drop by #anaconda on irc.freenode.net if you’d like to get involved or simply voice your opinions.

(Polite Panda for Fedora 19?)

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

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.