581084 - List of search results doesn't visually differentiate between installed add-ons and remote search results

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: screenshot

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b2) Gecko/20100720 Firefox/4.0b2

Searching for add-ons in the new add-ons manager will return installed add-ons and results found on AMO in one list. Right now it is really hard to visually distinct between both types of add-ons. We should eventually use a different background.

Steps:
1. Open the add-ons manager
2. Search for "feed"

After step 2 you will see two results: Feedback and Reliby while Feedback is installed in the applications extension folder and Reliby comes from AMO. There is no visual distinction between both except the Disable/Install buttons.

Comment 1

[Jennifer Morrow [:Boriss] (UX)]

Attachment: Mockup: proposed design (with possible solutions that don't quite cut it)

Differentiating between local and remote add-ons in search is definitely problematic now, both because the only difference between the two is the text on buttons (install vs disable) and because they are intermingled in the list.

Making a stylistic or color change, like a differently colored background, would make it clear that there are two different kinds of items, but not particularly clear what the difference is.

Another possible solution would be to mark in readable text that local add-ons are already installed, where the "install" button on remote add-ons is.  However, adding this text to the entry would give the items different vertical heights, making them visually jarring in a list.  Removing the disable/preferences buttons on local add-ons would give space for "already installed" text, but would remove the needed use case of navigating to a local add-on via search and being able to enable/disable/access preferences with one click (as in list view).

One possible solution would be to separate out local and remote add-ons in different sections, clearly labeled, and allow them to be collapsed.  Local add-ons would be displayed first, since it's unlikely there would be more than a couple local add-ons matching a query of reasonable length.  The pros of this design are distinct visual separation, quick access to results that are local (at the top) and remote (scroll or minimize local), and the ability to see both local and remote on one screen, which could help users discover how to find and install additional add-ons.  The negative is that by displaying all add-ons on one screen, there are still two very different kinds of results being returned that each have different functionality.  Also, it would be very difficult to add a third category (such as paid items) to such a design.

However, there's a method we could implement that's actually consistent with other areas of Firefox.  In the current Library, a search returns Bookmarks by default.  But, by clicking the History Label next to Bookmarks, the search changes to within History only.

This design, aside from being consistent, clearly denotes which category is being returned.  It allows the user to switch categories quickly, to only navigate one category at a time, and allows for other categories (like paid add-ons) to be eventually added.  Also, by displaying local results first, the remote add-ons section would be given extra time to load while the user views local results and switches to remote.

Comment 2

[Tony Mechelynck [:tonymec]]

(In reply to comment #1)
> Created attachment 460767 [details]
> Mockup: proposed design (with possible solutions that don't quite cut it)
> 
> Differentiating between local and remote add-ons in search is definitely
> problematic now, both because the only difference between the two is the text
> on buttons (install vs disable) and because they are intermingled in the list.
> 
> Making a stylistic or color change, like a differently colored background,
> would make it clear that there are two different kinds of items, but not
> particularly clear what the difference is.

For remote addons, the Enable/Disable and Preferences buttons are irrelevant; I suppose they should be greyed out. For the third button, what about a red "Remove" button for local addons and a green "Install" one (or maybe yellow for addons not yet validated by the AMO team)? I think this would be obvious enough, and consistent with the green "Install" buttons found everywhere else at Mozilla (not only at AMO but also for application install).

Distinct sections (local vs. remote) and the possibility to see only local ones or only remote ones could come in addition to this colour difference.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I like the proposed solution at the bottom of the mock-up. The only helpful input I can give here is, that we should avoid coloring stuff. At least not with red/green. This is less informal as Jennifer already mentioned and also gives problems to color-disabled users.

Separating search results into two different categories sounds great, because it also minimizes the lag until results for locally installed add-ons are displayed. But one thing we should think about, how do we know which type of results the user wants to see initially. I would say lesser users will disable one of the checkboxes, so shall we show local or remote search results first? Local ones in favor of the loading speed or remote results to discover other available add-ons? Would be good to know how often users will use the search to find locally installed add-ons.

Comment 4

[Dave Townsend [:mossop]]

There are a couple of choices we could make, one is that if no local add-ons match then switch to the remote ones immediately, another is to default to remote but remember the user's choice after that (on the basis that their first searches are likely to be with few local add-ons installed anyway).

Comment 5

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #2)
> (In reply to comment #1)
> For remote addons, the Enable/Disable and Preferences buttons are irrelevant; I
> suppose they should be greyed out.

We don't even need to display them - especially in the design with two categories.  Rather than Enable/Disable, an obvious button for installing should be visible.

For the third button, what about a red
> "Remove" button for local addons and a green "Install" one (or maybe yellow for
> addons not yet validated by the AMO team)? I think this would be obvious
> enough, and consistent with the green "Install" buttons found everywhere else
> at Mozilla (not only at AMO but also for application install).

Unreviewed add-ons would not be appearing in the add-on manager search.

> Distinct sections (local vs. remote) and the possibility to see only local ones
> or only remote ones could come in addition to this colour difference.

The attached mockup is sectioned this way - do you feel it addresses your concerns?

(In reply to comment #3)
> I like the proposed solution at the bottom of the mock-up. The only helpful
> input I can give here is, that we should avoid coloring stuff. At least not
> with red/green. This is less informal as Jennifer already mentioned and also
> gives problems to color-disabled users.

Coloring buttons is certainly an area to proceed with caution in, because it's not something we do anywhere else in the UI.  The reason I'm recommending coloring install buttons is because it's a web convention that makes it clear to the user that they are installing something brand new.  The remote add-ons are in a very different category than the rest of functionality in Firefox: though appearing within a content page, it is the only place where we are offering new items that we did not write ourselves.  The green is meant to make them visually quite different and associate them with brand new installation convention rather than ordinary browser functions.  Colorblindness shouldn't be a big issue because the coloring is not needed for use: it only enhances the difference of installation vs other functions.  It provides no "new" information: only ads a visual difference.  Also, the vast majority of colorblind users would perceive a difference in the light/darkness of the button even if they could not perceive the particular hue.

Comment 6

[Jennifer Morrow [:Boriss] (UX)]

(In reply to comment #4)
> There are a couple of choices we could make, one is that if no local add-ons
> match then switch to the remote ones immediately, another is to default to
> remote but remember the user's choice after that (on the basis that their first
> searches are likely to be with few local add-ons installed anyway).

I was imagining the latter case.  Exposing early the availability of remote add-on installation is valuable both for users unfamiliar with add-ons ("Oh, I can install these and try them out") and those familiar ("oh, local search for reviewed add-ons within the browser")

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Jennifer, we want to use different backgrounds for the list box entries, right? Couldn't we simply use two different ones with unique patterns for local vs. remote add-ons? Similar to the mockup from Stephen:

http://www.stephenhorlander.com/images/blog-posts/incontent-ui/mac-extensions-view-list-large.jpg

Comment 8

[Dave Townsend [:mossop]]

Only necessary by feature freeze.

Comment 9

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This is a first-round implementation of the mockup. Fairly straightforward, though the colours aren't perfect yet.

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 467260 [details] [diff] [review]
patch rev 1

Note: this is on top of the patch in bug 562902, which in turn is on top of the patches in bug 585950.

Comment 11

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 467260 [details] [diff] [review]
patch rev 1

I just noticed the mockup attached here names the search category "Search Results", rather than the current "Search" - is that something that was purposefully changed, or just an incorrect detail in the mockup?

>+<!ENTITY search.filter2.installed.label       "My Add-ons">
>+<!ENTITY search.filter2.available.label       "Available Add-ons">

Not sure if these should have tooltips or not.

I'm happy to have the colors tweaked (including the gradient on the filter box) in a followup bug, just as long as that's filed and blocking.

Comment 12

[Dave Townsend [:mossop]]

(In reply to comment #11)
> Comment on attachment 467260 [details] [diff] [review]
> patch rev 1
> 
> I just noticed the mockup attached here names the search category "Search
> Results", rather than the current "Search" - is that something that was
> purposefully changed, or just an incorrect detail in the mockup?

Yeah I had missed that, it has also moved down below get add-ons. I'll double check these with Boriss.

> >+<!ENTITY search.filter2.installed.label       "My Add-ons">
> >+<!ENTITY search.filter2.available.label       "Available Add-ons">
> 
> Not sure if these should have tooltips or not.

Will throw some in with some text as soon as I find Boriss.

> I'm happy to have the colors tweaked (including the gradient on the filter box)
> in a followup bug, just as long as that's filed and blocking.

Comment 13

[Dave Townsend [:mossop]]

(In reply to comment #12)
> (In reply to comment #11)
> > Comment on attachment 467260 [details] [diff] [review] [details]
> > patch rev 1
> > 
> > I just noticed the mockup attached here names the search category "Search
> > Results", rather than the current "Search" - is that something that was
> > purposefully changed, or just an incorrect detail in the mockup?
> 
> Yeah I had missed that, it has also moved down below get add-ons. I'll double
> check these with Boriss.

She says that everything on the left is to be ignored.

Comment 14

[Dave Townsend [:mossop]]

Landed with the tooltip changes, bug 590221 filed for the colour follow-ups.

http://hg.mozilla.org/mozilla-central/rev/00186bbb7459

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100825 Minefield/4.0b5pre