Re: Allow ... centralized dialog up front

On Wed, Feb 6, 2013 at 2:09 AM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> **
> This may be true. But pointer-lock is an example of something that needs
> the entire UX to be thought through. simply switching from one to the other
> without the user knowing is also poor UX, since it risks making the user
> think their system is broken. Add to this a user working with e.g.
> mousekeys, or a magnifier at a few hundred percent plus high-contrast.
>
> The problems are not simple, and it is unlikely the solutions will be
> either. Ian's claim that everything can be done seamlessly without making
> it seem like a security dialog may be over-confident, and as Robin points
> out the first UI developed (well, the second actually) might not be the
> best approach in the long run, but it is certainly the direction we should
> be aiming.
>
This particular problem is exceedingly simple.

A pointerlock can be used in two ways: #1 it can be used to permanently
lock the pointer until the user escapes it (by esc or other means). That is
a model well suited for games. #2 A pointerlock has uses besides games
(such as controlling viewports, value input controls, high precision color
selectors, etc.) mainly found in productivity applications. Permanently
locking the pointer would require the user to explicitely initiate an exit
of pointerlock whenever he wants to use the mouse outside of the
productivity application. That is the antithesis of "productive".

The current pointerlock request model has progblems for usecase #2
- The dialog to enable pointerlock is only presented at first use. First
use was trying to drag something, which will always fail under that
circumstance.
- The users attention was anywhere but at the top of the browser for
notifications, the permission dialog to enable pointerlock often goes
unnoticed
- Triggering the pointerlock dialog up front is impossible since it has to
be the result of a user interaction

Usecase #2 is not broken, per se. But it does require a prospective web
application developer to put in his own up-front dialog explaining how the
browser is broken and what series of incantations and buttons the user has
to push, to operate the black box (the browser) so it works. This in short
is the antithesis of UX. You find yourself explaining how to do something
awkward in order to make things work, rather than doing something not
awkward.

I suspect that similar issues can be found in a lot of the extended
permissible functionality where one usecase works fine with whatever
paradign happens to be currently implemented, but others lead to a
cul-de-sac of having to do awkward things without any way to make them not
awkward.


> So where are we? The "single up front dialogue" doesn't work. We know
> that. Mutliple contextual requests go from being effective to being
> counter-productive at some magic tipping point that is hard to predict.
>
> To take an example, let's say I have a chat application that can use
> web-cam and geolocation. Some user agents might decide to put the
> permissions up front when you first load the app. And some users will be
> fine with that. Some will be happy to let it use geolocation when it wants,
> but will want to turn the camera on and off explicitly (note that Skype -
> one of the best-known video chat apps there is - allows this as a matter of
> course. I don't know of anyone who has ever complained).
>
> Some "app stores" might refuse to offer the service unless you have
> already accepted that you will let any app from the store use geolocation
> and camera. Others will be quite happy with a user agent that (like skype -
> or Opera) puts the permissions interface in front of the user to modify at
> will. And there are various other possible configurations.
>
> At any rate, having a way of declaring the things that will be requested
> (as I mentioned a zillion messages ago, most platforms have implemented
> this somewhere, sometimes several times) would at least simplify the task
> for implementors of deciding which approach to use, or how to blend the
> various different possibilities.
>
I agree with this, and just to clarify it, again.

Browsers stand no chance to do anything about these really difficult UX
issues without a better API that is not that is not locked into one
particular UI idea of piecemeal accumulation of permissions.