915982 - Upload Screenshots to support the ability to Market apps

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: Developer Pages, enhancement, P5)

Description

[Karen Ward [:kward]]

The Content, Bus Dev, Apps Review and Marketing teams work with the Operators to provide additional assets that are used for collateral materials (to promote apps which promote FFOS phone sales).  The additional assets needed are:
1) Hero Screen shot
2) Screen shot featuring the App logo only.
Resolution must be 300dpi.  Format can be pdf, psd or ai.
Please add the requirement to upload this info to the app submission process.

Comment 1

[Christopher Van Wiemeersch [:cvan]]

Also, worth noting that we currently allow admins to upload a promotional graphic for any app:

http://f.cl.ly/items/1C3w1V1J1O250Q3y3W0B/Screen%20Shot%202013-09-13%20at%2010.44.51%20AM.png

We don't show the graphics in the UI anywhere yet though.

Comment 2

[Matt Basta [:basta]]

I think we also shouldn't make these a requirement, since most casual developers won't have these graphics made up (let alone at 300dpi or in a proprietary Adobe-created format or PDF). One more requirement for submission is one more developer lost because the submission process is too complex. Making them optional seems like it would be just fine.

We also have no way of validating the integrity or creating previews for non-image file formats (including PDF, PSD, and AI). That means that developers could potentially upload malicious or unpleasant files (especially in the case of PDF) in these fields and we'd be none the wiser. It's unlikely that we'll get this functionality, either, since there are few (if any) libraries for these formats (especially PSD/AI) and the ones that exist are largely incomplete, especially for the latest versions of Photoshop and Illustrator.

It should also be noted that the Developer Agreement [1] may need its wording tweaked to apply to screen captures as well, since these are not necessarily "brand features".

[1] https://marketplace.firefox.com/developers/docs/policies/agreement (see Licenses section)

Comment 3

[David Bialer [:dbialer]]

This should not be a required field.  It should be an attachment to a submission that doesn't require review.   We don't need to display it. Just a file.

I am not as worried about any security aspect of things like PDF files as this issue is prevalent anywhere on the Internet.  I think it is just a blob, no validity check, any person who downloads should still ensure the content is safe through whatever means they normally do.  big disclaimer for us.

I would think that screenshots are covered under 'other distinctive brand features".

The agreement currently give Mozilla & affiliates (usually meaning subsidiaries or associated companies) usage rights, not other partners.  So this would be good for our own promotions and marketing, but not for partners.  I rather not rewrite the dev agreement to include un-named partners.  I think the dev still needs to control their brand and usage rights with whoever wants to use their brand in whatever way the dev sees fit.  So basically, if a partner wants to use a developers stuff, they should ask the developer.

Comment 4

[David Bialer [:dbialer]]

KPI tracking - add universal tracking code to track submissions (click to uploads).

Comment 5

[Wil Clouser [:clouserw]]

This is still productwanted and uiwanted.  Marking p5/enh so it doesn't show up in our triage.

Comment 6

[Dan Horner]

