Following are changes which should be done for the next iteration or before beta.

[Myk: in order to ship a public beta by the end of June, these changes should land before the second preview release, as it will be hard to make them after that release and still have time to ship a public beta by then.]

After FlightDeck UX review

FrontPage

1. Add a place for tutorial
   • slideshow of the easiest path to create an addon as a placeholder
2. Make it more descriptive
   • Myk: see bug 566252 for a description of the changes we should make to the home page.

PackageBrowser

1. Menu
   • Make [New Extension] / [New Library] more prominent
     • Myk: actually, it's only the [New Extension] link that should be more prominent, since our primary target audience is developers who want to build an addon, not those who want to build a library. See the mockup in bug 566252 for a visual explanation of the difference in prominence these links should have.
2. Move See more to the bottom of the page
3. Package Action bar
   1. Change [Edit] to [View Source] if user can't edit the code
   2. Add number of other plugins author has written
      • Myk: it would also be valuable to link the author's name to a profile page that lists their add-ons and libraries.
        • zalun: this is already done as next to the Package's name it's said by [author name] which links to the public profile
   3. Add author overall rating
      • Myk: currently, the site doesn't have ratings, and we should definitely not add them in this next phase of development. In fact, I'm leery of adding them at all, except possibly for libraries at some point.
        • zalun: I'd say we should remove ratings from design then
   4. Remove versions
      • Myk: also, remove [Try in browser] from the list of addons; users should view the source of an addon before deciding to try it out, since FlightDeck is a developer-focused site, where the purpose of giving developers access to each others' addons is to encourage them to learn from each others' code.
        • zalun: If it's so easy to test/untest the addon I do believe people may like to see what the thing is doing before checking the source. Imagine - I want to look for example of an addon colouring tabs - there is about 10 such addons - I'de prefer to check the result first and then see how it's done.

FlightDeck Plugin

1. [Install Flightdeck] above Categories
   • Myk: actually, we should remove Categories and the [Install FlightDeck] button entirely from the home page, since they don't provide any value (there are no categories, and it isn't necessary to install the addon to use the home page).
2. Make a FlightDeck Add-on warning show when needed - not all the time
3. Change the wording in confirmation after installed addon
   • Myk: note: we'll have to rename this addon to something like "Add-on Builder Helper". Also, I suggest we implement the following behavior for exposing it:
     • when you visit the home page, FlightDeck doesn't prompt you to install the Helper addon, since it isn't necessary to use any feature of the home page;
     • when you press the [Build Add-on] button to create a new addon or the [Edit] or [View Source] buttons for an existing addon to edit it or view its source, FlightDeck still doesn't prompt you to install the Helper addon, because it still isn't necessary to have that addon in order to start editing one of your add-ons or view the source of someone else's;
     • when you press the [Try in Browser] button for an addon from the Edit or View Source pages, however, and you don't have the Helper addon installed, FlightDeck prompts you to install the Helper addon, since the Helper addon is necessary to test an addon; once you install it, the Helper addon notifies FlightDeck that it has been installed, and FlightDeck tells the Helper addon to install the addon being edited/viewed.

Editor

1. Add [Duplicate & Edit] for Package
   • Myk: call this simply [Copy]
2. Add ability to upload an icon
   • Myk: is this for display in FlightDeck itself or for including in the XPI bundle? If the former, this is not a priority, as the focus of the site is development, not distribution, so it is less important for addons to be able to advertise themselves better by using graphical aids like an icon. It will be valuable for libraries to advertise themselves via an icon, on the other hand, but library development is a lower priority in the initial phases of the application.

Test Now

1. Change [Try in Browser] to [Test Now]
   • Myk: [Test] should be sufficient for this button, as "Now" is implicit and idiomatic.
2. Make the button to show the status of testing - leave it pushed if the Addon is under testing
   • Myk: right! Also, if you press the button again, it should uninstall the addon being tested and then revert to its unpressed state.
3. add another URL for create_xpi action - test_now - should do the same, but in # case it will do different action in the future - we're saved
   • Myk: it's not clear what this is trying to say; can you elaborate?
     • zalun: /[...]/create_xpi/ and /[...]/test_now/ should use different URL

Login Sign in Page

1. text: Log in to the Firefox Add-On Builder with your addons.mozilla.org account. Don't have an account? Get one.
   • Myk: nit: log in -> sign in
