437150 - Remove author and user confusion about featured vs. recommended

Status: RESOLVED DUPLICATE of bug 483906

(addons.mozilla.org Graveyard :: Public Pages, defect, P1)

Description

[Basil Hashem [:baz]]

Today we have some naming inconsistency that is confusing to add-on authors and users alike. We need to align all the naming so that between Firefox's Add-ons Manager and AMO - we use the same terminology.

As I've blogged about at http://blog.mozilla.com/basil/2008/04/24/changes-to-the-featured-recommended-add-ons-on-amo/ (For the full background), we have two main types of lists. (Featured Add-ons & Category-Recommended add-ons)

Firefox 3's Addons Manager has a label "Recommended" in the "Get Add-ons" panel. Since we've fixed bug 426914, what we return now are indeed a selection of add-ons from the category recommended list. There are approximately 120 addons in the current reco addon's list (see https://addons.mozilla.org/en-US/firefox/editors/featured)

So, for this bug what we need are:
- Change the current upper left label that says "recommended" to "featured"
- Add a new upper left label that says "recommended" to category-recommended add-ons
- Add a label or indicator on detailed pages if something is current "featured". If it's both featured and recommended (as some are, featured wins). Don't put both labels there.
- Change the main page text on https://addons.mozilla.org/en-US/firefox/ from "We Recommend" to "We Feature" or "Featuring" (also in the right hand list)
- Retitle the page, https://addons.mozilla.org/en-US/firefox/recommended as "Featured Add-ons"

- Keep the recommended wording on the category landing pages, e.g. https://addons.mozilla.org/en-US/firefox/browse/type:1/cat:22. But we need more specificity on the "See All Recommended Add-ons" since this shows all recommended from the currently selected category.

- Add links and a new paginated listings page that show you "ALL category-recommended addons".

I need Madhava to give this a hard review to ensure this makes sense.

Comment 1

[Dave Garrett]

A couple quick notes:

I think the "recommended" and "featured" labels that show in the upper-left should look similar but be different enough to not accidentally mix them up.  You might consider making "featured" bold so as to emphasize that it is a higher level honor than "recommended".  No one is going to notice a difference between the two without additional queues.

Another very simple addition would be tooltips for "recommended" and "featured" and "experimental".  Just a quick and simple description of what this label means could go a long way.

Comment 2

[Basil Hashem [:baz]]

Dave, totally agree here - I need some input from the UX team on this exact matter of how best to differentiate these three classes.

Comment 3

[Dave Garrett]

A couple more ideas:

Consider changing the background color for the "recommended" and "featured" featured entries slightly, similar to the pinkish color added for "experimental".  Maybe keep the colors more or less similar, but darken it slightly for "recommended" and then a bit more for "featured"?  Another idea might be to add a slight border to the boxes when recommended/featured.

I think we should also have the upper-left corner labels and any other queues on the public pages and not just in the list.  This is already done for experimental add-ons.

Comment 4

[Madhava Enros [:madhava]]

Some of the problem here stems from two related issues:

- I think it's non-intuitive to users, especially casual ones, that there would be two parallel streams (or pools? my metaphor's running out here) of add-ons that are in some way elevated above the rest.  I'm not sure, to be honest, that that the extra complexity of two types of recommendations is going to easily understandable.

- the first issue is compounded by the fact that "recommended" and "featured," as much as we may want to imbue them with different meanings, are pretty much close enough to being synonyms that they don't help people figure out the different between the two.  That said, even fixing this with super-understandable names still leaves the first issue.

At the outset, I'd thought that they'd be nested -- there'd be a set of add-ons that have "Recommended" status, and certain of those would be flagged to be featured on landing pages.  The featured ones would change periodically, but always be drawn from the Recommended set, and that full set could always be seen in its entirety.

I realize that there's complexity to the model that we're trying to find a way to represent... but I wonder, would it be possible to deal with some of that internally and only represent one kind of super-level to users?  Even if add-ons come to featured or recommended status in different ways, could they all be represented as being of that higher-profile status?

Comment 5

[Chris Pollett]

