Here's some UX redesign discussion notes from #anaconda today, with the todos/questions 'action items' upfront: Action items / Questions ======================== * Figure out boot camp instructions for mac users, a test run-through might be good (anybody got a mac and a copy of bootcamp?) * 'BOOTCAMP' partition auto-detection * Check / if !BOOTCAMPpart && hw = mac, display 'you need to run bootcamp' screen as very first screen * Figure out chkdsk instructions for Windows users * Work with websites team on redesign for get.fpo to accommodate all this * Documents for root of install disc for Mac boot camp / VM install / windows * (mo) Investigate non-grub issues users are currently complaining about re: linux+linux dual boots * grub2 upgrade, will it make linux+linux dual boot better? * Investigate/implement resize dry-run mode, including resize estimate & rpm test run to see how much space selected sw choices will take * Need solution for not-enough-space for upgrades issues (because of scriptlets' temp space?) * KS file save to usb option, incl. screen under quit button to ask if you'd like to save * KS file auto-detect functionality, incl. screen to ask if you'd like to continue from previous KS or start fresh Dual Boots ========== We talked about the user experience for three types of users who already have an operating system installed: - Mac users with OS X installed (<= likely a key portion of our target userbase we're not accommodating very well today) - Windows users - Non-Fedora Linux users - RHEL users The story here is a user who's already using a non-Fedora OS, who is ready to try Fedora but doesn't want to blow away their old OS in case they decide to bail out. The recommended path for these users is going to be dependent on their starting point: - Windows users: chkdsk, then Anaconda - Mac users: Boot Camp, then Anaconda - non-Fedora Linux users: resize Let's walk through each user scenario, going over the points that were brought up for each: Windows User ============ Install path: chkdsk => anaconda resize => dual-boot install The Windows users need to run chkdsk before going into anaconda. They need to run chkdsk because if their filesystem is dirty, chances are high that a resize operation will corrupt their filesystem (the chances of filesystem corruption when you resize without chkdsk are even greater if they are using Vista or Windows 7.) There isn't much we can do for them; they really need to run chkdsk on their own. One resource we do have at our disposal is ntfsfix, which is a utility that can fix common errors, but the downside to this is that if users press any key while it runs, it'll skip the filesystem check operation, rendering the whole process useless. So we'll need to lean on them and make sure we document well the chkdsk process. Will found this following documentation on shrinking partitions in Windows: http://technet.microsoft.com/en-us/library/cc731894.aspx Elad has experience supporting Windows users and is familiar with the tools involved as well. Mac User ======== (The doom some Mac users have experienced getting grub working to start, and GNOME 3 graphics working to finish aside) Boot Camp => anaconda auto-detect bootcamp partition => dual-boot install We don't have any support for resizing HFS/HFS+ partitions which is the main filesystem Macs use. So out-of-the-gate, Anaconda resizing is not possible for Mac users. Boot Camp is the Apple supported way of dual-booting, so we need to advise our Mac users starting out that they should work in Boot Camp first, then install Fedora. Will had the amazing idea that we could autodetect bootcamp partitions in anaconda so when these Mac users end up in the installer, we'll have the storage settings they need ready-to-go and they won't need to touch them. The Boot Camp partitions are easy to detect: look for a FAT32 partition labeled "BOOTCAMP". We had another idea: we can detect if a user is using Mac hardware. In the case they are using Mac hardware AND we don't detect a "BOOTCAMP" partition, we could push a warning screen before hub #1 that tells them "You should run Boot Camp before installing Fedora (unless you really, really know what you're doing." and offer a quit button. Grub issues will hopefully be improved when we upgrade to Grub2. Non-Fedora Linux Users ====================== anaconda resize => dual-boot install We have a few problems in our dual-boot Fedora + another Linux story today: * We don't label other distros properly in GRUB * We don't tell other bootloaders about Fedora. If you install Fedora first, then install another Linux, you won't have a boot entry in your bootloader for Fedora by default. For less-experienced dual-booters, this means they won't be able to boot Fedora (fail) I think we need to do some more research on folks' complaints about Linux+Linux dual boot scenarios with Fedora, these are mostly GRUB issues but I think there might be issues too in the storage section, when we auto-detect a Linux partition I don't think we say what distro it is either. RHEL users ========== Folks looking to try out RHEL usually install to a virtual machine, so they don't face the storage quandries that would be a lot more common for the Fedora use cases above. Supporting Users in these scenarios =================================== Some of these (Mac most notably) paths aren't documented at all today on the Fedora website. Others could stand to use a bit more documentation & guidance (*especially* on the download Fedora pages of the Fedora website.) Some ideas: * More information on the get.fedoraproject.org webpages to guide users depending on which OS they are starting out with * Peter's awesome idea: have QR codes so that folks can read the instructions on their smart phone as they install on their machine (useful if they have a smartphone and only one laptop) * Have documentation in the root of the disc for these scenarios, especially important if the users received a physical disc from a conference and did not go through the website. Document suggestions: * Mac Boot Camp instructions * VM Installation instructions * Windows instructions * Have blurbs on the sleeves for printed Fedora media for each of these scenarios as well Resize issues ============= We also talked about how the storage UI pieces fit into the overall UI screen map. There's a complication that resizing introduces. The designers would like all options in hub #1 to be non-commital and reversable until the users hit the 'proceed with installation' button. However, the resize case is not reversible at this time. A solution could be to implement a dry-run version of resize. Here's the issue: we don't know how much space we'll have available post-resize. We can only know by running it today, since there is no dry-run version. A dry-run version of resize would need two components: (1) Dry run of the resize to determine how much space we'd get (2) A dry run of the RPM transaction to determine how much space we'll need There's a complication with upgrades here too, especially during preupgrade. The amount of space an install needs - the estimate can be off enough to cause the upgrade to fail. In Will's words: "We can *guess* how much room RPM will want for the install but it's not a guarantee until we actually try to run the transaction with the disks live." Confounding factors include the temp space scriptlets consume. One potential work-around is to save out the resize operation commands in the kickstart, and not run it until the user hits 'proceed to install'. 'Apply', in the context of Hub #1, is 'save to kickstart object. Saving KS ========= This all led into a discussion about our plans to save out partial KS for users who bail out before installation. There's a couple of ways we could go: - Save out to a KS file every time a field in a hub spoke is modified AND when the user hits 'proceed' or 'quit' - Save out to a KS file only when the user hits 'proceed' or 'quit' Not sure which is best, the later is easier to do but maybe work would be lost if we didn't do the former and a crash occurred. The story for saving a kickstart: You're jamming around anaconda filling stuff out, and you realize it's 5:30 and it's time to go home. No time for an install. You hit 'Quit' (maybe not intuitive, maybe needs to be 'Save and Quit') and a dialog pops up: "If you'd like to save your selections to a kickstart file to use later, insert a USB key with at least $FILESIZE free, and press the 'Save' button below. Insert some awesome instructions here on how you'd proceed with the install later on. \n Otherwise, you can quit using the 'Quit' button below." <= okay not the best verbiage but you get the gist Okay, so you go home, eat dinner, sleep, head back into the office where Anaconda awaits you. You turn the machine back on. It looks for a saved KS file. Oh crap, you forgot to insert your USB key. Okay, so now that I'm writing this up, I'm realizing auto-detection is maybe stupid because who would remember to insert the USB key before turning anaconda on? We could have a little inconspicious 'Continue a previous installation' on the front language selection / splash screen maybe?? In either case, somehow you are miraculously compelled to insert a USB key with a KS file valid for the version of Fedora you're installing. If we find this KS file, a dialog pops up, before you hit hub #1: "We've found a previous install attempt from $DATE. Would you like to continue with this previous installation, or would you like to start fresh?" --- Okay I'll try to integrate this into the wiki discussions page now. I'm a bit behind on documentation here; I've got tons of notes; just need to get them in the wiki. :) Here's the full log btw http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Notes/irc-log-21june2011.txt ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
