Closed Bug 831137 Opened 11 years ago Closed 11 years ago

Adjust regions listing to add more detail for paid apps

Categories

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

Product:
Marketplace Graveyard
Component:
Payments/Refunds
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
2013-06-13

People

(Reporter: clouserw, Assigned: bram)

References

(Blocks 1 open bug)

Details

(Whiteboard: u=dev p=2)

Attachments

(1 file, 4 obsolete files)

hover on price - Japan
264.77 KB, image/png
Details 
We need to add:

- The local price (coming from the price tiers, bug 800520
- The "net to developer" price; which is tiers minus taxes and fees.  David will have answers regarding how much taxes+fees are.
- An asterisk/tooltip to indicate prices which include VAT

In addition to the UI part of this, we'll need the backend which includes storing a "net-to-developer" price as well as a flag on each region to indicate whether prices include VAT (or, generically, a tax, I suppose).

Talk to me tomorrow and I can show you UI changes in person.
Whiteboard: u=dev p=
Can we get Bram or someone else on UX to mock up what this will look like?
I can show you the UI changes in person tomorrow.
I think I'm clear to get the ball rolling on this. Can I confirm for now:

- There will be (for the foreseeable future) only a single currency (PriceCurrency) for any given region?
Whiteboard: u=dev p= → u=dev p=2
(In reply to Matt Basta [:basta] from comment #3)
> I think I'm clear to get the ball rolling on this. Can I confirm for now:
> 
> - There will be (for the foreseeable future) only a single currency
> (PriceCurrency) for any given region?

Yes
I am going to work on bug 828090 tomorrow (show developer information associated with price tier selection).

Since it could turn out to be quite a complicated project (due to variations in region and tax amounts, plus, new regions are going to be added in the future), I want to know if you guys have got an existing UI already developed, so that I don’t have to reinvent it from scratch?
I don't have anything drawn, just what David and I talked about last week.  I didn't know you were going to work on it, but assigning to you for designs then.  Thanks.
Assignee: mattbasta → bram
Version: 1.0 → 1.2
Target Milestone: 2013-01-24 → 2013-02-07
Here’s a mockup detailing the user experience around selecting default locale, price tiers, regions and taxes:
http://f.cl.ly/items/330p3n3w0V2S3Q0L3X2K/regions-price-tiers-taxes.pdf

Notable things:

1. Every field will impact the value of every other field, so developer is always informed of what his choice entails

2. I use default locale as a source of truth for determining currency and region. This means that the price field will not always contain USD, but the value of the currency associated with the default locale. This makes it less US-centric.

3. When developer selects a new locale or a new price, the local currency value for each selected region is always displayed. Is this a good thing, or will it make the interface too complex to code?

4. When a region has tax or VAT, the listing price and the “net to developer” price are displayed side by side. The latter is called “you earn: $x.xx”. For example, Tier 3 for United Kingdom is £ 2.25 (you earn: £ 1.88). There is no tooltip or asterisk.

Does this cover the feature requirement?
I like it
Attached file regions, price tiers and taxes UI - 02 (obsolete) — 
The interface has been updated with these notable features:

* Default locale is always written country first and language second to make the list more scannable.

* Currency is always written in ISO 4217 code (AUD, CAD, EUR, etc.) to prevent having multiple “dollar”s, “peso”s and “pound”s.

* “Retail price” and “You earn” values are displayed in a table. The idea is that user would read this like a financial information

* Price calculations are accessible by hovering on the tooltip beside the “You earn” values. This is very important. Exposing how the final price is calculated brings transparency to the process, and addresses one of the top concerns our developers have during our qualitative research: namely, they feel like they’re submitting into a black box with unknown price/review mechanisms.


Everything else stays the same as v1.
I'm a bit confused by the layout now.  There are 5 countries at the top, then it says "Telefonica" and there are some more countries, and then it says "Europe" and there are some more countries.  So, it seems like the top countries are uncategorized, then you categorize by carrier, then by continent.  What is the order/grouping on the page?  If you're grouping by carrier, what happens when carrier X and carrier Y both offer service in Japan?
Why are we calling it "Default Locale" but then listing country names? http://cl.ly/image/2Y110x0Q163K/o

I'm confused how the Price changes based on Default *Locale*. The Google Chrome Web Store lists all the price points next to the country name: http://cl.ly/image/0D1w460R2o0F/o I realize that we don't allow the developer to select different price points for different countries, but I really like how clean that looks. It's so hawt.
OK, now that I've read through all the slides I understand why we're listing the Price in the developer's price.

But I still think we should change the "Default Locale" field (or at least its wording).

I don't think we should be automatically allowing the developer to enroll in future regions, so I'd remove this checkbox: http://cl.ly/image/1L403R3p3725/o
(In reply to Chris Van Wiemeersch [:cvan] from comment #12)
> I don't think we should be automatically allowing the developer to enroll in
> future regions, so I'd remove this checkbox:
> http://cl.ly/image/1L403R3p3725/o

I don't agree with that.  Happy to hear from David if that's actually the case.
I can weigh in on the Default Locale change, since it came from a comment I made when we reviewed Bram's first version of this. It was odd that the label is "Default Locale" (locale meaning "A Place") and then all the options in the list were languages. So we discussed either changing the label or changing the list items so that we were displaying options that we were the thing we actually asking for with the form. Bram brought up a very good point, that they speak the same language in a lot of different countries, and since the tax info we're computing based on this input is country specific, it didn't make sense to ask for "Default language" so we decided it would be best to change the format of the options in the drop down to be places, since that's what the field is asking for.
"Default Locale" is carried over from add-ons.  It exists purely as a fallback locale.  So, if you go to a.m.o/de/addon/blah you will get German content for that add-on.  However, if German content doesn't exist, it has to fallback to something.  Instead of hardcoding fallbacks to en-US we allow developers to choose a fallback.  In this way a Japanese developer who speaks German could create an add-on that is only available in ja and de, and never need to know English.

That's the history of Default Locale and the only thing it's used for on the site.  In that case "Locale" is not a place, it's a language.
We have a number of issues that have been percolating in my head about how things are getting mushy between locales, language, pricing, supported platforms, regions, countries, operators, and payment processors.  I feel that we may heading down a path where it is getting hard to keep these distinct but simple for end users, and give content control to developers.  It's a really tough problem.   I see, while this design works, there are some potential pitfalls in scaling this to other platforms, payment processors.   I will send a separate email outside this bug to those on this list - as we should discuss. 

But to weigh in, I think asking the developer is the proper way (as I see in the design).   The request to be able to restrict content has been coming up - and this at least puts the developer in control.

I've seen others handle this by allowing individual country control, or by having an exception list (don't allow in these countries) - which may have to do with export control or content licensing in the app.
Attached file regions, price tiers and taxes UI - 03 (obsolete) — 
If we can take locale out, or use it in a different screen that’s not related to payment, I’m happy. It means less complexity for our user!


(In reply to Wil Clouser [:clouserw] from comment #10)
> What is the order/grouping on the page?  If you're grouping by carrier,
> what happens when carrier X and carrier Y both offer service in Japan?

This was the problem that I was trying to solve by use of the heading. But now that I look at it again, I think there’s a way to go about it that doesn’t involve any heading at all, thus greatly reducing complexity.

The mockup attached shows how different operators that has different price cuts, is stacked on top of each other.

Your question is a great one. I paraphrase it here:
What if a developer wants to make his app available in Japan, but just for NTT DoCoMo and not for SoftBank? Do we allow that? Should we allow that?

Tony’s user research indicates that this level of control and granularity is not something that developer preferred. The only issues that came up about payment processors and taking payments were “How much do I get from each sale? How do I get my money? And can I do free with in-app payment?”

Giving developers the choice of countries to sell apps in makes sense, but any control greater than this seems like something the devs we've talked to don't want, or haven't asked for, or said anything about.



What about different platforms having different country availability?

I think we should take the informations that developers had supplied in the manifest file and say “If this developer is submitting for a platform that is not available in country x, then we should take out x in the country selection”. If a developer wants to sell in country x, he must modify the manifest file to remove the platform that’s incompatible to be sold in that country.

Alternatively, we can say “This country is incompatible with this platform. You can modify your manifest file to reflect this, or if you hit continue, your app will not be sold in this platform, for this country”. But I think saying this could lead to all sorts of exceptions and edge cases that aren’t covered by the UI or documentation. With the approach above, I was trying to steer away from that complexity.



What about multiple payment processors?

In an ideal world, we’ll have one payment processor for all currencies, so developers don’t have to register for multiple payment processors in order to get their apps to sold everywhere.

When we cannot avoid having multiple payment processor, we should have the registration page for these processors be located *after* user has finished setting up price tier and countries.



Developers want to submit their app and get money in their pocket as soon as possible. We should optimize our flows to support this goal. Everything else can be hidden until needed, or put into another page.
I'm ok with that if we're defining regions as countries now.  I know David suggested that, I didn't know it was official.

Also, a minor thing, but it's not obvious to me that I can click on the carrier names in the last screens to register with them.
(In reply to Wil Clouser [:clouserw] from comment #18)
> Also, a minor thing, but it's not obvious to me that I can click on the
> carrier names in the last screens to register with them.

Hi Wil,

Thanks for pointing out the problem. I should have clarified that the point of the last mockup was to show that any registration for payment processor need to happen after country selection. I agree with your point that clicking on the carrier name to register is not an obvious way.

A better way to do this is to have the payment processor logo on top, and then a button labeled “Add new account” or “Login” on the bottom. That way, we clarify what company processes the payment, and how to register for it.



> I'm ok with that if we're defining regions as countries now.  I know David
> suggested that, I didn't know it was official.

I don’t think it’s official, either.

I’m mainly in favor of the region-as-country model, because this means making 3 things less complex:
* Default locale can be decoupled from price or country, or be dispensed away entirely
* Currency selection becomes country-neutral (it doesn’t need to be displayed in USD term, just in Tiers)
* Operator-specific price rules (even odd ones) don’t impact the country-based organization scheme

I want to unwrap point #3 a bit. What do I mean by “odd operator-specific price rules”, and how a country-based checkboxes system can handle it better rather than an operator-based one.

Let’s say that an operator, Telefonica, decides make itself available in two regions: Brazil and Spain. On the old interface, Telefonica would get its own heading. Under that heading, we put a checkbox called “Brazil” and “Spain”. Simple enough.

Time goes by, and we get one more operator: Deutsche Telekom. This operator only operates in Australia, New Zealand and Brazil. So now we have two checkboxes called “Brazil”. But one Brazil is Telefonica’s, and the other Brazil is DT’s.

To a developer, if he makes the app available to more operators, he’ll potentially make more money at the end of the day. He wants to get his app sold in Brazil to as many networks as possible, not necessarily decide at a granular level which operator he wants to sell to.

By limiting the checkbox at the country-level only—meaning, if you make this app available in Brazil, you’re going to make it available in *every* carrier in Brazil, now and in the future—we reduce the developer’s cognitive load and make the interface easier to parse.

Plus, we’ll deal with less overlaps and exceptions, and that’s always a good thing.
(In reply to Wil Clouser [:clouserw] from comment #18)
> I'm ok with that if we're defining regions as countries now.  I know David
> suggested that, I didn't know it was official.
> 
> Also, a minor thing, but it's not obvious to me that I can click on the
> carrier names in the last screens to register with them.

I think changing regions to countries make sense.  Countries is common as a region and since they have content restrictions and currency implications, I think this is the best definition of a region.
I think what Bram is saying all sounds right and in the direction we want to go.
Bram - what's the status/ETA here?
Target Milestone: 2013-02-07 → 2013-02-28
Attached file regions, price tiers and taxes UI - 03 (obsolete) — 
The mockups had been revised with one change: the payment processor logos are now removed in favor of a simple name, an “add a new account” link, and a drop-down menu that will appear if the system detects that the user already has an account with that payment processor.

We also agreed to use countries, yes? This is a simpler and more clearly divisible concept than regions: so that solves the biggest problem that this mockup set to solve.

I think that about wraps it up for the design.
Attachment #711708 - Attachment is obsolete: true
Attachment #712816 - Attachment is obsolete: true
Yes, countries.  From an eng POV they are still regions, just 1 region = 1 country.

I like the layout.
I think, we may want to add in settlement amount for the developer: how much the developer makes.

Here is an example:
User selects Price Tier a (US$.99)

Example for Country X: exchange rate CUR$1000 to US$1.00, but our pricing includes a VAT of 10%. Our price table says price tier 1 is CUR$1100

User Pays:  CUR$1100 (tax inclusive.  Aprox 10%)
Net before taxes and fees: CUR$1000
Developer Net: CUR$700

Another example for Country Y: exchange rate is CUR$2 to $1, taxes and fees in that country are 30% total added on top of the amount we charge.
Our price tier table says the price is CUR$2.00 because they don't include taxes.
User Pays: CUR$2.60
Net before taxes and fees: CUR$2.00
Developer Net: CUR$1.40

Don't know if that is clear:  but what I am saying is that the developers get a net on the pre-taxed price to the end user.
Hi David,

The intent for the interface is to show the consumer-facing value (“retail price”) and settlement amount (“you earn”), because the two numbers—how expensive it will be for my customer and how much I get—are what developers care about the most at the end of the day.

If the price tier value is lower than what user pays because taxes has been added, then let’s only display the user pays value in the UI, and we can display the price tier in the tooltip.

Same thing with the net-before-taxes-and-fees values. It’s important to have, but we should clarify that in the tooltip.

The idea is to keep the information that developer sees in the UI be the direct translation of what the user sees. Thus:
* This is what my user will pay at the end of the day
* This is what I will make at the end of the day

The details could go in the tooltip, to be checked out at the developer’s interest.

And the tooltip doesn’t have to be displayed in one-line, either. We can display what’s in the tooltip like a subtraction table, going from top to bottom like so:

User pays        1100
Tax (10%)         100 -
                -----
Net before fees  1000
Mozilla fees      100
Operator fees     200 -
                -----
You earn          700


What do you think?
Yes.  I don't think we want to enumerate all the split fees or how the split is between Mozilla, operators, and processing.  We have the rights to disclose this, but the details will vary by country.  Same thing for taxes on top of a transaction - since mobile operators bill the end user, and end users may be subject to different taxes within the same country, we can only estimate what these may be since we do not know any information about the end user.  

Perhaps in the tool tip we can tell approximate percentages that will vary by each country.
Agreed. Developers won’t care about how we split fees. Plus, having this information might overwhelm them. They do care about how the price difference is calculated, but we can simply group all our fees under one line item.

The bottom line is, as long as developers see four values:

* What user will pay at the end of the day (plus taxes)
* Price tier (if a difference exists)
* What developer will earn at the end of the day
* Rough breakdown of the difference between the two (taxes and fees)

We should be good to go.

Re: taxes on top of user price – this is a hard situation to design for. Our price tier will not be the end price that user will pay because no tax has been added to it. I still recommend that we show the ultimate price, with taxes added.

However, if we cannot show this value, I think we can still show something like (user pays 1,100 + 2.25–3.00% sales tax), without actually showing the ultimate price. Developers will understand that there are small variables that we don’t know exactly.

So let’s revise the tooltip to:
* Add sales tax on top of list price
* Group all fees into one line item

It becomes something like this:

User pays  1100 + 2.25-3.00% sales tax
VAT (10%)   100
Fees        300 -
---------------
You earn    700
Any update on this?
Attached image hover on price - Japan — 
(In reply to Andy McKay [:andym] from comment #29)
> Any update on this?

The latest mockup that we can implement is attached above (attachment 716389 [details]), and an example of the tooltip that you can expect on the pricing page is attached here.
Target Milestone: 2013-02-28 → ---
I am marking this blocking 775802 since there is no way a developer can make head or tail of our pricing structure across regions with the current implementation.
Blocks: marketplace-payments
I’m done with the UI part of this bug. Feel free to reassign to me should an unresolved issue pop up.
Assignee: bram → nobody
This mockup supersedes attachment 716389 [details], but there are some captions on that design that should be used here. So I’m not making that attachment obsolete.

This mockup visualizes a UI to show user the relationship between price tier, country, retail price and final price.

The pages explain how the logic works, but here’s a brief summary:

1. First, developer would select a price tier in order for the list of country to display.

2. The price tier drop-down menu is labeled with the type of payment that a tier supports. For example, Tier 1–4 supports carrier billings only.

3. After selecting a price tier, the country list is updated. It will only show countries that are compatible with the tier’s payment support, selected above.

4. Incompatible countries are not shown so as to not confuse users with the problem of “this country is on the list, but why can’t I click on the checkbox?”
Assignee: nobody → bram
Please find the latest mockup for this problem on bug 868179 comment 3.
Comment on attachment 745019 [details]
price tier, country and payment method UI - 01

Superseeded by attachment 754311 [details] on bug 868179
Attachment #745019 - Attachment is obsolete: true
Comment on attachment 745019 [details]
price tier, country and payment method UI - 01

Superseded by bug 868179 attachment 754311 [details].
Comment on attachment 716389 [details]
regions, price tiers and taxes UI - 03

Superseded by bug 868179 attachment 754311 [details].
Attachment #716389 - Attachment is obsolete: true
Bug 868179 is assigned to Stuart and the attachments on this bug are obsoleted by that bug, so I guess we're done here?  Closing this...
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2013-06-13
All the concerns in the bug have been addressed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.