Labs/Jetpack/FlightDeck/1.0a2/UXChanges: Difference between revisions

From MozillaWiki
< Labs‎ | Jetpack‎ | FlightDeck‎ | 1.0a2
Jump to navigation Jump to search
Line 61: Line 61:
* Sidebar contains Attachments Section
* 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
* 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".
* 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:
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.
* 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 =
= Other changes =
=== Whole System (needs changes on the backend as well) ===
=== Whole System (needs changes on the backend as well) ===
# Add rating
# Add rating

Revision as of 08:18, 24 May 2010

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

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

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
    3. Add author overall rating
    4. Remove versions
    5. Myk: also, remove "Try in browser" from this 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 other users' addons is to encourage developers to learn from each others' code

FlightDeck Plugin

  1. "Install Flightdeck" above Categories
  2. Myk: actually, we should remove Categories and the Install FlightDeck link 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).
  3. Make a FlighDeck Plugin warning show when needed - not all the time
  4. Change the wording in confirmation after installed plugin
  5. Myk: I suggest we implement the following behavior:
    • when a user visits the home page, FlightDeck doesn't prompt her to install the Helper addon;
    • when the user presses the Build Add-on button to create a new addon or the Edit or View Source buttons for an existing addon, FlightDeck still doesn't prompt her to install the Helper addon;
    • when the user presses the Try in Browser button for an addon from the Edit or View Source pages, and she doesn't have the Helper addon installed, FlightDeck prompts her to install the Helper addon; once she installs 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?

Login 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.

After build system changes

Editor

Jetpack-editor-wireframe.png
  • 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".
  • 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:
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.
  • 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