|Release target||Firefox 15|
|Status note||This feature will be worked on as a Spring 2012 course project for students at Michigan State University. Jared Wein and Blair McBride are the Mozilla points-of-contact for the project. Probably land in 15 but may not ship until later.|
|Product manager||Asa Dotzler|
|Directly Responsible Individual||Jared Wein|
|Lead engineer||Jon Rietveld|
|QA lead||Mihaela Velimiroviciu|
|UX lead||Zhenshuo Fang|
|Product marketing lead||`|
Security and usability concerns associated with letting content area widgets modify the surrounding browser
Stage 1: Definition
1. Feature overview
As part of UX's goal to eliminate Firefox's separate management windows in favor of in-content designs, the Preferences window should be moved into the content area.
Such a move provides several benefits for users. First, it removes yet another easy-to-lose window. It means that changing preferences in Firefox can be an identical and easy experience across all devices, including tablet computers. It also means that more interactive portions of Preferences, such as about:permissions, can be integrated with the rest of preferences.
This feature falls primarily in the Experience category (from the "Discover, Experience, and Connect" vision statement.)
This project has two major components:
Move Preferences into in-content pages
Redesign Preferences such that their current usability problems are fixed and they integrate well within the content area
Improve the design of Preferences
Integrate the parts of Firefox that should be in Preferences (such as the Add-ons Manager)
Move Preferences into the content area
2. Users & use cases
Modifying Firefox, using add-ons
In-content UI Visual Unification: https://wiki.mozilla.org/Features/Firefox/In-content_UI_Visual_Unification
A fully-integrated, usable, redesigned Firefox Preferences which displays in the content area of the browser.
- It is not a goal of this project to modify the organization of the preferences. - It is not a goal of this project to move the modal dialogs accessed through the current preferences window to be rendered in-content. Those dialogs, e.g. the Saved Passwords dialog, will remain as a modal dialog for this project.
Stage 2: Design
5. Functional specification
The preferences will be implemented as a single XHTML document that includes different sections for the various panes. The sections will be shown/hidden based on the search filter.
There will be 7 predefined filters that will match the current sections of the preferences window. These filters will be presented as sidetabs when viewing preferences.
Searching using the search box in the upper right will visually bring the view to search results sidetab but will not require a pageload. Sections of the page will be shown/hidden based on the matching of the filter.
pushState/popState will be used to track navigation through the page and allow traditional back/forward navigation to continue to work.
6. User experience design
See these pages for mockups and designs of the new in-content preferences:
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
Meta bug: bug 718011
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
|Engineering team||Desktop front-end|
Team status notes
|Quality assurance||in progress||Test Plan|