499738 - developer.AMO homepage designs

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, enhancement)

Description

[Chris Howse [:chowse]]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11
Build Identifier: 

Create a site that aggregates documentation, resources, tools, news, and networking opportunities for add-on developers.

Reproducible: Always

Comment 1

[Chris Howse [:chowse]]

 Wiki: https://wiki.mozilla.org/AMO:Projects/developer.AMO

Goals: https://wiki.mozilla.org/AMO:Projects/developer.AMO/Objectives
 Spec: https://wiki.mozilla.org/AMO:Projects/developer.AMO/Features
Notes: https://wiki.mozilla.org/AMO:Projects/developer.AMO/Meeting_Notes

Comment 2

[Chris Howse [:chowse]]

Attachment: Preview Mockup

Comment 3

[Chris Howse [:chowse]]

Attachment: Preview Mockup (Variation)

Comment 4

[Justin Scott [:fligtar]]

The mockup looks awesome. My comments, in no particular order:

* We can get rid of the post author and time in Developer News section
* I like that events show the location
* I like the categorization of links in the bottom. I think they're correct.
* I can't decide between the first and second variations. The first highlights the promo area and leaves the links a bit more obscure, while the second highlights the links. I think it depends on what we have in the promo section as to which we should go with.

I'll work on some copy to replace the Lorem ipsums, and think about the menu dropdowns.

I need to think more on the main section. Where do you imagine the "Start Building Add-ons" link going?

Comment 5

[Chris Howse [:chowse]]

(In reply to comment #4)
Thanks for the feedback. In response:

> * We can get rid of the post author and time in Developer News section
I'd recommend at least leaving the time in. That's useful for revisits, doesn't take up much space, and should be relatively easy to extract from feeds. I'd recommend keeping an author (or some kind of source) if we start aggregating different feeds.

> * I like that events show the location
Thanks. I'm assuming the event names don't frequently include the location itself. ;)

> * I can't decide between the first and second variations. The first highlights
> the promo area and leaves the links a bit more obscure, while the second
> highlights the links. I think it depends on what we have in the promo section
> as to which we should go with.
Agreed, though I'm leaning toward the former. I can add visual touches to make the links more prominent. We really want the promo to attract first-time users.

> I'll work on some copy to replace the Lorem ipsums, and think about the menu
> dropdowns.
Heh, recognized those toolbar buttons for drop-downs, huh? ;) Here's the organization I'm currently considering:

* Documentation
* Resources
  * Tutorials
  * Best Practices
  * Case Studies
  * ...
* Tools
  * Add-on Builder
  * Code Search
  * Add-on Verifier
  * ...
* Community
  * Forums
  * News
  * Events

> I need to think more on the main section. Where do you imagine the "Start
> Building Add-ons" link going?

Some kind of tutorial page. I'd really like to steer first-time users toward one of these two pages:
* https://developer.mozilla.org/En/Firefox_addons_dev_guide
* http://vimeo.com/3740324

I need to flesh out the IA of this site a bit more, then I'll work on another round of wireframes.

Comment 6

[Chris Howse [:chowse]]

A few more random ideas for Dev.AMO:

