Re: Comments on DeviceOrientation Event Specification, Editor's Draft 24 August 2010

Thanks for the comments Claes.

> -          We propose a  boolean 'needsCalibration' property that indicates
> that the magnetometer needs calibration.
This seems reasonable to me. Unless there any objections, I'll add
this to the spec.

> -          In the current version of the specification the device
> orientation data is provided as Euler angles. However, there are other ways
> of providing sensor data. I looked at the following interesting
> presentation: http://www.youtube.com/user/GoogleTechTalks#p/u/0/C7JQ7Rpwn2k
> . At the end of the presentation different ways of exposing sensor data for
> developers are described. There are apparently limitations with Euler angles
> that occurs when the device is pointing right up, Gimbal lock,
> http://en.wikipedia.org/wiki/Gimbal_lock. Do you consider this limitation
> acceptable meaning that applications using the Device Orientation Event have
> to be constrained taking the Gimbal lock problem into consideration?
I'm aware of gymbal lock but I think that it's probably not a problem
in most applications. The use of Euler angles still allows us to
always express the orientation of the device. The only limitation is
that certain device motions will cause extremely rapid changes in some
of the angles and I think that for the simple use-cases for which the
API is intended, this shouldn't be a problem.

> So, have you considered to also provide orientation data as a rotation
> matrix?
We chose Euler angles rather than a rotation matrix as for simple
use-cases (such as determining the device's heading for a compass
application, or its tilt for a gaming application), they're easier to
work with. If we were to provide a rotation matrix, I think this
should be an additional property.

Personally, I'd prefer to leave this out, rather than increase the API
footprint with properties that can be computed with a JavaScript
library. If we see lots of user-feedback for this to be included
natively, we could consider adding it in a later version of the spec.

> -          As the attribute “acceleration” does not include the gravity
> component we propose to call it “linearAcceleration”.
I'm not sure why the term 'linear' would suggest anything about
whether or not gravity is included? Have you seen the latest version
of the draft spec, which provides both acceleration and
accelerationIncludingGravity? Is this sufficiently clear?

> -          It would be nice to have more examples on the Device Motion
> Event.
I've added a couple more. Feel free to suggest any further examples
you think would be helpful.

Thanks,
Steve

-- 
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
Registered in England Number: 3977902

Received on Wednesday, 1 September 2010 10:40:20 UTC