From MozillaWiki

Please use "Edit with form" above to edit this page.

Status

Panel Menu Stage Shipped Status Complete Release target Firefox 29 Health OK 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 Cornel Ionce UX lead Stephen Horlander Product marketing lead ` Operations lead ` 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





Panel Menu

Customization Tab Mode

Dragging Icon to Toolbar

Dragging Icon to Toolbar or Menu





TBD and Alternative Ideas

TBD: Direct Item Manipulation

Potential Alternative: One Column List Menu





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

`





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

Team status notes

status notes Products ` ` Engineering ` ` Security sec-review-needed sec review work to be done by freddyb Privacy ` ` Localization ` ` Accessibility ` ` Quality assurance ` ` User experience ` ` Product marketing ` ` Operations ` `



