Personal tools

Features/Desktop/Panel Menu

From MozillaWiki

Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Status

Panel Menu
Stage Landed
Status In progress
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 ` `