778882 - Device compatibility and Payment vendors

Status: RESOLVED FIXED

(Marketplace Graveyard :: Developer Pages, defect)

Description

[krupa raj[:krupa]]

During app submission, we ask the developer to specify what devices they plan to support (Desktop, Mobile and Tablet).

a) We need to add FireOS to this list.

b) Based on the device selection we need to decide what Payment vendors we ask the developer to sign up to (b2g only supports bluevia and fennec/desktop need PayPal)

Since we plan to add more Payment vendors in the future, we need to think of this flow carefully.

Comment 1

[krupa raj[:krupa]]

(In reply to krupa raj 82[:krupa] from comment #0)

> a) We need to add FireOS to this list.
> 
s/FireOS/Firefox OS

Comment 2

[Andy McKay]

Yep. I think this area needs a re-think. BTW, I was under the impression that we were removing payments from app submission and just leaving it in the developer hub.

Comment 3

[krupa raj[:krupa]]

Adding maria for UX input

Comment 4

[krupa raj[:krupa]]

Attachment: screenshot

Comment 5

[Maria Sandberg [:mushi]]

adding Bram - can you take a look at this? The drawing above was very quick and you have full freedom in using/changing/discarding.

Comment 6

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #2)
> Yep. I think this area needs a re-think. BTW, I was under the impression
> that we were removing payments from app submission and just leaving it in
> the developer hub.

I would like to know whether payment is:

* Something that you get to select when in the app submission flow. That is, after you submitted your app manifest, and in the Edit Details page? Today, we put device compatibility in this page. So maybe it makes sense to put payment vendors on the step after Edit Details?

* Or, is it something you see on the developer hub, after you are done submitting your app? (comment 2) So, you would submit your app and select device compatibility, and then hit “Submit”. And then, while your app is awaiting review, you can choose a payment vendors. I guess this will break the flow, and might cause developers to forget.

* Or, if the placement of device compatibility and payment vendors in the flow is up to us?

Comment 7

[Christopher Van Wiemeersch [:cvan]]

