Categories: end users releases

AMO Design Update (now with all Mozilla products)

In my last post, I outlined some the design changes we’re planning for AMO.  A number of commenters raised the issue that the design could lead to non-Firefox applications being under-represented on the site — definitely not something we want to do.  So, we went back to the drawing board and came up with what we believe to be a reasonable balance between streamlining the basic use case — a Firefox user grabbing an add-on — and still showcasing the other applications in the Mozilla community.  The mockups appear below.  There are three major changes represented here:

  • Removed the “global header” that currently graces most mozilla.com properties to help give AMO an identity, additional simplicity and a logical navigation structure
  • Reduced the overall height of the header area which means that you get to the content/meat quicker
  • Added an application selector to the “main page” in a prominent position on the page

This raised the question of what are the Mozilla products that should be supported by AMO. Given that AMO is a Mozilla project resource meant to support the Mozilla project’s official products/applications – the list of apps include Firefox, Thunderbird, SeaMonkey, Camino and Sunbird exclusively. (Currently, Camino does not natively include add-ons capabilities or an add-ons manager so it’s not listed). It is expected that as Mozilla’s mobile efforts bear fruit that mobile-related add-ons would be supported as well.

The default entry point advertised by Mozilla application are the AMO subsites: Firefox, Thunderbird, SeaMonkey, Sunbird. This is where the application selector would appear. Currently, the AMO top level page (http://addons.mozilla.org) redirects to a localized Firefox subsite as the majority of users are installing Firefox add-ons.

I think of AMO as a hosting service supporting multiple apps with a shared backend (servers, mirror network, user database, reviews and discussion infrastructure and so forth.) I’ve argued for “segregation” in order for each app to provide (possibly) unique user experiences using app-specific AMO skins/theme, add-on installation options, etc. Our current “subsite” structure essentially offer this today, e.g. categories are app-specific and the recommended add-ons list is unique. I would expect this to continue and would love to hear feedback about unique needs of Mozilla apps so that we can work it into future AMO revisions.

App Selector (closed)

App Selector (open)

SeaMonkey header

Special Thanks to Madhava Enros and Henry Brown for the overall design and mockups.

10 comments on “AMO Design Update (now with all Mozilla products)”

  1. Brian King wrote on

    I always found the segregation confusing. Anything that lessens this confusion is good, but I am not sure the proposed dropdown in your mockup goes far enough.

    For eample, search results only give hits for the product you are in at the time. Consider at least giving search results for all products. Or at least provide links at the top of the results page something to the effect of ‘See also results for Thunderbird’.

  2. Myk Melez wrote on

    Hey Basil,

    This looks great. I just realized that you responded to my comment in your earlier blog post:

    > @myk: The final design actually has a dropdown box with 5,10,20,50,100 items so there should be less page turning.

    Any chance you can add an “All” item to this menu? I regularly do searches that return more than 100 items, and it’s much much easier to find the addons I’m looking for in the search results using Firefox’s Find in Page feature when I don’t have to jump from page to page to do it.

  3. bhashem wrote on

    @Brian: We have some ideas to help the search problem along the lines of what you suggest. They are not likely to go into this upcoming release but certainly for consideration for the one after that.

    @Myk: Great idea Myk, it’s natural to have an “All”, we’ll get that added in.

  4. Callek wrote on

    these mockups do address my main “other apps” concerns, thanks…

  5. Michael V. van Rantwijk wrote on

    Removing this 175 pixel tall chopper image will definitely make room for a menu or whatever.

    I also agree with Brian that the drop down menu might not be enough, but it might be the only solution when more and more applications are added.

    However, what about having an entry page where all applications are listed, where people select the target application. Moving the “We Recommend:” section at the right of the page over to the appropriate pages. I mean, you probably want this for every single application, right?

    It would be cool if you could check the HTTP User Agent to select the target application section/pages automatically, skipping the main/entry page. Having a link on all pages (or a tab) to ‘return’ to the main/entry page would be a plus.

    p.s. The current ‘Extend Firefox 2 Contest’ banner is a bit distracting on non-Firefox related pages.

  6. Dave Miller wrote on

    We already have a few add-ons for Bugzilla, and we’re approaching the point where we’ll be able to have self-contained plugin bundles dropped into a specific place to add features to Bugzilla. Any thoughts about a section for Bugzilla? I imagine it would be useful for localization packs, skins, and plugins alike for Bugzilla, none of which we host right now, and you have to look for them scattered all over the web. The hitch is that none of it would be xpi or jar files.

    http://wiki.mozilla.org/Bugzilla:Addons lists a bunch of what’s out there now.

  7. Brian King wrote on

    I agree with Michael that a lead in homepage with all products listed would be useful. I also understand the rationale behind defaulting to Firefox, with it being the most popular and the most extensions.

  8. bhashem wrote on

    @Michael V. van Rantwijk: We have an outstanding feature request for SeaMonkey to do User Agent string detection and route appropriately. Doesn’t quite work for Thunderbird since most will be using a browser to download Thunderbird add-ons.

  9. Simon Paquet wrote on

    The current design is better in terms of visibility for the other apps, but to be completely honest, that wasn’t very difficult as the other apps weren’t visible at all in the earlier design mockups.

    The design still misses to address the following use-case:

    A person looking for Thunderbird add-ons comes to http://addons.mozilla.org (please notice the “.org” in the URL) and is greeted with a big fat “Firefox Add-ons header”. If that doesn’t turn him away immediately, he then has to look for the “Other applications” link. Let’s assume that he is totally smart and tries to search for “Thunderbird”, that will not direct him the “Other applications” link, right?

    I totally understand your desire to streamline the usability for Firefox users, but you should also understand that you’re creating a self-fulfilling prophecy here. By de-emphasizing the other apps, fewer people will look for non-Firefox extensions which will in turn lead to a higher percentage of Firefox-only searches, giving you more incentive to de-emphasize the other apps even further.

    I repeat my statement from your earlier post on this matter: This would be fine, if this were a addons.firefox.com or even a addons.mozilla.com website, but mozilla.org is about much more than just Firefox and this should be reflected in pages coming from that domain.

    What I would propose is an easy-entry page like http://www.mozilla.com, call it Mozilla Add-ons, put a big link to Firefox add-ons on top and smaller links to Thunderbird, SeaMonkey and Sunbird add-ons below the big Firefox link. Then continue with your current design (from this post).

  10. Eduardo wrote on

    I, sincerely, hated the AMO for a long time.
    When I search for a Seamonkey add-ons all thing come back, but only one add-on for Seamonkey and ten for FF when a stay at Seamonkey session of site.
    Now a hope the service work better, with the add-ons repor to to search product correctly.
    Thank you for the work!