Idea: supplement app listing page with screenshots

[brampitoyo]

This issue will think of a flow where a contributor could upload screenshots and videos to the app listing page.

These screenshots and videos need to be functional, good looking, and taken from a Firefox OS device. We’ve noticed that many apps in the Marketplace lacks this.

[brampitoyo]

The basic idea:

• At some point during the app submission flow, developers consent that their app is able to accept new screenshots by contributor
• Contributors take screenshot using their Firefox OS phone or simulator and upload it directly on the app landing page
• From here on out, there are two ways to go about it:

1. Screenshot is not posted until approved explicitly by developer

Pro: no nasty surprise for developer Con: long turnaround time until user can see screenshot

2. Screenshot is posted automatically until developer chooses to remove it

Pro: screenshots of apps with inaccurate content can be surfaced, warning other users Cons: developers might feel a lack of control over how her/his app is presented

The problem with developer consent

1. Apps that benefit the most from having additional screenshots are more likely to have developers who wouldn’t necessarily consent to community contribution. If my app is low-quality/misleading/spammy (ie. a game guide, masquerading as a game), I don’t want its real screenshots to be listed
2. If the consent is only applied for app submissions going forward, what happens to apps that are submitted before this service is launched? Furthermore, if the app I submitted has low-quality screenshots, it might indicate that I don’t care enough about it to submit a good-quality screenshot, and I probably won’t care about consent.

[brampitoyo]

UI mockup, which is pretty straightforward because it only has three elements:

1. A button to add a screenshot
2. Interface to pick an image – handled by the respective OS
3. Some sort of a progress meter that shows up while uploading

The mockup below has one button that appears immediately below the screenshot gallery. Another button appears in the gallery itself as a blank image element with an added ‘+’ symbol.

The hardest part of this project consists in figuring out the consent model. Does developer need to consent to be able to accept community contribution? After uploading, do we automatically publish the new screenshot or do we want developer to approve it first?

[brampitoyo]

My preference is for pre-launch reminder, auto opt-in and instant upload.

What does this mean?

1. Prior to launch, we send an email out to developers that say “In x weeks, we’ll launch a service that enables our trusted contributors to ”We have enabled our trusted contributors to supplement your app details page with high-quality screenshots taken on a Firefox OS device. So if your app doesn’t already have one, please give it a set of good screenshots!”
2. At launch, we send an email that gives developer a way to opt out: ”We have just launched this service. [Click here] if you don’t want to accept community contribution on your app details page.”
3. Post-launch, every image that our contributor upload will be shown on the app details page immediately, but it will also be marked with “Contributed by [username]”. We do this in order to personally credit them and also to further accountability.

[brampitoyo]

Note from weekly meeting, 25 September 2014

This applies to both this idea and the translation service that @pwalm is working on at issue #16.

Let’s map out the customer journey for the service if it’s opt-in and if it’s opt-out. There are challenges associated with both approaches.

• If this service is opt-in, our challenge will be to get developers to know about this service and activate it
• If this service is opt-out, our challenge will be to communicate our change in such a way that no developer will be angry or disappointed when they start receiving community contribution (will they be angry or disappointed in the first place? We have to learn this)
• Compare the two approaches (each will have pros and cons, and we’ll have to be able to defend why we pick it).
• Then, do some paper mockups of what the developer-facing interface will look like, as well as how they will get notifications about the service.
• Finally, pick an approach to go with when we pitch, and be able to defend it.

[brampitoyo]

Below is the contribution permission model where developers will have to opt out of the service.

[brampitoyo]

Updated the opt-out customer journey map.

Pre-launching the program

Pre-launch notifications about the contribution program is delivered two ways. The message is the same: “We’re launching in a few weeks. Would you like to turn contribution off? If you do nothing, the default is on.”

There are two pre-launch starting points:

1. Email: sent to everybody
2. Web: shown to everybody who’s logged in to DevHub

Launching the program

Launch notifications is also delivered two ways. The message changes: “The program is launched, so we’re going to turn contribution on. Would you like to turn it off?”

There are similarly two launch starting points:

1. Email: sent only to developers who hadn’t logged into DevHub
2. Web: shown only to developers who hadn’t logged into DevHub

Moderating contributions

The moderation model may stay the same regardless of whether contribution is opt-in or opt-out.

In this diagram, I’ve presented a really simple moderation system that could work well for this service. Phil had a similar moderation system in place on issue #16.

Keep in mind that we’re here to talk about the opt-in vs. opt-out model, not the moderation system.

1. After a translation/screenshot is submitted by a contributor, it’s stored by the system
2. The system notifies developers that a contribution is ready
3. Developers can view contribution, then approve or decline it
   • If approved contribution is a screenshot, it’s appended to the existing screenshot gallery
   • If approved contribution is a translation, it overwrites any translation that’s currently up
   • If contribution is not approved, it doesn’t go up anywhere

So there are two end points. Either the contribution is approved, or declined.

[brampitoyo]

This is the opt-in customer journey map.

Launching the program

Launch notifications about the contribution program is delivered two ways. The message is the same: “You should turn on community contribution because of these benefits”.

You’ll see these messages in two places:

1. Email: sent to everybody, prompting you to log into DevHub
2. Web: shown to everybody who’s logged in to DevHub

If contribution is enabled, then great. We will enable the Add Translation and Add Screenshot links on the App Details page.

If contribution is unchanged (disabled), we will show an additional message that says “If you ever change your mind, go to the Contribution section to enable it with one click”.

Moderating contributions

It’s virtually the same as the opt-out model.

