Bug 988979
Summary: | "Manual Partitioning" screen is badly organized, making it very difficult to use | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dale R. Worley <worley> | ||||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 19 | CC: | anaconda-maint-list, dshea, g.kaviyarasu, jonathan, mkolman, sbueno, stephent98, vanmeeuwen+fedora, worley | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2014-01-02 17:55:26 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Dale R. Worley
2013-07-26 20:23:46 UTC
Thanks for your comments. Another problem with terminology in the storage configuration GUI is that if you click "+" to add a new mount point, you will find that "swap" is listed as a possible mount point. "... since the left side is organized as if it is a list of mount points, there has to be (effectively) an artificial OS under which the unused partitions will be presented." At the top level, the left side lists installed systems, except for "New Fedora 19 Installation". Storage devices that cannot be identified as belonging to any installed system are listed under "Unknown". What do you see listed at the top level on the left side? Could you attach a screenshot showing your particular storage configuration as presented by the installer? Annotate it with comments, if you like. In general, a bug report should address one specific issue, so developers can manage each issue separately. Feel free to open new bugs for specific issues you have identified: Bug Writing Guidelines https://bugzilla.redhat.com/page.cgi?id=bug-writing.html Created attachment 779106 [details]
screenshot showing sda3 listed under "Unknown" in Manual Partitioning
Dale: When you say "artificial OS", are you referring to the "Unknown" list of partitions, as shown in the attached screenshot?
Until I read your comments, I could never understand what was "Unknown" about a known partition. :-)
(In reply to Dale R. Worley from comment #0) > ... there is an "other" category at the bottom of the > left side: ... Could you attach a screenshot showing this? (In reply to Dale R. Worley from comment #0) ... > - creating partitions > - assigning partitions for use as mount points ... Good points. The intent, AIUI, is to do both simultaneously, but that may not seem natural to experienced users who are used to doing each step in order: 1. create partition 2. format partition 3. configure mount point Logical volumes add another complication to this ... :-) BTW, the installer uses /etc/fstab to identify partitions that are part of an installed system. If you comment out a spare partition in /etc/fstab, that partition will be listed under "Unknown" by the installer. That is what I did to get the configuration shown in the attached screenshot. (In reply to Steve Tyler from comment #4) > Good points. The intent, AIUI, is to do both simultaneously, but that may > not seem natural to experienced users who are used to doing each step in > order: I am assuming that the manual partitioning screen is targeted toward users who are quite aware of that disks are partitioned, that the partitions are assigned roles in the OSs that can be booted, etc.. One way of looking at my complaint is that the current format of the screen tries to gloss over those complications and distinctions in a situation where (1) the user does understand the complications, and (2) to be effective, the user has to cope with those complications. In contrast, the default partitioning options do not require the user to understand, but at the cost that the installation reformats one or more disks and dedicates them entirely to the OS being installed. Now that I think about it more, I believe that the default partitioning options are a Good Thing for naive users, but that the manual partitioning screen tries to hide too much from the user. (In reply to Steve Tyler from comment #3) > > ... there is an "other" category at the bottom of the > > left side: ... > > Could you attach a screenshot showing this? I was labeling the item semantically rather than literally. I mean the "Unknown" pseudo-OS, as shown in the screen shot that you attached in comment #2. (I don't know how to get a screenshot from Anaconda, as I only run it via the Fedora install disks.) (In reply to Steve Tyler from comment #2) > Dale: When you say "artificial OS", are you referring to the "Unknown" list > of partitions, as shown in the attached screenshot? Yes. If you look at the organization of the left-side list, the top level is "which operating system installation" and the second level is "which mount point (role) within the operating system". Hence "Unknown" functions like an OS ... Which makes no sense to the user that is not practiced at using Anaconda. (And almost no Anaconda user is practiced at it.) On a larger scale, the problem is that the left-side items are treated as if they are an enumeration of mount points, but if you select an item, the actions you can perform on it are essentially operations on partitions. E.g., if you select an item, you can reassign the selected partition to an entirely different mount point, but you can't assign that mount point to another partition (even if the mount point has no partition assigned and the partition in question is not assigned any purpose). I would like to encourage the maintainers to pay close attention to the usability of Anaconda for naive users. It's the first program that people are going to touch when they try Fedora. Worse, even heavy Fedora users are unlikely to run it more than once every six months, so they will not build up any knowledge of its quirks. Hence the need for it to be very carefully crafted for usability. (In reply to Dale R. Worley from comment #6) > (In reply to Steve Tyler from comment #3) > > > ... there is an "other" category at the bottom of the > > > left side: ... > > > > Could you attach a screenshot showing this? > > I was labeling the item semantically rather than literally. I mean the > "Unknown" pseudo-OS, as shown in the screen shot that you attached in > comment #2. Thanks for clarifying that. I completely agree that there is a mish-mash of categories in the left pane ... > (I don't know how to get a screenshot from Anaconda, as I only run it via > the Fedora install disks.) A digital camera or cellphone photo would be fine. If you are using the Live image, you can use the desktop's screenshot tool. What installer disk are you using? (Live? DVD? netinst?) (In reply to Dale R. Worley from comment #5) ... > In contrast, the default partitioning options do not require the user to > understand, but at the cost that the installation reformats one or more > disks and dedicates them entirely to the OS being installed. ... I apologize for quoting your comments out of context, but this really got my attention ... :-) Did you actually have this happen? Did you lose any data? Was the resulting system bootable? Were other operating systems bootable? FYI, if the install completed successfully, there should be installer logs in /var/log/anaconda/ on the installed system. It would be helpful if you could attach them, so the developers can determine what happened during the install. Please attach them as separate, uncompressed, text/plain files, so they are easy to open in a web browser. In particular, there is a disk selection screen which allows the user to specify which disks are to be used for the install and which disks are to be ignored. Did you attempt to select install target disks with it? Created attachment 781406 [details]
screenshot showing Installation Destination dialog with sdb selected as an installation destination
This dialog lets you select which disks are install targets and which disks are to be ignored. The white on black tooltip displays the disk's serial number, IIRC.
Were any disks that you did not select here reformatted?
(In reply to Dale R. Worley from comment #6) ... > (I don't know how to get a screenshot from Anaconda, as I only run it via > the Fedora install disks.) FYI, the screenshots I have been attaching are from a virtual machine (VM) running in a window: $ qemu-kvm -m 4096 -hda f19-test-3.img -hdb f18-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on http://www.qemu.org/ You didn't ask, but since I am going to keep asking you for screenshots and specifics, here is a mini-tutorial on using a VM: Open a terminal. Create a disk image (size can be from about 12G and up): $ qemu-img create f19-test-1.img 32G Start the VM and select the DVD/CD to boot from (memory can be from 1024 and up): $ qemu-kvm -m 2048 -hda f19-test-1.img -cdrom ~/xfr/fedora/F19/Fedora-Live-Desktop-x86_64-19-1.iso -vga std -boot menu=on Complete a test install. Reboot into the installed system by selecting the disk from the boot menu. For more command-line arguments than you can shake a stick at: $ man qemu NB: Your processor needs to support virtualization: http://www.linux-kvm.org/page/FAQ#How_can_I_tell_if_I_have_Intel_VT_or_AMD-V.3F BTW, there is a GUI front-end for qemu called virt-manager: http://virt-manager.org/ Dale, I should warn you that this is the sort of reaction you may get from anaconda developers when they read a GUI design bug report: Bug 978255, Comment 1. (In reply to Steve Tyler from comment #9) ... > If you are using the Live image, you can use the desktop's screenshot tool. ... On the F19 Gnome Live image, press "PrintScrn" to save the entire screen and alt-PrintScrn to save the current window. Files are named ~/Pictures/Screenshot*. > Did you actually have this happen?
Damn, sorry, I wrote hastily. I've not used any of the naive modes of the Installer, and was incorrectly stating how aggressive the Installer is. What I meant to say was that in a "naive mode", the Installer is necessarily going to be Procrustian will do things the way that it sees fit. That's perfectly fine with me, even if it is rather aggressive, as long as the user is properly warned of things he might find undesirable.
But once the user goes beyond "let the installer do it the way it wants to", the user really will have to be aware that there are partitions, and there are mount points, and that he's creating, deleting, and formatting partitions, and assigning partitions to mount points, etc. There's no way to present the needed information in a way that is simpler than that without obscuring information that the user must have clear access to.
I thank you for working on this, but are screen shots really necessary to address the issue? With enough hassles, I can get screen shots, but is my complaint unclear without particular images? I would think that what you would find it more significant for me to make clear is what I think things ought to look like. I could write up ASCII art for that, but I'm not sure that would be the right thing for me to do. The reason for that is that the issue isn't such things as the screen layout of the data items, but that the screen isn't organized in a way that matches the mental model that the user *must* have to do the task effectively. And I know that I am not a UI designer; I've no reason to believe that any proposal I create would be a good fit for the task either, although it would probably alleviate the one problem that I've identified. The issue needs to be addressed by someone who is aware of the pitfalls of graphically representing a complicated task. (In reply to Dale R. Worley from comment #17) > I thank you for working on this, but are screen shots really necessary to > address the issue? With enough hassles, I can get screen shots, but is my > complaint unclear without particular images? Comment 6 exemplifies why screenshots are more efficient than words ... > I would think that what you would find it more significant for me to make > clear is what I think things ought to look like. I could write up ASCII art > for that, but I'm not sure that would be the right thing for me to do. The > reason for that is that the issue isn't such things as the screen layout of > the data items, but that the screen isn't organized in a way that matches > the mental model that the user *must* have to do the task effectively. And > I know that I am not a UI designer; I've no reason to believe that any > proposal I create would be a good fit for the task either, although it would > probably alleviate the one problem that I've identified. The issue needs to > be addressed by someone who is aware of the pitfalls of graphically > representing a complicated task. Anaconda had a designated GUI designer: http://mairin.wordpress.com/2010/11/18/fedora-installation-user-experience-improvements-syslinux/ (Note the digital camera photos -- there is no operating system running when the syslinux menu is displayed.) A very nice GUI design analysis and mockup: https://fedoraproject.org/wiki/Design/AnacondaStorageUI (Note the extensive use of annotations.) http://mairin.wordpress.com/category/fedora/anaconda/ More from Máirín: The Partitioning Personas are brilliant: What’s your partitioning persona? And, the partitioning UI thus far. http://blog.linuxgrrl.com/2011/12/14/whats-your-partitioning-persona-and-the-partitioning-ui-thus-far/ This shows the anaconda GUI design that was first implemented in F18: More Anaconda Custom Partitioning http://blog.linuxgrrl.com/category/fedora/anaconda/ While we've made some changes around custom partitioning and are continuing to make additional changes to improve things, I'm going to close this bug. First, it's an awful lot of problems rolled into one bug which is always extremely difficult to track and know when you've finished something. Second, we are not a design-by-bugzilla component which this bug report is basically going for. If you would like to discuss things, I encourage you to join anaconda-maint-list. |