Re: Sensors API - Motion

Hi,

This doesn’t sound like a great idea IMHO. Native APIs have them separated and I think it’s for a great reason. They provide different type of data which may or may not be useful together depending on what you try to achieve. You have devices not shipping without an Accelerometer (yet they provide you orientation events with some other way) so that means that the API would look broken in some way. What I should return as a property value when I can’t get it from the given sensor : 0 which is semantically incorrect (you can have 0 x, y acceleration value for example).

As an implementation point of view it seems inefficient to pull the data from the accelerometer if nobody uses what you call translateX, Y, Z. This has impact on battery life for example. The naming also gives me issue, accelerometer values doesn’t stick with Orientation IMHO, especially when writing a game and using the motion sensors as controllers.

Thanks.

On Nov 23, 2016, at 7:56 PM, Felipe Nascimento de Moura <felipenmoura@gmail.com<mailto:felipenmoura@gmail.com>> wrote:

Hello.

I have two things to discuss about the Sensors API. (will send them in two different e-mails).
Here goes the first:

Motion capabilities
I've tested and played around with Tango Project from Google, and it is quite impressive, very accurate and so far, very reliable.
They are focused on Java and Unity and I was talking to them about a move for the Web. It is in their roadmap...but there is nothing defined up to now.
My suggestion is (as simple as possible):

`simply add motion to Device Orientation API`

This way:
window.addEventListener("deviceorientation", handleOrientation, true);

Would provide us an object with:
- absolute (for orientation),
- alpha, beta, gamma (for rotation),
- translateX, translateY, translateZ (for movement/navigation)

I believe that, with that addition (from devices that do have support for those sensors) Web Developers would already have enough power to create A TON of things involving WebGL, Canvas, SVG and even regular HTML pages and CSS.

Note that translate(X/Y/Z) would be relative to the position in the starting point (set as 0, as soon as the page becomes interactive).
They would be expressed in inches.
Values for translateZ are positives when motion is toward the backface of the device (in its starting point).
Values for translateY are negative when moving down and positive when moving up (in relation to its starting point).
Values for translateX are negative when moving left and positive when moving right (in relation to its starting point).

I'm not sure how far have the discussions gone by now, about these new sensors, but I think we should be ready for them (as they are, actually, already here in some devices).
As this platforms and tools evolve, I see a web API approach as something fundamental.

I see implications for this in devices like watches, glasses, cellphones and tablets in a very near future.

Please let me hear your thoughts about it.
Thanks.

--

Felipe N. Moura
Web Developer, Google Developer Expert, Founder of BrazilJS<https://braziljs.org/> and CTO at Nasc<http://nasc.io/>.

Website:  http://felipenmoura.com<http://felipenmoura.com/> / http://nasc.io/

Twitter:    @felipenmoura<http://twitter.com/felipenmoura>
Facebook: http://fb.com/felipenmoura

LinkedIn: http://goo.gl/qGmq

---------------------------------
Changing  the  world  is the least I expect from  myself!