482857 - Update search results design

Status: RESOLVED FIXED

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

Description

[Nick Nguyen [:osunick]]

http://docs.google.com/Doc?id=dds6vwb4_11wbmfwfdj

Goal here is to improve the presentation so that it is more dense and visually scannable.

Comment 1

[Nick Nguyen [:osunick]]

Moving to 5.0.5- but this really needs to get done in this milestone.

Comment 2

[Neil Lee [:neilio]]

Attachment: First draft of search results wireframe

Here's a first draft at a rough search results wireframe. This is mostly for rough positioning, page structure, and results metadata. I'm working on the advanced search form fields, which are available once the "Advanced Search" disclosure triangle is toggled.

(N.B. This page will also serve as the advanced search page - if a user clicks on an Advanced Search link, they arrive on this page with the advanced search filters visible and no search results.)

Comment 3

[Fred Wenzel [:wenzel]]

(In reply to comment #2)
> Here's a first draft at a rough search results wireframe. This is mostly for
> rough positioning, page structure, and results metadata. I'm working on the
> advanced search form fields, which are available once the "Advanced Search"
> disclosure triangle is toggled.

What's the empty rectangle on the right for? Is that just unused space, or does will it contain anything?

Comment 4

[Neil Lee [:neilio]]

@wenzel: It's placeholder space for promo stuff like bandwagon, etc. - I'm trying to leave some space now for new content/features that are coming fairly soon.

Comment 5

[Neil Lee [:neilio]]

Attachment: 2nd iteration

Here's a new version that adds # of downloads and removes the advanced search option. In discussion with Nick we decided to remove the advanced search as all of the options for filtering are available in the search results (via the "sort by" feature).

In this new configuration search result will be constrained by product, so if you are looking at Firefox add-ons, searches will be constrained to just Firefox. If you switch to Thunderbird (using the product switcher in the header) search will be constrained to that product.

Thoughts?

Comment 6

[Nick Nguyen [:osunick]]

I think we should show both weekly and total downloads- seems like useful info, no?

Comment 7

[Neil Lee [:neilio]]

I dunno; having two sets of numbers in each result would probably be pretty noisy / confusing. If we wanted to spotlight certain add-ons as being "fast movers" or something like that we could maybe call them out in some way, but I think having one set of download #'s is probably best.

Comment 8

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

(In reply to comment #5)
> Created an attachment (id=373718) [details]
> 2nd iteration
> 
> Here's a new version that adds # of downloads and removes the advanced search
> option. In discussion with Nick we decided to remove the advanced search as all
> of the options for filtering are available in the search results (via the "sort
> by" feature).

What about the app-compat range?

Comment 9

[Nick Nguyen [:osunick]]

Neil, how close are we to finishing design on ths?

Comment 10

[Neil Lee [:neilio]]

Attachment: First run at a hi-res mock

Okay, here's a first run at a hifi mockup of the search results. A few notes:

- This doesn't show the "over" state for "more tags" yet, but it will be a very basic popup selection list similar to the top downloads popup in this mock: http://people.mozilla.com/~nlee/amo-category/v4/mockup3.html

- the "Only show results for" select menu is to constrain results by app version. I'm still mulling over how to label this so it's more clear and could use some suggestions

- The "Add to Firefox" buttons are placeholder - the new, smaller buttons that rdoherty created for the category page redesign should go here.

Let 'er rip, folks.

Comment 11

[Wil Clouser [:clouserw]]

Thanks Neil,

> Here's a new version that adds # of downloads and removes the advanced search
> option. In discussion with Nick we decided to remove the advanced search as all
> of the options for filtering are available in the search results (via the "sort
> by" feature).
> 
> In this new configuration search result will be constrained by product, so if
> you are looking at Firefox add-ons, searches will be constrained to just
> Firefox. If you switch to Thunderbird (using the product switcher in the
> header) search will be constrained to that product.
> 
> Thoughts?

Can you go through each feature in advanced search and explain how it's used in the new design?  E.g. I don't see how to filter by platform or version in your mockup.

Other thoughts:

- Add-ons can have up to 3 categories right now.  That could take up all of the tag space.

- There isn't a lot of space for tags anyway and if we're sorting by name new ones may never show up and anything that starts with 'a' will have an "unfair" advantage.

- Would saying "$num more tags" be helpful?

- Do we really need to show the categories/tags on the search page?  Can we take a queue from search engines and instead highlight _what_ is matching the search?  So, if a tag or category or add-on description or whatever matched maybe we could highlight a snippit of it?  I'm just kind of brainstorming here but I'm not sure all this information is actually needed or is really what a user wants on this page.

- What is the "next 10" link doing at the bottom?  how is that different than "next"?

> - the "Only show results for" select menu is to constrain results by app
> version. I'm still mulling over how to label this so it's more clear and could
> use some suggestions
How are you can combining two dropdowns (from version and to version) into 1 dropdown without limiting functionality?

- What does sorting by category do?

Comment 12

[Neil Lee [:neilio]]

Attachment: New version that addresses a few things

Thanks for the great feedback. I've tweaked the mockup a bit to address your comments.

Here's a tweaked version that addresses a few things - I've added a "show # results" drop down and clarified the "next 10" link to be more clear.

The way I see this working is that the search is constrained by what application you're currently viewing - if you're in Firefox add-ons, you search only those, etc.. We then sniff for OS and disable non-compatible add-ons just as we do currently on the site. We control app-compat based on auto-detect, which can be overridden by the drop down selector to the right (the "only show results for" menu). If the user is searching for Thunderbird extensions or we can't autodetect version, we show everything.

Other items from advanced search:

Last updated: in the new sort-by selector at the top of the results
Type: fiddly - we should just show everything.
Sort by, last updated: made obsolete with the new sort-by selector

Regarding the tags / categories, I'm all for contextual show/hide based on what's being searched on. I personally don't think tags should be in the results either; we can use them as keywords to help improve search results, but the item tags shouldn't be visible in the results. The spec required tags in results so I've included them here for discussion but I'd prefer they just appear on individual add-on pages.

Sorting by category is applicable if the search results contain results from across multiple categories.

Comment 13

[Wil Clouser [:clouserw]]

- If the "Only show results for" menu is for platform we should choose the platform by default (instead of showing the label) in which case it won't be obvious what it's for.

- I don't think people are going to like us taking away "type" - some people consume search RSS and they'll want to keep it.  If we do remove the option we should support "type:addontype" in the search parameters and add a wee bit of documentation to the FAQ about it.  Actually, I think supporting all our filters this way would be good (category, etc.). hmm.

- You mention everything in the advanced search except version - I don't see where you can change that on your design.  I think we'll suffer similar objections to "type" if we remove it.

- I don't think sorting by category provides a lot of benefit for the space it takes up.  People can just change the main search drop-down if they want to view a specific category.

- Shouldn't "Date Added" be "Date Updated" ?

- Let's hide the green > arrow by default

- Would weekly downloads be more useful than total on this page?

- the "11-20" still doesn't clarify it for me.  What is the difference between that and the "Next>" link?  Oh, I was almost ready to send this but I'll bet it's talking about pages 11-20.  I was thinking it meant add-ons 11-20 since we were viewing 1-10.  That may just be me but I found it confusing.

- I agree with you on the tags.  I think in this layout they will overwhelm the results.  If they are really needed on the results page I think we'll need to make the rows larger.

I'd be happy to have input from someone else.

Comment 14

[Neil Lee [:neilio]]

Just a clarification - the "only show results for" drop down is for app-version (3.5, 3.0.x, etc.) - the application is based on the application selector that's not shown here (it's in the header).

Waiting on Nick to wade in re: tags, but I'm all for removing them, and only showing category if it makes sense contextually.

Oh - also, the category selector is there because the category drop down that's in the search area only affects when a search is performed - it will not change the current results.

Comment 15

[Scott McCammon [:mccammos]]

(In reply to comment #14)
> Waiting on Nick to wade in re: tags, but I'm all for removing them, and only
> showing category if it makes sense contextually.

Would it make sense to show only tags that match the search?

I agree that showing all tags provides more clutter than usefullnes, especially without the context of the full description.

Comment 16

[Nick Nguyen [:osunick]]

Met with Neil yesterday to go over this.  We're going to try a different approach- a more columnar format with name, rating, downloads, date and a clear header for each to make downloads more clear.  We're also going to show the first category for each add-on (with the assumption that the first = primary) so users can help decide what to pick.  Tags will only appear if a user is coming from a clicked tag or they click 'search tags'

Comment 17

[Neil Lee [:neilio]]

Attachment: "Segemented" search sidebar

After pondering this a lot (and tossing out a bunch of different options that didn't work) I think I finally have a solution that covers all of the requirements. This new version uses a segmented search sidebar that does both sort (top section) and refine (bottom section).

The benefits here, besides having all of the various controls that affect search results together in one place, is having a lot more space for adding new criteria as well as giving an "at a glance" ability to quickly refine and sort results.

I haven't included all of the possible criteria in the sidebar for the refine section, but this should give you an idea of what's possible with this new configuration.

One thing to note is the sidebar area for "promo" is gone. I think this is a good change as it helps free up space for the search results and makes them less crowded.

Comment 18

[Nick Nguyen [:osunick]]

I think this looks really good- time to move to the next step?

Comment 19

[Wil Clouser [:clouserw]]

I think the concept is good.  I'm curious how the interface will work with categories and tags (since there are so many of them).  Are we showing all tags? or just matching tags? or...?

Anyway, I like the idea.

Comment 20

[Neil Lee [:neilio]]

Attachment: Search in the new design w/ new sidebar

Here's the mockup of how the segmented search wireframe translates into the new AMO design. I tried to follow all of the existing visual conventions in the new design, so all of the graphics and styles should already exist.

I'm not 100% sure about l10n, but I assume if this layout works for the collections page, it should work for search as well.

Comment 21

[Nick Nguyen [:osunick]]

Looking good- if no one else has any comments I think we can close this design bug and open an implementation one for an upcoming release.

Comment 22

[Wil Clouser [:clouserw]]

Questions from me:

This design removes the ability to filter ranges of versions.  Are we ok with that?

What does "Reset" do?  Change version to auto-detect, category to all, and remove filter on tags?

How are you choosing what categories to display?

How are you choosing what tags to display?

I think moving the application buttons to the sidebar would be more appropriate and would let us put the sort buttons along the top like the front page has.

Comment 23

[Nick Nguyen [:osunick]]

We should include version range in the filter- that was probably an oversight.

Reset should reset to default search- if the search started as tag specific this doesn't remove the tag restriction.

Categories and tags are pulled from the resultset- we can set a max of 10 of each for the purposes of keeping the UI neat.

Neil, can you add the version range to the mock, then we can consider design complete.  Can you try to get this done on Monday?

Comment 24

[Wil Clouser [:clouserw]]

> Categories and tags are pulled from the resultset- we can set a max of 10 of
> each for the purposes of keeping the UI neat.

So, we're pulling tags that match the search queries or we're pulling add-ons that match on name+description and then pulling 10 random tags from that set of add-ons?

Comment 25

[Nick Nguyen [:osunick]]

the latter.  The ten most common tags.

Comment 26

[Wil Clouser [:clouserw]]

That'll be really computationally intensive, particularly for large sets of tags.  Are you sure that showing 10 seemingly random links will provide a lot of value to the user in the context of filtering results?

Comment 27

[Nick Nguyen [:osunick]]

Yes, this is important. They aren't random- they provide context to the resultset and are valuable in drilling down, particularly if they're the most common ones. Filtering is a key use case for tags.  I understand that implementation may be tough but this is something Dave Dash and Toby have some experience with- see if they can help on this. Removing this would be bad.

Comment 28

[Nick Nguyen [:osunick]]

Actually, upon further consideration, I don't think we need version range in the filter- neil convinced me that there are some usability issues that make it hard to design and understand.  Rationale being that add-ons have a range of compatible versions but browsers have only one.  So someone with Fx3.5 only needs to access 3.5 compatible extensions which includes add-ons only compatible with 3.5 and add-ons compatible with a range of versions including 3.5.  This is an improvement over what we have now.

Resolving as fixed and sending mock to webmocha.