Marketplace/Tarako/Technical design

The Tarako device class is a low-cost smartphone. In order to allow the Marketplace to work on such a device, a different architectural approach must be taken.

Technical requirements and constraints

Known device and environment constraints (as of 2014/04/28)

• 128MB RAM
• 30MB RAM max for an app
• 6MB available for browser cache
• 15MB a safe ceiling for local storage (non-browser)
• attempts to multitask result in OOM and app shutdowns requiring restart, reboot in some cases
• no GPS

Relevant audience and environment research highlights

• EDGE use is popular, and should be treated as a baseline
• users are aware they are getting a "smartphone" and have expectations about quantity of apps in the catalog
• users are used to slower connections
• advertising is seen as questionable / bad
• network / data will be heavily constrained

Known FxOS/other issues (as of 2014/04/28)

• we will not have feature detection API in 1.3T
• keyboard bug (https://bugzilla.mozilla.org/show_bug.cgi?id=984635) may appear more regularly in marketplace? Krupa to verify.

Design drivers

• navigating: we should be as close to a flat page as we can be (safest to assume hierarchical navigation won't be usable for target audiences, and so they wouldn't use it); utility of search is equally unclear.
• apps need to be targeted: need to be ones that run well on Tarako class devices; need to be most relevant.
• operator shelf not necessary for launch (potentially at all).
• low bandwidth, high latency: performance issues related to network latency are likely to be seen as less of a big deal than we see them as, these slow networks are the norm in the target markets.
• lower end of the market implies lower levels of education & literacy: possibly replace category labels with icons? streamline app detail pages.
• home page content must be targeted as specifically as possible.

Technical drivers

• device / environment constraints
• design drivers
• KPIs for performance

KPIs for performance

Need to clarify these KPIs against https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines.

• TMP initial launch: <3000ms baseline, <2000ms target
• TMP load (wifi): <8000ms baseline, <5000ms target
• TMP load (edge): <10000ms target

Position

With an aggressive timeline for v0 delivery and outstanding blockers on key aspects (Persona, GA), the chosen approach for v0 was that of a separate hosted app that could be locally cached over a real packaged app or possibly futile optimizations of the existing marketplace.

This approach would allow for the development of a custom UI quickly, fast warm loads of the app, offline/transition use of the app, as well as the ability to iterate on changes to the app without deploying packages or requiring Gaia updates. The drawback is that we lose MNC/MCC access, and thus payments capability (though there are currently no paid apps anyway).

The ultimate goal is a real packaged app, re-instating billing, logins, and useful implementation of GA; because of the timeline, these will need to be all in future releases, as necessary.

Once the FxOS landing date changed and the hosted app testing showed that it would not perform against the quantity of apps anticipated for Tarako release, the approach was changed to the preferenced packaged app (a derivative of Fireplace) to be delivered in a v0 and v1 iteration (requiring two separate uplifts).

Technical design details

The packaged marketplace app for use with Tarako will consist of pages and assets (JavaScript, CSS, and images) needed for the interface as well as initial data for the app in JSON format.

Interfaces

0. Global: Searchbox at the top of the screen, below that is a navigation bar that shows icons and labels for Home, Games, Tools, and Lifestyle (the latter three are Tarako-specific aggregations of Marketplace categories).
1. Home page: shows a random selection of 6 apps chosen from those editorially designated for the homepage collection, and four buttons for Help, Feedback, Privacy Policy, and and Terms of use at the bottom of the page.
2. Category list view: shows all apps in that category, in pages of 10 at a time.
3. Search results: shows all apps meeting the search criteria, as well as a header below the global elements that shows a result count on one side of the screen and a toggle control on the other that switches between compact and expanded views of each app.
4. Compact / Expanded app view: shows the basic information for an app; the expanded view reveals a thumbnail of a screenshot.
5. Detail view: shows more information for the app, including a description and a thumbnail of a screenshot that the user can click on to load a full screenshot.

Content filtering

6. Filtering apps for device: short-term: tagging apps to be served to Tarako devices (v0); long-term: integrated dev submission flow, review verification, and feature detection API used to filter apps for device (v1).

Content caching (and offline implications)

7. Local caching of marketplace data: enables fast startup of the application while data is updated asynchronously in the background (when online). When offline, the application will notify the user of the need to be online to use the application.
8. Cache contents: for bootstrapping startup, the cached data will consist of: text data for the application, icon, and 1-3 screenshot thumbnails for each app. This will be stored for the 30 apps that may appear on the homepage as well as each 10 on the first page of each of the 3 categories (this enables bootstrapping of initial pages (except search) and anticipated next-click detail pages).

Home page freshness

9. The homepage experience will be very simple: there will be a list of 6 editorially-chosen apps. These apps will be a random subset of a "Tarako Featured" collection maintained by the curation team. Target size of collection: 30 apps. We'll store the full contents of this collection locally, updating its content as a connection is available. To maintain the appearance of editorial freshness, the selection of apps displayed on the homepage will be updated each day, but will remain static throughout that day. The randomness will be weighted based on popularity and possibly other factors. Algorithm TBD.

INSTALLS_ALLOWED_FROM

10. For v0 and v1, we will use an iframe approach. For the future, we should consider the approach outlined in https://bugzilla.mozilla.org/show_bug.cgi?id=965964.

Repository

• https://github.com/mozilla/yogafire/

Summary of functionality for v0

Packaged app with a streamlined UI for performance, especially on low-memory devices; size of package not to exceed 1mb.

• no:
  • no offline functionality
  • no login
  • no review/rating submissions
  • no reviews
  • no prepopulated search
  • no payments
  • localizations are incomplete and/or not included
• JSON data for homepage (all 30 apps, not just 6 shown)
  • text data
  • icon
  • top 3 screenshot thumbnails (maximum)
• JSON data for first page of categories (10 apps each)
  • text data
  • icon
  • top 3 screenshot thumbnails (maximum)
• data is included as JSON in the package
  • apps are identified back-end and tagged (by Wil)
  • apps are filtered by tag on search endpoint
• all assets not loaded into the package will be lazy-loaded (when the user is online); none of that data will be cached/saved
• all assets loaded into the package only get updated with a new package release
• online cached to appserver according to existing Fireplace logic -- updated based on ttl (1 week) and size (4mb limit)

Summary of functionality for v1

Building upon v0 to deliver improved performance and localizations.

Changes to v0:

• apps are identified back-end without using tags (replacement method is under discussion now)

Additions:

• data is included as JSON in the package
  • developers are able to specify that their app is Tarako-ready
  • reviewers are able to filter (and override) apps by "Tarako-ready"
  • curators are able to filter apps by "Tarako-ready" and create the "featured" collection used to populate the homepage
• package includes localizations for 4 languages + English
• JSON data is cached in localStorage after the initial (cold) load; subsequent app launches should startup with cached data first
• include blocking notification that the user must be online to use the marketplace
• include notification that the (cached) data is updating when the user is online

Tentative release schedule (draft)

• v0: April 30, 2014
• v1: May 13, 2014
• v1.1: July 2014 -- revisions based on device and user testing in-market (TBD).
• v1.5: TBD 2014 -- add login, user rating and review submissions, list of my installed apps.