Features/Desktop/Panel Menu: Difference between revisions

shipped!
No edit summary
(shipped!)
 
(13 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{FeatureStatus
{{FeatureStatus
|Feature name=Panel Menu
|Feature name=Panel Menu
|Feature stage=Draft
|Feature stage=Shipped
|Feature status=In progress
|Feature status=Complete
|Feature version=Firefox 29
|Feature health=OK
|Feature health=OK
}}
}}
{{FeatureTeam
{{FeatureTeam
|Feature product manager=Asa Dotzler
|Feature feature manager=Stephen Horlander
|Feature feature manager=Stephen Horlander
|Feature lead engineer=Blair McBride
|Feature qa lead=Cornel Ionce
|Feature ux lead=Stephen Horlander
|Feature ux lead=Stephen Horlander
|Feature additional members=Jared Wein, Mike Conley
}}
}}
{{FeaturePageBody
{{FeaturePageBody
Line 14: Line 19:
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.
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 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 ux design=Known design requirements:
|Feature ux design='''Known design requirements:'''
*Redesigned Panel based Firefox Menu living on the toolbar
*Redesigned Panel based Firefox Menu living on the toolbar
*In-Content Customization Tab/Mode
*In-Content Customization Tab/Mode
Line 30: Line 35:
*Reduce toolbar item redundancy and complexity by eliminating "magical" button merging behavior
*Reduce toolbar item redundancy and complexity by eliminating "magical" button merging behavior


Potential requirements:
'''Potential requirements:'''
*Direct manipulation of items in addition to drag-and-drop:
*Direct manipulation of items in addition to drag-and-drop:
**Direct selection
**Direct selection
Line 38: Line 43:
**"Reset to Default"
**"Reset to Default"


Potential design variations:
'''Potential design variations:'''
*Icon and Grid based menu vs. traditional single column menu
*Icon and Grid based menu vs. traditional single column menu


Line 46: Line 51:
[[File:PanelMenu-i01-DragToolbar.jpg|600px|thumb|none|Dragging Icon to Toolbar]]
[[File:PanelMenu-i01-DragToolbar.jpg|600px|thumb|none|Dragging Icon to Toolbar]]
[[File:PanelMenu-i01-DragToolbarOrMenu.jpg|600px|thumb|none|Dragging Icon to Toolbar or Menu]]
[[File:PanelMenu-i01-DragToolbarOrMenu.jpg|600px|thumb|none|Dragging Icon to Toolbar or Menu]]
 
<br />
'TBD and Alternative Ideas'
<br />
'''TBD and Alternative Ideas'''
[[File:PanelMenu-i01-DirectManipulation.jpg|600px|thumb|none|TBD: Direct Item Manipulation]]
[[File:PanelMenu-i01-DirectManipulation.jpg|600px|thumb|none|TBD: Direct Item Manipulation]]
[[File:PanelMenu-i01-MenuAltList.jpg|600px|thumb|none|Potential Alternative: One Column List Menu]]
[[File:PanelMenu-i01-MenuAltList.jpg|600px|thumb|none|Potential Alternative: One Column List Menu]]
<br style="clear:both" />  
<br style="clear:both" />
|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 implementation notes={{bug|770135}} - Prototype/explore new Panel UI, and interactions with addons
}}
}}
{{FeatureInfo
{{FeatureInfo
|Feature priority=Unprioritized
|Feature priority=P1
|Feature theme=Experience
|Feature theme=Experience
|Feature roadmap=User Experience
|Feature roadmap=User Experience
Line 61: Line 133:
|Feature engineering team=Desktop front-end
|Feature engineering team=Desktop front-end
}}
}}
{{FeatureTeamStatus}}
{{FeatureTeamStatus
|Feature security status=sec-review-needed
|Feature security health=OK
|Feature security notes=sec review work to be done by freddyb
}}
Confirmed users
933

edits