2. Remove Menu Bar
   • Myk: Aza's suggestions are actually more significant than this. He suggests that the sign in process should happen on the same pages on which you do something that requires you to sign in. For example, when you press [Build Add-on] on the home page, the home page itself should prompt you to sign in. And when you press [Copy] on a View Source page, the View Source page itself should prompt you to sign in before it transfers you to the Edit page for the new copy of the addon.
     • zalun: for sure - as the moment the login process is a bit complicated (due to scraping the AMO website), I'd leave it for the next iteration. It does work as it is.

After build system changes

Editor

• Manifest and other metadata are now edited inside a window. This window should be an "information window" if user has no editing rights (is not the author)
• New Modules section - this is a list of Modules inside edited Package
• Libraries section is to provide "Add Library" and "Library View/Remove" triggers.
• View Library opens a new tab with the Editor
• Sidebar contains Attachments Section
• jetpack-core dependency is hidden and added in the back-end, however if someone would add a replacement to the FlightDeck it might be used and will not be overwritten by the SDK one

Myk: overall, this looks pretty good. However, there are some issues:

• The Edit Package Info dialog should be called either Edit Add-on Info or Edit Library Info depending on what kind of package is being edited. In general, users shouldn't have to know that add-ons and libraries are both kinds of packages, they should always interact with the concepts of "add-on" and "library" rather than their underlying implementation as "packages".

• The difference between Full Name and Name is unclear. And it shouldn't be necessary for users to understand this difference anyway, since the name is only used internally by the SDK, and FlightDeck can generate a name automatically by removing spaces and other invalid characters from the full name. So the Edit Add-on Info dialog should only prompt users for a fullName, although it should call it simply a "Name".

• Changing the version is different kind of task from editing general information about the package. It indicates that the developer wants to mark the current revision in a special way and potentially distribute it to users. Thus its interface should be distinct from the one for the package info editing task, although it's not yet clear to me how best to provide it. It could be a [Mark as Version] button in the toolbar.

• The name of the author should appear underneath the add-on name and version rather than at the bottom of the sidebar, and it isn't necessary to label it with the label "author", as its meaning should be clear in context.

• The button for editing package info should be placed by the package info itself near the top of the sidebar rather than near the bottom. And it should be called [Edit Info] rather than just [Info].

• The dropdown menu labeled "version" is actually a revision selector, not a version selector. However, "revision" is a fairly technical term and is going to be confusing to users given that the site also uses the similar word "version" to mean something different. So we should label that selector with a different label. Since the button for creating a revision is called Save, let's call it "Saves".

• • Daniel: Calling these Saves to me doesn't feel right. I believe that revisions is the best choice, I don't think it is too technical for our demographic. It is a pretty common word (code bases, documents, and reports all can have revisions) and has the advantage of having no alternate meanings.

• Ideally, however, the list of revisions would be integrated with the Save button, which would be a combobutton (i.e. a combination of a button and a dropdown menu) such that pressing the button part would save a new revision and display the number of the new revision, while pressing the dropmarker would display a list of revisions along with the date/time when they were made and the version number (for revisions that were marked with a version), i.e. something like:
  • zalun: This is a bit confusing (maybe just for me as English is my second/third language) as "save" is a verb and a noun. It looks weird that a submenu has different type of action - "save" vs "load", but it may be just me.

Before pressing save:

+-------------+
| Save | 122 v|
+-------------+

After pressing Save:

+-------------+
| Save | 123 v|
+-------------+

Upon pressing dropmarker:

+-------------+
| Save | 123 v|
+--------------------+
| 123 - [Date]       |
| 122 - [Date]       |
| 121 - [Date] - 0.1 |
| 120 - [Date]       |
| ...                |
+--------------------+

Upon selecting older revision:

+-------------+
| Save | 121 v|
+-------------+

• The revison number shouldn't be displayed with the package info at the top of the sidebar, as it is already being displayed in the revision selector dropdown menu at the bottom of the sidebar, and it is not like the other information about the package that becomes part of the XPI bundle and is shown to users who download and install the extension.
  • zalun: That may be confusing as If I'd set a version and modify addon it will become a revision of that version. For the author it is an important information that it's a revision which is "non versioned" or "under construction".

• The mockup doesn't show the buttons on the toolbar, but the buttons I would expect based on the functionality we've been describing so far are: [Save], [Test], and [Download], with perhaps also [Mark as Version] between [Test] and [Download].

• The buttons should all have tooltips that describe their function and what to do once you invoke them (f.e. the Download tooltip should explain that it will package your add-on and download it to your computer, after which you can submit it to AMO).

Other changes

Whole System (needs changes on the backend as well)

1. Add rating
   • Myk: no ratings! Not now, anyway. Maybe later.