Re: In defence of a motion sensor spec

Having looked into the problem domain for a while now, I agree. There are
no real good resources or books explaining how all these sensors work
together, it is all very thinly spread out, with some mention to low and
high pass filters, Kalman, complementary filter etc here and there. I even
reached out to some of the Android experts who have written about this
before and their knowledge seemed superficial at best.

Having written code doing actual fusion, I now have a much better
understanding, but this has taken quite a while and most developers don't
have the luxury and time to dig so deep into that area as I have done.

I think that a well written introductory part would be very beneficial and
the information would cascade down into articles written around the
subject, and that will benefit the web community (though not limited to) as
a whole.

I will happily help Tobie with this, and I also think it makes a lot of
sense having all the motion sensors in one spec.

Cheers
Kenneth

On Tue, Mar 7, 2017 at 12:15 PM Tobie Langel <tobie@sensors.codespeaks.com>
wrote:

> > 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).
>
> Both audiences seem to completely lack domain expertise, so I think this
> should prove highly beneficial to all involved, myself included. :)
>
> The feedback for the introductory part to the generic sensor spec was
> quite positive, so I'm willing to give this a try and fold it out into
> an explainer doc if necessary.
>
> > 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.
>
> I think the explainer doc is only a very small part of the reason why
> having these specs defined together is important. And these reasons
> still stand whether or not the explainer part is spec-contained.
>
> If the only concern with this approach is W3C process, we can figure out
> ways around that as needed, but we certainly shouldn't let that dictate
> how and what we deliver. In the priority of constituencies, editors are
> at the bottom of the pile. So is the process by which they get
> organized.
>
> --tobie
>
>