Re: In defence of a motion sensor spec

> On 07 Mar 2017, at 02:09, Tobie Langel <tobie@sensors.codespeaks.com> wrote:

[...]

> ### In practice, what does it mean? ###
> First of all, as mentioned above, and similar to what's found in the
> generic sensor API, include an important introductory section to the
> spec that details key concepts and gives a high-level overview.
> 
> Secondly, provide a list of all primitive and fused sensors, probably at
> least partially in the form of a table, listing what primitive sensors
> fused sensors are composed of, the kind of data they're exposing, their
> strengths and weaknesses, and their use cases.
> 
> Thirdly, define a Sensor subclass these sensors would inherit from.
> Would it be specific to motion sensors? E.g. a MotionSensor interface?
> Or would instead sit in the Generic Sensor API and be defined by certain
> characteristics? E.g. a HighFrequencySensor interface. That's still TBD.
> But the intent is clearly to expose some dedicated APIs that are
> relevant to motion sensors, that meet the requirements we've been
> gathering in the different GitHub repositories (and that we hope to
> complete with more developer input), that can seamlessly handle BYOB
> (bring your own buffer) scenarios, multiple data formats (matrixes,
> quaternions, etc.) were relevant, and fine tune things like polling
> frequency, buffering, etc.
> Note this might also allow moving some of the features which seem not so
> relevant to motion sensors, and even potential foot guns, into a
> dedicated interface which other, non-motion sensors could inherit from.
> 
> Fourthly, fold in the gyro, accelerometer and magnetometer spec,
> expanding them in multiple types where necessary. For example, splitting
> up accelerometer (which included gravity) and linear acceleration (which
> doesn't because it filtered out on old devices, or fused out when a
> gyroscope is present) into two distinct types. Figuring out how to
> expose uncalibrated data where it opens up new use cases, etc.
> 
> Fifthly, specify all the key motion sensor fusions listed in 2) above.
> 
> Lastly, and perhaps most importantly, sprinkle all of the above with
> copious examples.
> 
> I hope the above has convinced you of the value and necessity to
> consider motion sensors holistically. I'm happy to discuss this further
> either in writing here on the list or on our call this Thursday.
> 
> Thanks for your time reading the above.

Thanks for writing all this down!

My thinking is we have two distinct audiences at play here with their own preferences and requirements:

* Browser implementers
* Web developers

Catering to both the audiences extensively in the same document may not work out (history lesson, but I'd be happy to be proven wrong).

The concrete specs at https://www.w3.org/2009/dap/#sensors are geared toward browser implements. They're concise, assume certain level of domain expertise. Granted, they're not good references for web developers or to be used as learning resources.
 
Couple of ideas:

* Start an explainer document for Motion Sensors (or "Motion Sensors for Web Developers" document) that bring together all the informative content in a form digestible to web developers. This doc would inform the normative spec work (because of Priority of Constituencies).

* Produce (semi-automatically) "Sensors Snapshot" document similar to https://www.w3.org/TR/css-2017/ updated as new concrete sensors emerge.

This would allow us make progress on the Rec Track on more mature concrete sensors as we keep adding new high-level motion sensors in the future.

Thanks,

-Anssi

Received on Tuesday, 7 March 2017 10:08:11 UTC