Anaconda/UX Redesign/Discussion

UI Structure

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)
• 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.

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.

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.

Storage

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 ye tanother option polluting the screens)