Intent to Experiment: Generic Sensors

258 views
Skip to first unread message

Mikhail Pozdnyakov

unread,
Aug 18, 2017, 6:55:47 AM8/18/17
to blink-dev

Contact emails

mikhail.p...@intel.com, anssi.ko...@intel.com, alexander...@intel.com


Spec

https://w3c.github.io/sensors/

https://w3c.github.io/accelerometer/

https://w3c.github.io/gyroscope/

https://w3c.github.io/orientation-sensor/


Summary

The Generic Sensors API is a framework for adding sensor devices to the web platform in a consistent way. We intend to experiment with the Accelerometer, LinearAccelerationSensor, Gyroscope, AbsoluteOrientationSensor and RelativeOrientationSensor interfaces which are are replacements for the DeviceMotionEvent and DeviceOrientationEvent interfaces.


Link to “Intent to Implement” blink-dev discussion

Intent to Implement: Generic Sensor & Ambient Light Sensor APIs

Intent to implement Accelerometer, Gyroscope and Magnetometer Sensor APIs


Goals for experimentation

The goal for this experiment is to gain developer feedback on the shape of these new sensor APIs. As there are ongoing discussions around the security and privacy implications of adding new and higher resolution sensor APIs to the web platform we are currently not seeking to experiment with sensor types which are not already exposed by an existing API.


Experimental timeline

Currently targeting M-62 to M-65.


Any risks when the experiment finishes?

Sites who were using these new interfaces will have to switch back to the older events.


Ongoing technical constraints

None, except for platform sensor availability as documented in the next section.


Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

This feature will be supported on all five Blink platforms, however sensor availability varies by platform. The current state of platform support for various sensor types is documented in //services/device/generic_sensor/README.md


OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=750018


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5698781827825664


BR,

Mikhail

Philip Jägenstedt

unread,
Aug 23, 2017, 7:35:28 AM8/23/17
to Mikhail Pozdnyakov, blink-dev
This looks like a great set of APIs, but I wonder about the goals for experimentation. I went to https://www.chromium.org/blink/launching-features for guidance and this in particular caught my attention: "Is there a reason that this API needs to be deployed to real users, rather than behind a flag, for data to be meaningful?"

Running an experiment isn't a necessary step to ship, so if you could get the desired feedback without an experiment, you might end up shipping sooner, perhaps much sooner. Is there anything beyond such feedback that you think is blocking an Intent to Ship?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9b4d1602-059e-4e67-969c-fbe8212dd2e5%40chromium.org.

Reilly Grant

unread,
Aug 24, 2017, 4:48:12 PM8/24/17
to Philip Jägenstedt, Mikhail Pozdnyakov, blink-dev
Mikhail may join in with other blockers but my feeling is that by other metrics there is little blocking an Intent to Ship. The implementation is well tested and the spec has a positive review from the W3C TAG.

This new API is designed to be a replacement for the existing device orientation and motion events and to be as forward-looking as possible about additional types of sensors we could add to the platform. I think given this opportunity we should be particularly careful about choosing the right API shape so I don't feel the need to move quickly. I would rather ship the right API in 3 milestones after evangelising the Origin Trial and collecting feedback than get approval to ship now something that looks good on paper but turns out to be awkward to use in practice.

Mikhail Pozdnyakov

unread,
Aug 25, 2017, 3:16:31 AM8/25/17
to blink-dev, mikhail.p...@intel.com

Hi Philip,


Thanks for your question!


I agree with Reilly that we should be careful about choosing the right API shape.


The goal of experiment is to gather feedback on current API usability. The Origin Trial feedback (questionnaire) would help WG to make important decisions about Generic Sensor API development, for example to decide whether we need to:

  • Expose sensors to service workers

  • Provide sensor readings at higher rates (>60Hz)

  • Allow changing sensor options after construction (e.g., frequency)

  • Provide solution for synchronization of sensor and screen coordinate systems

  • Improve sensor features detection

  • Provide better mechanisms for the Sensor interface extensibility

  • Clarify whether we need granular permission tokens for orientation sensor classes

  • Provide new sensor types and/or options (e.g. accuracy)


BR,

Mikhail

Philip Jägenstedt

unread,
Aug 28, 2017, 10:28:44 AM8/28/17
to Mikhail Pozdnyakov, blink-dev, cha...@chromium.org
Thanks Reilly and Mikhail, sounds like an immediate Intent to Ship would be a bit hasty, so let's table that idea.

It sounds like running an Origin Trial might result in web developer feedback you wouldn't otherwise get, even though testing on real users isn't part of the reason. That seems OK with me, but I'd like to hear what +Jason Chase thinks as well. Must an experiment have a clear hypothesis to test, or is it OK to run an experiment and see what happens?

Jason Chase

unread,
Aug 28, 2017, 10:59:56 AM8/28/17
to blink-dev, mikhail.p...@intel.com, cha...@chromium.org
To Philip's question, ideally there would be a clear hypothesis for every experiment. That hasn't been a hard requirement for past trials, and we have run similar trials that took a more free-form approach to getting feedback. I think the goal to gather developer feedback on the current API shape and ergonomics are definitely in line with the appropriate uses of an origin trial.

Generally, the origin trials team looks to consult on potential trials prior to the Intent to Experiment, in part to help with questions like these. As well, we're continually trying to improve the overall process, and especially the quality of data collected.

I'll start a separate thread with the Generic Sensor folks, to see if we can help ensure they get the data desired from the origin trial.

Thanks,
Jason

Philip Jägenstedt

unread,
Aug 28, 2017, 12:48:20 PM8/28/17
to Jason Chase, blink-dev, mikhail.p...@intel.com

Thanks Jason, and LGTM for this experiment in whatever form it takes.


Mikhail Pozdnyakov

unread,
Aug 29, 2017, 10:11:41 AM8/29/17
to blink-dev, cha...@chromium.org, mikhail.p...@intel.com
Thank you Philip for the discussion and approval!

We're looking forward to email from Jason and in the meantime preparing Generic Sensor blog post for https://developers.google.com/web/updates.

Mikhail Pozdnyakov

unread,
Oct 4, 2017, 7:58:51 AM10/4/17
to blink-dev
The updated Experimental timeline for the experiment is M-63 to M-65.

BR,
Mikhail
Reply all
Reply to author
Forward
0 new messages