Observations

You’ll quickly observe that the opt-in model presented above is simpler to deploy. It’s simpler because the system doesn’t need to keep track of whether a user has logged in. It will simply show the message once regardless of whether you have responded to the email or took action between pre-launch and launch periods; and when dismissed, it’s gone forever.

However, by design, this model will mean less developers joining in.

Next up

Mockups:

• Opt-in and opt-out notifications and dialogues (ideally, it should take one click to turn off and on)
• Contribution moderation interface

[brampitoyo]

Mockups:

[brampitoyo]

As discussed in our meeting earlier today, I thought of an approval model that’s neither opt-in nor opt-out, but is simply launched as a feature that’s activated for everybody, but is completely optional.

1. Mozilla activates community contribution. This will do three things:
   • Enable translate and add screenshot links on App Details page
   • Notify all contributors who log in that they can now add translation and screenshot
   • Notify all developers who log in of a new feature called “Contribution”. The tone of the messaging emphasizes the newness of the feature.
2. When a contribution is received, developers get notified. The notification here can’t be as splashy as the “New feature” notification. Maybe it’s a bar that appears up top. Maybe it’s a ① that appears to the side of the Contributions tab. There are many ways we can do this.
3. The moderation process is identical to the previous maps

My task tomorrow:

1. Mock up different ways to do notification
2. Explore ways to display list of contributions, to approve, and to reject them
3. Start consolidating our maps and mockups so they’re ready by the end of the week

[brampitoyo]

Mockup: Two ways to notify developers that the contribution program is launched.

1. Non-modal tooltip
2. Modal dialog

[brampitoyo]

Mockup: Notification of new contributions that come in, plus interface to approve and reject them.

1. Using numbers to indicate new contributions
2. Using coloured dots to indicate new contributions
3. Using modal window
4. Using a header menu that’s accessible on-demand
5. Using a proper Contributor section in the DevHub interface
6. The Contributor section, divided by tabs to help differentiate Translations and Screenshots-based contributions

[brampitoyo]

Mockups for integrating contributors screenshot moderation into the existing Edit details interface.

Idea 1

Replace the Select an image to upload interface with Add screenshots from contributors.

To upload his own image, the user can either:

1. Drag-and-drop the image (illustrated below)
2. Click another button that says Add your own screenshots

Idea 2

Immediately below the Screenshots pile, show another pile called Contributions.

1. To add an image to the Screenshots pile, drag and drop it from the Contributions pile. This is the equivalent of performing an Approve action.
2. To delete any image, click x. If done on the contributions image, this is the equivalent of performing a Reject. Image is removed from the pile.
3. To reorder an image on the Screenshots pile, drag and drop it to the desired position. User cannot reorder the image under the Contributions pile.

Idea 3

Split off the Contributions pile into two sections: Pending and Approved.

• To add an image to the Approved section, user must go to the Pending section and check an image.
• After an image is moved to the Approved section, it can then be drag-and-dropped up to the Screenshots section.
• Reordering is done via drag-and-drop, similar to the last idea.

Idea 4

Show the My Screenshots and Contributed Screenshots piles side by side.

• To add a screenshot to the My tab, user goes to the Contribution tab and click Approve on one of the image. The image moves to My, and can be reordered as desired.
• To reject a contributed image, user goes to the Contribution tab and click Reject. This will remove the image from the tab.

[pwalm]

Here are some ideas on how the user contributed screenshots could look on the app details page.

• Tabbed UI: One for developer screens, one for user submitted.
• A segmented control.
• One continuous stream of images, with user submitted called out. Call out ideas:

[pwalm]

@brampitoyo I'm really digging the drag 'n drop simplicity of Idea 2. You've got your screens, the user screens, and you can make your own mix pretty easily. But maybe we change the label to something like "Published Screenshots" so the dev knows what's live (everything they've uploaded + some contributor shots).

[brampitoyo]

Awesome. As I looked at all four ideas again, Idea 2 seem to be the simplest in terms of mental models.

1. There’s no extra tab or non-standard modal window required
2. The way to approve and reject doesn’t require going to another interface. To approve, drag-and-drop. To reject, click the ‘x’ that’s always there
3. The UI could be ‘bolted on’ to the existing interface without very much alteration

Our development challenge here will be in making the drag-and-drop interface work, but that’s an implementation-level detail.

[brampitoyo]

I’m in favour of calling out contributors by using avatars. I think it’s an idea that we can extend to every other type of contributor. Avatars will show up on Top Contributor review, so it syncs up with that idea nicely, but it can also show up on the translated Description field.

[brampitoyo]

Here’s the customer journey flow for the simplified screenshot contribution program, seen only from the developer side.

In a hosted app, note that it may be possible to simply grab the image URL and input it straight away into the Marketplace Config file as a screenshot. So a way to copy the URL to clipboard must be provided.

In a packaged app, the image will need to be included the app’s folder before the whole package is resubmitted. Dragging-and-dropping the image to the desktop seems to be the easiest and most direct way to do this. Right-clicking and selecting Save Image As… is equally simple and familiar.

Here’s the paper mockup for a DevHub screenshot section UI that fulfills this workflow. The instructions provided here isn’t necessary because hopefully copy-pasting and Save As are both familiar actions – but it’s included here, just in case.

[brampitoyo]

I’ll start upstreaming all of our final paper sketches and customer journey maps to the repository, them write documentation for them, tomorrow. This will wrap up the project.

[brampitoyo]

I’ve put the new customer journey map and UI mockup up on the spec page, completing the scope of this bug.