Discussion - Week of 07/14/14

[ezoehunt]

Here is where we can discuss things for this week.

[ezoehunt]

From David Bialer:

I am having a problem that the Mission statement doesn't really have a goal of what we are trying to achieve.

I think the Goal of this project, for Marketplace, is to help increase the number of app submission by making the process easy and the experience positive.

Our key indicators and success factors for Marketplace are: a) # of submissions b) # of the top 100 submissions.

The theory behind making submission a positive experience is that it will help increase submissions and attract key apps, and thereby influence our success as defined by the team KPIs.

[ezoehunt]

David -

We've stated clear goals for this project on the Goals & Metrics page. Did you see those here: http://tsmuse.github.io/FirefoxMarketplaceDevPagesDesign/home_2.html ?

I think we are saying the same thing. If I'm understanding you correctly, the difference is that you would prefer that this project's goals are the KPIs. That's not how design works however.

Design solves a problem. For this experience, the problem we are solving is a tedious and error-prone submission process. The problem is not "we have low submissions." The problem is that the developer's experience of submitting an app leads to errors and abandonment, which leads to low # of submissions.

If we don't state the problem like that, we will only achieve incremental changes that will never solve the real problem.

We believe that by creating a more positive app submission process, we will reduce errors and increase developer loyalty/engagement. The Goals & Metrics page gets more specific about how we'll achieve our mission. The KPIs (metrics) then explain how we'll measure our success. This is the tried-and-true methodology for solving a problem through design.

[dbialer]

Thanks. Didn't see this. Yes we are on the same page.

----- Original Message -----

David -

We've stated clear goals for this project on the Goals & Metrics page. Did you see those here: http://tsmuse.github.io/FirefoxMarketplaceDevPagesDesign/home_2.html ?

I think we are saying the same thing. If I'm understanding you correctly, the difference is that you would prefer that this project's goals are the KPIs. That's not how design works however.

Design solves a problem. For this experience, the problem we are solving is a tedious and error-prone submission process. The problem is not "we have low submissions." The problem is that the developer's experience of submitting an app leads to errors and abandonment, which leads to low # of submissions.

If we don't state the problem like that, we will only achieve incremental changes that will never solve the real problem.

We believe that by creating a more positive app submission process, we will reduce errors and increase developer loyalty/engagement. The Goals & Metrics page gets more specific about how we'll achieve our mission. The KPIs (metrics) then explain how we'll measure our success. This is the tried-and-true methodology for solving a problem through design.

— Reply to this email directly or view it on GitHub .

[dbialer]

While I think it is great to explore new submission options, our current submit page has confusion problems in the UI.

I would like to see our current app submission fixed. I believe we still need to maintain and improve the identified problems.

Specifically in the 3-D choice between Free/Paid&In-app, platform selector, form factor selector. The Usertesting.com report completed last October in 2013 clearly illustrated the problem - where developers typically make incorrect choices and spend 5 - 10 minutes (sometimes) trying to figure this out.

Can we please fix the current self-service submission flow in the short term.

Specifically, remove the Tab-based UI for the mutual exclusivity between Free/Paid, and remove the In-App and Paid from the same choice as in-App may be with BOTH free and Paid apps. So, for instance, the app may be Free OR Paid. Then the app may include or not include In-app payments.

Also the packaged/hosted interface is confusing with the tab interface.

My understanding of best practices for tab interfaces is to use them to divide content into meaningful sections rather than as a mutually exclusive selector (which is more like a radio button type of selector).

So I think the selection process should be: a) select a form factors (multiple select) b) based on above, select platforms (fxos, android, desktop) - multiple select c) select packaged or hosted (mutually exclusive selector)

I think this is more straightforward and could save the developer from making incorrect choices.

Thanks, David

[ezoehunt]

David, Thanks for reminding us of the short-term needs.

If I'm remembering correctly, at our last meeting, we decided to file bugs for the short-term fixes. So if you could do that, we'll have these items on our radar.

[dbialer]

Added you to Bug 1032516 There were actually several more rough spots identified not addressed in this bug. I don't believe that having a remote repository nor drop off services completely addresses all of them either.

These are:

1. Submission Preparation - We do not have an app submission checklist prior to starting the submission process, and therefore no way of knowing how to prepare the right material to submit.
2. Submit Page (Bug 1032516 ) - The app manifest submission page we have today is confusing as it is. We have a high page exit rate at about 94%. We don't know why - but videos that Tony did of the submission process lead me to believe it is confusing. Improving this may not increase submissions, but it will probably add to the delight of developers. The usertesting.com videos completed in October 2013 clearly demonstrate some of the confusion points (I identified in the bug above).
3. Screenshots - are complicated and any assistance for the different form factors would be useful. Improving screenshots would also be a big help to end users as well so they don't see poor and tiny screenshots.
4. Privacy Policy - many developers are not prepared with a privacy policy when they submit. Hence we get a lot of very low quality privacy policies which are of no value to end users. Given Mozilla's focus on privacy, we really should improve this by pointing to privacy policy generators/tools/information.
5. Payment improvements a) Multiple payment providers - we need to take into account Boku and serverless in-app payments (which isn't in the scope of this submission process as Liz was working on this). Very complex but very pressing. b) As pointed to in the bug, In-app payments should be separated from Paid apps as in-app payments may occur with both free and paid apps.
6. High Manifest error rate - Though possibly not in this scope, building an app manifest is hard for many developers. 80% of hosted app submissions return with at least 1 error in the manifest. I think the same is true for packaged apps. It is tedious to correct the error, rezip a file, and resubmit it. This issue merits further investigation as to how we can help developers create error-free manifests.

I had though that the DevHub improvements project was addressing these issues, but I can file bugs for each one and prioritize these

----- Original Message -----

David, Thanks for reminding us of the short-term needs.

If I'm remembering correctly, at our last meeting, we decided to file bugs for the short-term fixes. So if you could do that, we'll have these items on our radar.

— Reply to this email directly or view it on GitHub .

[ezoehunt]

David,

Please be assured that the work on the Devhub project includes all of the issues you've outlined above. Both remote repo and dropoff will include:

1. Checklist
2. Education about screenshots
3. Education about privacy policy
4. Education and features that help developers create valid Manifests
5. Improved help around payments is part of the mix as well