Comments on: Geolocation Redux and a JS Library http://www.azarask.in/blog/post/firefox-geolocation-js-library/ -- aza | ɐzɐ -- Mon, 22 Mar 2010 09:33:51 +0000 http://wordpress.org/?v=2.6.5 By: eldemia http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-2727 eldemia Tue, 14 Oct 2008 08:41:58 +0000 http://azarask.in/blog/?p=55#comment-2727 Занимаюсь дизайном и хочу попросить автора www.azarask.in отправить шаьлончик на мой мыил) Готов заплатить... Занимаюсь дизайном и хочу попросить автора http://www.azarask.in отправить шаьлончик на мой мыил) Готов заплатить…

]]> By: Jeffrey Morgan http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1531 Jeffrey Morgan Wed, 11 Jun 2008 09:35:32 +0000 http://azarask.in/blog/?p=55#comment-1531 If you only have the lat/long then you can still form a rough address. One can work out the city from a lat/long which would then give the country. If the lat/long is in the woods, a desert, or some other place not near a city, then the lat/long still gives the country, which the browser can then present as a simple “Nothing” or “USA” choice (if the user in the USA). The browser can only present the location information that it has available. The user interface for the scale must be flexible, which is why I believe an address-based scale is more suitable. We are all used to dealing with incomplete addresses, or addresses that are less detailed than others. Using my Google headquarters address example, all of the following would make humane scales: USA Nothing California USA Nothing Mountain View California USA Nothing Amphitheatre Parkway Mountain View California USA Nothing Another important interface issue is the level of detail from the human perspective. A pair of lat/long co-ordinates accurate to a metre is technically very accurate, but the name of the street the user is in is more informative and meaningful to people, even though it is technically less accurate. Users might also consider a street name more detailed than their numerical lat/long position because names are more meaningful to us than numbers, but you'd need to do some user testing on that. If you only have the lat/long then you can still form a rough address. One can work out the city from a lat/long which would then give the country. If the lat/long is in the woods, a desert, or some other place not near a city, then the lat/long still gives the country, which the browser can then present as a simple “Nothing” or “USA” choice (if the user in the USA).

The browser can only present the location information that it has available. The user interface for the scale must be flexible, which is why I believe an address-based scale is more suitable. We are all used to dealing with incomplete addresses, or addresses that are less detailed than others. Using my Google headquarters address example, all of the following would make humane scales:

USA
Nothing

California
USA
Nothing

Mountain View
California
USA
Nothing

Amphitheatre Parkway
Mountain View
California
USA
Nothing

Another important interface issue is the level of detail from the human perspective. A pair of lat/long co-ordinates accurate to a metre is technically very accurate, but the name of the street the user is in is more informative and meaningful to people, even though it is technically less accurate. Users might also consider a street name more detailed than their numerical lat/long position because names are more meaningful to us than numbers, but you’d need to do some user testing on that.

]]> By: Aza Raskin http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1530 Aza Raskin Wed, 11 Jun 2008 03:01:03 +0000 http://azarask.in/blog/?p=55#comment-1530 @Jeff: That's a phenomenal idea! I like it a lot. The biggest problem, though, is that geocoding data might not be available. For example, with a GPS you won't know the user's non-lat/long location information without a round-trip to a geocoding server. And even then, you might not be returned useful results. I think the solution I gave might be a good fallback mechanism... but any more thoughts about what happens when you only have access to lat/long? @Jeff: That’s a phenomenal idea! I like it a lot. The biggest problem, though, is that geocoding data might not be available. For example, with a GPS you won’t know the user’s non-lat/long location information without a round-trip to a geocoding server. And even then, you might not be returned useful results. I think the solution I gave might be a good fallback mechanism… but any more thoughts about what happens when you only have access to lat/long?

]]> By: Jeffrey Morgan http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1529 Jeffrey Morgan Mon, 09 Jun 2008 11:42:18 +0000 http://azarask.in/blog/?p=55#comment-1529 A more humane way to label proximity granularity would be to label the scale with the geolocation information itself. Instead of using exact location neighbourhood city nothing as the scale, the browser would label the scale with each part of the address of the user's location. For example, if the user was located in Office number 123 at Google's headquarters, the scale would be: Office 123 1600 Amphitheatre Parkway Mountain View California USA Users would then be able to say that they don't mind an app knowing that they are in Mountain View, but telling the app that they are in Amphitheatre Parkway would be too much information. The advantage of an address-based proximity scale is that it doesn't use country- and language-specific terms, such as neighbourhood and city, but does use the address format familiar to users in each country. A more humane way to label proximity granularity would be to label the scale with the geolocation information itself. Instead of using

exact location
neighbourhood
city
nothing

as the scale, the browser would label the scale with each part of the address of the user’s location. For example, if the user was located in Office number 123 at Google’s headquarters, the scale would be:

Office 123
1600 Amphitheatre Parkway
Mountain View
California
USA

