Bug 883148 - [custom part usability] Proposal: separate new installation from existing installation in newUI custom part
[custom part usability] Proposal: separate new installation from existing ins...
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All All
unspecified Severity low
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-12-03 16:54 EST by Adam Williamson
Modified: 2014-12-09 09:36 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-12-09 09:36:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mockup of my 3 pane design (60.58 KB, image/png)
2012-12-03 16:55 EST, Adam Williamson
no flags Details

  None (edit)
Description Adam Williamson 2012-12-03 16:54:48 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.
Comment 1 Adam Williamson 2012-12-03 16:55:39 EST
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.
Comment 2 Bob Cochran 2012-12-03 22:42:46 EST
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.
Comment 3 Adam Williamson 2012-12-03 23:27:03 EST
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.
Comment 4 Adam Williamson 2013-01-30 17:28:27 EST
Bumping to Rawhide - if we're going to look at this we should do it soon as it's a major change. Mo?
Comment 5 Adam Williamson 2013-02-14 21:54:13 EST
Mo - any chance of looking at this in time for F19 Alpha?
Comment 6 Fedora End Of Life 2013-04-03 09:40:11 EDT
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:
Comment 7 Adam Williamson 2013-10-25 19:16:38 EDT
This is a Rawhide bug as it's an enhancement request.
Comment 8 Chris Lumens 2014-02-21 16:53:54 EST
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?
Comment 9 Adam Williamson 2014-02-21 17:26:12 EST
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.
Comment 10 Adam Williamson 2014-02-21 17:52:39 EST
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.
Comment 11 David Shea 2014-12-09 09:36:03 EST
(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.

Note You need to log in before you can comment on or make changes to this bug.