KarmicOEMConfigImprovements
Launchpad Entry: foundations-karmic-oemconfig
Created:
Contributors:
Packages affected:
Summary
This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples.
Release Note
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.
Rationale
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.
User stories
Assumptions
Design
You can have subsections that better describe specific parts of the issue.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:
UI Changes
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.
Test/Demo Plan
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
Address three issues raised by the Canonical OEM Services team:
1. Better time zone selection (less twitchy, translated cities, less crazy drop down (100s of items), not necessarily clear which city to pick). Debconf has support for a translated list (local names) of timezones per country, but we don't use it because country + timezone are picked at the same time.
* ubiquity and oem-config are similar but the codebases have diverged
* changes don't always get merged back in
* timezone selection has been fixed in ubiquity and need to be migrated to oem-config
* mterry : merging oem-config and ubiquity
- focus effort on single code base and if possible a single package implementation
* don't intuitively know which 'city' to choose (use case: I am in Austin, TX and don't realize Chicago is my timezone city) also, set the correct default time server correctly (potential bug)
* when selecting the nearest city in a timezone, stay whithin the country? (Use case: I click near Austin, TX but a city in mexico gets selected instead of Chicago)
* make it more clear that the timezone map can be clicked on by timezone
* potentially zoom on the timezone map near the cursor (Use case: some places the cities are too close together)
- when zooming, show the cities on the map instead of just the map on the zoomed back view
* translate city names
http://people.ubuntu.com/~evand/tmp/new_timezone_nyc.png
GEOIP coming, RT ticket
Translated timezones, can do.
2. Keyboard selection is confusing for non-technical users. Can we possibly do this automatically or provide a smaller list to make it less overwhelming (restricted to country the user chose)? User isn't sure how many keys they have or if they have dead keys ("none of mine are broken").
* again in ubiquity but not yet carried over
* often we setup a default layout but also install another keyboard layout for the user to switch to after install
- some method of displaying the actual keyboard layout they have already selected (think picture of keyboard)
- more usability testing with the keyboard selection
- possibly use a 'calculate layout' option (from alternate installer)
* localization support
* usernames are limited to latin characters
* hovering text in native language
c http://developer.amazonwebservices.com/connect/entry.jspa?externalID=609
Could do keyboard detection by a few key presses, but we have limited resources and that's a lot of work.
3. Setup wifi, so it's ready to go on first user experience, and we can download language packs.
* Don't have network manager running because it is not a full gnome session
* how do you carry the setup over to the user session or save to their settings
* put the configuration into the installed system (for ubiquity) for the user
Network Manager Netbook: http://www.gnome.org/~michael/blog/2009-05-21.html
4. username limit to latin chars
* covered above
5. Fallback to -debconf config if X fails (https://bugs.edge.launchpad.net/ubuntu/+source/oem-config/+bug/315647)
* Use case: user boots to the system, but it doesn't boot into X
- fall back to a usable debconf instead of nothing
* will fall back to bullet-proof X after they setup their user
- what about falling back to bullet-proof X for the user setup? and never drop the user back into a console
6. Purge unneeded language packs (https://bugs.edge.launchpad.net/ubuntu/+source/oem-config/+bug/315644)
* Use case: we preinstall all language packs, when the user installs the system, they still have tons of unused languages installed and now need to update them which takes longer than nessesary
- solvable by network connectivity and downloading just the one you need? what about no network
- if you are not on the dvd and use the cd you download the needed language pack
* choose which language packs to keep and which ones (all the others) to purge after the oem-config process
- prevent unnessesary package updates
- computer janitor?
- language selector?
* at least the default language needs to be there, other languages could be done later
7. Add support to show EULAs for third party packages
* EULA text is also localized
* potentially a EULA viewing page object that can show EULAs
8. Simplify mechanism to add pages to wizard
9. hooks to run scripts after oem-config completes (system hooks, user hooks)
* Ubiquity does this, so should oem-config
* add to debconf template
* we have scripts that need dpkg and oem-config has a lock on it
* useful to have a script for the first time the user logs in
- Use case: finding out the translated music directory?, also for branding