- From: Tim Volodine <timvolodine@google.com>
- Date: Tue, 11 Feb 2014 14:35:59 +0000
- To: Rob Manson <roBman@buildar.com>
- Cc: public-geolocation@w3.org
- Message-ID: <CAJv4RS0tdidYemJuTu_=M-fVzr-t3a7dknLK7K5gvFttCWAbgA@mail.gmail.com>
Hi Rob, I think your input is very valuable as you actually built something using the existing API :). It would be great if you could send us some pictures/3D models you have that you think would clarify the specification. Was there anything in particular you would like to see improved in the current specification aside from visual examples? Regarding Quaternion representation I think it would be good to have more justification for it's inclusion in the specification. Euler angles have known issues (at least theoretically e.g. gimbal lock) and were more or less abandoned in Android in favor of the quaternion representation. It is not clear though if this would be a useful addition for developers in Chrome. This may probably be worth a survey actually ;). Tim On Tue, Feb 11, 2014 at 4:38 AM, Rob Manson <roBman@buildar.com> wrote: > Hey guys, > > really glad to hear that you'll both be taking on the co-editing of this > spec! 8) > > If there's anything I can do to help please let me know. We'd definitely > be happy to contribute feedback on the javascript examples and we also have > a range of animations and 3D phone models already setup that could easily > be used to visually annotate the spec. > > In terms of enhancements I think there's two key areas that would be good > to look into. > > First, it would be great if the API also supported data in a format other > than just Euler angles. e.g. As a Quaternion and/or a Rotation Matrix. > NOTE: On the topic of Quaternions, I also found this interesting post > linked from inside some of the three.js documentation > http://www.gamedev.net/page/resources/_/technical/math- > and-physics/do-we-really-need-quaternions-r1199 - but I'm sure you guys > know a lot more about this topic than I do. > > Second, the "original orientation" point that Rich raised a few weeks ago > would be great to clarify. If different devices provide a different > reference frame then we will end up back in the same "confused UX" > situation we have been in recently 8( > > Also, it seems that the latest Firefox Beta on Android now implements the > spec more accurately so we've removed the special code fork we had for that > now. So this means we just need to remove the jumpiness from the Opera > implementation and then the three leading browsers on Android are all in a > workable state - w00t! > > roBman > > > > On 3/02/14 9:11 AM, Rich Tibbett wrote: > >> Hi Tim, Dom, >> >> On Fri, Jan 31, 2014 at 3:16 PM, Dominique Hazael-Massieux <dom@w3.org> >> wrote: >> >>> Hi Tim, >>> >>> On ven., 2014-01-31 at 13:30 +0000, Tim Volodine wrote: >>> >>>> I would also be willing to co-edit the Device Orientation/Motion >>>> specification. I have played a major part in implementing Device >>>> Motion in Chrome, as well as making sure that our Device Orientation >>>> implementation properly matches the specification. >>>> [...] >>>> I believe Rich Tibbett from Opera also expressed interest in being an >>>> editor. I would be happy to edit the specification together. >>>> >>> Indeed, Rich has separately indicated interest on editing that spec; >>> >> Yes. I would be happy for us to tackle this together. >> >> In terms of my own background, I tested the original device >> orientation implementation in Opera Presto. I have also written a few >> orientation-based web-apps and I have also previously edited other W3C >> specs. >> >> while we go through the chartering administrativia, I think it would be >>> great if you guys could start bringing edits based on the recent >>> discussions. Tim, do you already have write access to dev.w3.org where >>> the spec is currently hosted? >>> ( http://dev.w3.org/cvsweb/geo/api/spec-source-orientation.html ) >>> >>> [it might also be that Rich and you would determine you'd rather edit it >>> on github ] >>> >> I like the idea of doing this on Github mostly for its ability to >> track pull requests via its web interface. Doing this on Github may >> also come in handy for getting wider input from developers (e.g. for >> obtaining [ bug fixes / feedback / more JavaScript-based API examples >> ] for the spec). >> >> - Rich >> >> >
Received on Tuesday, 11 February 2014 14:37:20 UTC