Re: gUM's optional constraints algorithm penalizes user-choice chasing best-match for webpage

On 9/3/13 3:47 PM, Cullen Jennings (fluffy) wrote:
> At first glance, I liked you proposal but the more I thought about it, I wonder if it really is the right thing.
>
> The thing I like about this is that applications developer had a choice on what they wanted to have happen. If what they want is your first case, they can get it, if what they want is the second case, they can get it  by not adding the optional constraint.
>
> What you are proposing removes the ability of the application developer to get the behavior they want.

I disagree,

  * about what they want: By choosing "optional" over "mandatory", they
    want it to work even if these requirements are not met.
  * that ability has been removed: Webpages will still dictate defaults.
    Poorer choices will be secondary and can be marked as undesirable.

Only when the user explicitly disagrees with the app does this shift the 
weight. What I'm saying is:

If I have a modern laptop with a high-res USB camera plugged in, and 
your webpage picks my USB camera every time, don't force me to unplug 
it! - UX fail.

>   Now the example you give, the algorithm you propose makes sense because it is unlikely that it  would be a good idea to set this optional constraint, but in other cases, I'm not sure I would like the outcome.

I can think of many good reasons to set optional constraints, like: "I'm 
a dialing app, so I prefer the front camera" - so we may have a 
disconnect here.

> It seems like there would be cases where it resulted in a lot of sub optimal solutions being proposed to the user and the user picking one which may not be best for the application.ink

An example would be nice here, as it's hard to argue with supposition.

Only mandatory constraints guarantee the application developer anything, 
and even there the user may reject the request entirely. Optional 
constraints imply willingness to compromise and are as much a property 
of the webpage as a request IMHO.

.: Jan-Ivar :.

> On Aug 31, 2013, at 1:43 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> In Firefox, we let users of gUM webpages choose which source to allow from a subset dictated by the webpage, or choose to allow none.
>>
>> I believe this dictated subset is overly narrow when optional gUM constraints are in play. To illustrate:
>>
>> Consider two phones A and B.
>>
>>     Phone A has both a front camera and a back camera.
>>     Phone B has only a back camera.
>>
>>     A webpage C has this constraint = { optional: [{ facingMode:"user" }] }
>>
>> Meaning the webpage prefers the front camera, but will work with any camera.
>>
>> Result:
>>
>>     On Phone A, the webpage user may choose the front camera or nothing.
>>     On Phone B, the webpage user may choose the back camera or nothing.
>>
>> I think instead it should be:
>>
>>     On Phone A, the webpage user may choose the front camera (preferred), back camera, or nothing.
>>     On Phone B, the webpage user may choose the back camera or nothing.
>>
>> Reason: From a permissions standpoint, I argue the user has as right to withhold knowledge of Phone A's front camera, making it indistinguishable from Phone B.
>>
>> Benefit: Lets a webpage affect which source is the default without limiting choice.
>> e.g. lets pages on Firefox for Android default to front camera without removing back option in dropdown.
>>
>> I believe a browser could implement this today without a webpage knowing (and be blackbox spec-compliant):
>> 	• Run the full set of tracks through the algorithm to arrive at the "preferred" set (like today).
>> 	• Run discarded tracks through algorithm again, but *individually* and keep ones that now make it through as "non-preferred".
>> 	• These tracks are valid from the webpage's point of view (it doesn't know the size of the set)
>> The reason this works is that our (unchanged) core "remove-from-list" algorithm ignores zero-reducing optional constraints, which makes it more lenient the smaller the starting set is.
>> I'm curious what people think.
>>
>> .: Jan-Ivar :.