566252 - update home page to focus on common use cases & target audiences

Status: RESOLVED FIXED

(Mozilla Labs Graveyard :: FlightDeck, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

The current home page for FlightDeck would benefit from some changes that focus it on the most common use cases for the primary target audience of casual developers.

It should also incorporate changes as necessary to support the secondary target audience of professional developers (including traditional addon developers) who are looking for an SDK-like experience, since FlightDeck is going to become the primary entry point for all people who are interested in building a new-style addon.

The primary reason people will visit FlightDeck is to create an add-on.  Therefore, the most prominent content on the page should be a button for creating an addon and a link to a step-by-step tutorial that takes you through the process of creating an addon using the site.

An important secondary use case is people who want to browse existing addons before making their own, so some references to existing addons (such as the Recent Extensions section that is currently on the home page) are also useful, although they should be in a position of secondary importance and prominence.

And the tertiary priorities for the page are to support the much smaller sets of people who visit the site either because they want to use it to create a library or because they want to download the SDK and develop an add-on locally.  Thus there should be references/links/pointers to creating a library and downloading the SDK, although these should be the least prominent content on the page.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Attachment: rough mockup illustrating relative prominence

Here's a rough mockup that illustrates the ideas in the description of this bug.  It puts getting started/tutorial information and a "Build Add-on" button in the positions of greatest prominence; displays lists of add-ons and libraries in a position of secondary prominence; and makes it possible to download the SDK or build a library, although those functions are the least prominent on the page.

Caveat: this mockup isn't intended to determine how the home page must look; it's just a visual illustration of the relative prominence the various functions of the page should have.  These functions may well be arranged completely differently than is demonstrated by this mockup.

Comment 2

[Piotr Zalewa [:zalun]]

It is removing the sidebar from the landing page. I think it's a good idea.

Comment 3

[Myk Melez [:myk] [@mykmelez]]

I went through the most recent changes to the home page, and it's definitely much improved!  There is still some more work to do, however.  Here's my review of the remaining issues:


Header/Primary Navigation Bar

The thin "Mozilla" header on AMO should be added to the top of the page (above the header).

The logo should be replaced with the one Sean provides in bug 570167.

Signing in on the home page should return you to the home page.  On AMO, this is accomplished by adding a "to" parameter to the URL specifying the URL to which to return the user, f.e. if I click AMO's "log in" link from its home page <https://addons.mozilla.org/en-US/firefox/>, it takes me to <https://addons.mozilla.org/en-US/firefox/users/login?to=en-US%2Ffirefox%2F>.  Then, upon signing in, I get returned to the home page.

When you are signed in, the logout link should be called "Sign Out".

The API Browser link should be called Documentation, and it should link to an introductory page (to be written) describing the various kinds of documentation available on the site, including (but not limited to) the API docs.

The Package Browser link should go away, as browsing add-ons and libraries is a less prominent feature of the site and doesn't need to be at the top of every page.

The "Sign in" link should be written "Sign In" (title case, with a capital "I" in the word "In").

The tooltip for the Sign In button doesn't need a title, and its description should read "Sign in with your addons.mozilla.org account."


New Add-on/Library Buttons

The New Add-on button is a bit more prominent now that its background is a brighter color, but it still isn't prominent enough. It should be much more noticeable. Conversely, the New Library button is too prominent. It should be much less obtrusive (just like the button for downloading the SDK).

I don't think we can accomplish these goals while leaving the buttons in their current location on the secondary navigation bar, as it constrains our ability to use size and other techniques to highlight that button.  Instead, we should move both buttons down into the main content of the page and get rid of the secondary navigation bar entirely (which wastes a lot of vertical space on the home page given that it only hosts these two buttons).

Regarding the New Add-on button, see the "Start Making Add-ons" button in the Add-on Developer Hub <https://addons.mozilla.org/en-US/developers> and the "Download Firefox - Free" button on the Mozilla home page <http://www.mozilla.com/en-US/> for examples of what I mean when I talk about prominence.  When someone loads this page, their eye should be instantly drawn to that button; it should be the biggest, boldest, brightest, and/or most centered thing on the page, outshining the introductory text, the lists of add-ons and libraries, and *everything else*.

Regarding the New Library button, it should be even less prominent than the "Download Add-on Builder SDK" button at the bottom of the page, i.e. it should be smaller, more off to the side, lower down (i.e. below the fold), and/or less colorful than almost all the other content on the page.

Also, the labels of these buttons should be calls to action, i.e. "New Add-on" should be "Build an Add-on", and "New Library" should be "Build a Library".

Finally, instead of telling me I need to be signed in when I press the "New Add-on" button while signed out, FD should just take me to the sign-in page.  And when I press the button while signed in, it should take me directly to the editor without requiring me to fill out a form first (i.e. it should not be necessary to specify a name and description in order to start building an addon).


Introductory Text

The introductory text shouldn't be divided into three different sections, as we won't actually have enough text to justify breaking it up, and the text that we will have won't be cleanly divided into those three parts, it'll be all mixed together.  I don't have a final version of the text ready yet, but it'll be something like:

<h2>Welcome to Add-ons Builder!</h2>

This site is the quickest and easiest way to build an add-on for Firefox using common web technologies.  Building an add-on is as simple as pressing the <b>Build an Addon</b> button and typing in your code!

You can use a <a href="">variety of APIs in the core library</a> to add functionality to Firefox, including <a href="">widget</a> and <a href="">context-menu</a>.  Check out the add-ons listed below for inspiration and take advantage of third-party libraries of additional APIs. And <a href="">read the tutorial</a> for a step-by-step guide to building your first add-on using this site.

Happy hacking!


Content Width

The content on the home page and other non-editor pages is very spread out on wide monitors, with too much white space between sections.  The width of that content should be constrained, the way it is on mozilla.com, addons.mozilla.org, and other Mozilla websites, so there isn't so much space around it.  Per Daniel, this can be implemented as min- and max-width limits with a percentage width style.

Note: one tricky issue is that, unlike those other websites, FD has a page (the editor page) whose width should not be constrained, since we want to give users as much space as possible to edit their addons.  But if we constrain the headers in addition to the content on all the other pages (the way those websites do), then the headers will change size between the editor and non-editor pages.

I'm not sure what to do about this, but I think we should still constrain the content of non-editor pages, despite this issue.


Get Ideas Section

It's great that the "more" buttons are now at the bottom of the page, but since "add-ons" and "libraries" are linkified in "browse add-ons and libraries (APIs)", the first actions you are being presented with are still to leave the page without browsing the add-ons and libraries it displays.

And the two layers of headers and dividing lines costs a lot of vertical screen space. So let's eliminate "Get ideas [Browse Add-ons and Libraries (APIs)]" and replace "Recent Add-ons" and "Recent Libraries" with "Browse Add-ons" and "Browse Libraries", respectively.  Then change the links at the bottom from "Browse Add-ons" and "Browse Libraries" to "Browse More Add-ons" and "Browse More Libraries".

Also, the version identifiers are not important in these lists of add-ons and libaries and should be left out.

And the View Source button should have rounded left corners for libraries.

Finally, the "Browse [More] Add-ons/Libraries" links seem fairly divorced from the lists of addons and libraries, perhaps because there is a line between them.  They should feel more connected, since the "more" links represent a continuation of the lists.


"Prefer the command-line? Want to work locally?" Section

The title of this section should be "Get the SDK", and the text of the section should be:

Prefer the command-line? Want to work locally?
[Download Add-ons Builder SDK]
<a href="">More Info</a>

Note: the button currently reads "Download Add-on Builder SDK" with "Add-on" in the singular; it should be plural "Add-ons".


Footer

The page should have a footer like the footer on addons.mozilla.org pages, except for the following modifications:

* the image on the right-hand side should be a different logo (Sean to provide this in bug 570167);
* the "Blog" link should point to the Jetpack blog;
* the "Forum" link should point to the Jetpack discussion group;
* the About, FAQ, and Developer Hub links should be hidden;
* the "other languages" dropdown menu should be hidden.

Comment 4

[Piotr Zalewa [:zalun]]

Just a quick explanation: 
> Also, the version identifiers are not important in these lists of add-ons and
> libaries and should be left out.

The version revision are displayed to the author of the package and allowing to switch to 2 most used cases - edit the latest saved revision or "main" version of the package. It is only visible if the latest saved revision is not the "main" version.

In example:
User copies/creates a package, bar looks like:
[View Source | Edit]
User changes something and saves without making it a version:
[View Source | Edit (initial) | Edit (rev. 1)]

I think it is needed otherwise user will have to remember the link.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #4)
> The version revision are displayed to the author of the package

In my case, I wasn't the author of any of the packages, but I still saw these identifiers.


> In example:
> User copies/creates a package, bar looks like:
> [View Source | Edit]
> User changes something and saves without making it a version:
> [View Source | Edit (initial) | Edit (rev. 1)]

I understand the value of allowing users to edit a version of an addon/library in order to branch and release a minor update of that version, but that feature isn't a priority for the second preview release, and it raises complicated issues about how we present branching in the app.

So we should leave it out for now and only provide users with the option of editing the latest revision of an addon/library.

Comment 6

[Piotr Zalewa [:zalun]]

> I still saw these identifiers.
You seen them because of the recent AMO HTML change {bug|570960} all users had the same username 'user'.

> So we should leave it out for now and only provide users 
> with the option of editing the latest revision of an addon/library.

It's OK to give people access to the latest editing Add-on.

However I can see few problems: 
* address they'd share directs to the precise PackageRevision (by revision number or version name)
* PackageRevisions depend on LibraryRevision - it has to be the Revision to avoid problems with not backward compatible changes of Libraries. We have to allow to at least see non latest revision

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #6)
> > I still saw these identifiers.
> You seen them because of the recent AMO HTML change {bug|570960} all users had
> the same username 'user'.

Do you mean bug 570360?  Note that while you need to write {{bug|570360}} to linkify a bug on the wiki, in Bugzilla you just need to write "bug 570360"!


> * address they'd share directs to the precise PackageRevision (by revision
> number or version name)