I tend to agree with Madhava: an end-user is not going to bother to figure out what is the distinction between recommended and featured. Both words recommended and featured are somewhat vague. I think something like Editors' Picks sounds stronger and conveys how the choice is being made. I think the page context almost suffices to let a user know that it is a editors' pick for a given category. If each category had a color or icon associated with it, you could match the color or icon of editor's choice to the category. In the long run, you could also do a group by of averagerating by category and could similarly display most popular by category.

Comment 6

[Dave Garrett]

I agree, something like "Editor's Pick" or "Editor's Choice" sounds like a good replacement for the word "Featured".

WRT dropping the 2nd status altogether, featured-status would be needed to decide who gets on the front page and in the not-yet-renamed "featured" list.  The full category-recommended list is a bit too big to just stick here fully, in my opinion.  Also, there are a few category-recommended add-ons that probably aren't quite qualified to be fully featured up here.  (i.e. there's an "Alerts & Updates" category-recommended extension that pops up a Dilbert comic of the day; nothing wrong with it, but not really the sort of thing that I think needs to be specially featured up front)

Oh, and as far as I know, the featured list is a sub-set of the full category-recommended list.  (or are there any exceptions?)  Regardless of what gets done, I think there should be a better description of the meanings of all this on the pages with lists in question.

Comment 7

[Basil Hashem [:baz]]

Thank you all for the suggestions so far. Let me try to elaborate on what I'm trying to get across so you can help in the design changes.

- I'm happy with us changing the current, undifferentiated name of "Recommended" to Editors' Choice or Editors' Pick. I like that because it describes how the choice was made. My one concern is that the current Fx3 add-on manager says "Recommended" in huge letters on the Get Addons panel. If we can live with that for the time being and change it to "AMO Editors' Choices/Picks" or something similar in 3.0.1/3.1 - that would be great.
- I've wanted to envision the 140 or so editors' pick add-ons as a large pool  that the AMO editors have helped select based on their familiarity with the site and thru active participation of our AMO users.
- Generally, the ones appearing on the home page are some subset of what these Editors picks - so, if we don't want to call these out separately that's fine with me. We can call these Editor picks as well but I need help making the titles and links consistent across the site.

- We need to manage a separate "featured" list for several reasons:
  1) As more and more non-developers come to AMO, I didn't want to include add-ons from categories such as "Web Development" (or Search Engines or even Themes) on the front page
  2) Rotating 140+ add-ons on the front page means that each one will get little exposure since the algo is currently "random" from the list of 25 or so. 
  3) With 140+ add-ons the current "featured list" is unmanageable. (Could be paginated I suppose).
  4) As Davegar mentioned above, the Dilbert add-on is fun but I'm not going to put it on the front page
  5) The reality is that there is a "top tier" of add-ons (AdblockPlus, PicLens and a small handful of others) that represent the very best of what is out there and I don't rotate them out of the featured list very often.

- This is not really a big issue at all but I just wanted to let everyone know that there is currently a "global" (all locales) featured list as well as locale-specific lists. E.g. we can feature Orkut add-ons in Brazil, etc... To date, we have not done that since I haven't had time to work with each locale to help them pick ones. Similarly at the category level, the reco list there includes global for the AMO site as well as locale-specific.

Comment 8

[Dave Garrett]

