Anaconda/UX Redesign/Discussion

The organization of this page is fairly arbitrary; if you've got a better scheme please feel free to either re-organize or slap your own section on at the end.:)

UI Structure

Save-your-progress via Kickstart to USB Key

'Apply', in the context of Hub #1, is 'save to kickstart object.

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?"

Language selection at the beginning of the flow

One concern with the hub-and-spoke model was raised by elad - if users can´t read the text in the UI (especially the hub) they might not know how to change it to their language. We could ask language up front, and allow it to be changed again in the hub as desired. Input method should be chosen later though, because if someone types in say Hebrew or Japanese it would cause issues auto-generating their username and the system hostname.

One proposed screen flow:

Language? => Name? => Hub => Progress bar => Done

Note that anaconda only has the languages and keyboards for what anaconda itself supports.

Move from Wizard-based linear UI to a Hub-and-Spoke Model

We would like to move to a hub-and-spoke UI model (common in mobile device settings dialogs) rather than the current linear wizard model. This affords a few things:

• If there´s only a few things you need to modify before installation, it´s much faster to get where you need
• If you need to go back and change something you set earlier, it is at most 2-3 clicks away rather than having to navigate backwards through every single screen
• It´s a scalable model - more features can = more spokes
• It´s less total clicks required for an install, given sane default settings.
• The hub also can serve as a ´shopping cart' or inventory of what you selected which you can read through to confirm before going through with installation.

Inventory loader and try to integrate what makes sense into UI

Ideally we would be able to get rid of loader, so it would be good to integrate what we can from it into the UI. Here's a quick loader inventory:

• Media check
• Load updates.img - UI not needed for this
  • cant do in UI... it´s too late; you´re already in the installer (unless this is done in a pre-UI)
  • Used by testers and developers
• Load product.img - UI not needed for this
  • product.img is a way to brand anaconda for your own distro or tweak it
  • you can also modify installclass, which effects which screens show up
• Fetch kickstart file
• Driver disks (auto or not)
  • Driver Disk documentation
  • it's for OEMs to provide drivers for stuff we don't ship drivers for
  • allows you to load drivers for hardware not supported by the stock runtime/images. this is especially important if you need to install from a network source but your network card drivers aren't supported natively
  • it's also for hardware that ships after our releases, when we don't have drivers yet.
  • 'traditionally I think users do dd=whatever and we load from the specified source; the newer stuff also has a way to detect that some media is a driver disk and handle it automagically IIRC' (pjones)
  • end-users going thru the installer and OEM builders need to load driver disks
  • not sure how frequently / how widely they are used
  • the driver disks are shipped by, for example, dell. dell has a system where there's essentially an internal USB stick with the drivers on it. not sure about other manufacturers - they may require you to download drivers / make your own physical disc. dell are likely more sophisticated than most hw vendors
  • 'Driver diskettes can be used during kickstart installations. You need to copy the driver disk's contents to the root directory of a partition on the system's hard drive. Then you need to use the driverdisk command to tell the installation program where to look for the driver disk. ' <= in actuality you'd probably use USB stick, CD, DVD - but there is NFS support
  • Some discussion on driver disks in anaconda in this bug
• Run firmware loader process
• Kick off hardware probing
• Load a lot of modules
• Prompt for and load keyboard layout & language
• Process basic kickstart commands (halt/reboot, network, method)
• Bring up network
• Network Proxy setup => would be good to do in GUI
• Serial console installs
• Enable debugging mode

We may not be able to kill loader though because removing askmethod from loader means breaking implicit updates.img fetching.

What Goes in Anaconda / What Goes in Firstboot?

Stuff moves between the two a lot. One idea: add firstboot plugin support to Anaconda so it's easier to switch things between the two.

Mizmo thinks firstboot is only useful for OEMs and that we should make it possible to install without using firstboot by default and special case it for OEMs. One problem here is figuring out where to display the license agreement (maybe in ransom notes?)

Fedora vs RHEL

We can use installclass to modify the screens present / screen flow in Fedora vs RHEL but the less changes between them, the more testing either will get.

Install Methods

Combine Live media and DVD?

