Closed Bug 873167 Opened 7 years ago Closed 3 years ago

[project] Discovery: Optimize Marketplace app discovery w/ integration of E.Me


(Tracking :: User Story, defect)

Not set


(Not tracked)



(Reporter: cgalimidi, Unassigned)




No description provided.
Project Tracking Bug
[User Story], [UX] & [Dev] bugs to be dependent on this bug.

Integrate FFx Marketplace w/ E.Me via API call to show FFx Mobile Apps search results on FFxOS

Phase 1. (Target v1.01) > Preliminary pilot / Indexing the Store (E.Me to use existing API) - No gaia work needed
a) E.Me to use existing API
b) no keywords, category information collected in manifest (E.Me to provide workaround or live without)
c) no information on installed vs uninstalled apps
d) *include* default locale / region information in API (Moz Wil)

Phase 2. (v1.1 FFxOS) Final solution and integration > Gaia work needed
a) E.Me to index of store using API, locale/region info already included from Ph1 (Wil, E.Me)
b) potentially include keywords on apps to make E.Me search results more focused (Maria, Dan B, David B)
c) categories & keywords in data dump to make results more meaningful
d) potentially include category and keyword in the manifest to enable search on device / alternately show apps on device in search results with a workaround by E.Me
e) Uninstall / Install event read on device by E.Me to show accurate search results for "suggested apps" on device

1) Data dump from marketplace
a) design, document and develop daily dump of data from marketplace (JSON) (Moz Wil)
b) Work with Ops to place the daily dump / feed behind authorized wall (Mark Mayo)

2) Decision on whether or not to update manifest with category / keyword (BWalker and more)

3) Workaround to category / keyword in manifest file (E.Me)

4) Decision with Dev Eco / Dev Engage on Keywords on apps (opportunity for Devs to show app in E.Me?)

5) Integration of Keywords in the app submission flow (Dan B / David B)

6) Decision with Marketplace whether or not to leverage Keywords (David B)

7) Privacy & Sec Review with E.Me (E.Me and Alina Hua, Ray Forbes)
- Indexing of apps and app data usage

8) Access to app event management on device by E.Me (uninstall / install info in order to properly display in on-device app in search results) (Dietrich, CLee, Fabrice)

9) Gaia updates to enable E.Me access to uninstall / install event info (Dietrich, Fabrice, Vivien)

Oh there may be more.
Blocks: 873164
Summary: [project] Discovery: Optimize discovery integration w/ E.Me → [project] Discovery: Optimize Marketplace app discovery w/ integration of E.Me
Depends on: 873194
Depends on: 873197
Duplicate of this bug: 873189
Really great plan.
One thing to consider if we want the daily dump open to all (Deliverable 1b).  Unless there are security concerns, I don't see why we wouldn't want this dump publicly available to any indexer, as long as they are publicly available apps and information.
Depends on: 875170
Basically, we have concluded that app meta-data (related categories) should not be bundled into app's manifest but rather retrieved from Marketplace.

But what of apps that aren't in the Marketplace? Preinstalled apps (Music, Camera, Gallery...) and even developer apps not yet in the Marketplace. Should they have a manifest fallback?
pre-loaded non-core apps (like pre-loaded non-mozilla apps that are removable) that have meta information should be able to be retrieved from the Marketplace as this is how updates happen.

The core apps - like dialer, camera, contacts, gallery do not have this meta information from any place that I am aware of.  I think we would need to create something to solve this case.
Preinstalled apps are not really a problem - we feed their data into our API and fetch their metadata just like we do for any other installed app. They're predictable.

The only question is - do we want to support development apps. If so, we should allow category param in manifest.webapp.

* By development apps I mean - an app a developer works on which is not yet in the marketplace. We may want to provide the developer tools for previewing and improving their visibility in app results.
That's fair too.  I think at this point you'd need to support both methods to hit all the users you want to.
Hey, would love to get the Moz UX team looped in here on how we display the different types of results and what happens when a user taps them. Let me know when there will be opportunity for us to start working on that.
I don't think we need to address the use case of developer previewing the apps in search for non-published apps.
Depends on: 875587
No longer depends on: 879342
No longer depends on: 873190
Depends on: 873543
Have missed the deadlines for v1.1
To ensure acceptance into V1.2 need to land patch and code review asap.

UX improvements forthcoming.
Proposed, revised timeline

Final Approval : 881064
15-Aug : code approved 

Development: 881063 
8-Aug : code submitted 
8-Jul - 8-Aug : development 

UX : 873543 
25-Jul : UX final
22-Jul : UX final review, last round feedback
18-Jul : E.Me UX updates complete
8-Jul : UX Review, 2nd round feedback
25-Jun : UX Mozilla Initial feedback
Depends on: 910316
Depends on: 925815
Depends on: 925806
No longer depends on: 925806
No longer depends on: 925815
No longer depends on: 875587
Depends on: 910332
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.