(In reply to David Bialer [:dbialer] from comment #3) 
> The agreement currently give Mozilla & affiliates (usually meaning
> subsidiaries or associated companies) usage rights, not other partners.  So
> this would be good for our own promotions and marketing, but not for
> partners.  I rather not rewrite the dev agreement to include un-named
> partners.  I think the dev still needs to control their brand and usage
> rights with whoever wants to use their brand in whatever way the dev sees
> fit.  So basically, if a partner wants to use a developers stuff, they
> should ask the developer.

The opportunity here is for developers to get their apps featured in Marketing campaigns and in-store promotions by *Carriers* (hence the need for 300dpi). If they don't want to get all the extra promotion they would receive by allowing this, then they shouldn't opt-in / provide their branding assets.

This needs to be clear when they check the box.

The reason for doing this, is that it simply is not scalable for Mozilla to be asking every developer for permission each time a Carrier wants to use an app-screen -- there will be 100s of these requests otherwise. There will clearly be big name exceptions, which we'll have to secure on a case by case basis.

Comment 7

[Matt Basta [:basta]]

(In reply to Dan Horner from comment #6)
> The reason for doing this, is that it simply is not scalable for Mozilla to
> be asking every developer for permission each time a Carrier wants to use an
> app-screen -- there will be 100s of these requests otherwise. There will
> clearly be big name exceptions, which we'll have to secure on a case by case
> basis.

It's not impossible for us to send an automated message to each developer a few days after their submission saying something like, "Hey friend, thanks for submitting your app. If you'd like us to feature your app in promotional materials, <set of instructions for submitting stuff> and we'll take care of the rest"

Even if we provide a way for developers to provide these assets, we have no way to check that they're 300dpi (or if they're a reasonable size; you might get some 300dpi logos that are a microscopic 100x100 pixels!) so you'll probably end up sending lots of requests for re-upload anyway.

It also sounds like--if this is something that the carriers want for *their* promotional materials--that we'll need to build a portal for carriers to access this data. It seems like a really inefficient process for carriers to have to go through a human Mozillian to download some simple files. That, IMO, would be higher priority and probably easier to spec out.

Comment 8

[Dan Horner]

(In reply to Matt Basta [:basta] from comment #7)
> (In reply to Dan Horner from comment #6)
>
> It also sounds like--if this is something that the carriers want for *their*
> promotional materials--that we'll need to build a portal for carriers to
> access this data. It seems like a really inefficient process for carriers to
> have to go through a human Mozillian to download some simple files. That,
> IMO, would be higher priority and probably easier to spec out.

It's actually the other way round. We want to give apps on our Marketplace all the promotion they can get, one of the ways to do this, is to make Apps, branding, permissions etc, available on a plate to Carriers. This way, apps can get into all manner of promo opportunities; TV, in-store, posters etc.

Mid-Longer term, the intention would be to ask local Mozilla communities to select 10 apps every 1-2 months, that deserve promotion. We can suggest that Carriers use these (disclaimer: which they may choose to ignore), during our ongoing dialogue with their marketing teams.

This request is all about making it super easy for apps to get promotion, and not having to request things each and every time there's an opportunity.

Comment 9

[Karen Ward [:kward]]

Adding Thomas Elin to distribution.  Needs to be added to Marketplace scope requirements.  Mostly likely to be added to Sales Force Integration phase 3 as long as uploads do not exceed 5MB per file.  David - please update scope request to Thomas.

Comment 10

[[e-mail]]

Thanks Dan for adding to thread. Is there anything else needed from product marketing? To echo Dan's comment, the intent is to provide operators with few creative templates that can be used to promote markerplace, the feed, or a single app. Having the assets readily available will help scaling this program.

Comment 11

[David Bialer [:dbialer]]

This should go to David Almstrom.

Comment 12

[David Almström]

The idea for Thomas is just marketplace submission to be able to upload files into Salesforce (one way integration only).

If doing this locally, local BD/Mozillians can probably manage this directly via Salesforce which might be a better solution instead of cluttering the submission flow.

An alternative option would be, after reviewed and accepted, send out an email to a micro-site for uploading graphics, test-plans, etc. to salesforce.

Comment 13

[David Bialer [:dbialer]]

As noted in Comment 1, we support some promo graphics today that can be attached by an admin.  This could be enhanced.  It could even be exposed to devs, but rather not since out of context, either nobody will do it and it adds more tedious details for developers to enter.  Something that we try to simplify.

However, my impression is that you want a place for devs to upload and maintain graphics as well as be able to communicate with devs (if they have the wrong size, dpi, file format, etc.)

This should be part of the CMS system in Salesforce deployment Phase III.

Comment 14

[Potch [:potch]]

(In reply to David Bialer [:dbialer] from comment #13)

> This should be part of the CMS system in Salesforce deployment Phase III.

O.o

Comment 15

[David Bialer [:dbialer]]

(In reply to Potch [:potch] from comment #14)
> (In reply to David Bialer [:dbialer] from comment #13)
> 
> > This should be part of the CMS system in Salesforce deployment Phase III.
> 
> O.o

That is a BD project to enhance their partner management system.

Comment 16

[Dan Horner]

Is there a bug / wiki for that?

Comment 17

[Lisa Brewster [:adora]]

https://docs.google.com/a/mozilla.com/document/d/1Pz_Bekhtm4d3zAb20vqnS4R1X4twkDIDn22ek6iqHH4/edit