384125 - Tracker bug for category-specific "Addon" buttons (Requirement ADD-005d)

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect, P3)

Description

[(no longer active)]

I'm wishing to work on the ADD-005d requirement for Firefox 3 <http://wiki.mozilla.org/Firefox3/Product_Requirements_Document#P3>.  I'm opening this tracker bug to track the progress of specific bugs filed for each component that needs an "Addons" button.  I'm hoping that the Extension/Theme Manager category is appropriate for this tracker.

Addon categories (see <https://addons.mozilla.org/en-US/firefox/browse/type:1>):

    * RSS, News and Blogging
    * Web and Developer Tools
    * Downloading and File Management
    * Privacy and Security
    * Search Tools

    * Interface Customizations
    * Bookmarks
    * Site-specific
    * Language Support and Translation
    * Photos and Media

    * Social and Sharing
    * Web Data, Alerts, and Widgets
    * Miscellaneous

For each category, a place to add the "Addons" button will be identified, and a bug in the appropriate component will be opened.

Comment 1

[(no longer active)]

Buttons for the "Downloading and File Management" will be developed in bug 389386 and bug 389387.

Comment 2

[(no longer active)]

Buttons for the "Privacy and Security" category will be developed in bug 389388.

Comment 3

[Dave Townsend [:mossop]]

I question whether bug 389386 is going too far given that you already have
plans to link to download extensions in bug 389387. It seems that following
this rationale we could end up with quite a large number of such buttons in the
preferences.

Have the appropriate people looked at a list of where you are planning to put
all these buttons yet?

Comment 4

[(no longer active)]

Button for the "RSS, News and Blogging" category will be developed in bug 389389.

Comment 5

[(no longer active)]

(In reply to comment #3)
> I question whether bug 389386 is going too far given that you already have
> plans to link to download extensions in bug 389387. It seems that following
> this rationale we could end up with quite a large number of such buttons in the
> preferences.
> 
> Have the appropriate people looked at a list of where you are planning to put
> all these buttons yet?

I'm filing bugs in the hopes of getting people's extensions...

Comment 6

[(no longer active)]

Button for the "Bookmarks" category will be developed in bug 389391.

Comment 7

[(no longer active)]

In the following list, the categories for which I anticipated buttons in the GUI are listed with a + next to their names, and the places in the UI where the buttons appear.  The rest of categories, for which there is a - next to their names are the ones I couldn't figure out where to put an appropriate button.

+ RSS, News and Blogging: Feeds section of Preferences window
- Web and Developer Tools
+ Downloading and File Management : Downloads section of Preferences window, Download Manager
+ Privacy and Security: Privacy and Security sections of Preferences window
- Search Tools

- Interface Customizations
+ Bookmarks: Organize Bookmarks dialog
- Site-specific
- Language Support and Translation
- Photos and Media

- Social and Sharing
- Web Data, Alerts, and Widgets
- Miscellaneous

Please feel free to add to this list.

Comment 8

[Steffen Wilberg]

Oh, I didn't notice the tracker bug. Really, we should strive to simplify the UI, not keep adding stuff to it. We don't need 4 or more additional buttons to a.m.o. You can't promote a.m.o through the use of buttons in the prefwindow or download manager.

You can make it even more prominent on the first run page. Or the release notes. Or the Firefox Start page http://www.google.de/firefox). But don't clutter the UI. Try to remove stuff instead of adding it.

By the way, ADD-002a (bug 384956) looks like the same as this.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Steffen, the idea is to have a small button which can be placed (like the help "?" button) in various dialogs to jump a user to the appropriate section of AMO in order to help them find tools to extend the functionality of the UI that they're looking at.

This is different from bug 384956 which is about making it easier for users to get to the preferences of their installed add-ons.

I'm not sure why you WONTFIXED a bunch of the deps here; this is something which we're actively exploring as per the PRD line item.

Comment 10

[(no longer active)]

Mike,

What are the possibilities to improve the discoverability of the category-specific add-ons?  Do you have any suggestions?

What I've been thinking is that we need a UI element which the can:
1) indicate to the users that it can be acted on (e.g. clicked)
2) can make what it does clear (either by textual or visual content)
3) can provide more info on what it does as a tooltip
4) is roughly the same (textually and/or visually) for everywhere it's added to.