* Search that spans not only Dev.AMO, but relevant sections of DevMO, the Add-on Blog, and other add-on sites.
  * By default, the search should interleave results from all sites and prioritize them by relevance. This could be achieved with Google Custom Search (http://www.google.com/coop/cse/) or Yahoo BOSS (http://developer.yahoo.com/search/boss/).
  * Provide the option on the results page (and possibly in the toolbar) to narrow the search to single site. Results could then be drawn from the site's API (or by adding domain constraints to a search engine).

* A fine-grained how-to/FAQ system.
  *  Frame questions in terms of common tasks (e.g. "how do I create a Preferences window for my add-on?").
  * Answers can be a quick summary, with links to a full tutorial or the relevant documentation.
  * See the iPhone How-To Page for an example (http://www.apple.com/iphone/how-to/).

* A video library: screencasts, bootcamps, ... showing, not telling.
  * Examples: Google Developer Channel (http://www.youtube.com/GoogleDevelopers), YDN Theater (http://developer.yahoo.net/blogs/theater/archives/2009/06/developer_spotight_mint_part1.html)

Comment 7

[Justin Scott [:fligtar]]

I think we should think about logged-in/logged-out cases too. If we make this page the replacement of the /developers index, logged-in users could see information about their submitted extensions in the center promo module instead of something trying to get them to make their first extension.

My thoughts on the navigation:

* Documentation
** Getting Started
** Best Practices
** Tutorials

* Resources
** Add-ons Blog
** Add-on Policies
** Case Studies
** Newsletter

* Tools
** Add-on Builder
** Code Search
** Submit Your Add-on

* Community
** Forums
** Newsgroups


(In reply to comment #5)
> (In reply to comment #4)
> > * We can get rid of the post author and time in Developer News section
> I'd recommend at least leaving the time in. That's useful for revisits, doesn't
> take up much space, and should be relatively easy to extract from feeds. I'd
> recommend keeping an author (or some kind of source) if we start aggregating
> different feeds.
> 

I don't think we'll be aggregating multiple feeds. I'm expecting only articles of great interest to developers will appear there, probably once a week on average, maybe 2. I don't think the time and author are important enough to be in this concise box of developer-related news, but we can leave it there for now and see how it feels.

Comment 8

[Chris Howse [:chowse]]

(In reply to comment #7)
> I think we should think about logged-in/logged-out cases too. If we make this
> page the replacement of the /developers index, logged-in users could see
> information about their submitted extensions in the center promo module instead
> of something trying to get them to make their first extension.

I like this idea, and am working on some wireframes for it. I'm thinking:

* A reduced stats dashboard in the promo module, showing downloads/users for all the user's add-ons.
* Queue stats in the sidebar.
* A list of sandboxed/flagged add-ons in the sidebar, along with updates or requests for attention.

Any other useful data you think would be relevant?

> My thoughts on the navigation:
> 
> * Documentation
> ** Getting Started
> ** Best Practices
> ** Tutorials
> 
> * Resources
> ** Add-ons Blog
> ** Add-on Policies
> ** Case Studies
> ** Newsletter
> 
> * Tools
> ** Add-on Builder
> ** Code Search
> ** Submit Your Add-on
> 
> * Community
> ** Forums
> ** Newsgroups

Not a bad org. Some questions/observations:

* What's the "Newsletter"?
* What's the difference between "Tutorials" and "Getting Started"? The latter seems like a type of the former. Would the latter be locally hosted? That said, I like drawing attention to the former (hence it being in the promo).
* I treated "Documentation" as meaning reference material in particular (e.g. API docs), as opposed to learning resources (which I put under "Resources"). This would need to go somewhere in this model (maybe as "References" under "Documentation").
* "Submit my Add-on". Good catch, this needs to be under top-level navigation. Once the user is a "developer" (i.e. has submitted at least one add-on), this should probably become "Manage my Add-ons", which takes the user to the equivalent of the Developer Tools page.

Comment 9

[Chris Howse [:chowse]]

Attachment: Manage My Add-ons (i.e. Dev Tools) Wireframe

An alternative landing page for when a developer is logged in. Preserves the current functionality of the Developer Tools page, but adds more information that would be of interest on recurring visits (e.g. add-on stats, notifications, review queue status).

Comment 10

[Chris Howse [:chowse]]

Attachment: Updated Homepage

New version of the Developer.AMO home page, integrating new features and feedback.

Comment 11

[Justin Scott [:fligtar]]

Cool logged-in wireframe.

A few comments:
* I think all of the graphs make the page a lot more complicated than it needs to be. If we have the stats in a big graph at the top, I don't think we should have the same stats in graphs next to each add-on entry.
* The scrolling menu is a cool effect, but I'm not sure it's helpful. If you are scrolling down the page, you're already at the add-on boxes that those menu links go to.
* Since the Manage My Add-ons menu is also available from the toolbar, I'm thinking we should just get rid of that column and make the main stats display wider.
* I think I like the 3rd style of add-on display best, although Managing preview images isn't important enough to be there, I don't think. We should replace the preview image line with a link to upload a new version, because that's a very common action.
* I like the Recent Activity box, and we can link that to a newsfeed page with all sorts of goodies, like someone reviewing/rating the add-on, someone adding it to their collection, etc.
* I like the Review Queue graphs.

Comment 12

[Justin Scott [:fligtar]]

On the new homepage mockup:

* I actually prefer the previous arrangement of links at the bottom of the page. It requires less scrolling and we would have to come up with images for each of those links in this layout.
* I like the better submission call to action box. The wording is a bit weird for me though - maybe a heading of "Ready to share?" and body "It's easy to list your add-on on our website. [Submit Your Add-on]"
* I think the blog box should have a "Developer News" heading.

Other than that, it's looking great.

Comment 13

[Chris Howse [:chowse]]

(In reply to comment #11)
Thanks for the feedback.
> * I think all of the graphs make the page a lot more complicated than it needs
> to be. If we have the stats in a big graph at the top, I don't think we should
> have the same stats in graphs next to each add-on entry.
With the right size and use of color, this doesn't have to appear overly complex. Balsamiq doesn't give me much to work with in terms of charts, so I'm stuck the loud, bold ones. I honestly imagine those charts more as sparklines (see here for an example: http://analytics.blogspot.com/2008/10/slight-touch-up.html). We can experiment with this as the mockups get more hi-fid.

> * The scrolling menu is a cool effect, but I'm not sure it's helpful. If you
> are scrolling down the page, you're already at the add-on boxes that those menu
> links go to.
I have to disagree. The menu box is intended for quick nav (i.e. take me straight to add-on X) and I imagine it could be used not just at the top of the page, but even once the user gets to the add-on list (either by scrolling or using the nav bar).

> * Since the Manage My Add-ons menu is also available from the toolbar, I'm
> thinking we should just get rid of that column and make the main stats display
> wider.
While I agree that making the stats block larger would be a good thing, I still think having the menu box there is important (namely, for when users come here to make a change to an add-on). It also is (currently) the only way to get to the Add-on Submission page from the body of this page.

If we include add-ons under the "Manage My Add-ons" (now just "My Add-ons"), this might be less of an issue. I still like making this kind of navigation visible in the page itself.

> * I think I like the 3rd style of add-on display best, although Managing
> preview images isn't important enough to be there, I don't think. We should
> replace the preview image line with a link to upload a new version, because
> that's a very common action.
While I agree that adding a new version will probably happen more frequently, right now finding how to add/update previews is very buried in the UI, and I'd like to make it more visible. Let me see if I can include both in the interface.

> * I like the Recent Activity box, and we can link that to a newsfeed page with
> all sorts of goodies, like someone reviewing/rating the add-on, someone adding
> it to their collection, etc.
Just my thinking. I'll build this out further once we have wireframes for more high priority pages.

Comment 14

[Chris Howse [:chowse]]

(In reply to comment #12)
> * I actually prefer the previous arrangement of links at the bottom of the
> page. It requires less scrolling and we would have to come up with images for
> each of those links in this layout.
Here's the thinking behind the change:
- We can exclude images for most (or all) of the items, if necessary. I just like to imagine I have a set of beautiful images for every UI element I make. ;)
- With the 2 column layout (and our current number of subpages), we can still fit all of the links above the fold (on a 1024x768 screen, anyway).
- I'm a little concerned that with 3 columns, the description we put under each link will wrap poorly and span more than 2 lines unless we make them extremely succinct (i.e. to the point of uselessness).
- Since we now have 4 categories of subpages, we have to use a slightly different organization for this linkset (4 cols is out of the question). "Learn & Explore" and "Create & Connect" felt like a nice breakdown. I need to think a little more about a 3-way split.

I actually have several different designs for that block. I can provide more samples once the IA solidifies.

> * I like the better submission call to action box. The wording is a bit weird
> for me though - maybe a heading of "Ready to share?" and body "It's easy to
> list your add-on on our website. [Submit Your Add-on]"
I like that copy a lot better. It'll be in the next iteration.

> * I think the blog box should have a "Developer News" heading.
That was my first instinct, too. But if the "More..." link takes users to the Add-on Blog (even if filtered to dev articles), I feel we should use Blog somewhere in the title. "Developer Blog", maybe?

Comment 15

[Chris Howse [:chowse]]

Attachment: Javascript for Floating Menu

A JQuery plug-in to make the floating menu box in the Manage My Add-ons mockup. Makes an element fixed-position when the window scrolls below its original y-position on the page. Only changes the DOM when that threshold is crossed, so is pretty responsive. No fancy effects or anything, just keeps the menu in a place you expect.

Comment 16

[Chris Howse [:chowse]]

Here's another quick iteration on the home/manage pages:

http://people.mozilla.com/~chowse/drop/developer_amo/v1/

Comment 17

[Wil Clouser [:clouserw]]

On the manage add-ons mockups:  Is the graph at the top the sum of all your add-ons or each one plotted separately?  Judging from the legend it's each add-ons' stats plotted separately against each other.  If that's the case I'm not sure it's useful since you've got all that data next to each add-on anyway.

If it's the sum of your add-ons' stats, it is computationally intensive but more interesting.  Not sure it's useful though, particularly taking up the most important spot on the page.

Comment 18

[Chris Howse [:chowse]]

Another iteration on the My Add-ons page:

http://people.mozilla.com/~chowse/drop/developer_amo/v2/

The chart on the top of the page was intended to show each add-on's stats separately. Since this make's the graphs beside each add-on redundant, I've removed them in this iteration. Since the small icons beside each add-on's label (supposed to be eyes) are used to show/hide individual lines, it can still be used to view a single add-on's stats. Clicking on the add-on's label will also open the stats dashboard for just that add-on.

I've modified the add-on entry slightly to make use of the extra space. I've used two styles, both of which are included in each mockup. Any thoughts on which is better?

Like before, I've included versions with a the graph occupying 1 and 2 columns. I'm warming up to the 2-col version, but only if the top of the list of add-ons can appear above the fold. It's not unreasonable to expect devs to come to this page to make changes, and I don't like the fact there's nothing immediately visible to indicate this can be done.

Comment 19

[Wil Clouser [:clouserw]]

- Can you annotate some of the links?  Where does "Recent Activity" go?  What about "Review Queue"?  Any others we can't see (like clicking on a graph)?

- What all is in the dropdowns on the main graph?

- What is the black arrow pointing to the "2,500 add-ons pending approved" indicating?

- I like the second add-on box better than the first, but what do you think of using consistent language for modifying the properties?  "Edit add-on" "change status" "manage previews" - how about just a little "edit" or "manage" link after the text?  That said, I prefer "Submit new version" or "Add a new version" instead of just the "new version" link.

Comment 20

[Wil Clouser [:clouserw]]

Double-comment!

I know I said I like the second add-on box better, but I like the "2 images" link in the first one - it seems more useful than just text.  Also maybe we could throw a small "new version" link up by the title to keep our rows straight?  Just an idea.  I guess I like a combination of the two boxes.

Comment 21

[Justin Scott [:fligtar]]

My thoughts:

* I think the placement of "Submit a New Add-on" in the stats table is odd
* I think the Quick Links box is only useful if it's at the top of the page. Once the user has scrolled down to the list of add-ons, it's not helpful. And I still don't think it needs to have the fancy scroll-with-the-page effect.
* I think the add-on boxes have too much information. I would like to keep them with about the same amount of stuff to look at that they currently have. Having to choose something to remove, I would kill the stats. I think the large stats box at the top with links to the dashboard is more than sufficient for this index page.

I don't think this page should be very complicated or dense -- it should be a portal to what a logged-in developers wants to access quickly. We don't need to try to compress the entire Dev CP into this page.

Comment 22

[Wil Clouser [:clouserw]]

https://addons.mozilla.org/en-US/developers