Users would then be able to say that they don’t mind an app knowing that they are in Mountain View, but telling the app that they are in Amphitheatre Parkway would be too much information.

The advantage of an address-based proximity scale is that it doesn’t use country- and language-specific terms, such as neighbourhood and city, but does use the address format familiar to users in each country.

]]> By: Doug Schepers http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1524 Doug Schepers Thu, 05 Jun 2008 19:44:21 +0000 http://azarask.in/blog/?p=55#comment-1524 I like the proximity granularity, but I would also like to have a duration UI selector. I might like to allow a webapp to get my location over a certain duration, but no more than that. I suppose I could navigate away from a webapp or shut down a widget, but it's something to consider. I like the proximity granularity, but I would also like to have a duration UI selector. I might like to allow a webapp to get my location over a certain duration, but no more than that. I suppose I could navigate away from a webapp or shut down a widget, but it’s something to consider.

]]> By: Aza Raskin http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1512 Aza Raskin Mon, 02 Jun 2008 22:46:46 +0000 http://azarask.in/blog/?p=55#comment-1512 @Gregor: I work with Doug, so yes. I called him out in particular in my <a href="http://azarask.in/blog/post/geolocation-in-firefox-and-beyond/" rel="nofollow">first blog post about geolocation</a>. @Gregor: I work with Doug, so yes. I called him out in particular in my first blog post about geolocation.

]]> By: Gregor J. Rothfuss http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1506 Gregor J. Rothfuss Sat, 31 May 2008 21:42:45 +0000 http://azarask.in/blog/?p=55#comment-1506 Finally! Are you aware of Doug Turners work? http://dougt.wordpress.com/2006/08/08/support-geolocation-in-the-browser/ Another one is http://blog.liip.ch/archive/2007/05/20/the-whereami-firefox-extension.html Finally!

Are you aware of Doug Turners work?

http://dougt.wordpress.com/2006/08/08/support-geolocation-in-the-browser/

Another one is http://blog.liip.ch/archive/2007/05/20/the-whereami-firefox-extension.html

]]> By: Ian http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1505 Ian Sat, 31 May 2008 21:40:53 +0000 http://azarask.in/blog/?p=55#comment-1505 " I believe that location is such vital context, Powerbooks should come with GPS receivers pre-installed, with an easy software API. Developers would then write software to take advantage of it, and other computer makers would follow suit. Someday, a computer without GPS might seem as silly as a computer without a clock." Bret Viktor Nice to see that you are following him and extending some of the great ideas he's proposed. ” I believe that location is such vital context, Powerbooks should come with GPS receivers pre-installed, with an easy software API. Developers would then write software to take advantage of it, and other computer makers would follow suit. Someday, a computer without GPS might seem as silly as a computer without a clock.” Bret Viktor

Nice to see that you are following him and extending some of the great ideas he’s proposed.

]]> By: Google To Launch Large Scale Geo-Services http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1503 Google To Launch Large Scale Geo-Services Sat, 31 May 2008 21:02:53 +0000 http://azarask.in/blog/?p=55#comment-1503 [...] way to pinpoint other locations as a basis for a location-based service. There is also an effort to develop and define a standard API for accessing Location data and services in the browser. As with local browser storage, Google are leading the way here by implementing [...] [...] way to pinpoint other locations as a basis for a location-based service. There is also an effort to develop and define a standard API for accessing Location data and services in the browser. As with local browser storage, Google are leading the way here by implementing [...]

]]> By: Aza Raskin http://www.azarask.in/blog/post/firefox-geolocation-js-library/#comment-1359 Aza Raskin Thu, 22 May 2008 19:37:04 +0000 http://azarask.in/blog/?p=55#comment-1359 @Ian: Thanks for the graphic feedback. I've updated it also modulate the circle size. In terms of the radius thing, all it is doing is forcing an increase in the error. That is, if you select "neighborhood", then Ars Technica with get back a lat/long that is good to within +/- 1km of your actual location. So Ars Technica might think you are .7km northwest of your actual location. At least for the first round of geolocation in the browser, you won't get automatic access to geocoding so that there will never be the border problem you described. The basic idea with the location api is to abstract, as you say, all the difficulties of actually getting your location. So on the backend, it will try GPS, wifi-based location, IP-based location, ESP, whatever it can to get your location as best it can. But as a user, you'll never see that. @Ian: Thanks for the graphic feedback. I’ve updated it also modulate the circle size. In terms of the radius thing, all it is doing is forcing an increase in the error. That is, if you select “neighborhood”, then Ars Technica with get back a lat/long that is good to within +/- 1km of your actual location. So Ars Technica might think you are .7km northwest of your actual location. At least for the first round of geolocation in the browser, you won’t get automatic access to geocoding so that there will never be the border problem you described.

The basic idea with the location api is to abstract, as you say, all the difficulties of actually getting your location. So on the backend, it will try GPS, wifi-based location, IP-based location, ESP, whatever it can to get your location as best it can. But as a user, you’ll never see that.

]]>