I figured two options, either a link or a button.  I think a link takes up too much space, so I decided to go with a button.  What I currently have in mind is a button without a text-caption showing the "add-ons" icon (possibly with a mellow "glow" effect implemented as an animated PNG) which shows context-specific tooltip, and once clicked, takes the users to the category specific to the context of the button (i.e. download add-ons, privacy add-ons, etc.)

What do you think?  Any suggestions?

Comment 11

[Robert Strong (they/them - no direct email)]

Last I talked with beltzner about this (several months ago) the thought was to have an easily recognizable small image with a tooltip (e.g. "click to find download add-ons" or some such text)  that opened the associated AMO page. If a button is used then hopefully it will have it's margin and padding greatly reduced to save on ui real estate.

Comment 12

[(no longer active)]

(In reply to comment #11)
> Last I talked with beltzner about this (several months ago) the thought was to
> have an easily recognizable small image with a tooltip (e.g. "click to find
> download add-ons" or some such text)  that opened the associated AMO page. If a
> button is used then hopefully it will have it's margin and padding greatly
> reduced to save on ui real estate.

That's what I had in mind as well.

Perhaps I need to open another bug to develop an XBL binding implementing that button, and then get a review and ui-review on that bug, and once that code lands, I just use the binding in the appropriate place for the deps of this bug?

Comment 13

[Robert Strong (they/them - no direct email)]

What do you have in mind for the xbl binding that isn't easily accomplished with either an image or a button as is and a little js?

Comment 14

[(no longer active)]

The XBL binding helps to keep the buttons in different places easily in sync, so that if we want to change something or add a behavior later, we'd only have to make the change in one place, and not go through all of the code and make changes everywhere.

Comment 15

[(mostly gone) XtC4UaLL [:xtc4uall]]

is this dropped off FF3 ? (-> re-targeting?)

Comment 16

[Basil Hashem [:baz]]

The AMO team has been making changes to the site to help facilitate navigation, etc...In particular, I've made some proposals and changes to the names of categories. I would be hesitant to hard code the categories into the Firefox binary itself. We need to remain flexible to allow natural progression of category names, descriptions, etc...

Here is the requirements document that we are working towards for delivery in early December (http://wiki.mozilla.org/Update:RequirementsV32). The renamed categories have already been rolled out (mostly).

Finally, there are some mockups that Madhava Enros has at http://wiki.mozilla.org/Firefox:Add-ons_Manager_UI which is what is desired for Fx3.

Comment 17

[(no longer active)]

I don't think I'll be able to handle this bug and its dependencies in a timely fashion...

Comment 18

[Dave Townsend [:mossop]]

Do we still want to do something like this?

Comment 19

[Basil Hashem [:baz]]

I still hold to my comment 16 that I think we need to keep the categorization managed outside of Firefox. From an AMO perspective, we may move categories around, create new ones, etc... At the moment, I'm aware of only a couple of links to AMO:
- Get Addons (& related, Browse All, see All Recommended)
- "get more search engines" from the Manage Search engines dialog
- "Get Bookmark Add-ons" bookmark (Is that still in there on the default profile?)

Comment 20

[Dave Townsend [:mossop]]

Yeah anything we do here could hamstring AMO from changing their categorisations or at least require them to make mappings between Firefox's defined set and theirs. That doesn't seem all that a good idea to me.

Comment 21

[Alex Faaborg [:faaborg] (Firefox UX)]

my comments on irc

[15:36] <faaborg> it feels like this would clutter the UI, I want us to try to cut back on "might be useful" cues
[15:36] <faaborg> for instance, the open search smear is a "might be useful" cue
[15:36] <faaborg> also, aren't add-ons that spread organically across social ties going to be higher quality and more relevant
[15:37] <faaborg> I wouldn't mind putting something like the functionality of our facebook app on a new "home tab"
[15:38] <faaborg> but sprinkling little + buttons around the interface doesn't seem right

Comment 22

[Dave Townsend [:mossop]]

Yeah I think this proposed approach has issues and causes too much UI clutter. We already have better ways to offer extensions to the user through the get add-ons panel so I don't believe we would take this any longer