Closed Bug 582001 Opened 15 years ago Closed 15 years ago

Designs for new Developer Tools

Categories

(addons.mozilla.org Graveyard :: Developer Pages, defect, P3)

Product:
addons.mozilla.org Graveyard
Component:
Developer Pages
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fligtar, Assigned: chowse)

References

(
URL
)

Details

Spec: http://docs.google.com/Doc?docid=0Acwo2Bn17-PrZGZudHRobnJfNzhmNTh6dGtmeg&hl=en Designs: http://people.mozilla.com/~chowse/drop/amo/devtools/v1/ From chowse: "The only thing that's missing is the page for contributions and dev profiles and eventually marketplace stuff (labeled 'Manage Payments'), but this shouldn't involve much work. A few parts I need a little input on (esp. stuff involving status and version) and I could use some help with copy here and there, but hopefully this should be enough to move on."
This looks really nice chowse. Just a couple notes right now: * No localization messages * No required vs. optional markings
Thanks, chowse. Some initial feedback and a few copy tweaks are below. Dashboard --------- * I like sorting options, though I'd rather simplify them a bit for this view. I don't think we need Rating and default should be Name. I think other sorts that would be useful are Date Created and Status, but I don't really want to add more things to that row. Maybe we should consider bringing back the sort dropdown since sorting isn't a big part of this page? * Max icon size is now 64x64 per the meeting and follow-up thread. We can kill the 128s. * When I mentioned the idea of the icon hover change link, that was mainly to get people to upload a larger version if they only have a 32. I don't think people change icons enough to warrant the link on every hover. Perhaps we can have it only for people that don't have a 64 icon or have the default icon. * We should have a different icon for Compatibility. And I'll look into the licensing of your current set. * Do we really need help text on Edit Listing and New Version? I like consistency but I think it could be annoying to have a tooltip on every link unnecessarily. * Copy changes: ** Compatibility help text: View and update application compatibility ranges ** Statistics help text: Daily statistics on downloads and users ** Update Compatibility overlay text: "Adjusting application information here will allow users to install your add-on even if the install manifest in the package indicates that the add-on is incompatible. [Learn more about supported applications]" Manage Add-on pages -------------------- * I like the sidebar and localization (though the sidebar is inconsistent between mocks) * I like the edit details pages, though I am suspicious of the help bubbles. I'm wiling to give them a shot and see if they bother me too much. * For custom icon uploads, the text should be "PNG and JPG supported and will be resized to 64x64 pixels if larger" to make it clearer that we'll resize if it's too large. * What does the Details link do in screenshots and videos? * There's no character limit on Descriptions. Also we should indicate which fields allow HTML somehow and what tags are supported. * Add-on flags -- see spec for some changes that should be there * I'm not sure how I feel about combining authors and licensing on the same page -- they don't really go together. * License versions should be shown and can't really be combined into a single entry unfortunately. * EULAs and Privacy Policies don't have character limits, and Privacy Policies should have the option to enter a URL instead (see spec) * On Add a New Version page, we shouldn't show compatibility info until after a file is uploaded since that's what we read the compatibility info from. Submission ---------- * An 8 step process looks pretty intimidating. * I'm okay with reducing the link to additional policies, but let's call it "Additional Add-on Policies" instead of "Other" * How do users with platform-specific files handle uploading multiple files and specifying which platforms the file is compatible with? (also, see the spec/my mock for mobile details) * I think the review process selection buttons should be in the white boxes that they go with. ================ A few things that were missing: * Disabling an add-on / marking an add-on inactive * Deleting an add-on
Dashboard -------------- - I think it's confusing to have the compatibility icon be the same as statistics - I agree with everything Fligtar said except for adding sorts. I think if people want them they'll let us know. Manage add-on pages ----------------------------- - Right now we have locale tabs directly on textareas, but your mockups make that a per-page option. Are we abandoning the per-textarea widgets or will the dev tools depart from that UI? - The help bubbles bug me. Help should only be around when you need it, not for stuff like "Name" (Ha, I just got to the edit categories section - omg, help bubbles) - Are we no longer allowing people custom text licenses? If not, we should tell the people who have them now they'll need to find hosting for their license. - on Addon_04, is "Action to Take" a link? If so, what does it do? Submission --------------- - I agree 8 steps is a lot to take in. We cut them down on the current version on purpose: do the bare minimum, and then provide links to further customize later on. Overall, I think fligtar's feedback was really good.
When I signed up for djangocon, there was a list of 4 things I had to do (register, add profile, ..., submit talk). The next action was the only link, and once I finished something it got a line through it. I like how they had all the steps lined up. Since only fligtar might understand the whole add-on process, something like that would probably help (along with simplification).
Thanks for the feedback, everyone. Responses inline: (In reply to comment #2) > Dashboard > --------- > * I like sorting options, though I'd rather simplify them a bit for this view. > I don't think we need Rating and default should be Name. I think other sorts > that would be useful are Date Created and Status, but I don't really want to > add more things to that row. Maybe we should consider bringing back the sort > dropdown since sorting isn't a big part of this page? Will users be visiting this page frequently to check up on their add-on's popularity? If so, having a way to sort out which of your add-ons are most active or highly rated. I would be alright w/ a drop-down, though. > * When I mentioned the idea of the icon hover change link, that was mainly to > get people to upload a larger version if they only have a 32. I don't think > people change icons enough to warrant the link on every hover. Perhaps we can > have it only for people that don't have a 64 icon or have the default icon. Just to be clear, the 'change icon' link only appears when hovering over the icon, not the add-on. I don't think clutter will be an issue here. If you want to make it more visible (say, appearing on add-on mouseover) for the circumstances you mentioned, I'm okay with that. > * We should have a different icon for Compatibility. And I'll look into the > licensing of your current set. Yep, forgot to go back and change that. I couldn't find a good icon in my icon set, so I'll probably need to create my own. Any recommondations for how to represent 'compatibility'? > * Do we really need help text on Edit Listing and New Version? I like > consistency but I think it could be annoying to have a tooltip on every link > unnecessarily. It'd be annoying if it showed up frequently as the mouse moved over the page. If that's the case, I'm fine removing some of the tooltips. > * I like the sidebar and localization (though the sidebar is inconsistent > between mocks) Just FYI: if the heading/sidebar elements are faded, please don't consider it definitive. The common heading/sidebar elements are defined in http://people.mozilla.com/~chowse/drop/amo/devtools/v1/Addon_01_Common.png. > * I like the edit details pages, though I am suspicious of the help bubbles. > I'm wiling to give them a shot and see if they bother me too much. The help bubbles will be a bit less distracting once I prepare the final assets. > * What does the Details link do in screenshots and videos? It will show a pop-up with details like filename, file size, dimesnions, and format. I will include an example in the next iteration. > * I'm not sure how I feel about combining authors and licensing on the same > page -- they don't really go together. But neither are large enough to be separate. Both pertain to ownership and usage rights, so they didn't strike as strange bedfellows. The alternative would be to place them both back on the 'Edit Details' page. > * License versions should be shown and can't really be combined into a single > entry unfortunately. I need some clarification. If this version of a license (e.g. GPL2 vs. GPL3), or licenses on each version of an add-on? > * On Add a New Version page, we shouldn't show compatibility info until after a > file is uploaded since that's what we read the compatibility info from. (In reply to comment #3) > Manage add-on pages > ----------------------------- > - Right now we have locale tabs directly on textareas, but your mockups make > that a per-page option. Are we abandoning the per-textarea widgets or will the > dev tools depart from that UI? I'd really like to start moving away from per-field editors. The UI for it is incredibly awkward, and it doesn't follow the way localization is done (many fields for one language, not one field for several languages). If we continue to use the widgets, please at least consider the new design which hides l10n options until they're required: http://people.mozilla.com/~chowse/drop/amo/translation/ I haven't had time to completely doucment/mock up how whole-page l10n works, but here's the gist: 1. The user uses the drop-down in the top-right to switch to a different locale. 2. For fields that haven't been translated, we fall back to the English version, but add a different styling (typically, gray and italicized). This applies to static and editable fields. 3. For editable fields w/o a translation, we leave the English version in by default. This gives them the opportunity to copy the English version (or just start entering their translation before or after). If the user makes any changes to the field, we remove the 'untranslated' styling. 4. When a field loses focus, check to see if it is empty or is identical to the original English version. If it is, reapply the 'untranslated' styling and add back the English translation. 5. When submitting a form, perform the same check as 4. If the field is blank or identical to its English version, then treat the field as untranslated. > - The help bubbles bug me. Help should only be around when you need it, not > for stuff like "Name" (Ha, I just got to the edit categories section - omg, > help bubbles) I'm fine with removing them on the obvious stuff. For everything else, I will make the suggested changes and update the mock-ups.
(In reply to comment #6) > Updated mock-ups now posted: > http://people.mozilla.com/~chowse/drop/amo/devtools/v2/ Fligtar just pointed out that the Payments page was a duplicate. The real Payments page (with a few updates) is now posted: http://people.mozilla.com/~chowse/drop/amo/devtools/v2/Addon_04_Payments.png
Thanks chowse, these look good. Can you put the masters somewhere? I'll tweak the copy and add annotations.
This is fixed. We'll track anything else in separate bugs. Thanks chowse!
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.