Status
| Panel Menu | |
| Stage | Development |
| Status | In progress |
| Release target | Firefox 24 |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Panel Menu
|Feature stage=Development |Feature status=In progress |Feature version=Firefox 24 |Feature health=OK |Feature status note=` }}
Team
| Product manager | Asa Dotzler |
| Directly Responsible Individual | Stephen Horlander |
| Lead engineer | Blair McBride |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | Stephen Horlander |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | Jared Wein, Mike Conley |
{{#set:Feature product manager=Asa Dotzler
|Feature feature manager=Stephen Horlander |Feature lead engineer=Blair McBride |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=Stephen Horlander |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=Jared Wein, Mike Conley }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
For Firefox 4, we changed the menu to be a single, unified menu. This project is the next step in this evolution, which unifies the concepts of toolbar customization, adds the ability to customize the menu, and makes the 80/20/2 rule have a natural mapping in the UI.
It also provides a path for mapping the same menu structure to mobile devices like phones and tablets, as well as TVs and projection screens.
2. Users & use cases
Simplifying the ability for users to find what they're looking for, increase relative discoverability for the important items, have a predictable and consistent approach to interface customization.
3. Dependencies
`
4. Requirements
`
Non-goals
`
Stage 2: Design
5. Functional specification
`
6. User experience design
Known design requirements:
- Redesigned Panel based Firefox Menu living on the toolbar
- In-Content Customization Tab/Mode
- Icon drag-and-drop including:
- Dragging from a tools palette to the Menu or a Toolbar
- Dynamic icon rearrangement and visual placement (i.e. you can see exactly where you are placing your icon not an abstract placement indicator)
- Visual indicators for acceptable drag areas
- Customization Mode Appearance including:
- Additional browser padding
- Toolbar and/or Window textures
- De-emphasis of non-relevant areas of UI
- Contextual Options menu for:
- Small Icons
- "Reset to Default"
- Reduce toolbar item redundancy and complexity by eliminating "magical" button merging behavior
Potential requirements:
- Direct manipulation of items in addition to drag-and-drop:
- Direct selection
- Buttons for Add/Remove
- Layout options
- Small Icons
- "Reset to Default"
Potential design variations:
- Icon and Grid based menu vs. traditional single column menu
TBD and Alternative Ideas
Stage 3: Planning
7. Implementation plan
Open UI questions
- In the panel UI, should built-in widgets be separate from add-on widgets?
- Thinking no - why create artificial boundaries?
- In customization UI, should built-in widgets be separate from add-on widgets?
- Thinking yes - for easier discovery
- How do toolbars fit into the customization UI?
- Would be nice to have, as the current UI isn't friendly (have to right-click on a built-in toolbar - many addon toolbars have their own right-click menu)
- But we can't (reliably) get a preview of them
- Scaling with many addons
- Customization UI is relatively easy to scale - scrolling, and maybe text search
- Panel UI harder to scale
- Things add-ons will want: Everything. Only a subset of "everything" will fit in the Panel UI
- Allow addons to restrict where a widget can go? How is that expressed in the customization UI?
Existing issues
- Buttons added by add-ons aren't automatically available in the toolbar, add-ons need extra code and to make sure it's only run on first-run
- Overlays don't play nicely with restartless add-ons
- Customizing one window doesn't update other windows
Interaction with Add-ons Manager
- Adding widgets from add-ons kinda fits with the Add-ons Manager, but built-in widgets do not - doesn't make sense to have such a big split between the two
- Ergo, customization UI shouldn't be in the Add-ons Manager.
- Customization UI includes lightweight themes (backgrounds), but probably shouldn't include heavyweight themes. The Add-ons Manager will keep supporting those, but the relevant UI will only shown if one is installed.
Method 1 - Re-use existing method of overlaying toolbarpalette
- Buttons aren't automatically added to the toolbar when added to the palette - add-ons need extra code to do that, and make sure it's only done on first run. Easy to get wrong. This occasionally causes issues with addons re-adding a button after a user has chosen to remove it.
- Widgets from existing add-ons won't always fit into new panel UI - eg, a longer-than-usual button, a button that opens a dropdown panel, etc
- Doesn't play well with restartless add-ons
Method 2: Introduce new API
Cu.import("resource://.../CustomizeableUI.jsm");
var button = CustomizeableUI.registerWidget({
id: "weather-indicator", // how to enforce reasonable value that should be unique?
type: "button",
name: "Weather",
shortcut: "Ctrl-Alt-W",
description: "The weather outside",
defaultPlacement: "toolbar",
allowedPlacement: ["toolbar"],
icons: {
16: "chrome://weather-indicator/icon16.png",
32: "chrome://weather-indicator/icon32.png"
}
});
// Affect all windows:
button.disable = false;
// Affect one window:
button.windows[window].disable = true; // .windows is a Map
// When a restartless add-o is disabled, remove it:
button.unregister();
Alternatively, it could use a manifest file in JSON format. But not sure how that would fit with other applications. And l10n becomes awkward.
Benefits:
- Application wide registration, not per window.
- Fixes issue of default buttons (When addon is installed, is it's button visible? Where?)
- Much easier for restartless addons
- Harder for addons to screw up normal styling
- Should be able to support existing add-ons, by detecting added widgets. But for safely, might only be able to show them in the toolbar (not the Panel UI)
Drawbacks:
- Another API
- More difficult for custom widgets? (Might be good thing)
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
bug 770135 - Prototype/explore new Panel UI, and interactions with addons
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=For Firefox 4, we changed the menu to be a single, unified menu. This project is the next step in this evolution, which unifies the concepts of toolbar customization, adds the ability to customize the menu, and makes the 80/20/2 rule have a natural mapping in the UI.
It also provides a path for mapping the same menu structure to mobile devices like phones and tablets, as well as TVs and projection screens. |Feature users and use cases=Simplifying the ability for users to find what they're looking for, increase relative discoverability for the important items, have a predictable and consistent approach to interface customization. |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=Known design requirements:
- Redesigned Panel based Firefox Menu living on the toolbar
- In-Content Customization Tab/Mode
- Icon drag-and-drop including:
- Dragging from a tools palette to the Menu or a Toolbar
- Dynamic icon rearrangement and visual placement (i.e. you can see exactly where you are placing your icon not an abstract placement indicator)
- Visual indicators for acceptable drag areas
- Customization Mode Appearance including:
- Additional browser padding
- Toolbar and/or Window textures
- De-emphasis of non-relevant areas of UI
- Contextual Options menu for:
- Small Icons
- "Reset to Default"
- Reduce toolbar item redundancy and complexity by eliminating "magical" button merging behavior
Potential requirements:
- Direct manipulation of items in addition to drag-and-drop:
- Direct selection
- Buttons for Add/Remove
- Layout options
- Small Icons
- "Reset to Default"
Potential design variations:
- Icon and Grid based menu vs. traditional single column menu
TBD and Alternative Ideas
|Feature implementation plan=====Open UI questions====
- In the panel UI, should built-in widgets be separate from add-on widgets?
- Thinking no - why create artificial boundaries?
- In customization UI, should built-in widgets be separate from add-on widgets?
- Thinking yes - for easier discovery
- How do toolbars fit into the customization UI?
- Would be nice to have, as the current UI isn't friendly (have to right-click on a built-in toolbar - many addon toolbars have their own right-click menu)
- But we can't (reliably) get a preview of them
- Scaling with many addons
- Customization UI is relatively easy to scale - scrolling, and maybe text search
- Panel UI harder to scale
- Things add-ons will want: Everything. Only a subset of "everything" will fit in the Panel UI
- Allow addons to restrict where a widget can go? How is that expressed in the customization UI?
Existing issues
- Buttons added by add-ons aren't automatically available in the toolbar, add-ons need extra code and to make sure it's only run on first-run
- Overlays don't play nicely with restartless add-ons
- Customizing one window doesn't update other windows
Interaction with Add-ons Manager
- Adding widgets from add-ons kinda fits with the Add-ons Manager, but built-in widgets do not - doesn't make sense to have such a big split between the two
- Ergo, customization UI shouldn't be in the Add-ons Manager.
- Customization UI includes lightweight themes (backgrounds), but probably shouldn't include heavyweight themes. The Add-ons Manager will keep supporting those, but the relevant UI will only shown if one is installed.
Method 1 - Re-use existing method of overlaying toolbarpalette
- Buttons aren't automatically added to the toolbar when added to the palette - add-ons need extra code to do that, and make sure it's only done on first run. Easy to get wrong. This occasionally causes issues with addons re-adding a button after a user has chosen to remove it.
- Widgets from existing add-ons won't always fit into new panel UI - eg, a longer-than-usual button, a button that opens a dropdown panel, etc
- Doesn't play well with restartless add-ons
Method 2: Introduce new API
Cu.import("resource://.../CustomizeableUI.jsm");
var button = CustomizeableUI.registerWidget({
id: "weather-indicator", // how to enforce reasonable value that should be unique?
type: "button",
name: "Weather",
shortcut: "Ctrl-Alt-W",
description: "The weather outside",
defaultPlacement: "toolbar",
allowedPlacement: ["toolbar"],
icons: {
16: "chrome://weather-indicator/icon16.png",
32: "chrome://weather-indicator/icon32.png"
}
});
// Affect all windows:
button.disable = false;
// Affect one window:
button.windows[window].disable = true; // .windows is a Map
// When a restartless add-o is disabled, remove it:
button.unregister();
Alternatively, it could use a manifest file in JSON format. But not sure how that would fit with other applications. And l10n becomes awkward.
Benefits:
- Application wide registration, not per window.
- Fixes issue of default buttons (When addon is installed, is it's button visible? Where?)
- Much easier for restartless addons
- Harder for addons to screw up normal styling
- Should be able to support existing add-ons, by detecting added widgets. But for safely, might only be able to show them in the toolbar (not the Panel UI)
Drawbacks:
- Another API
- More difficult for custom widgets? (Might be good thing)
|Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=bug 770135 - Prototype/explore new Panel UI, and interactions with addons |Feature landing criteria=` }}
Feature details
| Priority | P1 |
| Rank | 999 |
| Theme / Goal | Experience |
| Roadmap | User Experience |
| Secondary roadmap | Firefox Desktop |
| Feature list | Desktop |
| Project | ` |
| Engineering team | Desktop front-end |
{{#set:Feature priority=P1
|Feature rank=999 |Feature theme=Experience |Feature roadmap=User Experience |Feature secondary roadmap=Firefox Desktop |Feature list=Desktop |Feature project=` |Feature engineering team=Desktop front-end }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}