Features/Desktop/Panel Menu

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	`

{{#set:Feature name=Panel Menu

|Feature stage=Shipped |Feature status=Complete |Feature version=Firefox 29 |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	Cornel Ionce
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=Cornel Ionce |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

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

` {{#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

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

|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	sec-review-needed	sec review work to be done by freddyb
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=sec-review-needed |Feature security health=OK |Feature security notes=sec review work to be done by freddyb |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=` }}