Re: Measuring the gap between the spec and browser implementations

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