W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2017

Re: FPWD of Pointer Lock 2.0

From: Vincent Scheib <scheib@google.com>
Date: Fri, 28 Apr 2017 11:00:34 -0700
Message-ID: <CAK-EfXnqRnAebYy7KevFaCDW-ST9=UVNce3-CHSt9_vpVTp+Tw@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Léonie Watson <tink@tink.uk>, public-webapps WG <public-webapps@w3.org>
My proposal for today is to use other buttons. I'm aware of the common game
paradigm of ESC exiting games. I've played plenty of counter strike, ;) but
we also needed a reliable unlock gesture.

My implementation in Chrome does not re-show The ESC instructions when a
page calls exitPointerLock and then requestPointerLock again - specifically
to avoid the nuisance you mentioned.

Keyboard Lock, if it progresses, will offer applications & games the
ability to override taps to ESC key (the user agent will use a sustained
hold of ESC to force exit). See linked explainers and spec drafts here:
https://www.chromestatus.com/feature/5642959835889664


On Fri, Apr 28, 2017 at 10:41 AM, Florian Bösch <pyalot@gmail.com> wrote:

> ESC is actually a common key to trigger a menu in many games, and it
> usually does not mean exit fullscreen.
>
> On Fri, Apr 28, 2017 at 7:38 PM, Florian Bösch <pyalot@gmail.com> wrote:
>
>> 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...
>>
>>
>>
>
Received on Friday, 28 April 2017 18:01:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:42 UTC