|Release target||Marketplace June|
|Status note||Ready for implementation planning.|
|Product manager||Justin Scott|
|Directly Responsible Individual||Wil Clouser|
|Localization lead||Chris Hofmann|
|QA lead||Krupa Raj|
|Product marketing lead||`|
|Additional members||Michael Treese|
Stage 1: Definition
1. Feature overview
App stores that target users of different regions and languages need a way to deliver relevant, local content to those users. The Mozilla Marketplace will have a phased roll-out to particular locales, while still allowing users worldwide to discover and use apps. To facilitate this, we need a way for users to be taken to the most appropriate region store with their preferred language, and for developers to indicate which regions their content should be displayed in.
2. Users & use cases
- A user who lives in Brazil (supported region) speaks Portuguese and opens the Marketplace app. He should see the Marketplace in Portuguese with featured Brazilian apps and locally popular apps. Prices should be displayed in Reals.
- A user in New Zealand (supported region) searches for "restaurant ratings" to find a good restaurant ratings and reviews app. Yelp doesn't have relevant content in NZ, but DineOut does. Users in different regions have rated the apps accordingly. Search results should surface DineOut as a locally relevant app despite Yelp dwarfing it in global popularity.
- Hulu is only allowed to license streaming video content within the US, and does not want their app listing to be available outside of the US.
- A user in Russia (unsupported region) loads the Mozilla Marketplace. She should see international, country-agnostic content and be able to use all the features of the Marketplace.
- An English-speaking user from the United States visits France on a business trip, having previously visited the Marketplace from the US. His experience should remain unchanged.
- An English-speaking student from the US studying abroad in France purchases a B2G phone. The Marketplace initially loads in French / France, but she changes the language to English to better understand the content.
- IP-based geolocation service
- Identification of locale codes B2G will send
- Users who visit the Marketplace have an experience tailored to their language and region.
- The initial set of supported regions is available on the International page.
- Initial language and region settings are guessed based on information available to us.
- Users can change their language and region at any time and it will be remembered for subsequent visits.
- We will not block users from accessing other regions or content in the Marketplace. Apps that require certainty of a user's location (e.g. for content licensing purposes) should detect that themselves inside their app.
Stage 2: Design
5. Functional specification
A user's localized experience in the Marketplace hinges on two components: language and region. Language is based on the user's browser's preferred language settings (e.g. en-US, pt-BR, etc.). Region is based on the user's physical location, determined by IP address. Both language and region are automatically detected but can be changed by the user.
If none of a user's preferred languages are available, the default fallback is English. Language only governs the translations displayed for Marketplace strings and individual app translations. Additional languages can be added at any time as submitted from the Mozilla community.
Regions, however, require much more attention before being added and fully supported. Regions govern the apps displayed, as well as currency and price tiers, and in some cases may require special compliance with local laws (e.g. hiding the Games category in Brazil). If the user's region isn't available, the default is the Unsupported region. Unsupported is a magical region that houses all users in regions not yet officially supported.
Once in a region, only apps the developer has chosen to list in that region should be displayed. These apps are displayed regardless of whether they have a translation in the user's selected language, for now.
Each region should have a default currency mapped to it (listed on the International page), and that currency's price tiers are what is used to in price displays and purchases unless the user has changed it in their account settings.
Local featured apps are given priority, as described in the Feature Manager section of the Contributor Spec.
An app's regional popularity is based on two factors: the downloads from users in that region, and the app ratings from users in that region. These are factored into a regional popularity score that is used to highlight apps in search results and popular lists.
We should begin recording the locale used when downloading or rating an app to facilitate this.
Popular lists have 2 modes: global, which is based on all data we have, and regional, which is only based on that particular region. If there is not yet enough local data for a new region store, the global version should be used. Otherwise, the regional version should be used.
In addition to the other factors that go into search rankings, regional popularity should have weight as well (positive and negative), and potentially have a badge indicating its status as a local favorite.
Switching Regions or Languages
Users can change their region or language at any time from the footer.
By default, apps are listed in all regions. Developers may opt out of particular regions by managing their app's details after submission. We do not need to include this field during submission.
All regions selected:
Some regions selected:
When a new region becomes officially supported, apps that are listed in Unsupported will automatically be added to the new region. Apps not listed in Unsupported will not be listed in the new region and must opt in.
6. User experience design
- Chrome Web Store - allows changing language and region separately via options cog. Must access using Chrome.
- Windows Store - language and region tied but changeable (see Canada)
- Apple App Store - developer experience UI
Stage 3: Planning
7. Implementation plan
Phase 1: For June, the features above except for the regional popularity score and dependencies (regional popular lists and search results) are included.
Phase 2: At a later date TBD, the regional popularity score and dependencies should be completed.
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
Team status notes