Closed Bug 384125 Opened 13 years ago Closed 11 years ago

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

Categories

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

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ehsan, Unassigned)

References

()

Details

(Whiteboard: PRD:ADD-005d)

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.
Flags: blocking-firefox3?
Priority: -- → P3
Flags: blocking-firefox3?
Whiteboard: PRD:ADD-005d [wanted-firefox3]
Blocks: 385394
Buttons for the "Downloading and File Management" will be developed in bug 389386 and bug 389387.
Depends on: 389386, 389387
Buttons for the "Privacy and Security" category will be developed in bug 389388.
Depends on: 389388
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?
Button for the "RSS, News and Blogging" category will be developed in bug 389389.
Depends on: 389389
(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...
Button for the "Bookmarks" category will be developed in bug 389391.
Depends on: 389391
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.
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.
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.
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?
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.
(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?
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?
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.
is this dropped off FF3 ? (-> re-targeting?)
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.
I don't think I'll be able to handle this bug and its dependencies in a timely fashion...
Assignee: ehsan.akhgari → nobody
Status: ASSIGNED → NEW
Flags: wanted-firefox3+
Whiteboard: PRD:ADD-005d [wanted-firefox3] → PRD:ADD-005d
Product: Firefox → Toolkit
Do we still want to do something like this?
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?)
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.
Target Milestone: mozilla1.9 → ---
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
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
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.