Re: Visualising the geolocation API

Hi Rob, that's a nice demo, thanks for sharing. Some replies inline.

Regards,

Michael

On Mon, Mar 24, 2014 at 9:49 AM, Rob Manson <roBman@buildar.com> wrote:

> Hey,
>
> I think the list might also find one of our other recent projects
> interesting too and I'd really like to get your thoughts and feedback.
>
> We've recently released a Kickstarter project around our "Augmenting the
> Web" R&D (shameless plug - please back us here http://kck.st/1gnUJex). As
> part of that we've been working on all the key APIs and what we need to do
> to help convince users that the Augmented Web Platform really is as good
> as, if not better than native apps.
>
> One of the things we've found is that a lot of users still don't realise
> that browsers can track their location and even fewer can visualise how
> that works or how accurate it is. So we've created this demo that helps
> them do exactly that.
>
> https://buildAR.com/trackme
>
> We've found the easiest way to get people's attention is by starting with
> the privacy discussion, but once they start exploring this it opens up
> their mind to how this can really be useful too. People we've explored this
> with seem very aware that mobile apps can track them and also that the web
> can easily show local information. But many don't seem to make the
> connection with web based tracking and more accurate data like that
> required for AR.
>
> In this demo we use a mixture of getPosition() and watchPosition() and
> visualise lat, lon and accuracy. We haven't really used heading or speed,
> etc...yet.
>
> However, we have noticed a few small issues through all of our testing and
> evaluation with users. You can clearly see that the different devices have
> very different warm up processes after the watchPosition() is setup. But
> more interestingly, the behaviour across different browsers on the same
> device is also quite different. Especially around initial response and
> frequency.
>
> We've also noticed some peculiarities around the corner cases when
> permission is denied.
>
> As discussed earlier on this list this process is really very different
> for each different browser. I really like the Chrome feature on Android
> that lets you find the specific websites you've given permissions to and
> re-allow/deny this. But this is really hidden inside Settings -> Content
> Settings -> Website settings which is cryptically sitting just below
> Location Settings in the menu 8) Does anyone know if there's a quick way to
> access this directly from the page level?
>

Afaik there is not currently a faster way to these settings on Chrome on
Android (I work on this project). On desktop, there is an icon inside the
url bar that gives one-click access to these settings. The most obvious
challenge here is that there is so little screen real estate on mobile
devices, so some things are behind more clicks.


> When Location permissions are turned off globally at the Android OS
> Location Settings level then all the browsers seem to act accordingly. But
> both Firefox and Opera then throw the permission prompt again and if you
> allow this they seem to provide location data while leaving the OS level
> Location Settings off. This seems very confusing 8/
>

You could file bugs for these browsers. You'll probably get a more focused
discussion that way.


> We've also noticed that some browsers both on the PC and Android throw
> empty error objects. So all you get is {} with no {code:?} value or
> anything else. Is this a bug we should bother tracking down?
>

That sounds like a bug to me. The spec is quite clear: "If the attempt
fails, the errorCallback must be invoked with a new PositionError object,
reflecting the reason for the failure."

And the attributes of the PositionError interface are not optional:

[NoInterfaceObject]
  interface PositionError {
    const unsigned short PERMISSION_DENIED = 1;
    const unsigned short POSITION_UNAVAILABLE = 2;
    const unsigned short TIMEOUT = 3;
    readonly attribute unsigned short code;
    readonly attribute DOMString message;
  };

The best way to get this fixed is to file bugs with the relevant projects.


>
> On iOS Safari there doesn't seem to be any way to control permissions at
> the site level - only the global settings for Safari in the OS Location
> Settings. iOS also suffers from the constraints of web browsers not being
> able to run in the background too.
>
> Other than that the overall accuracy of devices and browsers seems to be
> significantly better than similar testing we did just over a year ago. So,
> just like DeviceOrientation it seems like this API is definitely ready for
> primetime and we're really happy using it in our Augmented Web applications
> 8)
>
> I'll look forward to hearing any feedback you have.
>
> roBman
>
>