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!
(Polite Panda for Fedora 19?)
) a web interface to control mcollective infrastructure adding windows support. The “problem” was that no windows package was available during our tests and, knowing that usual production environment servers could not have access to internet, this could cause installation problem.
Starting early in the morning, along with 
.
The Common Vulnerability Reporting Framework (CVRF) is a way to share
information about security updates in an XML machine-readable format. CVRF
1.1 got released this week and over at Red Hat we've started publishing
our security advisories in CVRF format.
Setelah meeting Go/No-Go beberapa jam yang lalu. Rilis Fedora 17 mundur satu minggu, dari 22 Mei menjadi 29 Mei.
