New Installer UI
Summary
The existing anaconda graphical UI is really starting to show its age, both to the users and to the developers. Adding new features (especially for new storage technologies) is difficult, and there's no apparent overall design to the user experience. We'd like to fix that.
Owner
- Name: Chris Lumens
- Email: clumens@redhat.com
Current status
- Targeted release: Fedora 18
- Last updated: (August 17, 2012)
- Percentage of completion: 80%
Detailed Description
The existing UI doesn't really have any cohesive design to speak of, nor has it seen any serious work in the past six or seven years. As such, we are really starting to hit the limits of what we can do with it. On some screens (for instance, the partitioning-related ones) there is entirely too much going on while other screens (like the root password) have very few widgets amid a sea of grey background color. Further, adding to the UI means either everyone has to see the new screen, or we have to come up with clever hacks for only making it appear in certain situations. There are also a whole lot of subtle little bugs due to the fact that much of our UI code is written by hand.
By replacing the existing graphical UI with our newly designed (and already being implemented) interface, we can fix all these problems. We started about a year ago with extensive design discussions that pulled in a variety of community and corporate user groups. We are now several months into implementation, during which time we are also modernizing the anaconda internals to allow us to be more responsive to future feature requests.
Benefit to Fedora
- The hub and spoke model (see the User Experience section) means every user doesn't have to go through every page, making for a faster user experience and allowing us to add new pages without making a more complicated UI.
- Third parties (rebuilders, etc.) will have a variety of methods for customizing the installer.
- Users should notice a more consistent experience and a better use of screen space throughout.
- Doing long-lived background tasks while the user is working on other things makes for a faster installation.
Scope
The changes are almost completely isolated to anaconda (there's some lorax patching required, but that's minimal). However within anaconda, this is a major body of work. We are taking this opportunity to also rewrite the packaging layer which is full of weird bugs, convert the internals to use pykickstart as a data store, remove old code, and more. This is on top of the design work and writing all the new UI.
How To Test
Most of the existing test plan relating to the user interface will need to be rewritten, obviously. This will require coordination with QA. While the UI is being written, we have a wiki page describing which parts work and can be tested: Anaconda/TestableUI.
We're putting images in front of QA right now, and the early results can be seen at UI test results.
It is my hope that we can come up with some way to automate UI testing, but I have not yet seen anything very promising.
User Experience
The graphical UI will be completely redesigned, so there will be a completely new user experience. The UI model we are following is called a hub and spoke. The user will get a limited number of screens up front that they must fill out (things like language), and then they will be put onto the first hub. From this hub, the user can choose what things to configure in the order they see fit. Then, they proceed to the second stage of the install where all their selections take effect.
We are also working on making a lot of tasks like repo metadata downloading happen in the background so the install is faster.
Dependencies
Since this new UI is making use of the latest versions of lots of GUI tools, lorax will require some changes to include new packages in installation images. Also, we are dependent upon those GUI tools and libraries not having any major bugs that stop our progress. So far, so good.
Contingency Plan
Development has been happening on a separate branch of anaconda git. We have a couple self-imposed deadlines, each of which is going to have a different contingency plans.
First, at some point before the development freeze, we need to merge the newui branch into master in git. At this point, regular anaconda builds will include the new UI and that's what everyone will see. Should we not get to a point where we're comfortable with merging before the development freeze, the contingency plan would simply be to not merge and wait for the next Fedora release.
Second, after merging we are kind of committed to taking this UI in for Fedora 18. It will be too large of a body of work to revert. Plus, much of our effort will have been spent on the newui branch which means regular bug fixing will have suffered. I do not have a good idea of what the contingency plan for this point will be.
Documentation
- Our documentation is linked from Anaconda/UX_Redesign
Release Notes
- I had previously stated there would not be a text mode for F18, which was a hedge given that no work had been put into it and no one was tasked with making it happen. However, we found some people with some spare time so there is currently a basic text mode and I expect it will be much more complete (though perhaps still lagging the GUI a bit?) for this release.
- There will be no advanced filtering UI for this release. Most Fedora users never even see this interface. It's primarily for big enterprise installations and those users will not be completely out in the cold. They will still be able to do installs but will just have to sift through all their many disks without help. This will be fixed for F19.