- From: Rich Tibbett <richt@opera.com>
- Date: Mon, 20 Jan 2014 16:17:18 +0000
- To: Rob Manson <roBman@buildar.com>
- Cc: public-geolocation <public-geolocation@w3.org>
On Mon, Jan 20, 2014 at 8:36 AM, Rob Manson <roBman@buildar.com> wrote: > Hi Rich, > > thanks for the feedback. Thank _you_ for kicking off this thread. > > >> FYI, I previously raised this issue on this list @ >> >> http://lists.w3.org/Archives/Public/public-geolocation/2012Jun/0000.html > > > Wow...that is going back a bit 8) Let's pick this up again. The previous thread seemed to get off-track quickly but there's obviously a lot to discuss here still. Also, see the bottom of this email for additional considerations we should discuss. > > > >> In that email I proposed a series of (manual) tests that could be used to >> check the calibration of device orientation across vendor implementations. > > > I'd love to work with you and the WG to formalise this test approach > further. We'd be happy to perform tests across all the mainstream browsers > on multiple devices and capture all the results along with photos of the > devices. Sounds very useful. I don't think the user agent calibrations I reported back in 2012 are all still applicable (though perhaps most are) and up-to-date calibration would be more reliable and useful. > > And it would be great to get these test repeated on a larger scale across > many users too. > > We've had three ideas around this. > > 1. Create an open source hardware rig that rotates devices through a > pre-defined set of poses. This could be paired with a simple test page that > also captures the resulting data throughout so the output can be validated. > > 2. In order to also test the DeviceMotion API we were thinking of getting > the worldwide drone community to repeat the same type of tests using drones > in different locations flying through pre-defined flight plans and logging > the data against calibrated sensors onboard. This has some limitations but I > think it could really capture a lot of people's imagination. > > 3. See our pairing app below. > > But perhaps just starting with your proposed desk-based tests could be > simpler to get started 8) Well, everyone has a desk :) > > Either way...I think a global "calibrate the web" day could deliver great > benefits to everyone involved. Sounds interesting and further thoughts or ideas on this would be good to share. > > >> I coded up an in-browser 3d compass implementation that could act as a >> useful calibration test for Device Orientation implementations @ >> >> https://github.com/richtr/Marine-Compass > > > I've seen this example...nice compass 8) > > >> That implementation is based on the calibration of Device Orientation >> found in Opera Mobile 12.1 which was implemented according to the >> calibration described in the draft Device Orientation spec. Opera Mobile >> 12.1 is available as a download from >> http://www.opera.com/mobile/download/versions/ in case you want to test this >> out :) > > > I'll definitely test our demos against Opera now too 8) As a side not, the Marine Compass currently _only_ works in Opera Mobile 12.1 and no other user agents. That's sort of why we're having this conversation in the first place I guess ;) > > > >> I think the specification could benefit from more visual feedback to >> developers (e.g. photos, diagrams and/or spatial graphs/charts would be very >> helpful) to understand how device orientation values should return as a >> device travels through a series of selected reference planes. > > > We'd be happy to provide 3D animations of common devices moving through > known poses and relating them to what the specified values should be. We > also have a websockets based mobile/pc paired app that could present this to > make it much easier for developers to understand what's going on. You > basically load a web page on your PC and then load the same page on your > mobile device to pair the two. Then you see a 3D representation of your > mobile device and what it's current pose should be - so you can easily and > visibly compare it to how the device is actually oriented. > > If you and the WG think this would be useful just let me know. That would be great but also I'd be happy to the low-tech photo approach. "Take a reading and record the orientation of the device via a photo" would be good. During alpha tests, perhaps we recommend testers capture the reading from an independent compass alongside their photo snapshots. > >> It may be worth revisiting that thread in relation to your research. >> >> Thank you for posting your findings. > > > No problems at all. This really is a deceptively complex topic 8) To really mix things up, one additional problem is deciding what the default screen orientation of a device is 'at rest' (when held 'upright'). Some e.g. tablets may be manufactured as being landscape by default with the option of rotating the screen to portrait mode. Other devices may be, by default, 'at rest' in portrait mode and the screen can be rotated to landscape by the user. In such situations, if one user attempted to calibrate deviceorientation from a portrait mode 'at rest' while another attempts to calibrate the deviceorientation of the same device from landscape mode 'at rest' then we're going to end up with conflicting and confusing data per device. This is not just a confusion for users. Some device manufacturers calibrate their internal sensors in the landscape mode while others calibrate them in the portrait mode. Knowing which is which is going to take some digging and experimentation and then some outreach to explain in what orientation each type of device should be considered 'at rest'. I wonder whether it makes sense for the deviceorientation spec and user agents to auto-compensate for screen rotations. If the screen display itself rotates automatically from portrait-to-landscape or vice-versa as the user turns their device, what values should deviceorientation report back? Should it now assume that the current device orientation is now the 'at rest' position or continue to maintain the coordinate system that was being used from the previous 90 degree rotation but with a bearing that no longer matches the provided coordinate system? An auto-compensatory model would be a major simplification of this API for developers and would solve the 'which way is the device upright at rest' problem explained above. Further to that, if a screen lock is set on the device and the screen itself does not rotate as the user turns their device 90 degrees as it faces them then perhaps no change to deviceorientation calibration would be required. In a nutshell, it's complicated to know the default way to hold some devices 'at rest', easy to get confused as a developer as the screen display itself rotates and developers need to manually rewire the orientation axis for the orientation change and there's not too much in the specification that discusses those factors. But these are perhaps still all secondary concerns since we can't even get our basic implementations to point in the same directions yet :/ Complex indeed. - Rich
Received on Monday, 20 January 2014 16:17:46 UTC