Can we alias "tip" to the latest revision and use it in URLs except when a user requests a specific revision?


> * PackageRevisions depend on LibraryRevision - it has to be the Revision to
> avoid problems with not backward compatible changes of Libraries. We have to
> allow to at least see non latest revision

Yes, absolutely!  It should always be possible to *view* a revision of a file.  I only want to delay enabling users to *edit* an older revision for now, since doing so means implementing branching, and that's a complicated feature that we'd have to spend a bunch of time on to get it right.

Comment 8

[Piotr Zalewa [:zalun]]

> Do you mean bug 570360?
yes, thanks for the tip - still learning bugzilla

> Can we alias "tip" to the latest revision and use it in URLs except 
> when a user requests a specific revision?

Do you mean - while editing it should always show the latest revision? (I suggest to mark it as /addon/edit/123234/latest/ to make it future compatible)
I can do it easily. I will also make a redirect to view if no author.

Linking to the Library: should it be to the latest revision, or latest "versioned" revision?

Comment 9

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #8)
> Do you mean - while editing it should always show the latest revision? (I
> suggest to mark it as /addon/edit/123234/latest/ to make it future compatible)
> I can do it easily. I will also make a redirect to view if no author.

Yes, that's right, the /latest/ URL (which is the URL to which we should direct users by default, whether they are editing or viewing the addon) should show the latest revision.


> Linking to the Library: should it be to the latest revision, or latest
> "versioned" revision?

To the latest revision.

Comment 10

[Piotr Zalewa [:zalun]]

Done - more "freedom" will be added in next iteration