857733 - Fix devhub to allow free apps with in-app payments

Status: VERIFIED FIXED

(Marketplace Graveyard :: Payments/Refunds, defect, P2)

Description

[krupa raj[:krupa]]

The only valid reason to still have price tier 0 is for Free apps with in-app payments enabled.

So, let's list the price tier option if the in-app payments option checked. Here are some UI changes to make this less confusing-

* List the Price dropdown below the In-app payments checkbox.
* If the user has in-app payments selected and selects price tier 0, show Help tip on the side. Help tip can be something like "This tier will allow users to install your app for free but the app will have in-app payments enabled"

Comment 1

[Kumar McMillan [:kumar]]

In Bram's original wireframes (bug 794695) I thought this was much more clear. It said "free" in the dropdown and you could check the "in-app payments" box. Why don't we just call "tier 0" "free" like the mocks?

Comment 2

[Matt Basta [:basta]]

If the user has a free app and an app with third party in-app payments, they will be unable to mark their in-app payments app as an upsell of their free app.

Comment 3

[Andy McKay]

(In reply to krupa raj 82[:krupa] from comment #0)
> The only valid reason to still have price tier 0 is for Free apps with
> in-app payments enabled.

I still think having the ability to make an app temporarily free and still get receipts and so on installed for it is useful.

Comment 4

[Andy McKay]

(In reply to Kumar McMillan [:kumar] from comment #1)
> In Bram's original wireframes (bug 794695) I thought this was much more
> clear. It said "free" in the dropdown and you could check the "in-app
> payments" box. Why don't we just call "tier 0" "free" like the mocks?

If we have tier 0, I think we should differentiate it from free.

I would be happy to see tier 0 be removed given the confusion it causes.

Comment 5

[Bram Pitoyo [:bram]]

I think that it’d be smart to remove the “free” and “paid” tabs in the app manage interface, and just use price selector and the in-app checkbox to gauge whether the app is free, paid, in-app, or a combination of the two.

It makes the interface less confusing for developers, and as a bonus, we may not need the logic where clicking a checkbox would trigger a value to be shown on the dropdown menu.

Comment 6

[krupa raj[:krupa]]

(In reply to Bram Pitoyo [:bram] from comment #5)
> I think that it’d be smart to remove the “free” and “paid” tabs in the app
> manage interface, and just use price selector and the in-app checkbox to
> gauge whether the app is free, paid, in-app, or a combination of the two.
> 
> It makes the interface less confusing for developers, and as a bonus, we may
> not need the logic where clicking a checkbox would trigger a value to be
> shown on the dropdown menu.

I think the reason we decided on tabs is because device compatibility varies based on whether an app is free or paid.

Comment 7

[Bram Pitoyo [:bram]]

The unbucketing work that Tony is doing to the app submission flow will solve this problem. In the meantime, I don’t mind removing ‘tier 0’.

Comment 8

[Andy McKay]

Ok, this is taking a while. I think I'll need to rip the current code apart :(

Comment 9

[Andy McKay]

Filing sub bugs.

Comment 10

[Bram Pitoyo [:bram]]

Please let me know if you need UX help on any specific part of the interface. Specifically, I’m thinking of the Free/Paid tab. It was originally designed to accommodate the fact that we don’t have payment in all platform, but it turned out that selecting the “Paid” tab to select “Free with in-app payment” is a model that’s hard to a lot of users.

Currently, we’re using the word “Paid/In-App”. We might be able to clarify this tab to say “Paid and Free with In-App Payment”.

Comment 11

[Andy McKay]

I feel like I should wait for you new spiffy mocks for this.

Comment 12

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #11)
> I feel like I should wait for you new spiffy mocks for this.

What do you think about doing something along the lines of attachment 745019 [details], page 6? I think that clearly labeling the drop-down menu, though a hacky solution, solves this problem without introducing new UI element.

Comment 13

[Andy McKay]

It looks much clearer. Questions: 

* because there's a drop down for "zero price but can accept in-app payment" instantly made me question whether the others had in-app payments. Would a "price"  radio button, followed by the tiers drop down (if they said yes) make sense?

* would changing the tiers in the drop down change the country selection? Would it reset it? I hate it when forms do that to me.

Comment 14

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #13)
> * because there's a drop down for "zero price but can accept in-app payment"
> instantly made me question whether the others had in-app payments. Would a
> "price"  radio button, followed by the tiers drop down (if they said yes)
> make sense?

Your issue is a valid one. By putting the word “in-app payment”, we’re implying that other tiers don’t have in-app.

A simpler thing to implement here is to erase the “zero price but…” label, and replace the “Tier 0” value with “Free”. We can even replace it with “Free (Tier 0)” or “Tier 0 (Free)” if it helps clarify that this “free” is different from that other “free”

This “free” is the free that supports in-app payment. The other “free” is the one where the app is free forever, and compatible with all 4 platforms instead of just Firefox OS.

Comment 15

[Bram Pitoyo [:bram]]

(In reply to Andy McKay [:andym] from comment #13)
> * would changing the tiers in the drop down change the country selection?
> Would it reset it? I hate it when forms do that to me.

I didn’t explain checkbox logic and behavior in my mockup, but it did show that all checkbox are cleared every time a new tier is selected. This is something we shouldn’t do.

Checkbox on/off state should be preserved between tiers. For example, when Brazil is checked, it should remain checked as long as it’s compatible with the tier.

However, the list of country will still change in order to prevent the confusion of of “why is this country present, but there is no way to check on the box?”.


Another good behavior to implement is to make the checkbox select all country by default until manually unchecked.

Our developer research had discovered the fact that most developers, when publishing a paid app, wants to maximize revenue and reach as wide of an audience as possible. By making everything checked by default, we’re helping them from having to check every box for every country.

That way, we’ll avoid having to clear all checkbox every time the price changes. We’ll simply keep all boxes checked on all price level, unless a developer specify otherwise.

Comment 16

[Bram Pitoyo [:bram]]

Attachment: price dropdown menu, no label on Free

Comment 17

[Andy McKay]

I think this is all done in your commits Stuart?

Comment 19

[[e-mail]]

(In reply to Andy McKay [:andym] from comment #17)
> I think this is all done in your commits Stuart?

Yes I think so.

Comment 20

[krupa raj[:krupa]]

verified