Support/Firefox Features/Clean up user profile/v2

From MozillaWiki
Jump to: navigation, search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

Status

Automatically Fix User Profile
Stage Stage II
Version TBD
Health Ok
Status note Need to set up a meeting with Alex Limi and Dave Townsend


Team

Product Manager
Feature Manager Michael Verdi
Lead Developer Dave Townsend
Security
Privacy
Localization
Accessibility
Quality assurance George Carstoiu (irc: GeorgeCarstoiu)
User experience Alex Limi
  • Feel free to list other team members below the table here.

Open issues/risks

  • Using the installer to do this is not a good idea but the process could be triggered in the installation process
  • How could this work on OS X and Linux since they don't have the same install process as Windows?
  • There is a plan to remove the Profile Manager UI (Bug 214675) and add an external Profile Manager application (Bug 539524). This solution is fine from a testing point of view but for the user who is just trying to fix Firefox this will complicate an already difficult process. Our feature would make the removal of the profile manager ui irrelevant from the user's point of view.

Stage I: Definition

1. Feature overview

We should provide some way for users to automatically fix Firefox by fixing their profile while retaining their data (bookmarks, history, passwords, etc). There are a number of serious Firefox issues (not starting, crashing, unexpected behavior, lost toolbars and more) that can be solved by fixing the user's profile. The problem is, fixing a profile is an incredibly difficult task – see these two articles (1, 2) for complete steps. Many users try to reinstall Firefox to solve these issues but reinstallation doesn't do anything to the profile folder. Providing this option on installation could make it both intuitive and discoverable.

2. Users & use cases

The goal is to take a difficult and confusing repair process that most people never discover (and often need one on one help to complete when they do find it) and turn it into an easy and discoverable operation that can be done without guidance.

Example:
A user determines that "something" is wrong with Firefox, so they attempt to fix it by reinstalling. The installation process should afford some mechanism for the user to repair Firefox (by repairing/creating a new profile and retaining the user data).

3. Dependencies

Defining giver dependencies and taker dependencies so you know who owes to whom what and when.

4. Requirements

  • Easy to use
  • Easy to discover (Ideally the user shouldn't have to go to SUMO to figure this out)

Non-goals

  • A Clean Install is another repair process that is not covered by this feature.

Stage II: Design

5. Functional specification

What the feature will do to satisfy the requirements, in written form.

6. User experience design

Designs, interactions, etc., mainly in visual form, if relevant.

Stage III: Planning

7. Implementation plan

Summary of the high-level approach to be taken

8. Security

Are there security risks; has the design been reviewed; what needs to be changed before we proceed?

9. Privacy

Are there privacy risks; has the design been reviewed; what needs to be changed before we proceed?

Stage IV: Development

10. Implementation

Links to bugs -- we don't try to track the detailed progress here, that should happen in bugzilla.

Stage V: Release

11. Landing criteria

Final checklist for everything the feature team feels should happen before a feature can land -- could be a scalability model, security code review, etc. Will eventually develop a standard table for this.

Feature details

Priority "unprioritized", "P1", "P2", "P3"
Roadmap whichever Roadmap this Feature is from, or set by Prod Mgr
Secondary Roadmap {{{secondary roadmap}}}
Feature List "Desktop", "Mobile", "Platform", "Services", or "Other"
Engineering Team Engineering team who will be doing primary development.
  • Property "Roadmap" (as page type) with input value "whichever Roadmap this Feature is from, or set by Prod Mgr" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
  • Property "Secondary roadmap" (as page type) with input value "{{{secondary roadmap}}}" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
  • ""Desktop", "Mobile", "Platform", "Services", or "Other"" is not in the list (`, BYOB, Desktop, Marketplace, Mobile, Platform, Plugin Directory, Services, Thunderbird, Jetpack, ...) of allowed values for the "Feature list" property.

Team status notes

Teams are welcome to use these fields however they see fit. Both fields can be used in queries to generate lists on other wiki pages. If you would like help or have questions, please contact Deb.

  status notes
Products
Engineering
Security
Privacy
Localization
Accessibility
Quality assurance
User experience


Revision history

date author change
2011/06/16 Michael Verdi Updating to new feature page format.