Closed
Bug 921515
Opened 11 years ago
Closed 9 years ago
Find a way to flag incompatible apps on operator shelves/collections
Categories
(Marketplace Graveyard :: API, defect, P3)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: basta, Unassigned)
References
Details
(Whiteboard: [marketplace-transition])
The issue:
Rocketfuel allows operators to add any apps to an operator shelf. We don't, however, use the feature profile in any way. That means that operators may unknowingly add apps to their shelf that none of their users can see because all of the phones that the operator ships don't support one of the app's buchets.
The goal:
To show the "Incompatible" message in app search and the app list in Rocketfuel when an app would not be ideal for an operator to add to the list.
My thoughts:
- Have an API of devices and their feature profiles; allow operators to specify which devices they ship and then filter using the greatest common denominator of all of the feature profiles that they specify.
- Allow the carriers to directly enter feature profile strings (same as above but no API)
- Have a big JSON file included in rocketfuel that serves as a pseudo-API that cvan and I pull our hair out updating once every three days.
- ????
- Do nothing and RESOLVED WONTFIX
I really don't know what the best way to solve this is. Obviously keeping a big list of feature profiles around isn't ideal since they will change over time, but that's exactly what one of Buchner's PRDs describes so we'll probably need to do it at some point anyway.
Thoughts?
(This also applies to FACs, though to a lesser extent)
Updated•11 years ago
|
Blocks: mkt-publishtool-ui
Comment 2•11 years ago
|
||
This is true for all collection types
Summary: Find a way to flag incompatible apps on operator shelves → Find a way to flag incompatible apps on operator shelves/collections
Comment 3•11 years ago
|
||
Moving to API component to ensure that we have a discussion about this in a triage meeting.
The administrative burden here is pretty enormous, too; we would need to maintain a database of all devices and all countries where they're deployed This could explode over time if Firefox OS catches on, and it's still not foolproof: there will always be the edge cases of people who have unlocked devices that they brought with them to a network.
This seems to have an simpler educational solution: we do a better job telling users of the curation tool exactly how feature profile (and region, etc) filtering happens, and make it very clear that not all users will see all apps added to the collection.
Component: Admin Tools → API
Reporter | ||
Comment 4•11 years ago
|
||
Check out bug 922165
We'll at least have some of the data that we need, especially for the "white label" devices.
I think for at least v1, we should be able to show carriers the devices that they're selling. So Telefonica could use the Alcatel device, and TMobile could show whatever devices they offer. In that way, there's no surprises. That's not an insurmountable amount of data, and we could even collect it internally (from QA, platform, etc.). That will also at least cover the case of carriers freaking out because the FAC or OSC that they created is seemingly empty on their phones.
Comment 5•11 years ago
|
||
Associating some feature profiles with a collection sounds like a simple place to start for this. Obviously tracking devices and their profiles is a bigger project.
Priority: -- → P3
Comment 6•11 years ago
|
||
What about a sort of middle ground, where we display a "simulation" dropdown showing what it would look like on popular hardware? The administrative burden is very light, and it provides some a look at how real users would view collections.
Reporter | ||
Comment 7•11 years ago
|
||
That's essentially what my plan is. Add a dropdown containing things like "Geeksphone Keon, Geeksphone Peak, Alcatel One" etc. either on the collection detail page or on the Add Apps modal. Selecting one of those options would then either gray out or show the "Incompatible App" warning in the list of apps.
I suppose for a first pass, having a simple JSON blob on the client would be sufficient since there's not many different platforms that we support. In the long term though, I think we're going to need an API of some variety.
Comment 8•11 years ago
|
||
Could be as easy as an AMD module returning:
{
"Geeksphone Peak": "01001123000.32.1",
"Geeksphone Keon": "01001323000.32.1"
}
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Whiteboard: [marketplace-transition]
You need to log in
before you can comment on or make changes to this bug.
Description
•