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

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 don't like that. 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. 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.





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 :.
>

Received on Tuesday, 3 September 2013 19:47:56 UTC