Confirmed users
933
edits
Shorlander (talk | contribs) 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= | |Feature stage=Shipped | ||
|Feature status= | |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= | |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 | |||
}} |