(In reply to Bram Pitoyo [:bram] from comment #6)
> (In reply to Andy McKay [:andym] from comment #2)
> > Yep. I think this area needs a re-think. BTW, I was under the impression
> > that we were removing payments from app submission and just leaving it in
> > the developer hub.
> 
> I would like to know whether payment is:
> 
> * Something that you get to select when in the app submission flow. That is,
> after you submitted your app manifest, and in the Edit Details page? Today,
> we put device compatibility in this page. So maybe it makes sense to put
> payment vendors on the step after Edit Details?

That's what we used to do (up until a few weeks ago when we disabled payments). After the "Details" step there was a "Payments" step.

> * Or, is it something you see on the developer hub, after you are done
> submitting your app? (comment 2) So, you would submit your app and select
> device compatibility, and then hit “Submit”. And then, while your app is
> awaiting review, you can choose a payment vendors. I guess this will break
> the flow, and might cause developers to forget.

Right now (on our staging/-dev site) this is what it looks like after the "Details" step: http://cl.ly/image/0q3y1H2N3j47

This bug is to either add the Payments/Device Compatibility info to the "Details" step - or make it its own separate "Compatibility/Payments" step.

> * Or, if the placement of device compatibility and payment vendors in the
> flow is up to us?

Correct.

Comment 9

[Bram Pitoyo [:bram]]

Attachment: no product selected

This mockup foregoes the checkboxes and radio buttons in favor of using normal buttons that will change into drop-down menus whenever price tier selection is needed.

Our situation today is such that only Firefox OS apps can be premium. But when we decide to support payment on a new platform one day, this interface won’t need to be revamped again. We’d just need to add buttons appropriately.

Comment 10

[Christopher Van Wiemeersch [:cvan]]

(In reply to Bram Pitoyo [:bram] from comment #9)
> Created attachment 667828 [details]
> no product selected
> 
> This mockup foregoes the checkboxes and radio buttons in favor of using
> normal buttons that will change into drop-down menus whenever price tier
> selection is needed.

This looks very nice!

What happens when if I want my app to be free and it works fine across Firefox Desktop, Firefox Mobile, and Firefox OS? How does that look?

And I assume if you click Firefox OS > "Premium" then all the other Desktop/Android Phone/Android Tablet options become disabled?

Comment 11

[Bram Pitoyo [:bram]]

Attachment: firefox OS selected - free

When the "Free" button is clicked, three things happen:
* The "Free" button is marked active
* All other buttons in the column is marked inactive
* The "Continue" button is enabled

If user changes his mind, he can simply click on any if the three inactive buttons in the column.

Comment 12

[Christopher Van Wiemeersch [:cvan]]

Ha, you answered both of my questions completely. Awesome, I'll get to implementing. Looks great.

Comment 13

[Bram Pitoyo [:bram]]

Attachment: firefox OS selected - premium

When the "Premium" or "Premium with In-App Payment" button is clicked, two things happen:
* That button disappear to reveal a drop-down menu of price tiers
* All other buttons in the column is marked inactive

If user wants to change his selection, he can either:
* Click on any of the three inactive buttons in the column
* Click the red ‘x’ arrow to the right of the drop-down menu

Comment 14

[Bram Pitoyo [:bram]]

Attachment: firefox OS selected - premium - 99c

After user selects a price from the drop-down menu, two things happen:
* The "Continue" button becomes active
* A caption saying "Next: select a payment processor" appears to the left of the "Continue" button

If user wants to promote an app by making it available for free temporarily, the drop-down menu will have an option that says “Free”. User can change this value to a price point after his promotion is over.

Comment 15

[Bram Pitoyo [:bram]]

Attachment: 4 platforms selected

This mockup shows how scalable this interface can be. When we want to add more app types, we can simply add the appropriate buttons under each platform.

Comment 16

[Bram Pitoyo [:bram]]

It would be great if we have an FAQ section on the bottom of this page (for an example of an FAQ, see attachment 661161 [details]) that addresses the questions below — just in case the developers decided to try out the process without reading the documentation first:

Topic: payment processors
* How many payment processors do we have? Who are they?
* When will I enter my payment data? (We’ve put this information on the caption, but it’s helpful to reiterate)
* What’s our plan for payment on the Desktop and Android platforms?

Topic: switching between free and premium
* Can I do it?
* What will happen when I do it (when I switched but the app’s status is still under review)?
* What’s the best practice? (Answer: for the best UX, a developer should stick to the choice he’s made

Comment 17

[Bram Pitoyo [:bram]]

Attachment: Explanation of device compatibility and payment method UI

Last Friday, cvan and I talked about where device compatibility and payment options belong in the app submission flow.

We agreed that the logical flow goes something like:
1. Which platform am I building for?
2. How do I make a manifest?
3. Supply the description and screenshots for my app
4. Supply payment info

The solution I proposed last time combined platform selection and payment options in one interface. It doesn’t make a lot of sense, because user don’t think about the two steps right after each other.



I decided to split platform selection and payment options. So the new flow goes something like:

1. User clicks “Agree” on the developers agreement

2. The platform selection screen appears. This screen will display payment options for each platform, but user cannot select any method yet. User clicks on any number of platform.

3. User uploads manifest

4. User fills in app details


5. The payment options screen appears. This screen will only display the platforms the user had selected in step 2. If I only select Firefox OS, then only Firefox OS will appear here.

Every platform will appear with a set of clickable buttons that correspond to payment options.

When user clicks on “Premium” or “Premium + in-app payment”, the button turns into a drop-down menu with price tiers.

Along with price tiers, the drop-down menu will also have an option called “Free/promotion”, this option is designed to address the situation where developers want to temporarily give away an app for free.


6. If user selects an option that require the set up of payment vendor, the next screen is NOT the “done” screen. It will be the payment vendor setup page.



Also note how in the mockup, I’ve shortened the wording of the steps, but made the steps longer to correspond with the above changes.

The new wording of the steps I’m proposing are:
1. Agreement
2. Devices/Platforms (pick one)
3. Hosting (rather than saying “Type”, which is a general-purpose word)
4. Details
5. Payment/Payment Type (pick one)
6. DONE

Comment 18

[Maria Sandberg [:mushi]]

One question - do we currently support tablets? I'm uncertain if we should offer this as an uploading option right now. Looking good!

Comment 19

[Christopher Van Wiemeersch [:cvan]]

(In reply to Maria Sandberg [:mushi] from comment #18)
> One question - do we currently support tablets? I'm uncertain if we should
> offer this as an uploading option right now. Looking good!

We do currently. "Tablet" meaning "Firefox for Android Tablets" yeah.

Comment 20

[Wil Clouser [:clouserw]]

-> andym because he has the other bugs (and I think I've already seen this partially implemented?)

This bug is still marked uiwanted - is that out of date or are we still waiting on something, Bram?

Comment 21

[Bram Pitoyo [:bram]]

(In reply to Wil Clouser [:clouserw] from comment #20)
> This bug is still marked uiwanted - is that out of date or are we still
> waiting on something, Bram?

uiwanted is outdated because I’ve worked with cvan a bunch and came up with a one-page solution to handling this.

Comment 22

[Wil Clouser [:clouserw]]

From cvan:

> 	WIP patch: https://github.com/cvan/zamboni/commit/c46ab50 

> new submission flow that includes Firefox OS, Firefox for Android Phone, 
> Firefox for Android Tablet, and Desktop
> nearly done - just need to make sure that the input[name=platforms] are 
> included in the correct <form>s when they are posted
> make sure that checkboxes for background-position of packaged-app validation 
> output looks okay
> make sure that the current flow (before the fancy-submit waffle) still 
> works *remember to bump the migrations!*

> related to https://bugzilla.mozilla.org/show_bug.cgi?id=776662 which is 
> essentially done (and leads into 794695 below)

Comment 23

[Bram Pitoyo [:bram]]

Attachment: Explanation of device compatibility and payment method UI

This is an updated mockup that cvan and I had worked on.

This mockup integrates device selection, payment type and upload in one page, which will hopefully make the process simple, as user will be able to revert and change decisions on the fly, and see what the ramifications are.

Some explanations:

* The first level of selection is either Free or Paid. Free apps can be made for all devices. Paid apps can only be made for Firefox OS. And you cannot have both free and paid coexisting simultaneously. Hence, the tab separation.

* The second level of selection is device. User selects device by clicking anywhere inside the box. Since user can select any number of product, we use the checkbox model here.

* The third level of selection is between hosted and packaged. User will only get to choose between hosted or packaged if he’s building for Firefox OS. The tab will appear if Firefox OS is the *only* product selected. If user selects multiple products, or other products other than Firefox OS, the tab will disappear and we will only show him the option to host.

* Finally, the user either uploads his manifest or submit the manifest URL, click validate, and click “Continue” to proceed to next step.

Comment 24

[Andy McKay]

Are there individual pictures for each of those choices?

Comment 25

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #24)
> Are there individual pictures for each of those choices?

Not really. I created the mockup using Firebug, so I have to recreate the whole thing from scratch.

Thankfully the series of mockup should visualize all the possible states.

To wit:

* When the page initially loads, the “Free” tab is selected by default

* The “Free” tab has multiple items under it, so no item is selected initially. When there’s no item selected, checkbox is unchecked, and the item box’s background color is white

* When user clicks on “Firefox OS” under “Free”, a tab with “Hosted” and “Packaged” appear. “Hosted” is selected by default

* When user clicks on other products under “Free”, the content of the “Hosted” tab appears, but the tab title itself won’t appear

* When user clicks on multiple items that includes Firefox OS, the same thing happen: the content of the “Hosted” tab appears without the tab title

* Let’s go back up top and say that user clicks on the “Paid” tab

* The “Paid” tab only has one item under it. When we only have one item under a tab, it is automatically selected. Selected items have their checkboxes checked, and a yellow highlight color  The one item under “Paid” is “Firefox OS”, and Firefox OS can have either “Hosted” or “Packaged” as an option

* So, upon clicking the “Paid” tab, “Firefox OS” is automatically selected, and the “Hosted” and “Packaged” tabs are immediately shown below the device selection

I hope this helps explain it. I can go over it with you on vidyo, too, should you need some explanation.

Comment 26

[Andy McKay]

That's all clear to, no need for vidyo chat, thanks!

Comment 27

[Andy McKay]

It's interesting you've got a distinction between Firefox OS and Mobile. We don't have that currently in the marketplace we just distinguish tablet, mobile and desktop. Do we need to distinguish the two?

Comment 28

[Bram Pitoyo [:bram]]

If I recall correctly, Firefox OS is distinguished by:
* Capability to have paid apps
* Capability to upload packaged apps

While the Android tablet and Android smartphone platforms don’t have this—or, at least, don’t have it yet.

Furthermore, in my experience with SUMO, we found that users understood product/OS name more than device type.

We were debating whether to describe Firefox as “web browser for desktop and laptop computers” or “web browser for Windows, Mac and Linux”. After research, we found that hybrid devices that looks mobile but are really full-blown computers like Tablet PCs and Surface, and phones that are kind of tablets like Galaxy Note, makes separating by devices confusing for users.

But calling out platforms made this problem disappear. “Windows” usually means only one thing, but “mobile”, “tablet” or “computer” can mean multiple things. So I decided to distinguish things by platform here, too, for more clarity.

Comment 29

[Andy McKay]

Sure, we use the device to filter things like searches. Other pages like the edit page list the device types of mobile, desktop, tablet. Should we be filing bugs to filter these by mobile, desktop, tablet and firefox os or not?

Comment 30

[Andy McKay]

"The “Paid” tab only has one item under it. When we only have one item under a tab, it is automatically selected."

That seems bad. 

I can't see what's in Paid because the tab is hidden, but clicking the tab to see what choices there are, doesn't automatically mean I want it.

Comment 31

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #29)
> Sure, we use the device to filter things like searches. Other pages like the
> edit page list the device types of mobile, desktop, tablet. Should we be
> filing bugs to filter these by mobile, desktop, tablet and firefox os or not?

Andy and I had a chat about this on IRC earlier today. The short answer is: “Yes. We will need to filter by Android phone, Android tablet, Firefox OS, and desktop, to make it as clear as possible for developers. But doing this might have user-side implications in the way that apps are listed and organized.”


(In reply to Andy McKay [:andym] from comment #30)
> I can't see what's in Paid because the tab is hidden, but clicking the tab
> to see what choices there are, doesn't automatically mean I want it.

That’s a good point.

Auto-select pros:
* It takes the user one less click to get to the item he wants

Auto-select cons:
* This behavior doesn’t work consistently across all tabs
* We will have more than one device under the “Paid” tab sooner or later, which obsoletes this behavior

So I think I am okay with the auto-select not getting implemented. I’d much rather spend time optimizing for more significant stuff on this flow.

Comment 32

[Andy McKay]

> Not really. I created the mockup using Firebug, so I have to recreate the whole 
> thing from scratch.

So what assets did you use for mocking up in Firebug? I'm not sure where to find these assets with the right size and transparency.

Comment 33

[Andy McKay]

In a branch awaiting some tabs from Davor and some assets from Bram. Waiting in branch:

https://github.com/andymckay/zamboni/commit/4cd776

Comment 34

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #32)
> So what assets did you use for mocking up in Firebug? I'm not sure where to
> find these assets with the right size and transparency.

I gave the assets to cvan before he went off to PTO, but should’ve posted it here.

I was not able to find any illustration of Firefox for Android tablet, so I created one using official assets. Then I adapted the same iconography for the Firefox for Android phone, so it matches.

The Firefox OS illustration is the one that we used on our product page.

Firefox OS
http://www.mozilla.org/media/img/firefoxos/firefox-phone.png

Firefox for Android phone
http://people.mozilla.com/~bpitoyo/marketplace/firefox-android-phone.png

Firefox for Android tablet
http://people.mozilla.com/~bpitoyo/marketplace/firefox-android-tablet.png

Comment 35

[Andy McKay]

Images added. 

https://github.com/andymckay/zamboni/commit/241cb3

Comment 36

[Andy McKay]

https://github.com/mozilla/zamboni/commit/1e89fb