Re: FPWD of Pointer Lock 2.0

On Fri, Apr 28, 2017 at 6:59 PM, Vincent Scheib <scheib@google.com> wrote:

> My suggestion is to use something other than ESC to exit pointer lock via
> javascript, and thus not exit fullscreen. E.g. the 'f' key, '~', space bar,
> 'q', etc.
>

You cannot override ESC, and the UA informs the user that to regain his
cursor, he should press ESC. It's inevitable that the user will actually do
so, since he's told to do so. From an UX point of view, designing an info
box explaining to the user to avoid pressing ESC (and ignore that other
info box), because that may not be what he wants to do, and instead press
another key, while another info box is hovering on screen telling him to
press  ESC sounds really bad, but I'm not expert, so... why don't you ask
an UX expert how confusing that will be to a user?


> The reason ESC was specified to exit both was to satisfy concerns of users
> not knowing how to exit these features. The concept of stacking the
> permissions adds conceptual complexity.
>
> Essentially, we believed there would be many users confused by a page
> entering both fullscreen and pointer lock, wanting to get out, trying ESC
> and not having fullscreen exit. They barely understand that pointer lock
> was also entered and is now exited. They may not understand the difference
> between an application drawn cursor and the now visible system cursor. They
> may not think to keep repeating pressing ESC.
>

Here's an example of a game (counter-strike) coming from a first-person
control to using a pointer based modal to operate a menu and then go back
to the first-person control: https://youtu.be/u8YbYBZtbAs?t=442 . The menu
is triggered by the key B. However counter-strike does not have to deal
with the fact that whenever a user returns from the menu to the
first-person view, that a black box is drawn over their viewport informing
the user to press ESC...