Red Hat Bugzilla – Bug 883148
[custom part usability] Proposal: separate new installation from existing installation in newUI custom part
Last modified: 2014-12-09 09:36:03 EST
Another usability issue with newUI custom part that keeps coming up is that people find the conflation in the left-hand pane unclear. It displays both actual, currently-existing partitions within actual, currently-existing OS installations, and a 'notional' group of partitions which do not in fact yet exist for an OS install which does not yet exist (the new install).
I think we need to separate the two out somehow, because people aren't really getting the workflow as is, they don't actually quite understand what the left-hand pane is showing. I'm attaching a terribly amateurish GIMP mockup of my idea of how to do this: make it a three-pane layout, and have +, - and Gears buttons for the 'new install' pane and just a - button for the 'existing install' pane (as you shouldn't be able to remove or reassign existing partitions, I don't think - though gears might make sense in future when it does more than just decide what disk a partition's going on). This has the added benefit of making it rather clearer what the +, - and gears buttons are for, I think (see https://bugzilla.redhat.com/show_bug.cgi?id=883138 ). (I had the subsidiary refinement idea that - and gears could be shown associated with the selected partition and only + be a 'general' button, though I can't think offhand how to make that look good).
Other ideas we had (some of which may be more viable as short-term band-aids for F18, since it's post-beta: anything more ambitious may have to wait for F19) included setting different background colors for the two types of group, and having entirely separate tabs or panes or something for 'existing' and 'new'. There may be other ways to do this.
Created attachment 657083 [details]
mockup of my 3 pane design
Oh - the mockup also adds explicit instruction text to the effect that you can assign mount points to existing partitions. It may be worth adding that on its own, without any other change.
I think this is a good start. I'm confused by the text 'Manual Partitioning' when the point of the screen is to assign mount points either automatically or manually. Should the text be changed to "Assign Mount Points"? And then show a proposed set of mount points that clicking the automatic mount point link would create? That can go on the left side. On the right side, give the user the chance to manually create mount points. Or maybe give the user the chance to read in an XML file that specifies custom mount points.
This is a nice mockup and it is definitely moving in the right direction.
All the text except 'or assign mount points to existing partitions below' and 'Existing operating systems' is as it currently exists in Beta. It is not part of my submission or relevant to the scope of this bug.
Bumping to Rawhide - if we're going to look at this we should do it soon as it's a major change. Mo?
Mo - any chance of looking at this in time for F19 Alpha?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This is a Rawhide bug as it's an enhancement request.
There was some discussion in IRC a little while back that my recent changes in the custom partitioning spoke may have also fixed up this problem. Did they?
Tried to take a look at it, but https://bugzilla.redhat.com/show_bug.cgi?id=1068802 makes it tricky. I'd like to see how it looks with the 'new' and 'old' treeviews populated. I think the drop-down definitely makes it better, though.
OK, 1068802 was pebkac. The dropdown makes this a bit better, but it goes away once you've created one partition, so I'm not sure it's entirely enough. Still, I don't hear people moaning about this issue specifically very often any more, so it's pretty low priority stuff.
(In reply to Adam Williamson (Red Hat) from comment #10)
> OK, 1068802 was pebkac. The dropdown makes this a bit better, but it goes
> away once you've created one partition,
All the expanders stick around on F21, at least, so let's call this fixed.