Device detection is currently done as one set of values: device: desktop, mobile, gaia, tablet This is too generic (and in some ways, too narrow) to handle the use cases that we need (the model doesn't match the use), and it's a pain to have to understand. Countless bugs exist because we conflate tablet/desktop and mobile/tablet. Instead, this system should be modeled across two sets of values: device: desktop, android, firefoxos, other (?) screen: wide, small (?), mobile We can easily separate this out on the client side and provide middleware which estimates screen width. This is the first step to Buchner's Buckets and will eventually block Fireplace. Things that need to be changed: - DeviceDetectionMiddleware - Submission flow - Lots of consumer templates - constants.platforms - Lots of JS (most things that use z.capabilities) - Ability to set up payments (mkt.developers.*) - Reviewer tools (minor changes, mostly presentation) - Search (for filters) - The API - Admin tools (featured app tool lol) Fireplace already uses this new system and doesn't require any real changes.

I've always disliked the mobile/tablet/desktop moniker, because it's not truly what we want to know. We use these flags to determine: input method: cursor vs finger (informs interaction design) screen size: informs design constraints and layout device type: mostly used for getting the right list of apps I'd love to see these more accurately reflected in whatever solution we come up with, instead of letting the word `desktop` mean something confusing.

How would this interact with bug 846438? It feels like the two clash.

CC Tony and Maria, because this will impact how we design everything on Marketplace. It’s a good bug for me to keep tabs on, as well.

We all hate tracking bugs, but this is the most central source of truth for the unbucketing project's progress.

What are the 'unbuckets' we have identified? I am struggling with what our design is for the unbuckets that adequately describe the capabilities of the device. I am wrestling with how we are distinguishing device type from other factors which are implied by saying something like "android tablet'. If we just use the factors of: input method (cursor, gesture, or both) screen size (small, medium, large, x-large) - or need a way to define these better. device type - I think this is really platform. Firefox OS, Android, Desktop - as related to the UA platform string (but presented as FFOS, Android, or Desktop OS - possibly break out Win 8 since this is kind of a hybrid OS). It seems to me that the device type pre-selects would imply: Firefox OS Phone - gesture, small screen, Firefox OS platform. Android Phone - gesture, small screen, Android platform. Android Tablet - gesture, medium screen, Android platform. Desktop - cursor, large screen, Win/Unix/Linux/Mac (though these are not important) Win 8 - cursor and gesture, med and large screen, Win 8 platform Win 8 presents a problem since it doesn't neatly fit into a desktop or tablet bucket. Along with pre-selects, the actual selections should be modifiable , like a large screen Android phone. Along with this list it seems we need a list of other capabilities, and these unbuckets need to be identified. For instance hardware features: NFC MMS Gyro Dual Camera (?) and software features: FFoS version needed Android version needed etc. So wondering if there is a spec that describes all the unbuckets?

(In reply to David Bialer [:dbialer] from comment #5) > What are the 'unbuckets' we have identified? I am struggling with what our > design is for the unbuckets that adequately describe the capabilities of the > device. This bug is now specifically to merge Android's tablet and smartphone "platforms" into one singular platform. The actual buchets that we've identified are what we have here: https://github.com/mozilla/fireplace/blob/master/hearth/media/js/buckets.js You can see it tests for all manner of device APIs ("'foo' in navigator"). > I am wrestling with how we are distinguishing device type from other factors > which are implied by saying something like "android tablet'. > > If we just use the factors of: > input method (cursor, gesture, or both) > screen size (small, medium, large, x-large) - or need a way to define these > better. > device type - I think this is really platform. Firefox OS, Android, Desktop > - as related to the UA platform string (but presented as FFOS, Android, or > Desktop OS - possibly break out Win 8 since this is kind of a hybrid OS). > > It seems to me that the device type pre-selects would imply: > Firefox OS Phone - gesture, small screen, Firefox OS platform. > Android Phone - gesture, small screen, Android platform. > Android Tablet - gesture, medium screen, Android platform. > Desktop - cursor, large screen, Win/Unix/Linux/Mac (though these are not > important) > Win 8 - cursor and gesture, med and large screen, Win 8 platform All of this is taken care of by feature profiles, which are addressed by other bugs. This bug is to exclusively deal with issues which are not brought about by the presence of APIs or not, but rather because of the implementation of Firefox. Ideally, this distinction will go away once payments becomes universal, and identity has settled. > Win 8 presents a problem since it doesn't neatly fit into a desktop or > tablet bucket. Metro will be considered Desktop, and the feature profile will identify it as supporting touch. > Along with pre-selects, the actual selections should be modifiable , like a > large screen Android phone. Screen size is something that we're not going for in v1 of this feature (an app shouldn't be outright broken at a different screen size). If the app is actually broken at a common screen size, that's grounds for rejection. > Along with this list it seems we need a list of other capabilities, and > these unbuckets need to be identified. > > For instance hardware features: > NFC > MMS > Gyro > Dual Camera (?) > > and software features: > FFoS version needed > Android version needed > etc. > > So wondering if there is a spec that describes all the unbuckets? This is addressed in the dependencies (and sub-dependencies) of bug 858314.

I echo dbialer...I have a LOT of questions about how this all is actually going to be implemented. I expect business development does as well, because "If the app is actually broken at a common screen size, that's grounds for rejection" is a very different policy than the review process today, and a target that many partners may not be able to hit right now. Rather than chasing down a dozen bugs to understand what's going on, perhaps we could have a meeting to walk through it?

I share similar concerns to Lisa and David... my initial thoughts are while this is something we should be doing as part of the overall un-bucketing changes, we absolutely should not be merging Tablet and Mobile until screen size is available as a selectable feature. It has to be in v1.

(In reply to Lisa Brewster [:adora] from comment #7) > I echo dbialer...I have a LOT of questions about how this all is actually > going to be implemented. I expect business development does as well, > because "If the app is actually broken at a common screen size, that's > grounds for rejection" is a very different policy than the review process > today, and a target that many partners may not be able to hit right now. If a developer (or partner) selects Firefox for Android as a compatible platform and the app is inoperable at common Android screen sizes, then how is that not grounds for rejection? If a developer says that their app is compatible with FXOS but a 320x480 screen makes the app impossible to use, then how is that acceptable? How is that any different than saying that an app works on Android but it doesn't work on any 5-8" devices (Nexus 7, Galaxy Note, etc.) because the screen is too big (or small)? Either way, this bug is to merge the Android platforms into one, nothing more. We cannot (CANNOT) detect whether a device is a phone or tablet. We have no way of measuring the screen's physical dimensions, how you hold it, or any other physical characteristics of the device. Even the aspect ratio, depending on how you're holding the device, tells us nothing about whether it's a tablet or a phone. Even if we did have access to that information, there's no clear line where a tablet ends and a phone begins. There are 5" Android tablets that are smaller than 5.5" Android phones. Given that we can't detect those properties anyway, having a separate platform makes this bug all the more relevant. Bug 858314 is tracking the transition to feature profiles, which will solve the issue described above.

(In reply to Matt Basta [:basta] from comment #9) > We cannot (CANNOT) detect whether a device is a phone or tablet. https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference#Android

(In reply to Andrew Williamson [:eviljeff] from comment #10) > https://developer.mozilla.org/en-US/docs/ > Gecko_user_agent_string_reference#Android This string is based on screen resolution and doesn't reflect what the device actually *is*. Versions of FX4A from as late as last year do not include Tablet in the UA string. Furthermore, the tablet/mobile determination is made purely based on screen resolution: http://dxr.mozilla.org/mozilla-central/mobile/android/base/GeckoApp.java#l1310 The UA string was added so sites would serve appropriate stylesheets to Firefox because Opera, Dolphin and the stock browser sent a Tablet flag with their tablet-based browser. The bug to implement said UA string even makes note of this: > There will always be borderline cases in the 5" to 8" range; no matter what we decide, some users will want the opposite, and we can give them that option through prefs or add-ons. Unfortunately we don't have the luxury of being able to rely on add-ons or prefs. Firefox for Android *is a single platform*. Soon enough, FXOS will run on tablets. Desktop is splitting out with Metro. The answer to this problem is feature profiles and not the preservation of technically debt.

(In reply to Matt Basta [:basta] from comment #11) > Furthermore, the tablet/mobile determination is made purely based on screen > resolution: okay. I wasn't aware of the method. > Unfortunately we don't have the luxury of being able to rely on add-ons or > prefs. Firefox for Android *is a single platform*. Soon enough, FXOS will > run on tablets. Desktop is splitting out with Metro. The answer to this > problem is feature profiles and not the preservation of technically debt. I absolutely agree the answer is feature profiles. I'm saying that this merge shouldn't happen until feature profiles are implemented (or at least the screen size part of it).

Agree with Lisa that we should have a meeting to discuss this rather than trying to resolve it in a bug. Basta--can you set something up? Might need to wait until the week of May 6th so David Bialer can attend.

Assigning to me since I'll do it, though it won't happen for at least a couple weeks. The replacement for screen size being tied to the platform is "Requires smartphone screen resolution" or something along those lines in the app feature profile. This means that apps that mark qHD support in the buchets will not be shown for devices which have screens larger than qHD. This should work for partners who have apps that aren't built right. When this lands, we'll have a migration so that all apps which currently have support for FX Mobile but not FX for Tablet will have the qHD feature profile marked by default. That means that functionally there should be no change in behavior for either the consumers or the developers once this lands.

What's the conclusion here?

(In reply to Christopher Van Wiemeersch [:cvan] from comment #15) > What's the conclusion here? afaik, its blocked on having enough of the buchets work implemented to be able to mark apps as needing a tablet sized or smartphone sized screen.

https://github.com/mozilla/zamboni/commit/2a486af Added profiles for mobile-only apps - as well as JS magic to toggle the "qHD" profile checkbox. "cvan tested, basta™ approved." The rest someone else can do in a few months when profiles are mature.

(In reply to Christopher Van Wiemeersch [:cvan] from comment #17) > The rest someone else can do in a few months when profiles are mature. What's the "rest"? What else needs to happen?

(In reply to Rob Hudson [:robhudson] from comment #18) > (In reply to Christopher Van Wiemeersch [:cvan] from comment #17) > > The rest someone else can do in a few months when profiles are mature. > > What's the "rest"? What else needs to happen? Per comment 0: - DeviceDetectionMiddleware > - Submission flow Removing the big checkboxes (eventually!) > - Lots of consumer templates > - constants.platforms > - Lots of JS (most things that use z.capabilities) > - Ability to set up payments (mkt.developers.*) > - Reviewer tools (minor changes, mostly presentation) > - Search (for filters) > - The API > - Admin tools (featured app tool lol)

We can't have a P1 assigned to no one blocking this goal. If you want to split the bug, that's fine, but please do and close this one.

This isn't really P1, and the only things blocking it are: 1. Messaging developers 2. Lots of testing of the pre-filled buchets (did the migration work?) 3. Making sure reviewer tools have appropriate accommodations

I'm afraid there's nothing for me to do here until we email developer and get Buchner's Buchets stats (there's a PRD for that somewhere).

We had a meeting this morning and made some decisions: 1) We're combining android tablet and android phone into "android" 2) We'll add a section letting a developer choose phone/tablet/desktop (actual wording to come) Other bugs are filed (bug 978150 being a main one) which you can watch if interested, but since we're 22 comments into this one I'm going to close it. Thanks for your input.