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?)
I’d like to see a summary screen after custom partitioning (actually, after any of them) that gives me a summary of all my devices and what actions will be performed on them. Something like the old custom partition screen, but read-only.
On the autopart selection screen I think it would be better to put the actionable items into the big area on the right, not into the left pane. The left area should be for selecting things and the right for doing somethhing to the selection
This might be outside the scope of a design discussion about Anaconda, but why must the swap space for Fedora always reside on a dedicated partition? Another, very viable option, is to use a swap file. It would be nice for there to be an interface in Anaconda to do this when installing/upgrading, rather than creating the system without any swap at the beginning, and then adding the swap file manually.
It would also allow the installer to grab a guaranteed contiguous piece of disk space on first installation. This would make the partitioned drive also look cleaner, by having fewer total partitions (I’m a one-partition Fedora user myself, everything is under “/” anyway).
how about this scenario ?, brand new computer with a common OS installed, I want to install Fedora from the installation DVD but by default I want it to split my disk 50/50 between the two systems and have it dual boot. BTW: when choosing dual boot, a slider could be used to select the proportion.
This is a great scenario. I think since we can’t read the Windows mount points, it’ll show up as ‘Windows’ (or ‘Other’ if we can’t identify it – but I think we can) and instead of being able to let you modify those partitions at all, they’ll be greyed out by default (just as in the greyed out example in the mockups above) and you’ll be given the opportunity to leave it alone or wipe it. If you need to shrink Windows’ or OSX (if it’s possible), you can do that sooner in the reclaim space screen.
With Windows I believe it’s not possible to have GRUB boot it, so you have to do config on the Windows side to boot into Fedora. We could maybe indicate that info somewhere but, we definitely can’t arrange that for you. With OS X, I’m not sure how dual boot would work as far as configuring the bootloader goes. I think it should work if you choose the same EFI partition that OS X uses but I honestly don’t know, it’s a good question I’ll look into.
BTW we actually came up with the idea for a slider to select the proportion between the two OSes in a dual boot scenario earlier (the white board photo is here! hehe http://www.flickr.com/photos/mairin/6174817767/in/set-72157627610602171/ ) but some things came up:
– I think we don’t exactly want to encourage dual booting since running one OS with VMs for the others is a better and more timely way to do what most dual booters seek to achieve, and it is pretty complicated.
– We can’t shrink every filesystem, and most filesystems we can’t shrink are present in the OSes folks would typically want to dual boot (NTFS for Windows, HFS with journaling for OS X.) So it’d be useless in the core cases.
We do have a slider in the custom partitioning UI though where you can slide between having more system / less data or more data / less system space.
Okay some clarification on dual-booting Fedora with Macs, starting with Fedora 17:
* go into OS X disk utility and resize your disk into two parts, making a fresh one for Fedora
* boot the fedora dvd, choose ‘use all free space’
* hold down alt when you boot your computer, Fedora should be in the boot entry menu, select it
It’s that simple.
With the Anaconda redesign we’ll be essentially doing ‘use all free space’ by default.
To further clarify the Windows case, if you buy a new Windows system from the store in the next 6 months or so it’ll likely be installed via BIOS. So the scenario there would be:
– insert Fedora DVD
– shrink windows drive
– install fedora
– reboot, choose ‘fedora’ from the boot menu
However after the next 6 months Windows via EFI boot will be more prevalent. I think EFI dual boots with Windows are pretty problematic right now. I don’t know how likely this is to be resolved by Fedora 18.
One other option is this: Since you’re able to put text in as “fine print” (read as the lighter colored font below the mount point), you could just say something like
“/home 32 GB
/home: Fedora 16 (Verne)”
“/ 20 GB
/: Fedora 16 (Verne)”
“/home 16 GB
/home: Fedora 17 (Beefy Miracle)”
“/ 20 GB
/: Fedora 17 (Beefy Miracle)”
Simple, clean, and explains what is where. Also, it makes it easier to decide to blow away mount points and whatnot.
Have a great day:)
Patrick.
Before you discount the possibility of using a pre-existing volume without erasing it, consider that the “blow away the old install” scenario frequently goes hand-in-hand with “keep /home” or even “keep another data filesystem.” Since the UI seems to revolve around which OS “owns” a filesystem would it make sense to simply “adopt” a filesystem and not format it? Or might another way be better?
What does empty space on a disk look like?
What does empty space in a volume group look like?
The number of use cases that the UI rewrite relegates to kickstart installations makes me wonder how easy it will be to supply a kickstart to anaconda. Right now one has to use the command line to point anaconda towards one. Have you folks thought about something along the lines of an “install using this kickstart instead” button/dialog?
(I realize you have probably done this already, but it doesn’t hurt to make sure 🙂 )
Have you looked at how Ubuntu’s installer handles partitioning? I find it very well done and easy to use.
Actually, I am generally a big fan on Ubuntu’s installer. It’s incredibly polished.
Now if only they would scrap Unity and adopt Gnome Shell already. Because Fedora beats Ubuntu anytime in terms of the default user experience 🙂
This, right?
http://i1-news.softpedia-static.com/images/extra/LINUX/small/newubuntuinstaller-small_007.png
http://i1-news.softpedia-static.com/images/extra/LINUX/large/ubuntu1010installer-large_002.jpg
I have to admit I don’t follow Ubuntu very closely although we did look at its installer some time back since several folks suggested there was good stuff there. Is there something better to look at for partitioning more recent than that version? Do you have any screenshots to share to point out what you like about it, specifically?
It didn’t support basic stuff like logical partitions last time I checked so it’s definitely made for a simpler subset of cases than we need to support unfortunately. (Eg wonder why the fellow in the screencast showing it off ends up opening up Gparted?)
While the Win vs Linux slider is pretty impressive, we’ve considered that but there are some issues (see comments above). The partitioning screen itself with the list table seems extremely similar to what Anaconda already has and we’re trying to move away from that model.
If Anaconda truly means to make usable UI it needs to be focusing more on the noobs less on the expert or semi experts.
That means something as simple as auto generate secure root password for the noobs and ask them to write it down and keep on a safe place then offer them to change the keyboard and language settings accept all defaults and install. ( and ofcourse all defaults should be set aimed at the noob not experts which means for example no lvm ).
All of this can fit in a single UI and can be executed by the noob with one mouse click.
Current scenario is a mess and I praise that the Anaconda team actually is trying to improve their UI experience since even as simple task as choosing between two local HD is utterly broken in the installer.
Just my two cents…
Yep this is how we’re trying to do the redesign, which may not be readily apparent by looking at mockups of the advanced partitioning screen. But basically, the user only needs to input their language and their network info (which they can skip), press next twice, and they have accepted defaults and are installing. That’s why we went with the hub and spoke model. Do you think it could work?
Until I watch the noobs try it I cant really say if it’s a step in the right direction it certainly sounds that way.
In my experience presenting them with network settings of any kind will just confuse them and raises more questions. The classic once are What’s a hostname?, Why does it say localhost.localdomain? Am I supposed to change this? so on and so fourth. So if you can get away with it, dont present that to the noob because it will only introduce the likely hood of them to clicking something that they do not understand and they end up finding themselves in trouble.
Dont present them with any kind if HD selection widgets or partitioning widgets they will get it wrong. Anaconda should be smart enough to choose the Master hard disk and install onto that. ( And the widget in play now that ask users to select HD if they have more then one has a record holding failure rate for noobs they just pick the top one *always* and installed onto that but as it seems Anaconda does not place the Master drive on top).
Dont present them with any widget if another OS is currently installed. The noobs aren’t going to be dual booting nor are capable of fixing grub or what ever currently OS installed boot loader, should Anaconda get it wrong.
And first and foremost ensure that the partitioning format happens last ( or have Anaconda test run anything that takes place after that before wiping the drive ) there have been too many failures that have occurred after the partitioning format has taken place leaving the noob with un-bootable computer which he then has to tear down from his room,hop into his car and hand over to what ever local computer store to fix and wait for hours even days to get it back.
I don’t know about you, but if I’m new to trying an OS, I’m going to dual-boot. I’ve never seen someone totally new to Linux decide without ever using it to only boot it and not also Windows. Besides, most people I’ve seen try Linux give in to peer pressure from their linux-using friends, who help them install it. That’s just my perspective.
If you’re a cautious noob, why would you dual-boot (complex) if you could just set up a VM?
[…] step back a second first. The custom partitioning tool in Anaconda (Fedora’s installer) still has a lot of rough edges to the design in Fedora 18 […]