(In reply to comment #7)
> - I'm happy with us changing the current, undifferentiated name of
> "Recommended" to Editors' Choice or Editors' Pick. I like that because it
> describes how the choice was made. My one concern is that the current Fx3
> add-on manager says "Recommended" in huge letters on the Get Addons panel.

I thought this showed add-ons from the full category-recommended list, and not the featured (now editor's choice) list, in which case it'd be fine.

i.e.
category-recommended -> just plain "recommended"
featured (currently labeled "recommended") -> Editor's Choice/Pick

Comment 9

[Dave Garrett]

(In reply to comment #8)
> I thought this showed add-ons from the full category-recommended list, and not
> the featured (now editor's choice) list, in which case it'd be fine.

To clarify, I'm referring to bug 426914 here.
(I just realized it's not pushed yet)

Comment 10

[Basil Hashem [:baz]]

OK, bug 426914 has not been pushed out...but it will this coming Tuesday. Right now Fx3 pulls from the small set, I want it to pull from the larger set. (The negative side effect is that Firebug will get presented to end users but I don't know how to fix that easily without creating 3 AMO managed lists, ugh).

I guess I'm agreeing with Madhava here and trying to simply what end users see - so, Editor's choice becomes the only thing that is highlighted/described on the site..no more "recommended add-ons" and the AMO team manages the previously-termed "featured list" which shows stuff on the front page. End users don't need to know that there are two levels....so given the various pages described in comment 0 what do we need to change?

Comment 11

[Dave Garrett]

(In reply to comment #10)
> I guess I'm agreeing with Madhava here and trying to simply what end users see
> - so, Editor's choice becomes the only thing that is highlighted/described on
> the site..no more "recommended add-ons" and the AMO team manages the
> previously-termed "featured list" which shows stuff on the front page.

Ok.  Then, what goes in the list that's currently "We Recommend" on the right side of the front page?  The full list or the sub-set shown on the front?  Also, what do we call it?  (if sub-set: still "Featuring:", just with no label applied on addons themselves?)

Comment 12

[Michael Morgan [:morgamic]]

Feels like Chris is blocked here -- could we clear up exactly what has to be done?

Comment 13

[Basil Hashem [:baz]]

Madhava, are you able to engage us on this to help figure out where we need changes. If you read my observations/recommendations in comment 7 and comment 10, is that enough you for you help us with mock up changes?

Comment 14

[Seth Wagoner]

Throwing in a new idea for consideration: attach the "recommended" label to all the addons that are recommended for a category, but on https://addons.mozilla.org/en-US/firefox/recommended show the current featured list *ordered by category* with each category having a link attached 

_See other recommeded addons in the [X] category"_  that leads to a subpage 

https://addons.mozilla.org/en-US/firefox/recommended/X

Comment 15

[Madhava Enros [:madhava]]

"Editor's Choice" or "Editor's Pick" makes sense in the context of AMO (if you think of AMO as a publication in that way), but within the Add-ons Manager, I'm not sure it does. I can see people wondering why Firefox has editors.  But, then, maybe if it were something like "Editors' Recommendations" on AMO and "Recommended" in the Manager, there would be enough continuity for it to make sense?

Otherwise, the situation Basil describes in comment 10 makes sense to me -- have one user-visible elevated list, and some subset of it shows up on the front page.  This subset doesn't have to be named in any user-visible manner.

For the record, I like Seth's suggestion in comment #14 - but maybe that's for another bug?

Comment 16

[Seth Wagoner]

My thinking is that if you implement my suggestion in comment 14 then you can stick with the "Recommended" nomenclature at all times and retain consistency with the addons manager. The "Recommended List" therefore, in the eyes of the public, would clearly include everything in /recommended *and* everything in the /recommended/subcategories - because they will be linked from /recommended 

On the category pages: 

"See All Recommended Add-ons" -> "All Recommended For Category" ? 

and https://addons.mozilla.org/en-US/firefox/recommended/cat:22

Should possibly be renamed 

https://addons.mozilla.org/en-US/firefox/recommended/categoryname ? 

I think the biggest confusion at the moment is that some recommended addons are labeled "recommended" in the listings, and some aren't. I think it would be better to label *all* the recommended ones as recommended, and perhaps keep the "featured" nomenclature as a non-public facing phrase for "the ones that are on the front page of /recommended. - or you could actually label the top of /recommended "Featured Addons for July", but it's clear that the ones that are on the subcategory pages are also part of the "Recommended List". 

Then the people who have heard that an add--on is recommended, or noticed it in their add-ons manager being labled as recommended, won't be confused when they go to /recommended and it's not there - they'll figure out soon enough that it must be behind one of the links that say "see all recommended addons for [bookmarks] 

I hope that made sense :-) 

Comment 17

[Michael Morgan [:morgamic]]

cpollett is away so punting off 3.4.5 -- this is also not critical afaik.

Comment 18

[Jennifer Morrow [:Boriss] (UX)]

Attachment: sketch of add-ons with recommended icons

I've been looking at this problem and reading everyone's comments and have a proposal.

First, to summarize the problem a bit:

As Basil and other have said here, the current distinction between recommended and featured add-ons is ambiguous to end-users and developers.  Currently, it's hard to even tell there's a difference: The front page has two groupings of recommended add-ons, yet an RSS feed for featured add-ons.  In particular categories, the distinction between add-ons which are recommended and not is confusing, because a small box surrounds some add-ons but not others.  Unless the "We recommend" label is visible, it's difficult to tell whether a particular add-on has been recommended or not.  And, in the sites for individual add-ons, no indication of recommended status is present.

There's two main stakeholders here: end-users and developers.  

   - End-users
      - Want suggestions in the form of recommended add-ons per category
      - Want to know that add-ons are safe and checked by editors
      - Are open to new add-ons from featured list

   - Developers
      - Want end-users to be assured their add-ons are safe and checked by editors
      - Want their add-ons to get publicity and traffic

Both kinds of classification are necessary, because recommended designations in categories gives users the assurance about add-ons they want, and the featured list gets the word out about the best add-ons.  So, "recommended" should relate that the add-on is safe, dependable, and has been tested to work.  "Featured" should relate that the add-on is exemplary.  So, collapsing both categories into one would eliminate vital use cases.

I don't think the confusion stems from there being two different categories of add-ons, but rather that they are implemented on the site so similarly to each other.  They are each given only a word as designation, and the words are synonyms.  I think that a different term, such as "Editors' Picks" is not really different enough to stop the confusion.  Instead of changing the word, I think we should be making the two systems completely separate in the minds of users.

Proposal

My proposal is to do away with the "recommended" categorization in favor of a simple icon placed on all formally recommended add-ons.  This icon would be displayed  along with an add-on's stars out of five, and the main page would continue to display the featured add-ons.  The icon should indicate that the add-on is safe and checked, such as an award ribbon or checkmark.  For This would be beneficial by:

- Giving recommended add-ons a clear, visual distinction that is present in a list or in a description - no need to scroll up to see if an add-on is included in a "recommended" box

- Making the designation for featured and recommended different in the users' mental model: "this add-on has earned a ribbon" vs "these add-ons are featured."  

- Simplifying the problem by essentially creating only one category of add-ons (featured) while recommended status would be a property of an add-on along with its author, ranking, etc.

- Changing the recommended category to a model more representative of what it is: rather than all recommended add-ons being downloads that the editors personally recommend users obtain, the add-ons have passed all the tests and earned an icon to prove it

I've included a rough screenshot of how this could look.

Any thoughts?

Comment 19

[Seth Wagoner]

A thought on Comment 18 - Currently, moving from the sandpit is meant to indicate that an add-on is safe / has been checked. The idea of an icon to indicate an extra level of quality has been reached is definitely a good one, I just think we need language that emphasizes quality over safety? Not sure. Recommended add-ons *should* be safer, but it's pretty hard to define some sort of objective standard for that and given that code goes stale, new exploits are found, etc, I'm not sure if we want to be making any implicit or explicit guarantees? I think just sticking with the label "recommended" is not a bad idea? But having an icon to indicate it is really important. 

BTW I think that Madhava is right, and I should migrate my thoughts on the per-category recommended lists to another bug. Will link from here once I've done that.

Comment 20

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #19)

Seth - Would an icon that emphasized quality over safety would address your concern?  I agree that an add-on's protection level isn't what we're trying to relate.  The icon in my screenshots in comment #18 is a ribbon, which I hoped would emphasize that an add-on is of a certain level of quality.  If you have an idea for an icon that does a better job, it's open to suggestions.

Comment 21

[Jennifer Morrow [:Boriss] (UX)]

Attachment: medal icon for recommended add-ons

I'm attaching a medal/award icon similar to the one in the screenshots.  My thought is that the medal conveys that the icon has achieved a status others haven't, that it's safe, and "recommended."  However, it could be that a medal might relate too much of an "award" rather than "security."  I tried a few variations such as check marks and thumbs up, but the checks looked a bit strange and looked like other icons and thumbs up is not L10N friendly ( http://en.wikipedia.org/wiki/Hand_gesture ).  Still open to suggestions on that one, but in the meantime we can use this as a placeholder.

Comment 22

[Jennifer Morrow [:Boriss] (UX)]

Just to clarify where this bug is - 

The first attachment shows where the icons should go in the AMO add-on descriptions, and the second attachment is the add-on itself.  So, unless anything here needs to be changed, there shouldn't be any missing graphic or UX elements.  What this bug needs is a developer to actually replace recommended status with the icons, and dissolve the textual recommendation status.  When the icons are put in place, they should link to a description of what recommended status is.  If any other UX is needed, I'm standing by.  :)

Comment 23

[Ryan Doherty (:rdoherty)]

(In reply to comment #22)
> If any other UX is needed, I'm standing by.  :)

Thanks Boriss, it looks like I have everything I need for this. 

I'm also thinking that when mousing over the image, a tooltip should pop up that says 'This add-on is recommended' or 'This add-on is recommended by Mozilla'?

Comment 24

[Jennifer Morrow [:Boriss] (UX)]

Ryan - good idea.

Comment 25

[Ryan Doherty (:rdoherty)]

Do we have a description of what recommended status is somewhere? I poked around and couldn't find anything.

Comment 26

[Ryan Doherty (:rdoherty)]

Attachment: Patch for medal image

Here's the patch. Will upload the image.

Comment 27

[Ryan Doherty (:rdoherty)]

Attachment: Medal image

Comment 28

[Michael Morgan [:morgamic]]

Comment on attachment 347396 [details] [diff] [review]
Patch for medal image

Need to add $html->urlImage() so it doesn't break on non-default installs.  Otherwise it looks good.

Comment 29

[Ryan Doherty (:rdoherty)]

Attachment: Patch for recommended icon

Comment 30

[Ryan Doherty (:rdoherty)]

Attachment: Patch for medal image and download stats on newline

Comment 31

[Ryan Doherty (:rdoherty)]

r19634

Comment 32

[Ryan Doherty (:rdoherty)]

Reopening as there's some confusion about what recommended addons are as stored by AMO. Seems like some addons show up under: https://preview.addons.mozilla.org/en-US/firefox/recommended/cat:22

but don't get the medal?

Comment 33

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #32)
> Seems like some addons show up under:
> https://preview.addons.mozilla.org/en-US/firefox/recommended/cat:22
> 
> but don't get the medal?

Ryan - why do you say they wouldn't get the medal?

Comment 34

[Ryan Doherty (:rdoherty)]

(In reply to comment #33)
> (In reply to comment #32)
> > Seems like some addons show up under:
> > https://preview.addons.mozilla.org/en-US/firefox/recommended/cat:22
> > 
> > but don't get the medal?
> 
> Ryan - why do you say they wouldn't get the medal?

I don't know why they show up in the recommended category yet fail the recommended check. I will have to look into it.

Comment 35

[Rey Bango]

(In reply to comment #33)
> (In reply to comment #32)
> > Seems like some addons show up under:
> > https://preview.addons.mozilla.org/en-US/firefox/recommended/cat:22
> > 
> > but don't get the medal?
> 
> Ryan - why do you say they wouldn't get the medal?

Jennifer, the recommended add-ons are not being designated as such on this page, similar to the way that they're showing normally with the recommended badge in the upper left corner and different color scheme in results.

Comment 36

[Jennifer Morrow [:Boriss] (UX)]

Sounds like a category problem rather than a UX problem - looks like Ryan will get back to us on that.

Comment 37

[Ryan Doherty (:rdoherty)]

It looks like if a category is specified for the recommended group, it doesn't use the Feature table (which is used for the recommended category by default) and instead searches the addons_tags table for tags with feature > 1. I'm not really sure what the difference is.

I checked the code, Chris Pollett added the category functionality in. Chris, is there a specific reason why the category functionality is different?

Comment 38

[Jennifer Morrow [:Boriss] (UX)]

Two other things still needed in this bug:

- Mouseover the ribbon should display text: "Recommended Add-on"
- Medal should link to page explaining Recommended status
- The page explaining recommended status needs to be created

Comment 39

[Dave Garrett]

(In reply to comment #38)
> - Mouseover the ribbon should display text: "Recommended Add-on"

It currently says "This add-on is recommended by Mozilla" on mouseover.


Has anyone yet looked into what needs to be changed in the category functionality to register the rest of the (category) recommendeds as recommended? getRecommendedAddons() and is_recommended() check the featured list, so now it needs to check the feature tag (which should probably be renamed to "recommended" to avoid more confusion, if I'm reading what it is properly) to list category-recommended add-ons instead of "recommended" i.e. featured add-ons. (I think... this bug makes my head hurt :p )

Comment 40

[Ryan Doherty (:rdoherty)]

(In reply to comment #39) 
> Has anyone yet looked into what needs to be changed in the category
> functionality to register the rest of the (category) recommendeds as
> recommended? getRecommendedAddons() and is_recommended() check the featured
> list, so now it needs to check the feature tag (which should probably be
> renamed to "recommended" to avoid more confusion, if I'm reading what it is
> properly) to list category-recommended add-ons instead of "recommended" i.e.
> featured add-ons. (I think... this bug makes my head hurt :p )

I'm looking into it. It will probably involved changing is_recommended() to include looking into the feature tag.

Comment 41

[Dave Garrett]

(In reply to comment #40)
> I'm looking into it. It will probably involved changing is_recommended() to
> include looking into the feature tag.

Based on design, the featured list should be a sub-set of the category-recommended list. If the tools for recommending add-ons honor that then you should only need to check the tag instead of the table. (the table would then only be for the featured add-ons list) Checking both here would/should be redundant.

Comment 42

[Jennifer Morrow [:Boriss] (UX)]

Perhaps this isn't a high priority, or should be on another bug, but it would probably be useful to have the ribbon link to a page explaining what exactly "recommended" means.

Comment 43

[Michael Morgan [:morgamic]]

Need to have more discussion on https://wiki.mozilla.org/Update:RecoListProcess to create a policy that is clear.  Will back out Ryan's changes until that is cleared up.

Comment 44

[Ryan Doherty (:rdoherty)]

r20416 back's out previous changes.

Comment 45

[Dave Garrett]

(In reply to comment #42)
> Perhaps this isn't a high priority, or should be on another bug, but it would
> probably be useful to have the ribbon link to a page explaining what exactly
> "recommended" means.

Just created bug 467834 for that so it doesn't get lost in the rest of this bug.

Comment 46

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #44)
> r20416 back's out previous changes.

Verified backed-out on https://preview.addons.mozilla.org/en-US/firefox/.

Comment 47

[Nick Nguyen [:osunick]]

We need to finish the FAQ and explain what Featured and Category Recommended mean (thus the dependency on 346991)

Comment 48

[Wil Clouser [:clouserw]]

I talked to Nick about where we should go from here.  We both think that adding an icon to the add-on listing doesn't provide a great deal more benefit than the labels we have now.  We also think the FAQ entry is useful and we should link the labels we have now to the FAQ.

Once that link exists this bug could be fixed.

I'd be open to revisiting this idea with a starting point of "what's best for the user?" rather than "how can we make what we have work?" if someone wants to go down that path.

Comment 49

[Dave Garrett]

What about showing the recommended label/icon for the category recommendeds and not just the featureds? (was brought up a few times above; see comment 32 - 41) As it stands right now, category-recommended add-ons have no indication of their status aside from the listing in their category's recommended page/slideshow. Spin off another bug for this?

Comment 50

[Wil Clouser [:clouserw]]

(In reply to comment #49)
> What about showing the recommended label/icon for the category recommendeds and
> not just the featureds? (was brought up a few times above; see comment 32 - 41)
> As it stands right now, category-recommended add-ons have no indication of
> their status aside from the listing in their category's recommended
> page/slideshow. Spin off another bug for this?

That sounds reasonable - please file another bug.

Ryan, just to be clear, once bug 483664 is resolved so is this one.  (Just spelling that out since I'll be gone when you get back. <3)

Comment 51

[Dave Garrett]

(In reply to comment #50)
> That sounds reasonable - please file another bug.

Ok, filed bug 483906 for the labeling issue.

Comment 52

[Nick Nguyen [:osunick]]

483906 supersedes this bug.