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.
Special Thanks to Madhava Enros and Henry Brown for the overall design and mockups.