Features/Desktop/Panel Menu: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
mNo edit summary
Line 9: Line 9:
|Feature feature manager=Stephen Horlander
|Feature feature manager=Stephen Horlander
|Feature ux lead=Stephen Horlander
|Feature ux lead=Stephen Horlander
|Feature additional members=Blair McBride
}}
}}
{{FeaturePageBody
{{FeaturePageBody
Line 118: Line 119:
* Another API
* Another API
* More difficult for custom widgets? (Might be good thing)
* More difficult for custom widgets? (Might be good thing)
}}
}}
{{FeatureInfo
{{FeatureInfo

Revision as of 12:17, 11 June 2012

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

Status

Panel Menu
Stage Planning
Status In progress
Release target `
Health OK
Status note `

{{#set:Feature name=Panel Menu

|Feature stage=Planning |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager Asa Dotzler
Directly Responsible Individual Stephen Horlander
Lead engineer `
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead Stephen Horlander
Product marketing lead `
Operations lead `
Additional members Blair McBride

{{#set:Feature product manager=Asa Dotzler

|Feature feature manager=Stephen Horlander |Feature lead engineer=` |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=Blair McBride }}

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

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

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();


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)

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=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=====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();


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 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=` }}


Retrieved from "https://wiki.allizom.org/index.php?title=Features/Desktop/Panel_Menu&oldid=439746"