475605 - Update category landing pages

Status: VERIFIED FIXED

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

Description

[Nick Nguyen [:osunick]]

This is a project to update our category pages to expose more add-ons in a friendly way.

Assigning to Neil for design.

http://docs.google.com/Doc?id=dds6vwb4_16d77dqkfr&invite=hjb8jf4

Comment 1

[Neil Lee [:neilio]]

Attachment: Category landing page wireframe

Here is the initial wireframe for the category redesign. Nick, we talked about just having two lists, but with this configuration there is space for a third, which I've included.

I've also included the "over" state so you can see how the category list overlay works - when the user hovers their mouse over the Category heading, the full list of available categories is revealed. The same concept works for the "Top Downloads" list - hovering over "week" reveals an overlay menu with "month" and "all time" options.

Beefs, bouquets, crits, etc. are all welcome.

Comment 2

[Neil Lee [:neilio]]

Attachment: Wireframe showing the Category menu overlay

Comment 3

[Yongqian]

Looks fantastic - may I suggest however that the date for the "Top Downloads" be date of last update? It seems that when an addon was uploaded matters less and less as time goes on and last updated gives better impression of whether it is being actively maintained.

Comment 4

[Nick Nguyen [:osunick]]

Agreed- we should make it clear that the date is last updated date when this goes to implementation.

Neil- we spoke a bit offline about the positioning of the icons, but you've convinced me. 

Also, I think in the bottom lists if we can at least show the icon for each add-on it would be more compelling.  As for add-ons without icons, we should probably omit the icon completely instead of showing the placeholder, whaddya  think?

Comment 5

[Neil Lee [:neilio]]

@nick:

>Also, I think in the bottom lists if we can at least show the icon for each
add-on it would be more compelling

After thinking about this for a bit, I'm a bit worried about adding more visual noise to the page. The problem I see is that a) many add-ons icon's were designed at a larger size, and scaling them down to a size that would fit into the list format would turn them into pixel mud, and b) even the most popular add-ons aren't probably recognizable by their icon. So icons wouldn't make the lists more readable or scannable.

Besides these points, were there any other changes required?

Comment 6

[Nick Nguyen [:osunick]]

Just 'last updated' vs just a date.  Also, would it be possible to create a higher fidelity mock to see how it feels?

Comment 7

[Yongqian]

"a) many add-ons icon's were
designed at a larger size, and scaling them down to a size that would fit into
the list format would turn them into pixel mud"

But aren't icons restricted to 32px x 32px (which is pretty small already)? Or are you referring to previews?

Comment 8

[Nick Nguyen [:osunick]]

I think he's saying that 32x32px is probably too big for inclusion in a list of add-ons.  I can see Neil's point- let's go to a higher fidelity mock and see if including full size icons would make the lists too bulky.

Comment 9

[Yongqian]

What is the status of this bug?

Comment 10

[Neil Lee [:neilio]]

Yongqian Li: I'm nearly finished the design mockup for this and will be posting something for review in the next day or so.

Comment 11

[Neil Lee [:neilio]]

Attachment: First run at a design mock based on wireframe

Okay, here's a first run at a design mock based on the wireframe. I've included add-on icons in the lists and Sean Martell chipped in with the lovely "Add to Firefox" buttons.

There still needs to be a bit of finessing and minor fine tuning, but I think at least the basic concept is ready for review.

Comment 12

[Nick Nguyen [:osunick]]

Some suggestions:
Third list should be "Recently Updated"
Metadata in lists can change- Date Added, Downloads, Updated

Comment 13

[Yongqian]

Looks fantastic - great job! I am wondering what program are you using for the mock-up?

Comment 14

[Yongqian]

What about random addons? Without them addons that do not make the top lists will have little exposure and even lower chances of getting there.

Comment 15

[Neil Lee [:neilio]]

Attachment: Second version, with cleaned up metadata

Here's a cleaned up version that I think is less dense and busy both visually and information-wise. I think this is much improved - thoughts?

Comment 16

[Nick Nguyen [:osunick]]

Yongqian:

Users will be able to drill down on any of the lists- and the idea of having a time restricted "top addons" list is supposed to help here.  Also, the most recently updated and recently approved addons guarantees that any add-on that gets an update at least spends some time in the limelight, which is better than what we had before.

-n.

Comment 17

[Nick Nguyen [:osunick]]

Neil, looks great- a couple comments

- We should have a search box somewhere on the page that makes it clear that users can search add-ons.  Also good to show count of add-ons in this category.  Like "Search 1421 bookmarks add-ons"

