W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2017

Re: In defence of a motion sensor spec

From: Kenneth Rohde Christiansen <kenneth.christiansen@gmail.com>
Date: Thu, 09 Mar 2017 12:25:04 +0000
Message-ID: <CAEC208tyHS+-Xo6dLYesV2=dHWYpX9o_u_UgEwwnx0JoD-u9dw@mail.gmail.com>
To: tobie@sensors.codespeaks.com, public-device-apis@w3.org
Hi there,

I gave it a shot and wrote an explainer doc to the motion sensor subject,
thus an introduction to low-level and high-level motion sensors, their
relation, inner workings and common use-cases.

I attached it to this email, so if it doesn't get through for some reason,
please tell me.


On Tue, Mar 7, 2017 at 12:59 PM Kenneth Rohde Christiansen <
kenneth.christiansen@gmail.com> wrote:

> 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

Received on Thursday, 9 March 2017 12:25:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:37 UTC