Today live media and DVD are separate. bcl is working to generate the live media images with Anaconda, since they aren't today and because live media are generated via a different code path, various stability issues are present in live media installs today. One of the issues, that dlehman says has gotten a bit better over time but still needs improvement, is that the user can interact with the live image as it's being installed, which can make the install fail in weird ways. (It's kind of a pulling-the-tablecloth-out-from-under-the-meal kind of problem, where the system is the tablecloth and the meal is the install process.)

It might be preferable to have a single all-in-one installation ISO... one that is live bootable, yet also has a full-blown Anaconda installer as well. It's only one piece of media to download, and one codepath for installations making installation more stable, easier to test, easier to debug.

One idea is that you would boot off of a live DVD and when you are are ready to install, clicking on the 'install to hard drive' icon boots the machine into full anaconda, either via modifying the GRUB configuration or using kexec.

An alternative solution to the 'tablecloth' problem would be to full screen Anaconda's window during live install with no option to minimize it.

A downside to disabling the live environment during install is that users say they like to be able to read documentation while installing.

Repo selection / Fedora People Repos

Today anaconda has a UI where you can add custom yum repos to your system, and where you can update from a repo rather than just what's on the media so you'll boot into a fully-updated OS. However, it could use some improvements.

One idea we had (currently in the mockups) was to let users add custom yum repos or browse a selection of available repos.fedorapeople.org repositories. PackageKit. PackageKit - the only GUI users have available post-install to work with software installation - does not allow for adding custom yum repositories. If anaconda does, there will be a bit of a mismatch. Part of the rationale of PackageKit not allowing it is (I believe) because of security / trust model concerns, and also because dependency changes in Fedora could change out underneath the Fedora People repo packages, making them non-functional. There are apparently a number a problems the Ubuntu PPA system has unsurfaced that would be unsurfaced should this be done. Here's an IRC log with hughsie on the topic that might help. PackageKit does not allow adding additional repos beyond Fedora, Fedora updates, Fedora updates-testing, Fedora rawhide

Some other concerns providing a Fedora people repo browsing interface:

• Fedora people repos are used to both provide software not included in Fedora AND to provide newer versions of software that is already in Fedora, overriding core Fedora software.
• Fedora people repos don't have comps. They might need them? Default / mandatory / optional packages would need to be defined otherwise nothing from the repo would get installed, right?
• Fedora people repos are not QA'ed and you need to trust the provider before installing from them. We would need some kind of warning indicating this.

We might need to update/institute Fedora people repo conventions / guidelines / rules on top of what's already there.

Specifying repos is definitely a requirement for those testing packages.

If someone enters a freeform repo URL, should we detect if it´s a mirror or not?

If we remove optional package selection, then repos will need to better think about each package. Right now there is default / mandatory / optional. Optional will be dropped.

UI Functionality

New feature: Keyboard layout testing text input box

We'll whittle down the GNOME 3 control center keyboard layout options, and in the resulting space add a text dialog users can use to type a bunch of text to see if their keyboard layout is selected properly. Chris said many users have requested such a functionality for a long time.

We'll also whittle down the options dialog to only allow for the configuration of layout switching, since non-live install won't have any other way beside key combos to toggle between layouts while the users fill out the various screens.

The way our discussion on this went was that the current options popup in GNOME 3 shows all of the options available in /usr/share/X11/xkb/rules/evdev.xml - way too many options than are really needed for the bare essentials of getting through the installer successfully in the correct language. We decided that layout switching *is* important to keep though, since again, non-live installs have no panel so there's no layout chooser otherwise.

We're deviating somewhat from the upstream GNOME keyboard layout screen design here, but not too much. We're removing:

• reset defaults button
• layout applies to all windows vs individual windows radio buttons (just not necessary in anaconda)

New feature: Password strength for user password selection

Would be nice to have a password strength meter for the user creation bits. Could use the new GNOME accounts dialog?

Individual Package Selection Removal / Adding Spins selection

We would like to remove the notion of individual package selection.

There are some issues that individual package selection causes today:

• Users can customize their package selection much more easily post-install via PackageKit or yum, where more information about individual packages is at their fingertips.
• Users can install individual packages in a live environment, and may suffer some confusion / annoyance when they realize their lovingly hand-picked packages are gone after rebooting into their fully-installed system.

Is there any other rationale here?

One reason people install software during install is because they have no / bad internet and they would like to install software that's on the DVD (or USB stick) but not in the default install. We can´t support this post-install right now because of a PackageKit bug that should be fixed.

Why do users like choosing individual packages in the installer vs. post-install? Is there any advantage to this? (Not sure.)

We could replace individual package selection with better high-level / abstracted software customization.

New feature: Saving user progress

One new feature we are considering is to save out a partial kickstart file if a user quits Anaconda before finishing. If we detect a partial kickstart file on a USB stick in th emachine, we'll reload all of the fields the user had filled in thus far so they didn't have to restart from scratch.

New (again) feature: Ransom notes

We would like to bring back the 'ransom notes' feature of Anaconda. You know, the feature that introduced the world to the glorious beefy miracle. They make the install process more fun and give the user something to look at as their install progresses.

Ransom note ideas:

• Where to get help
• Planet Fedora promo
• fedoraproject.org/using tutorials

New feature: sudo by default

Allowing the first-created user to have sudo by default would be nice. This may mean user creation should be in anaconda, though?

Install Progress screen

Aside from ransom notes, bcl suggested we could show a full log of the install progress on the progress screen. Mizmo suggested making this possible, but doing it as plymouth handles this - having a documented hot key to trigger a full-screen log mode, so most users wouldn see the log.

Clumens suggested we continue to display the currently-being-installed package on the progress screen.

Aruiz noted that Ubuntu asks for user details (the type we collect in firstboot) during the installation´s progress.

Automagical Media check

Move media check out of loader. Live media uses dracut to verify media. The DVD doesn't (not sure how it does media verify.) Things to consider:

- Automatic media check for DVDs - Automatic media check for Live Media

How long does it take though? Would the amount of time the media check takes be worth simplifying install by dropping a screen to ask if the user wants media check?

If media check is an option, where would it go? (Maybe in the 'install source' spoke?) If you already performed a media check though, it wouldn't make sense to offer it a second time so don´t show as an option in that case.

Add askmethod options to UI

Askmethod has a text-based UI that allows you to install via various network-based methods. Today ´askmethod´ is a parameter you can specify in syslinux (or via ks, or via a parameter in a repo.)

The methods askmethod supports: - CD - HDD - NFS - FTP - HTTP

With networked install sources you may need to provide information for a network proxy.

You may also need to provide information to connect to a wireless access point.

Right now the askmethod TUI has a place where you can make network card lights blink in a specific pattern in order to identify them. Is this still a necessary feature?

(We´ll of course keep the command line askmethod argument, we may potentially kill off the TUI if we can build good GUI for it)

Pulling in GNOME control center applets/widgets to reduce codepaths

Hadess (Bastien Nocera) is the contact person for the GNOME control center but he said that it is difficult to pull in control center applets from other applications and there is currently no work being done to make it easier, either. They are written in C.

Multiple user creation in installer

Other installers do this. Do we want to?

Storage

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'.

LVM by default?

Maybe we shouldn't default to LVM. Not for Fedora users. Does LUKS require it? (It doesn't seem to.)

Non-UI functionality

Image creation and cloning

Have a way to use anaconda to create / clone OS images?

Mirrors

Use Fedora mirror list by default for local fast copies of software. (Do we not do this now?)

IP-based geolocation

Could be a sexy way to:

• select an appropriate mirror
  • MirrorManager already does this automatically.
• give good guesses at locale and language info / make the most likely selections more prominent
  • To what degree of specificity do we need? Is country-level good enough, or do we need city/state data? I expect the latter. MirrorManager doesn't have that level of detail today.

Install updates by default

If network is up, and the user is installing via local DVD, mirror, or USB - install software updates by default. The rational for this is that folks will be booting into a fully-updated system. The rationale against it is that updates can make installation take much longer.

If updates make it take much longer, maybe give the user an option to bail out while the updates are being downloaded but before yum begins to apply them.

Installing updates by default is a bad option for the following install types:

• http
• nfs
• HDISO

Could maybe just ask the user. (Downside of this being yet another option polluting the screens)

Documentation / Other Dependencies

Supporting Users Coming from Other OSes

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

Better Dual-Boot Support

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.