- My presumption is that the lists on the bottom allow you to drill down, maybe good make that a clear call to action

- I'm thinking that "top rated" might be better instead of either "just added" or "just updated", since we introduced that bayesian algorithm.  What are your thoughts?

- A few people voiced concerns that the rollover navigation would be too hard to discover, but I think it frees up valuable screen real estate.  Maybe good to have a second mock with the rollover so we can show people what we're talking about.

Comment 18

[Michael Morgan [:morgamic]]

Neil?

Comment 19

[Neil Lee [:neilio]]

Hey Nick - see my comments inline below:

> We should have a search box somewhere on the page that makes it clear that
> users can search add-ons.  Also good to show count of add-ons in this category.
> Like "Search 1421 bookmarks add-ons"

There already is a search in the header (which this doesn't include - this is just the main content area) - do we want to have a completely separate category search? It might be confusing to have two search systems on the page.

I don't know if showing the number of available add-ons is really that useful as it's not actionable; it's not like a user will want to look at all of the add-ons. How do you see this information being used?

> My presumption is that the lists on the bottom allow you to drill down, maybe
> good make that a clear call to action

This is visible by the arrows in each of the rows as well as possibly a roll-over effect that subtly highlights the row.

> I'm thinking that "top rated" might be better instead of either "just added"
> or "just updated", since we introduced that bayesian algorithm.  What are your
> thoughts?

Just added is useful as it shows users what's brand new, but having a top-rated might be more useful than a "just updated". The main issue with this is the top-rated list will be fairly static - I wasn't sure if you wanted this page to be more dynamic content-wise or not, but I'm cool with either option.

> A few people voiced concerns that the rollover navigation would be too hard
> to discover, but I think it frees up valuable screen real estate.  Maybe good
> to have a second mock with the rollover so we can show people what we're
> talking about.

The rollover in the final design would look almost identical to the one in the wireframe, but I can add it into the mockup if you like. One idea to help make the category list more discoverable is to add some text that says "View all" right beside the category name that pops up the category list. What do you think?

Comment 20

[Nick Nguyen [:osunick]]

1- the search on the current category pages isn't really in the header- it's in the main content and it is restricted to category with a dropdown to optionally widen the search.  So I think it makes sense to understand how this fits in.  

2- Ambient info on the number of bookmarks add-ons is useful because we're still presenting (assuming no overlap of the lists) ~40 add-ons on this page.  The count is a call to action to show what is available, so the search is a way to act.

3- By drill down I actually meant how do we go to an expanded list with that criteria (poor choice of words on my part).  So from the top 10 list of new add-ons how do I get to a paginated list of add-ons sorted by age?

4- I think 'top rated' will be better- let's do that instead.  Otherwise we have three date-drive lists on the page.

5- I think "view all" could work, let's try that too.

Comment 21

[Neil Lee [:neilio]]

nick - okay, I can try to add search into the existing design -- I hadn't realized this was required so I didn't leave room for it, but maybe it just slot above the featured add-ons?

So, the search could have a tag that says something like "Search X [category] add-ons" with X being the total number?

I also wasn't aware that we needed to click through to a larger list - is adding a link to the bottom of each table that says "More [name of list]" good?

Comment 22

[Nick Nguyen [:osunick]]

search should go into the design- it's just that if you even look at today's design search isn't part of the header, so it's something we'd have to think about anyway.  As for representing the number of add-ons in a category I feel like it's important to do but can't think of a clean way to reconcile that with a mode selector that allows users to search 'all' add-ons.  Thoughts?  I suppose one way would be to have a persistent search box in the header that always searches all and a contextual search box that is on the category page that only searches the current context (in this case the category).

YOur idea for putting a link at the bottom of each table seems obvious, let's do that and see how it works.

Comment 23

[Justin Scott [:fligtar]]

I don't think search should be part of the header -- many pages don't currently have a search bar like Developer/Editor/Admin pages, and some pages (like Collections) will have a search bar that doesn't search add-ons.

Comment 24

[Nick Nguyen [:osunick]]

Yeah, thinking about it some more, redundant search boxes are confusing.

Let's use the current search box which has default text and a selector for category, and change the default text.

Instead of "Search for add-ons" make it "Search [number] add-ons" within [Category].  When the user changes this category selector, the number will change.  Since we have more width to play with we can make this search box a little wider to accomodate l10n.  And this count will always reflect a count of all add-ons, since experimental add-ons show up in search results.

Comment 25

[Neil Lee [:neilio]]

> Let's use the current search box which has default text and a selector for
> category, and change the default text.

I think I know what this means, but to clarify, we're going to use this

http://img.skitch.com/20090325-gtbtedks7f5h9fcynq6urnscj5.png

... but with some text changes?

Comment 26

[Nick Nguyen [:osunick]]

Yep.  Maybe color changes?

Comment 27

[Ryan Doherty (:rdoherty)]

Couple of implementation points (mostly minor, the design looks really good):

-'Add to Firefox' buttons - That font can't be used b/c the button will need to have text in it for localization. The button will also changed depending on compatibility. I think we'll have to use the existing cta buttons, but shrink them down a bit.

-Top modules - the fixed height will most likely change as every add-on will have different text lengths for name, author and description (unless we do some tricky truncation). The layout won't break, but each module may be a different height.

-What will the 'this week' dropdown look like? (Next to Top Downloads). More UI work for that will be appreciated for whomever implements it.

Comment 28

[Neil Lee [:neilio]]

@nick:
> Maybe color changes?

Sure, I can play with that a bit. Can I futz with the design a little? Nothing major, just slightly reducing the height to make it more integrated into the page.

@ryan:

>'Add to Firefox' buttons - That font can't be used b/c the button will need to
> have text in it for localization. 

Great point - I do have a "disabled" version that Sean made, but thanks for reminding me about localization. Could we use something similar to this but coded so that it uses regular text? Or do you think the implementation would be too problematic?

> Top modules - the fixed height will most likely change as every add-on will
> have different text lengths for name, author and description (unless we do
> some tricky truncation). 

Yeah, I thought about this a lot. I do think we should start requiring all addons to have a short, one sentence summary, but I know that in the meantime dealing with the existing addons is tricky. Any suggestions?

(FWIW I was looking at sites like the Apple Downloads page for inspiration - it truncates after a certain number of words: http://www.apple.com/downloads/ )

> What will the 'this week' dropdown look like? (Next to Top Downloads). 
> More UI work for that will be appreciated for whomever implements it.

I'll add over-states into the next revision to clarify the design here.

Comment 29

[Yongqian]

Just my two cents:

I think maybe "newest addons" can be merged into "most recently updated" -- just count the first version as an "update".

Comment 30

[Nick Nguyen [:osunick]]

@neil:

Futz away- I'm just articulating the goals- feel free to achieve them any way you see fit.  If you disagree with the goals, you can also futz with those as well, just let me know.

Comment 31

[Ryan Doherty (:rdoherty)]

(In reply to comment #28)
> Great point - I do have a "disabled" version that Sean made, but thanks for
> reminding me about localization. Could we use something similar to this but
> coded so that it uses regular text? Or do you think the implementation would be
> too problematic?

I think we could take the current green buttons and shrink them down a bit to fit (Les' 'Share This' button did this). But it will have to take into account all the states that are possible (Add, incompatible, platform). Might want to take a look around AMO for all the states unless someone has documented them somewhere.

> Yeah, I thought about this a lot. I do think we should start requiring all
> addons to have a short, one sentence summary, but I know that in the meantime
> dealing with the existing addons is tricky. Any suggestions?

We can truncate, it's definitely possible. There will be a significant amount of QA work for it to guarantee it always truncates shorter than it should to avoid breakage.

Comment 32

[Neil Lee [:neilio]]

Okay, I'll take these things into account and get my futz on. I'll try to post an amendment by EOD tomorrow at the latest.

Comment 33

[Neil Lee [:neilio]]

Here's a new version that should cover all of the missing requirements. I've created three versions so you can see the normal, rollover, and click states.

Click on the image to cycle through the states.

http://people.mozilla.com/~nlee/amo-category/v3/

Comment 34

[Nick Nguyen [:osunick]]

Looks awesome!  One question- how does one change the search box to switch between 'all' and 'bookmarks'?  That's the only thing I can think of.

Comment 35

[Ryan Doherty (:rdoherty)]

Nice, looks good.

We will absolutely need a non-js fallback for the category select menu. It needs to be part of the written specs. Otherwise this content will not be indexable.

Comment 36

[Neil Lee [:neilio]]

@nick:

> Looks awesome!  One question- how does one change the search box to switch
> between 'all' and 'bookmarks'?  That's the only thing I can think of.

That's... a great point. I didn't realize that this search would replace the site search, but I suppose that's possible as well.

Maybe we can do something similar to the google reader search?

http://img.skitch.com/20090331-n2i2tx1sgn6riya3uyamdynq7e.png

Here's how I imagine this would work:

- the drop down menu would have a full list of add-ons, with the current selection in that drop down based on what category you were in (home page would default to "All").
- the "helper" text in the search field would change based on the drop down menu, with home page text reading "Search all add-ons".

Thoughts?

Comment 37

[Nick Nguyen [:osunick]]

I think that works great- it's how I imagined it as well.  The current site search isn't in the header today, so we'd have to replace it.

Comment 38

[Neil Lee [:neilio]]

Here's the amended version with the search bar update. I've moved things in the "header" around a bit to accommodate longer category names in the header, and also tweaked the top 10 lists to make the "See all" links more integrated visually.

http://people.mozilla.com/~nlee/amo-category/v4/

Comment 39

[Ryan Doherty (:rdoherty)]

Looks cool. We'll just need to spec out that non-js users get a normal dropdown menu.

Comment 40

[Wil Clouser [:clouserw]]

Comment on attachment 368832 [details]
Second version, with cleaned up metadata

We've had ample time to review/comment.  I think the design looks good.  Let's open new bugs for 5.0.5 to implement.

Thanks neilio

Comment 41

[Nick Nguyen [:osunick]]

Agreed

Comment 42

[Ryan Doherty (:rdoherty)]

Neilo: do you have the psd somewhere I can grab it from?

Also, the search bar looks clipped on the right. Will it just be rounded like the left side?

Do the new homepage mockups affect this design at all? (graphics, fonts, layout, etc)

Comment 43

[Ryan Doherty (:rdoherty)]

fyi the mockups are also missing hover, open and down states for the search dropdown.

Comment 44

[Les Orchard [:lorchard]]

Starting to take a look at this since Ryan is out - I'll second the call for PSDs.  Can try to carve images out of the mockups, but I'm thinking that won't be pretty

Comment 45

[Nick Nguyen [:osunick]]

The other thing that is different from the mocks is that "recently updated" will be replaced by "top rated".  Neil, can you make sure the next rev of PSD's match?

Comment 46

[Neil Lee [:neilio]]

Here's the PSD:

http://people.mozilla.com/~nlee/public_html/amo-category/v4/mockv4.zip

Comment 47

[Neil Lee [:neilio]]

Arg. Sorry - I just noticed Nick's last comment after uploading that file. Here's an amended version with the proper heading text, plus I've added in the disabled version of the add to firefox button (not sure if we're using this or not).

http://people.mozilla.com/~nlee/public_html/amo-category/v5/mockv5.zip

Comment 48

[Nick Nguyen [:osunick]]

that last link is 404'ing for me

Comment 49

[Nick Nguyen [:osunick]]

here is the correct one :)
http://people.mozilla.com/~nlee/amo-category/v5/mockv5.zip

Comment 50

[Les Orchard [:lorchard]]

There are still a few more issues with this design that we're going to run into with the tight layout on the top 6 featured boxes:

* Already noted above, but I'll repeat it - summaries can be quite long.  Will need to play with truncations to see how existing summaries fair.

* The "Add-on Name with a very long name" text is actually not long enough to account for an addon like "Official JOCKlife sports Boom with basketball, baseball and football themes!"

http://addons.mozilla.org/en-US/firefox/addon/11166

* Addons sometimes have multiple authors, like these high-end examples:

HPTrailblazer 1.0
by Pat Croke, Cliodhna Hurst, Ann Johnston, Kim Tighe
https://addons.mozilla.org/en-US/firefox/addon/2473

Mozilla Labs - Ubiquity
by Mskadu, abimanyuraja, Atul Varma, fernando.takai, theREALjono
https://addons.mozilla.org/en-US/firefox/addon/9527

Ookong - Tailor your own deals @ Amazon.com
by Ookong, wenbinye, keaixiao, shawiz, seawan
https://addons.mozilla.org/en-US/firefox/addon/9308

That last one is particularly tetchy, since both the title, author list, *and* the summary are long. 

Granted, not all of these are going to be featured, and maybe we can introduce some character limits for featured addons and ask authors nicely to revise their text.  But, there you go.

Comment 51

[Les Orchard [:lorchard]]

Also, just checked out the aforementioned Apple downloads page.

They truncate pretty severely there - I'm amazed that they get away with "Microsoft O…"

Comment 52

[Neil Lee [:neilio]]

I talked about truncating summaries earlier - I think enforcing a limit is the only way we'll be able to do these "featured" lists without going full horizontal, which sucks for a number of reasons.

I'm not against dropping the author link from the featured boxes if that helps things - personally I don't really see how useful this is to end users anyway, as not many add-on authors have multiple add-ons, correct?

Comment 53

[Les Orchard [:lorchard]]

Attachment: progress so far

I made some progress on this, so here's a patch with what I've gotten through so far.  Hopefully it's useful work.

FWIW, while poking around, I've also noticed potential problems in the recent/popular/updated columns with long titles and versions/dates under updated.  Ugh.  Lots of truncation cases to consider.

Comment 54

[Nick Nguyen [:osunick]]

I'm ok with dropping authors for featured add-ons if that helps things.

Comment 55

[Ryan Doherty (:rdoherty)]

Attachment: Mega patch

Here's the patch. This should give Wenzel something to do on his long flight :)

Mini search is slightly different than mockup due to time constraints, but still looks pretty good. I also left out the 'popular' sorting due to time. It can be added in later.

Will attach new sprite also.

Comment 56

[Ryan Doherty (:rdoherty)]

Attachment: new sprite

Comment 57

[Ryan Doherty (:rdoherty)]

Attachment: Mega patch round 2

Arg, unsaved changes from search/replace.

Comment 58

[Fred Wenzel [:wenzel]]

Comment on attachment 374559 [details] [diff] [review]
Mega patch round 2

Oh I would have been so bored on the plane without your help, Ryan ;)

Looks very good already. Couple of things though:

- The patch does not include views/elements/search_mini.thtml, which I guess it should.
- In the mocks, there is an arrow next to the category name. Your patch says "[all]". Is that intentional?
- Also, the category list only appears on click, not hover. This is not necessarily wrong, but I remember Neil speaking of the "hover state". Do we want it to appear on click only? At any rate I would suggest making the click target bigger: "[all]", or an arrow in its place, is very small and thus hard to click.
- The current category is an <a> with a target of "#" and is not bound to a click event returning false --> when you click it, the link is followed. Same goes for clicking on "all".
- The featured add-ons do not seem to show a star rating. While the <p> in question is present, it does not display anything. Is that a problem with my dev instance or a bug?
- The "top downloads" column does not have a dropdown for different time periods. Or is that the thing you omitted for now?
- The "top downloads" column does not actually seem to be sorted by weekly downloads. On my dev copy, all-in-one sidebar with about 90k d/ls comes before IE Tab with 122k.
- I would sort the "recently added" column descendingly, so that the most recent entry is on the top. But that's just a suggestion.
- The link at the bottom of the "top rated" column does not actually lead to the "top rated" list but the "updated" list.

Comment 59

[Ryan Doherty (:rdoherty)]

-Will add search_mini.thml
-Will add arrow under 'all'
-Correct about rollover instead of click for category list
-Ratings images were referencing dev.addons.mozilla.org, will fix.
-Will ask Neil if the category name link should point somewhere.
-'Top Downloads' dropdown was removed due to time constraints.
-Not sure why the sorting isn't working for top downloads, will check.
-Good point about sorting 'recently added' descendingly.
-Will fix 'top rated' link

Comment 60

[Ryan Doherty (:rdoherty)]

Attachment: updated patch with fixes

Patch with fixes and a few small hacks.

Comment 61

[Ryan Doherty (:rdoherty)]

Attachment: updated sprite

Comment 62

[Ryan Doherty (:rdoherty)]

I forgot to mention I spoke with Neil and the menu is supposed to be activated with a click, not rollover.

Comment 63

[Fred Wenzel [:wenzel]]

Comment on attachment 374852 [details] [diff] [review]
updated patch with fixes

Looks good, though you should still sort the "most recent" list descendingly.

Comment 64

[Ryan Doherty (:rdoherty)]

(In reply to comment #63)
> (From update of attachment 374852 [details] [diff] [review])
> Looks good, though you should still sort the "most recent" list descendingly.

Thanks! They are sorted descendingly me, not sure why it doesn't work for you.

Comment 65

[Ryan Doherty (:rdoherty)]

r24979 . Also added extra sort to 'most recent' category which will ensure correct order.

Comment 66

[Fred Wenzel [:wenzel]]

(In reply to comment #65)
> r24979 . Also added extra sort to 'most recent' category which will ensure
> correct order.

That extra sort fixed the problem. Well done.

Comment 67

[Fred Wenzel [:wenzel]]

Uhm, I think I figured out why the API you used did not sort its results correctly: You are using getListAddons() which has been:

"* @deprecated since 4.0.1, use getAddonList() instead"

:(

While the page works for now, this should definitely be changed eventually.

Comment 68

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

Verified FIXED:

This has been implemented, had most of its regression bugs fixed, and in general looks really good.