changing "ever had a user gesture" to "ever had a click"?

[Ojan Vafai]

Today, we use the same user gesture logic for regular user gestures and the "has this frame every had a gesture" logic. I'm starting to wonder if instead we should change the latter to be more specifically whether the frame has ever had a *click*.

Restricting to clicks means that a frame can't force the bit when a user tries to scroll by preventDefaulting the touchstart. For vibrate, autoplay video, top-level nav by sub-frames, this would make restrictive in a way that makes a better user experience without breaking important use cases.

We could instead make it so that user gestures in general required clicks, but that cuts out what seem like pretty reasonable use cases to me (e.g. swipe up to fullscreen).

The "ever had" bit enables a feature on the page that isn't then tied to a gesture for the rest of the life of the page. But regular user gestures can only be used for one gesture consuming event and future things need new gestures. Concretely, we need you to interact with a frame to be able to vibrate, but we don't required you to interact every time we need a vibrate. On the other hand, we do require that every time you want to fullscreen or open a popup.

WDYT?

[Rick Byers]

Sorry for the delay (finally getting to the last of vacation e-mail).

It's an interesting question.  I'm concerned that trying to achieve interoperability (and so solid spec coverage) of "triggered by activation" is going to be pretty hard as it is without splitting the definition of "triggered by activation" into two separate concepts.  Personally I'd prefer we try really hard to make a single definition work before adding the complexity of two different ones.  Perhaps that means giving up on the "swipe to go fullscreen" scenario for now (until there's really strong evidence that people need it) or it means accepting (temporarily) the risk that someone will get vibration etc. permission by disabling scrolling.  Note that we still have some ideas around mitigating the risk of the latter - eg. control over disabling vertical scrolling within iframes.

Big picture, I'm sure there are better things we could do in Chrome, but my impression is that our efforts should be focused on getting something that works well enough across all browsers here....

[Ojan Vafai]

There are three competing constraints for user gesture interventions:

1. Getting the best user experience. I think this clearly requires not granting user gestures for touch (i.e. only doing it for touches that are clicks).

2. Providing the richest platform. This requires swipe gestures granting user gestures.

3. Providing an interoperable platform. This requires having something simple enough that all browsers can easily implement the same behavior.

I think we should not compromise on #1 (which we are doing today). So that leaves compromising on either #2 or #3. I don't feel strongly about which we do. We can always find ways loosen it up in the future, e.g. by doing my original proposal of having the ever-had-a-gesture and currently-has-an-active-gesture logic diverge.

Although, converging both of them on requiring a click has some backwards compatibility risk that just changing ever-had-a-gesture to use click doesn't since the latter only just recently shipped.

What's the right next step?

[Dru Knox]

I would say that we should compromise on #2 from Ojan's analysis. I think it's better to start from a base of interoperability and low user annoyance, adding capabilities as necessary. Are there many instances of "drag-to-fullscreen" style UX in the wild? If so maybe we should pursue a separate API now, otherwise wait for more demand for that capability?

Do we have an estimate of how much backwards incompatibility there will be?

--
You received this message because you are subscribed to the Google Groups "Intervention Dev (Public)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.
To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTschNJ-2MZ%3D%3Dw%3DpTcLoLHELZHXd2NRoJ8xxjRgHzmffZg%40mail.gmail.com.

[Ojan Vafai]

The common UI is a drag-based toggle button that you see as the default on mobile UIs instead of checkboxes. If you were trying to control something that required a gesture with one of these toggle buttons, you wouldn't be able to.

I actually can't think of anything we currently restrict to requiring a gesture that would want a toggle button UI though, which is why I came up with the fictitious swipe to fullscreen example. :) Although, I don't have the complete list of things we restrict in my head. I believe +Rick Byers has a list of things we gate on user gestures somewhere.

I think my concern is more around swipe-based UIs we haven't thought of yet than existing content.

Like I said, I'd be fine with any compromise here except status quo where we compromise on user experience. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAJcfO44fMj-zQrBdZ1cgPxhCUjhfUq4ScWmnguniPczSrgmg_A%40mail.gmail.com.

[Elliott Sprehn]

Lots of permissions are toggle switches, so something like "Allow access to contacts" would be a switch UI and would likely need a user gesture. I believe it's an accident of time that the geolocation one doesn't, though so many sites depend on that I don't think we can change it.

Another example might be: http://media.idownloadblog.com/wp-content/uploads/2014/08/iOS-Permission-Handling-1024x904.jpg

where you're toggling microphone access?

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-dev+unsubscribe@chromium.org.

To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTschNJ-2MZ%3D%3Dw%3DpTcLoLHELZHXd2NRoJ8xxjRgHzmffZg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Intervention Dev (Public)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-dev+unsubscribe@chromium.org.

To post to this group, send email to interven...@chromium.org.

[Anirudh Mohan]

I think seeing the list of things we gate user gestures on would help. 

Re: specifically the drag-based toggle buttons, aren't they usually implemented such that they can be toggled with a click as well? I was under the impression that users typically had a choice between swiping and clicking.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.

To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTschNJ-2MZ%3D%3Dw%3DpTcLoLHELZHXd2NRoJ8xxjRgHzmffZg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Intervention Dev (Public)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.

To post to this group, send email to interven...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAJcfO44fMj-zQrBdZ1cgPxhCUjhfUq4ScWmnguniPczSrgmg_A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Intervention Dev (Public)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-d...@chromium.org.

To post to this group, send email to interven...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAO9Q3iLOEPu%2BicWQFZFAkA3-4-V9krckSH3Mh8pxLY1mHs0k5Q%40mail.gmail.com.

--

Ani Mohan | Chrome

[Mounir Lamouri]

Should we consider two different concepts? For vibration and autoplay, we could introduce a concept of "meaningful interaction". In other words, the user interacted with the page in a manner that should allow the page to behave in ways that could be considered harmful/spammy. Typically, if a user reaches a page, it is quite annoying if it starts to vibrate and make sound as soon as they simply touch their screen. However, if they click on a button, a link or something else, it is a signal that the page can use these features. We could allow the current hacks but especially for autoplay, it would be very easy for websites to work around the restrictions as the type of use cases we try to avoid is in a grey area contrary to vibration that is fairly black and white.

-- Mounir

[Mustaq Ahmed]

Does replacing the "ever had a click" idea with "ever consumed a gesture" ease the cross-browser implementation concern? It seems to solve the use-case Mounir mentioned, and the implementation shouldn't be very different from Ojan's ever-had-a-gesture proposal (literally an enhancement "by a bit" without the possible expiry-time).

Not sure if this additional bit could possibly complicate the spec work (vs the spec for ever-had-a-gesture).

-- Mounir

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-dev+unsubscribe@chromium.org.

To post to this group, send email to interven...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CANMdWTschNJ-2MZ%3D%3Dw%3DpTcLoLHELZHXd2NRoJ8xxjRgHzmffZg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Intervention Dev (Public)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-dev+unsubscribe@chromium.org.

To post to this group, send email to interven...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/intervention-dev/CAJcfO44fMj-zQrBdZ1cgPxhCUjhfUq4ScWmnguniPczSrgmg_A%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Intervention Dev (Public)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to intervention-dev+unsubscribe@chromium.org.

To post to this group, send email to interven...@chromium.org.