Hi,
Some user feedback and usability testing we've done indicates that having custom partitioning accessible only by a pop up dialog attached to the 'done' in the storage spoke is confusing - people search for custom partitioning on the first storage spoke screen, don't see it, give up and hit done, then they see it.
I think we should consider providing a better pathway to it on the main screen rather than hiding it on the dialog. I think I was overzealous in trying to shield less-technical ("non-Pokemon") users from it in the original mockups and unnecessarily hurt the users wanting to access custom part.
We had a discussion about this in IRC today, and after a few iterations (we started with http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom... and iterated from there) I put some more work into a set of mockups that might work. The thing is, it's hard to just add a button here or move something there without affecting a lot of other things - in this case, the display of the dialog on exit from storage entirely and the encryption and autopart type options.
Okay so here's a little walkthrough:
AUTO-PART USER ==============
1) You click on the storage spoke icon and you see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
You might opt-into disk encryption, and you leave everything else alone.
2) You click 'Done' in the upper left corner. You go straight to the hub. Yeh. So basically:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Anything you would have been able to do in the dialog you already did in the main window. Except for choosing auto-part type. If you're not going into custom part, is the default auto-part type good enough? If not, the main screen design will need more thinking.
CUSTOM PART USER ================
1) You click on the storage spoke icon and you see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
2) You click on the radio button that says "I will configure partitioning" and hit Done. Then you'll see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
You pick the auto part type you want in the dropdown and hit create to let it do its thing and then tweak accordingly. Or you can start from scratch if you're into that.
3) You click on the 'done' button in the upper left corner of custom part and it does the same as it does now (summary of changes, then back to the hub)
RECLAIM DISK SPACE POP-UP =========================
Just a small mod to this one, since encrypt and autopart type are available else where, drop them:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
NO DISK SPACE POP-UP ====================
No changes to this guy:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Does this make sense? I know Chris had concerns about having two columns of options on the screen because translations can get lengthy, so I cut the text length substantially and did a vertical stack of options, but I made the radio buttons horizontally aligned (which the HIG actually allows for, who knew.) I also scaled the disk icon down to 96x96, although 64x64 might work better (need to account for icon height of network disks too.)
The only sticking point here is that auto-part folks won't get to choose their flavor unless they go into custom. But maybe it's good, people who don't really know the difference won't have to even make the choice. And it's easy enough to go into custom, hit auto part for the flavor you want, and get out?
Thoughts?
~m
The idea is great. Please make the two entries into buttons as opposed to appearing as links. May I also suggest the two be placed between [DONE] and the [keyboard selection / display] icon.
We should not have to go to the 4 corners of the window to do things as we now have to. Please also note that some video monitors overscan (until setup in Fedora), and that the bottom or right side is often past each rrespective margin.
Regards
Leslie
Mr. Leslie Satenstein An experienced Information Technology specialist. Yesterday was a good day, today is a better day, and tomorrow will be even better.lsatenstein@yahoo.com alternative: leslie.satenstein@gmail.com SENT FROM MY OPEN SOURCE LINUX SYSTEM.
From: Máirín Duffy duffy@redhat.com To: Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Sent: Tuesday, October 22, 2013 9:59 PM Subject: Idea for making custom partitioning more accessible
Hi,
Some user feedback and usability testing we've done indicates that having custom partitioning accessible only by a pop up dialog attached to the 'done' in the storage spoke is confusing - people search for custom partitioning on the first storage spoke screen, don't see it, give up and hit done, then they see it.
I think we should consider providing a better pathway to it on the main screen rather than hiding it on the dialog. I think I was overzealous in trying to shield less-technical ("non-Pokemon") users from it in the original mockups and unnecessarily hurt the users wanting to access custom part.
We had a discussion about this in IRC today, and after a few iterations (we started with http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom... and iterated from there) I put some more work into a set of mockups that might work. The thing is, it's hard to just add a button here or move something there without affecting a lot of other things - in this case, the display of the dialog on exit from storage entirely and the encryption and autopart type options.
Okay so here's a little walkthrough:
AUTO-PART USER
- You click on the storage spoke icon and you see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
You might opt-into disk encryption, and you leave everything else alone.
- You click 'Done' in the upper left corner. You go straight to the
hub. Yeh. So basically:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Anything you would have been able to do in the dialog you already did in the main window. Except for choosing auto-part type. If you're not going into custom part, is the default auto-part type good enough? If not, the main screen design will need more thinking.
CUSTOM PART USER
- You click on the storage spoke icon and you see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
- You click on the radio button that says "I will configure
partitioning" and hit Done. Then you'll see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
You pick the auto part type you want in the dropdown and hit create to let it do its thing and then tweak accordingly. Or you can start from scratch if you're into that.
- You click on the 'done' button in the upper left corner of custom
part and it does the same as it does now (summary of changes, then back to the hub)
RECLAIM DISK SPACE POP-UP
Just a small mod to this one, since encrypt and autopart type are available else where, drop them:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
NO DISK SPACE POP-UP
No changes to this guy:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Does this make sense? I know Chris had concerns about having two columns of options on the screen because translations can get lengthy, so I cut the text length substantially and did a vertical stack of options, but I made the radio buttons horizontally aligned (which the HIG actually allows for, who knew.) I also scaled the disk icon down to 96x96, although 64x64 might work better (need to account for icon height of network disks too.)
The only sticking point here is that auto-part folks won't get to choose their flavor unless they go into custom. But maybe it's good, people who don't really know the difference won't have to even make the choice. And it's easy enough to go into custom, hit auto part for the flavor you want, and get out?
Thoughts?
~m
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On 10/22/2013 10:20 PM, Leslie S Satenstein wrote:
The idea is great. Please make the two entries into buttons as opposed to appearing as links. May I also suggest the two be placed between [DONE] and the [keyboard selection / display] icon.
We should not have to go to the 4 corners of the window to do things as we now have to. Please also note that some video monitors overscan (until setup in Fedora), and that the bottom or right side is often past each rrespective margin.
I agree with these comments.
Let me also add the following since you are working in the area:
1. For "root", I must always have a fresh partition, logical volume or subvolume. This means that if it already exists, I must reclaim and reformat (or its btrfs equivalent of format destroy, device destroy, subvol device creqte, subvol format).
2. Given that there is free space, I should be able to create and format.
3. If there is an existing partition, logical volume or btrfs-subvol, I should be able to attach that to a mount point on the new system (that is, have that added to /etc/fstab). This should include EXISTING SWAP WITHOUT REFORMATTING the swap! This is something I cannot now do!
This aggravates me. Consider the case where you have mulitple versions of a system install on the same set of disks with all versions using the same swap and referencing it by UUID. The only way to keep the UUID is to not format it. I can currently do this by using kickstart but I cannot do it as a "regular GUI install.
Gene
On Tue, Oct 22, 2013 at 09:59:04PM -0400, Máirín Duffy wrote:
We had a discussion about this in IRC today, and after a few iterations (we started with http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom... and iterated from there) I put some more work into a set of mockups that might work. The thing is, it's hard to just add a button here or move something there without affecting a lot of other things - in this case, the display of the dialog on exit from storage entirely and the encryption and autopart type options.
Awesome! I'll have to try it in action because going through the walkthrough isn't quite the same as trying it in a real case, but, it looks like it really addresses the things that confused/frustrated me before.
The only sticking point here is that auto-part folks won't get to choose their flavor unless they go into custom. But maybe it's good, people who don't really know the difference won't have to even make the choice. And it's easy enough to go into custom, hit auto part for the flavor you want, and get out?
Flavor in this case is Partition Scheme? I think it makes sense for that to go away for automatic, because hey, automatic.
On Oct 22, 2013, at 7:59 PM, Máirín Duffy duffy@redhat.com wrote:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
You might opt-into disk encryption, and you leave everything else alone.
- You click 'Done' in the upper left corner. You go straight to the
hub. Yeh. So basically:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
I prefer this new layout.
However, in a single screen it refers to the user in the 1st and 3rd person: I will configure partitioning and You'll set a passphrase later. I think it's best if there's one narrative.
If you're not going into custom part, is the default auto-part type good enough?
Yes, it's good enough. I've always though guided/auto partitioning wasn't very guided or automatic, with many undefined terms that users wanting to use this path are unlikely to care about.
A noted option is that if the products idea really happens, it's possible to have different defaults behind the scenes for the different products based on the typical use case their working groups come up with: e.g. the cloud product probably doesn't need LVM by default, rather they may want extlinux and ext4 only as their "guided" default layout. And this doesn't require UI changes.
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
You pick the auto part type you want in the dropdown and hit create to let it do its thing and then tweak accordingly. Or you can start from scratch if you're into that.
Great.
RECLAIM DISK SPACE POP-UP
Just a small mod to this one, since encrypt and autopart type are available else where, drop them:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
NO DISK SPACE POP-UP
No changes to this guy:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
It's OK. I'd strongly consider getting rid of complete sentences in both of these. I'm reading 40-50 words before I get to the most important information buried in a sea of text: you don't have enough free space.
I'd lead with the summary of whether they have enough free space or not. Then summarize the breakdown of what software selection amounts to (space needed), and storage device selection (space available), and what the next step is.
The only sticking point here is that auto-part folks won't get to choose their flavor unless they go into custom. But maybe it's good, people who don't really know the difference won't have to even make the choice. And it's easy enough to go into custom, hit auto part for the flavor you want, and get out?
I think the gain outweighs the loss.
Chris Murphy
On Tue, Oct 22, 2013 at 09:41:34PM -0600, Chris Murphy wrote:
A noted option is that if the products idea really happens, it's possible to have different defaults behind the scenes for the different products based on the typical use case their working groups come up with: e.g. the cloud product probably doesn't need LVM by default, rather they may want extlinux and ext4 only as their "guided" default layout. And this doesn't require UI changes.
The cloud product is probably the easiest of all for anaconda UI, because it's mostly "does kickstart work"? :)
On Tue, 2013-10-22 at 21:59 -0400, Máirín Duffy wrote:
Hi,
Some user feedback and usability testing we've done indicates that having custom partitioning accessible only by a pop up dialog attached to the 'done' in the storage spoke is confusing - people search for custom partitioning on the first storage spoke screen, don't see it, give up and hit done, then they see it.
I think we should consider providing a better pathway to it on the main screen rather than hiding it on the dialog. I think I was overzealous in trying to shield less-technical ("non-Pokemon") users from it in the original mockups and unnecessarily hurt the users wanting to access custom part.
Awesome. I think I'd phrase it more generally, though: the Installation Options dialog (or rather, the three different dialogs with that title that show up in different situations) has turned out to be the most problematic part of the newUI workflow. (No attack intended, I understand entirely the process by which we arrived at it; it's just that in practice, it seems to be the thing that trips everybody up.)
We had a discussion about this in IRC today, and after a few iterations (we started with http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom... and iterated from there) I put some more work into a set of mockups that might work. The thing is, it's hard to just add a button here or move something there without affecting a lot of other things - in this case, the display of the dialog on exit from storage entirely and the encryption and autopart type options.
On the approach, A+: I like it. Killing Installation Options is definitely the way to go. It makes the process more consistent and understandable.
Okay so here's a little walkthrough:
AUTO-PART USER
- You click on the storage spoke icon and you see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
So, um, terribly humdrum question, but: will it fit if Specialized & Network Disks is populated? Looks like there's enough greyspace that it could fit in, but just wanted to be sure.
You might opt-into disk encryption, and you leave everything else alone.
- You click 'Done' in the upper left corner. You go straight to the
hub. Yeh. So basically:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Anything you would have been able to do in the dialog you already did in the main window. Except for choosing auto-part type. If you're not going into custom part, is the default auto-part type good enough? If not, the main screen design will need more thinking.
I hate to be Neddy Negative, but I fear it may not be good enough, no. We have the new LVM Thin Provisioning thing available in F20 which presumably was put in this way because we want people to be able to use it without creating a whole custom layout. We have this idea that we want people to be able to test btrfs so we can maybe make it the default in future. And we definitely have an annoying bunch of LVM refuseniks who will always pick ext4 because they 'understand how to deal with it' and don't want to learn LVM. I'm afraid I'm not convinced we can get away with 'defaults only' :/ But, see later!
CUSTOM PART USER
- You click on the storage spoke icon and you see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
- You click on the radio button that says "I will configure
partitioning" and hit Done. Then you'll see this:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
You pick the auto part type you want in the dropdown and hit create to let it do its thing and then tweak accordingly. Or you can start from scratch if you're into that.
- You click on the 'done' button in the upper left corner of custom
part and it does the same as it does now (summary of changes, then back to the hub)
A+, looks fine. Um. Except, are we ever gonna get around to https://bugzilla.redhat.com/show_bug.cgi?id=883148 ? I still think that would be a worthwhile clarification.
RECLAIM DISK SPACE POP-UP
Just a small mod to this one, since encrypt and autopart type are available else where, drop them:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Could we consider a similar 'straight-to' approach here? You're only going to see this if you pick disks without sufficient space and then pick "Automatically configure partitioning", yes? You're not going to see it if you pick "I will configure partitioning." - that's just going to take you straight to custom part.
So since the user has already expressed a desire for "automatic partitioning", can't we take them straight to the Reclaim Space dialog, with an option added to go back to the Disk Selection screen if they decide they want to go to custom partitioning or add more disks? I think that would be cleaner and easier to understand.
NO DISK SPACE POP-UP
No changes to this guy:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Does this make sense? I know Chris had concerns about having two columns of options on the screen because translations can get lengthy, so I cut the text length substantially and did a vertical stack of options, but I made the radio buttons horizontally aligned (which the HIG actually allows for, who knew.) I also scaled the disk icon down to 96x96, although 64x64 might work better (need to account for icon height of network disks too.)
Oh hey you thought of my first point. Whoops!
The only sticking point here is that auto-part folks won't get to choose their flavor unless they go into custom. But maybe it's good, people who don't really know the difference won't have to even make the choice. And it's easy enough to go into custom, hit auto part for the flavor you want, and get out?
Thoughts?
So I have one minor and one major thing to add.
Minor thing: I _think_ the design misses one workflow we put back into F19 by popular demand from F18: letting you go through the 'reclaim space' dialog even if you have sufficient space available. Sometimes people want that.
Major thing: I think overall this is a big improvement, but I think we're still neglecting one fairly interesting category of use cases which we also neglected in the original design: people who come in with an existing layout and a very specific idea of what to do with it.
I think we were mainly thinking about the 'clean slate' cases in the original design, I know I was. Of the hundreds of user reports I've read / heard since then, the ones that seem least well-served by the new design fall into a sort of middle ground between 'nice clean easy auto-partitioning' (which really, honestly, works best if you have an entire empty disk or a similarly nice and clean-cut 'clean slate' situation) and 'custom partitioning'.
Custom part is pretty big and scary: it's an entire GUI partitioning tool which is probably more capable than any single other standalone tool I know about, actually. It's pretty confusing when you first encounter it. I don't think we can 'solve' that: as long as we want the installer to contain an extremely capable graphical partitioning tool, it's going to have an inherent level of complexity. I don't think we can design a single-screen partitioning tool that handles arbitrary operations on existing and notional storage volumes, multiple filesystem types, btrfs, LVM, thinp, mdraid and all the rest of it and yet somehow make it simple enough for people who 'just want to do one simple thing' to be able to magically figure out how without reading the docs and without getting frustrated.
So far we've been telling those people, look, it's a big scary tool, we're doing our best, we have all this documentation, just chill out, read the docs, understand why it has to be so complicated, and you'll get used to it. I mean, that makes sense to us: we know intimately about all the horrible design challenges we're trying to solve in it. But to _them_, it's kind of a sucky non-answer: "okay", they think, "I accept that you guys need to write this mega-capable complex partitioning tool, but look, all I want to do is say use Partition 1 as / and Partition 2 as /home and I STILL can't work out how to do it in this damn thing!"
Sorry for the narrative approach, but I hope it illustrated things a bit :) So the use cases I'm thinking of are this kind of thing:
1) I just want to do a 'ghetto upgrade': re-use the partitions from an existing install, preserving /home and blowing away the others
2) I'm a super-organized person who already has a workflow for dealing with partitions, I've already created partitions for Fedora with the tool I've been using for a decade and know inside-out, I just want to tell you which partitions to install onto, no I don't want to learn your completely new UI for a super-complex partitioning tool!
3) I'm an OS Pokemon Trainer. I've got three versions of Windows installed, two versions of Ubuntu, one each of Gentoo and SUSE. I want to blow away Ubuntu 12.04 and SUSE, leave Windows and Gentoo alone, and shrink Ubuntu 12.10. (Or something along those lines...you get the idea).
It's kind of a middle ground between 'full automatic' and 'full-fat custom partitioning', and I think it'd be awesome if we could accommodate that somehow. Have you seen Ubiquity? Its partitioning is kind of incredibly dumb compared to ours: it gives you a little GTK+ table of existing partitions and lets you assign them mount points, and if you want to do...anything else, it has a little button that launches gparted. And, well, that's it. In all sorts of ways, it's way inferior to us. But it actually serves the above use cases pretty well, because a dumb little list of existing partitions with a very restricted list of possible operations on them is kind of what people want in those use cases.
I'm not 100% sure how we could incorporate a 'restricted manual' mode like this into your design, but I think it'd be awesome if we could. I think one general approach we could look at is using the custom partitioning code for identifying other existing OS installations outside of custom part. It's kind of funny, for instance, that the 'reclaim space' dialog doesn't really take advantage of this knowledge: if you look at 'reclaim space', its tree view is very similar to the one that oldUI custom partitioning had, the same kind of thing ubiquity has, the thing that we made a point of throwing out of custom partitioning because we thought it was difficult for some users. Yet we have it, in the workflow that's supposed to be for less sophisticated users than custom partitioning!
So I suppose the overall approach I'm feeling towards here is that we could sort of soup-up the Reclaim Space dialog a bit in terms of functionality, so it becomes sort of 'custom partitioning lite' - it lets you perform a range of operations on a pre-existing layout, not just deleting and shrinking to create space for a new auto-part layout, but letting you specify Fedora mount points for existing volumes and choosing to format or not. We could try and make it a bit nicer to look at and easier to understand, using the knowledge we have about which partitions are part of which OS installs. And we could slightly revise how it fits into the workflow so that we don't need Installation Options screens any more.
Perhaps if you have a non-empty disk and you pick Automatic Partitioning, you always go to this new 'Light Partitioning' screen, but it has a very simple and obvious 'don't touch any existing disk contents, just auto-partition into free space' option, to keep the simple flow available, but make sure anyone who wants to make simple modifications is able to? And it has options to cancel back to disk selection, or move over to 'full-fat' custom partitioning?
Or, hell, we could just do disk selection and then send EVERYONE to the 'light partitioning' screen, with a simple bypass option for 'just auto-part into free space', a breakout to full-fat custom partitioning, and the relatively simple UI for simple operations on existing partitions for our 'middle way' use cases? I suppose then I'm kinda re-inventing Installation Options, only it's a single dialog (not four variants) with clearer workflows and the 'reclaim space' dialog folded in and enhanced.
Anyway...the more I write about this, the more I think it feels like a productive avenue to explore. Should I do some mockups?
On Fri, 2013-10-25 at 16:44 -0700, Adam Williamson wrote:
Or, hell, we could just do disk selection and then send EVERYONE to the 'light partitioning' screen, with a simple bypass option for 'just auto-part into free space', a breakout to full-fat custom partitioning, and the relatively simple UI for simple operations on existing partitions for our 'middle way' use cases? I suppose then I'm kinda re-inventing Installation Options, only it's a single dialog (not four variants) with clearer workflows and the 'reclaim space' dialog folded in and enhanced.
Anyway...the more I write about this, the more I think it feels like a productive avenue to explore. Should I do some mockups?
So it's not exactly a mock-up, but here's some suggested wording for the 'Installation Options 2.0' screen described above (or rather, screens - yeah...turns out we'd want two versions...):
Disk(s) empty -------------
Your chosen disk(s) are empty. You can choose either to let the installer choose a disk layout for you, using all the free space on your selected disks, or use Custom Partitioning to decide a disk layout yourself.
(buttons: "Partition the disk(s) for me" and "Custom partitioning").
Disk(s) populated -----------------
The storage volume(s) on your chosen disk(s) are shown here. [shown only if sufficient free space: If you simply want to leave your existing volume(s) untouched and let the installer create a disk layout for Fedora in the free space on the disk(s), click Done now]. You can delete or shrink a volume to free up disk space, and you can choose to use an existing volume as part of the Fedora installation, reformatting it or keeping its current contents. Once you are happy with your selections, click Done. Any required volumes you have not explicitly specified will be created automatically for you once installation begins. If you want to create new volume(s) for the Fedora installation manually, choose Custom partitioning.
(buttons: "Done" and "Custom partitioning").
Too verbose, as my texts always are, but I hope it serves the purpose of illustrating how the workflow could work?
On Fri, 2013-10-25 at 17:03 -0700, Adam Williamson wrote:
On Fri, 2013-10-25 at 16:44 -0700, Adam Williamson wrote:
Or, hell, we could just do disk selection and then send EVERYONE to the 'light partitioning' screen, with a simple bypass option for 'just auto-part into free space', a breakout to full-fat custom partitioning, and the relatively simple UI for simple operations on existing partitions for our 'middle way' use cases? I suppose then I'm kinda re-inventing Installation Options, only it's a single dialog (not four variants) with clearer workflows and the 'reclaim space' dialog folded in and enhanced.
Anyway...the more I write about this, the more I think it feels like a productive avenue to explore. Should I do some mockups?
So it's not exactly a mock-up, but here's some suggested wording for the 'Installation Options 2.0' screen described above (or rather, screens - yeah...turns out we'd want two versions...):
Disk(s) empty
Your chosen disk(s) are empty. You can choose either to let the installer choose a disk layout for you, using all the free space on your selected disks, or use Custom Partitioning to decide a disk layout yourself.
(buttons: "Partition the disk(s) for me" and "Custom partitioning").
Disk(s) populated
The storage volume(s) on your chosen disk(s) are shown here. [shown only if sufficient free space: If you simply want to leave your existing volume(s) untouched and let the installer create a disk layout for Fedora in the free space on the disk(s), click Done now]. You can delete or shrink a volume to free up disk space, and you can choose to use an existing volume as part of the Fedora installation, reformatting it or keeping its current contents. Once you are happy with your selections, click Done. Any required volumes you have not explicitly specified will be created automatically for you once installation begins. If you want to create new volume(s) for the Fedora installation manually, choose Custom partitioning.
(buttons: "Done" and "Custom partitioning").
Too verbose, as my texts always are, but I hope it serves the purpose of illustrating how the workflow could work?
Oh - this would be a full-frame screen, like custom partitioning - not a 'pop-up' like the current Installation Options or Reclaim Space - and you would go to it from the Disk Selection screen via a 'Next' button at the bottom-right hand corner (by popular demand!)
The large paragraph may be pruned as follows, and would be split into mini topics.
This rework would match what Adam W. has proposed as an option.
The storage volume(s) on your chosen disk(s) are shown here. [shown only
if sufficient free space:]
If you simply want to leave your existing volume(s) untouched, click done now.
This action will start the anaconda installer program to configure and install Fedora using the free space on the disk(s).
You may delete or shrink a volume to free up disk space. You can choose to use an
existing volume as part of the Fedora installation, reformatting it or keeping its current contents.
Once you have completed your selections, click Done. Any required volumes you have not explicitly specified will
be created automatically.
If you want manually perform a custom installation, choose Custom partitioning. Regards
Leslie
Mr. Leslie Satenstein An experienced Information Technology specialist. Yesterday was a good day, today is a better day, and tomorrow will be even better.lsatenstein@yahoo.com alternative: leslie.satenstein@gmail.com SENT FROM MY OPEN SOURCE LINUX SYSTEM.
From: Adam Williamson awilliam@redhat.com To: Discussion of Development and Customization of the Red Hat Linux Installer anaconda-devel-list@redhat.com Sent: Friday, October 25, 2013 8:09 PM Subject: Re: Idea for making custom partitioning more accessible
On Fri, 2013-10-25 at 17:03 -0700, Adam Williamson wrote:
On Fri, 2013-10-25 at 16:44 -0700, Adam Williamson wrote:
Or, hell, we could just do disk selection and then send EVERYONE to the 'light partitioning' screen, with a simple bypass option for 'just auto-part into free space', a breakout to full-fat custom partitioning, and the relatively simple UI for simple operations on existing partitions for our 'middle way' use cases? I suppose then I'm kinda re-inventing Installation Options, only it's a single dialog (not four variants) with clearer workflows and the 'reclaim space' dialog folded in and enhanced.
Anyway...the more I write about this, the more I think it feels like a productive avenue to explore. Should I do some mockups?
So it's not exactly a mock-up, but here's some suggested wording for the 'Installation Options 2.0' screen described above (or rather, screens - yeah...turns out we'd want two versions...):
Disk(s) empty
Your chosen disk(s) are empty. You can choose either to let the installer choose a disk layout for you, using all the free space on your selected disks, or use Custom Partitioning to decide a disk layout yourself.
(buttons: "Partition the disk(s) for me" and "Custom partitioning").
Disk(s) populated
The storage volume(s) on your chosen disk(s) are shown here. [shown only if sufficient free space: If you simply want to leave your existing volume(s) untouched and let the installer create a disk layout for Fedora in the free space on the disk(s), click Done now]. You can delete or shrink a volume to free up disk space, and you can choose to use an existing volume as part of the Fedora installation, reformatting it or keeping its current contents. Once you are happy with your selections, click Done. Any required volumes you have not explicitly specified will be created automatically for you once installation begins. If you want to create new volume(s) for the Fedora installation manually, choose Custom partitioning.
(buttons: "Done" and "Custom partitioning").
Too verbose, as my texts always are, but I hope it serves the purpose of illustrating how the workflow could work?
Oh - this would be a full-frame screen, like custom partitioning - not a 'pop-up' like the current Installation Options or Reclaim Space - and you would go to it from the Disk Selection screen via a 'Next' button at the bottom-right hand corner (by popular demand!)
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Oct 25, 2013, at 5:44 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2013-10-22 at 21:59 -0400, Máirín Duffy wrote:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Anything you would have been able to do in the dialog you already did in the main window. Except for choosing auto-part type. If you're not going into custom part, is the default auto-part type good enough? If not, the main screen design will need more thinking.
I hate to be Neddy Negative, but I fear it may not be good enough, no. We have the new LVM Thin Provisioning thing available in F20 which presumably was put in this way because we want people to be able to use it without creating a whole custom layout. We have this idea that we want people to be able to test btrfs so we can maybe make it the default in future. And we definitely have an annoying bunch of LVM refuseniks who will always pick ext4 because they 'understand how to deal with it' and don't want to learn LVM. I'm afraid I'm not convinced we can get away with 'defaults only' :/ But, see later!
Two of four options are in the vicinity of experimental. On the one hand, I want to make it easy for people to test such things, but on the other hand they shouldn't be overly enticed as if these things have equal stability or support as other options.
In some sense, I prefer the + reveal of the F18 installer, albeit preferably named as "Advanced partition schemes" or maybe so far as to list them as "Technology Preview" or "Experimental" options.
A+, looks fine. Um. Except, are we ever gonna get around to https://bugzilla.redhat.com/show_bug.cgi?id=883148 ? I still think that would be a worthwhile clarification.
Agreed. Your mock-up makes this more clear. However, instead of "Existing operating systems" the title needs to be more generic because non-Fedora systems, and stand alone data partitions appear together as "Unknown." They're not recognized as operating systems.
"Other" is preferable to "Unknown" also. It should tell us, if nothing else, what device & partition it's on, its size, and its file system.
RECLAIM DISK SPACE POP-UP
Just a small mod to this one, since encrypt and autopart type are available else where, drop them:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Could we consider a similar 'straight-to' approach here? You're only going to see this if you pick disks without sufficient space and then pick "Automatically configure partitioning", yes? You're not going to see it if you pick "I will configure partitioning." - that's just going to take you straight to custom part.
Yes, as it stands proposed, this needs to be retitled to something other than Installation Options. There are no options. It's an available space summary, enough or not enough. Better to, as you say…
So since the user has already expressed a desire for "automatic partitioning", can't we take them straight to the Reclaim Space dialog, with an option added to go back to the Disk Selection screen if they decide they want to go to custom partitioning or add more disks? I think that would be cleaner and easier to understand.
Simpler language to convey information in Installation Options is preferred. Complete sentences are prone to being misinterpreted, requires much more effort to translate, and makes the installation process appear more complicated than it is. The existing Reclaim Space dialog also has a lot of words.
Major thing: I think overall this is a big improvement, but I think we're still neglecting one fairly interesting category of use cases which we also neglected in the original design: people who come in with an existing layout and a very specific idea of what to do with it.
There are all sorts of common and simple examples:
I can't directly delete LVM partitions (PVs), or Btrfs formatted partitions, in custom partitioning. I have to remove their parts (LVs or subvolumes) one by one; and in particular if they appear under Unknown because the delete all within Unknown deletes everything there without respect to what drive or partition its on.
Multiple device support is also difficult because the user is required to choose physical devices without indication what devices are members of LVM, Btrfs or md RAID.
Chris Murphy
On Fri, 2013-10-25 at 16:44 -0700, Adam Williamson wrote:
- You click 'Done' in the upper left corner. You go straight to the
hub. Yeh. So basically:
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custom...
Anything you would have been able to do in the dialog you already did in the main window. Except for choosing auto-part type. If you're not going into custom part, is the default auto-part type good enough? If not, the main screen design will need more thinking.
I hate to be Neddy Negative, but I fear it may not be good enough, no. We have the new LVM Thin Provisioning thing available in F20 which presumably was put in this way because we want people to be able to use it without creating a whole custom layout. We have this idea that we want people to be able to test btrfs so we can maybe make it the default in future. And we definitely have an annoying bunch of LVM refuseniks who will always pick ext4 because they 'understand how to deal with it' and don't want to learn LVM. I'm afraid I'm not convinced we can get away with 'defaults only' :/ But, see later!
Heh, it's funny I happened to come back to this thread while replying to a forum post, because cmurf and I were discussing this just the other day.
I may want to change my mind about this one, at least partly.
So we were trying to draw up a storage validation matrix which would let us at least test non-custom partitioning methodically and somewhere close to exhaustively, and when we try that, it quickly becomes obvious that one of the complicating factors is the partition/volume type. Basically, it's a multiplying factor: we have to find every path through guided partitioning, and then if we want to be thorough, we have to run each of those tests (currently) four times: one for each option on the dropdown.
I went back and looked at how, historically, we've got to this point, and it was actually kind of interesting.
In Ye Olde Times, we actually fairly clearly intended for non-custom partitioning to be pretty choice-free. The broad design was that you picked disks, got the 'approaches' question screen - "do you want to wipe all data? only use empty space? wipe only existing Linux partitions? or resize a partition?" - and that was pretty much it as far as choice went, unless you picked Custom.
We also had a clear split in testing: QA had a set of test cases intended to test all the 'choice' paths and all the various disk types anaconda supported, and this was designed to give assurance that the non-custom path was solid. Testing on custom part was much more 'optional extra' stuff, and there was no attempt at all to test it exhaustively.
So, back a while ago, we actually had a fairly clear 'line in the sand' that was a part of anaconda's design and reflected in our testing process: 'non-custom' partitioning was a fairly choice-free affair which we tried quite hard to make sure always worked; you could use custom if you liked, but we didn't guarantee it would never break.
Since then the lines have gotten a bit blurred. On the QA side we're now testing custom part a lot harder than we used to, and setting a higher bar for it (probably unrealistically high, which is one of the things we're working on). And I think both anaconda and QA unintentionally lost sight of the original clear vision for a split between 'simple, choice-free, reliable' non-custom and 'all choices here, bugs may occur' custom.
I think as long as non-custom simply gave you LVM and you liked it, there was a contingent which was unhappy with this and kept complaining about it. Eventually, a compromise was made: oldUI non-custom got a 'don't use LVM' checkbox.
Then I think what happened next was this got improved - from a design perspective - in newUI. A checkbox which is basically a filesystem selector doesn't make an awful lot of sense from a UI pov, so it was turned into a dropdown, which is a much better UI. But the checkbox also kind of encoded a hint about the nature of the option - that it was an ad-hoc compromise, not really a part of the design. The dropdown lost this, and I think we all sort of forgot about it, I know I did.
Right at the start of newUI, we added btrfs to that dropdown, which means we've now got 3x the paths through non-custom part. And F20 added lvm thinp, which makes it 4x. btrfs and lvm thinp are also far less 'safe' than ext4 as alternatives to the default LVM; it's pretty unusual for plain ext4 to break where LVM works - it's almost a perfect subset, really - but much more plausible that btrfs or thinp might. So instead of one 'default path' with a reluctantly-tacked-on but probably safe alternative, we have a default path with three alternatives that look 'equally blessed', two of which add considerable potential for problematic divergent behaviour compared to the default.
Sorry for the history lesson, but I found it instructive to look back over the history of how we got here, and I thought others might too.
All this does rather support the idea of dropping or at least reducing the range of filesystem Choice on the non-custom path, so I'm certainly less opposed to the idea now than I was before. In theoretical terms, the purest options are 'go back to just one default' or 'keep adding stuff when we want to, and accept that our model is now that non-custom part is more flexible and possibly less bulletproof'. But in practical terms, I actually think the late-oldUI approach of offering LVM as the default with ext4 as a 'reluctant alternative' has a bit to be said for it. I can certainly see dropping btrfs and thinp as non-custom alternatives.
cmurf suggested that we should either make thinp just what you get when you pick LVM, or downgrade it to a custom partitioning choice: offering it as an alternative to 'plain' LVM doesn't seem to fit very well. Using thinp while it's not the default seems to be a fairly advanced choice that probably doesn't need to be offered this visibly through the non-custom path.
anaconda-devel@lists.stg.fedoraproject.org