Anaconda/UX Redesign/Discussion

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: 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
• give good guesses at locale and language info / make the most likely selections more prominent

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