From Fedora Project Wiki
(Created page with "= Feature Name 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 featu...")
 
No edit summary
Line 14: Line 14:


== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
 


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
* The hub and spoke model 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 ==
== Scope ==
Line 23: Line 26:


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged documentDescribe the dimensions of tests that this feature is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate themThe more specific you can be, the better the community testing can be.
Most of the existing test plan relating to the user interface will need to be rewritten, obviouslyThis will require coordination with QAWhile the UI is being written, we have a wiki page describing which parts work and can be tested:  [[Anaconda/TestableUI]].
 
Remember that you are writing this how to for interested testers to use to check out your feature - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your feature.
 
A good "how to test" should answer these four questions:


0. What special hardware / data / etc. is needed (if any)?
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.
1. How do I prepare my system to test this feature? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the feature is
working like it's supposed to?
3. What are the expected results of those actions?
-->


== User Experience ==
== User Experience ==

Revision as of 17:17, 7 May 2012

Feature Name 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

Current status

  • Targeted release: Fedora 18
  • Last updated: (DATE)
  • Percentage of completion: XX%

Detailed Description

Benefit to Fedora

  • The hub and spoke model 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.

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.

Finally, there will not be any available text UI in the first Fedora with the new graphical UI. This is simply due to a matter of time and manpower - there's not enough time to design and implement a second interface at the same time. We are planning on having this finished up for the next Fedora release, though.

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

Release Notes

  • Mentioning the lack of a text interface will be important. A lot of users won't like that, but we need to explain that we're only taking it away in order to bring it back in a much improved form in the next release. Hopefully that will mitigate some complaints.

Comments and Discussion