KubuntuKarmicUbiquity

Differences between revisions 1 and 2
Revision 1 as of 2009-05-28 23:04:43
Size: 2873
Editor: 80
Comment:
Revision 2 as of 2009-06-09 15:19:46
Size: 1556
Editor: c-98-242-85-201
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
Ubiquity has reached a certain level of maturity but still lacks in some of the User Design and KDE Integration elements to really make the install process a better one. The installer should aim to be both functional and visually appealing to new users as it is often their first usable impression of the system. The goal is to use plasma drawing primitives to decorate existing elements and improve the general aesthetics without sacrificing usability and accessibility.  Ubiquity has reached a certain level of maturity but still lacks in some of the User Design and KDE Integration elements to really make the install process a better one. The installer should aim to be both functional and visually appealing to new users as it is often their first usable impression of the system. The goal is to decorate exsisting elements (adding new elements where needed) to create a more asthetically pleasing install experience for the end user.
Line 14: Line 14:
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

It is mandatory.
Line 20: Line 17:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

== User stories ==

== Assumptions ==
Other distros have good looking installer that don't look like just a basic application on the desktop. The installer is often the first experience the user has with the system and it should be a pleasant one.
Line 28: Line 21:
You can have subsections that better describe specific parts of the issue.
Line 32: Line 25:
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: The majority of the cahnges will focus around using Qt CSS to do cosmetic work on the current interface. New elements will be added as needed only when there is good implementational, usability, or asthetic reason.
Line 36: Line 29:
Should cover changes required to the UI, or specific UI that is required to implement this

=== Code Changes ===

Code changes should include an overview of what needs to change, and in some cases even the specific details.

=== Migration ===

Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.
TODO: mockups
Line 51: Line 33:
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

== Unresolved issues ==

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

== BoF agenda and discussion ==

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.
User feedback will be the most critical phase of testing the new installer look and feel. Will look into running just the installer shell without a backend so testers can just walk through the steps to get a general feel for the interface.

Summary

Ubiquity has reached a certain level of maturity but still lacks in some of the User Design and KDE Integration elements to really make the install process a better one. The installer should aim to be both functional and visually appealing to new users as it is often their first usable impression of the system. The goal is to decorate exsisting elements (adding new elements where needed) to create a more asthetically pleasing install experience for the end user.

Release Note

Rationale

Other distros have good looking installer that don't look like just a basic application on the desktop. The installer is often the first experience the user has with the system and it should be a pleasant one.

Design

Implementation

The majority of the cahnges will focus around using Qt CSS to do cosmetic work on the current interface. New elements will be added as needed only when there is good implementational, usability, or asthetic reason.

UI Changes

TODO: mockups

Test/Demo Plan

User feedback will be the most critical phase of testing the new installer look and feel. Will look into running just the installer shell without a backend so testers can just walk through the steps to get a general feel for the interface.


CategorySpec

KubuntuKarmicUbiquity (last edited 2009-06-18 22:05:53 by c-98-242-85-201)