But what about the mobile browser on your phone?

Mobile Firefox is the only major mobile browser to officially support extensions, and that is currently only for Maemo and Windows Mobile.

I’ve decided that’s not enough!

According to this man below, the mobile browser that accounts for most of our browsing is the iPhone’s Mobile Safari, so let’s start with that.

The technique for extending Mobile Safari makes use of bookmarklets, which are small snippets of javascript stored as a browser Bookmark. This does not require you to jailbreak your iPhone, and this does not require the latest iPhone hardware or software.

What extensions might be useful for your iPhone? According to Comscore, social networking is the fastest growing mobile activity, so I’ve focused on five extensions to make your mobile browsing more social.

There’s a whopping 55 million people using the Facebook iPhone app, and I suspect there might be demand from those people for some social extensions while browsing the web on their iPhone. So included below are extensions that allow you to Like or Share *any* mobile web page, not just the sites which have so far implemented Facebook Social Plugins. And there’s another extension that shows personalized Recommendations powered by Facebook.

Also, my personal use case: I often find myself wanting to tweet about the mobile page I’m reading. But some sites do not include any way to do this, and other sites do not make it easy, or use third party tools which require too many clicks or take me too far away from the page I am reading.

Figuring all that out on a mobile browser is not fun, so one of the extensions below is an easy, quick, reliable, always-opens-in-a-new-window extension to simply pre-fill the status box on Twitter’s own mobile site with simply the title and URL of the page you are reading. Simple.

And last but not least, there’s an extension for Google Buzz users too. Enjoy…

Like!

Whenever you want to Like a web page, this extension will display a Like button powered by Facebook Social Plugins. No more searching high and low for the Like button, and no more waiting for developers to add Like buttons to your favorite sites.

Go to http://mbx.hitching.net/like on your iPhone to add this extension.

Tweet!

To tweet about any web page, use this extension to open Twitter in a new Safari window. Your status will be pre-filled with the title and URL of the page, ready for you to embellish before tweeting. Long URLs will be automatically shortened.

Go to http://mbx.hitching.net/tweet on your iPhone to add this extension.

Recommend!

This extension displays personalized recommendations of content, powered by Facebook Social Plugins.

Go to http://mbx.hitching.net/recommend on your iPhone to add this extension.

Share!

To share any web page on Facebook, this extension will open a share page in a new Safari window, showing the title and URL of the page. You can choose an image from the page, and add a comment, before sharing with your Facebook friends.

Go to http://mbx.hitching.net/share on your iPhone to add this extension.

Buzz!

To post on Google Buzz about any web page, this extension will open Google Buzz in a new Safari window, showing the title and content from the page. You can add a comment before submitting your post.

Go to http://mbx.hitching.net/buzz on your iPhone to add this extension.

If you’ve been using Google Buzz on a mobile phone recently, you would know that you can choose between two filters to the real-time stream of content:

• Social – choose ‘Following’ to filter the stream based on your social graph, or social ‘circle’ as Google prefers to call it. You will see posts from your friends, and also some public posts from friends-of-friends if the Buzz filtration algorithm thinks you want to flex your social circle.
• Geo – choose ‘Nearby’ to filter the stream based on your location, as detected by your mobile phone. You will see public posts from nearby Buzz users, as a chronological list, or located on a map. Most of the value here comes from the stream being updated in real-time.

Now, with the release of the new Google Buzz API from Google Labs, I have added the real-time stream of geo-located Google Buzz content to GeoMeme, my pet project.

GeoMeme detects real-time geo-located trends, now based on millions of daily posts from various Google Buzz and Twitter and MySpace mobile apps.

GeoMeme can detect, for example, that Justin Bieber beats Lady Gaga in New York City.

If you’re curious about Justin Bieber, or about the amount and contents of geo-located Buzz posts, compared to geo-located Twitter and MySpace posts, check it out and let me know what you think.

Today Facebook announced that over 50,000 websites have implemented Social Plugins in the first week since their launch.

My favorite Social Plugin is ‘Recommendations’ which lists the pages on a site which have enjoyed the most Sharing activity by Facebook users lately. It’s a good crowdsourced measure of quality.

But I couldn’t find the plugin on any of my favorite sites.

So here’s a handy bookmarklet that allows you to see Social Recommendations for any website, not just those sites which have implemented the plugin. You might call it a Facebookmarklet.

1. Drag this link up to the bookmarks bar of your web browser: FB-Recommended
   
   

2. Navigate to your favorite site, and click the ‘FB-Recommended’ button to see the pages on that site which are most recommended.

If you are worried about privacy, don’t be. The plugin does not require you to be logged in to Facebook. Here’s the anonymous recommendations on news.bbc.co.uk today. On the site homepage itself, there’s no mention of Gordon Brown’s ‘bigoted woman’ gaff. But that story tops the list of recommended pages:

If you are logged-in to Facebook, the plugin gives preference to and highlights pages that your friends have shared:

This filtering-by-social-graph is hugely significant and valuable, for users needing to filter the signal from the noise, and for Facebook who can apply the same social filtering algorithms to improve their ad targeting.

Enjoy!

At the inaugural Chirp Conference this week, Twitter released its Places feature which instead allows Tweets to be approximately geo-located, within a ‘Place’ of chosen granularity; a city, or a neighborhood, perhaps a restaurant or a park.

This is a great option for users who have ‘geo-privacy’ concerns about revealing an exact latitude/longitude.

However, this approach presents a challenge to developers on the Twitter platform: how can approximately-located Tweets be displayed on a map?

Moreover, users need app developers to adopt a standard way of showing these approximately-located Tweets on a map. A consistent approach by developers will help users form a consistent understanding of this Twitter feature, in a similar way that @anywhere Hovercards provide a consistent approach to showing data about a particular Twitter user.

polytweet is a javascript library which displays approximately-located Tweets on a Google Map.

I hacked it together at Chirp, because I will need something like this for GeoMeme, and also to share it with other developers and encourage a standard approach.

Exactly-located tweets are represented by a profile image atop a blue pin.

Approximately-located tweets are represented by a semi-transparent profile image, placed along one of the edges of the Place polygon, at a consistent position so that zooming in and out does not shuffle the tweets.

Here’s an example, with thanks to the Twitter API team for sharing their geo-location. The tweet on the left hand side from @raffi is approximately located:

Hovering over a marker will trigger the display of any corresponding Place as a semi-transparent polygon. Hence the user can understand the area from which an approximately-located tweet was posted:

You can see the working demo at http://bit.ly/polytweetdemo which includes an added bonus of Hovercards.

See the source code for usage instructions and details of how to tweak the style of the markers and polygons.

Enjoy!

The awards were judged by Mike Jones, MySpace’s new Co-President, and Ron Conway, renowned angel investor, and David Glazer, Director of Engineering at Google, and Robert Scoble, tech blogger and uber-geek.

GeoMeme uses the new MySpace Real-Time Stream API to tap into the flood of geo-located updates being posted by MySpace users all around the world.

Activity Streams from MySpace are mashed up with tweets from a number of mobile Twitter apps, and located onto a Google Map. Local trends are identified using semantic analysis services from Yahoo.

For example, GeoMeme knows that Rihanna beats Lady Gaga in New York and that Avatar beats Hurt Locker in Los Angeles.

Beyond the discovery and measurement of real-time local trends, GeoMeme also provides a unique view into local activity streams, as a way to discover new like-minded and nearby friends. You can then buy the t-shirt (really, you can!) to share your trends with your friends.

GeoMeme is a lightning fast web app, and is also available on iPhone as a mobile web app, optimized for mobile using Google Maps v3 API. GeoMeme is built on Google App Engine for massive scalability.

And congratulations to the other winners of the Challenge:

• Best New MySpace App: Paradise Paintball
• Most innovative use of the Real-Time Stream API: GeoMeme
• Most innovative use of the Open Search API: Social Mention
• Most innovative use of the Photos API: Browser Not Included
• Most innovative MySpace Integration on Mobile: iSkoot

GeoMeme uses the new Real-Time Stream API from MySpace to tap into the flood of geo-located updates being posted by MySpace users all around the world.

MySpace content is mashed up with tweets from a number of mobile Twitter apps, and located onto a Google Map. Local trends are identified using semantic analysis services from Yahoo.

A couple of example GeoMemes generated by all this real-time geo-located content: Rihanna beats Lady Gaga in New York, and Avatar beats Hurt Locker in Los Angeles.

So I created a list of awesomeness, innovation and disruption, including topics such as ‘Mobile is big’, ‘Phones are getting better’, and ‘People pay for stuff on their phones’.

Here’s the full article; 10 awesome, innovative and disruptive things about mobile.

Mobile is an exciting sector to work in. It’s growing fast, and it’s being fundamentally disrupted from all sides, by all kinds of awesome innovation.

Here’s my current list of awesomeness, innovative and disruption in mobile. If this stuff sounds interesting, you should consider working in mobile. We need your help!

01. Mobile is big

You just won’t believe how vastly, hugely, mind-bogglingly big it is.

The global mobile phone subscriber base is 4.6 billion. By comparison, mankind owns a mere 800 million cars, 1.1 billion PCs and 1.5 billion TV sets.

Mobile phones will become ubiquitous within a few years as manufacturing costs drop as low as US$10 per phone.

Mobile internet is already bigger than desktop internet. Over 1 billion people access services using the mobile internet on their phone, more than the number of desktop internet users.

More data is consumed on the mobile internet than the desktop internet. Mobile data traffic will grow from 1 petabyte per month to 1 exabyte per month in half the time it took fixed data traffic to do so.

And mobile is big business. Mobile data services deliver more than US$200 billion of revenue, more than global desktop internet access and internet advertising revenues combined.

02. Phones are getting better

Long after mobile phones become ubiquitous, we will still buy them because of the continual advancement of hardware, battery life and software.

We are buying 1.2 billion new phones every year, gradually upgrading to smartphones (currently there are only 500 million) &/or 3G devices (currently only 1 billion).

At Myriad Group, we write a lot of mobile software to enable high-end smartphone features in lower price-point mobile phones.

03. People pay for stuff on their phones

The huge majority of desktop web users are either unwilling or unable to pay for stuff online.

But on mobile, every subscriber has a billing relationship with a telco, either prepaid or postpaid, that is suitable for micro-payments.

According to Portio Research, the market for mobile ringtones, wallpapers, games and other paid mobile content is US$85 billion, bigger that music, Hollywood and videogames combined.

04. App Stores disrupt paid mobile content

Traditionally, most of that revenue from paid mobile content goes to the telcos. However, the telco walled gardens are rapidly crumbling, and thanks to the emergence of the App Stores, revenue from paid mobile content is being redistributed.

By selling apps on iTunes, Nokia Ovi Store and Android Market, developers can now expect to keep around 70% of the sale price, with the remainder being shared between the App Store and possibly the telcos

Gartner predicts we will download 4.5 billion apps from various App Stores in 2010, spending US$6.8 billion.

Also disruptive to paid mobile content is GetJar, the App Store for free J2ME apps, funded by advertising, and currently bigger than Nokia Ovi Store and Android Market.

05. Mobile advertising is better

In times or places of information overload, a mobile phone can be an excellent information filtration device.

Mobile phones increasingly know who you are (and who your friends are), and where you are (even which direction you are looking), meaning that mobile advertising promises to become better targetted than other forms of advertising, including desktop web advertising.

Google recently spent US$750 million on AdMob, the biggest mobile ad network.

Personally, I believe that given enough local inventory, mobile advertising will eventually cease to be intrusive and will become useful local information.

Another innovation in this area is Google Latitude Proximity Alerts. By recognizing the patterns in your geolocation movements, Google can go beyond the ‘who’ and the ‘where’ and start to detect the why, or your intent, to better target its advertising inventory.

Gartner estimates mobile advertising revenues will leap from US$900 million this year to surpass US$13 billion by 2013.

06. Push Notifications disrupt SMS and MMS

Over 3 billion people are sending 5 trillion SMS messages per year. SMS is worth US$80 billion to the telcos, and MMS is worth US$27 billion.

Apple’s Push Notification Service, launched in 2009, allows an iPhone to receive similar short messages from a server controlled by an app developer. The cost to the sender reduces by a factor of 100, from an average of $0.10 for an SMS, to a few hundred bytes of mobile data, average cost around $0.001.

Why send an expensive SMS when you can send a Facebook message that will be pushed to your iPhone friends?

07. Open source

The mobile operating system, previously a competitive battleground, has recently been commoditized by Android, the open source mobile platform from Google and its partners, including Myriad Group, in the Open Handset Alliance.

Nokia has now also open sourced its Symbian operating system, the most popular on the planet.

Handset manufacturers no longer need to pay a license fee for an operating system; Symbian used to cost about US$4, while Microsoft charges about US$15 for Windows Mobile, so this represents a significant saving, especially for lower price-point phones.

By not being locked into a closed platform, handset manufacturers and telcos are now able to easily customize mobile phones to suit their brand proposition. This has shifted the competitive battleground to innovation in mobile software and cloud-based services, which will generate a lot of demand for mobile software engineers, and which will ultimately deliver more awesomeness and innovation to the benefit of subscribers.

08. Open contracts

Subscribers can also benefit from the flexibility of not being locked into a two year phone contract.

Since January 2010, subscribers in the US, UK, Hong Kong and Singapore can now choose to buy an unlocked Nexus One phone direct from Google rather than subsidized by a telco and locked into a two year contract.

Apple has also announced the iPad as an unlocked device.

This isn’t completely revolutionary. Already in many parts of the world, subscribers buy lower price-point phones directly from manufacturers and switch frequently between telcos competing mainly on voice pricing.

What’s different here is that smartphones consume as much data as 30 lower price-point phones, so we should expect mobile data pricing to become more competitive in markets with a high penetration of smartphones.

Elsewhere, the launch of mobile number portability in large markets including China, India and Indonesia will also encourage subscribers to switch and telcos to compete on voice and data pricing.

09. The Facebook Phone

The INQ Facebook Phone was launched in 2008 but it wasn’t a great user experience, IMHO because Facebook wasn’t deeply integrated into all the places on the phone that it should have been.

Nowadays, Facebook accounts for over 5.5% of all Internet usage, Facebook Mobile has 100 million monthly active users, and 40% of the UK’s mobile internet users are using Facebook.

These numbers reveal an emerging market of subscribers who might like to use Facebook as the Address Book and Inbox on their phone, caring more about a decent mobile social networking experience than who manufactures their phone or who is their telco provider.

Facebook works with many handset manufacturers and telcos to distribute their service, so will they have the courage to do what Google has done with the Nexus One and launch a phone to compete with those channels? You bet! I would expect Facebook to launch a phone within the next couple of years, probably built on Android, further disrupting both the handset manufacturers and the telcos.

Aligned with this prediction is the interesting fact that Facebook still does not expose friend phone numbers through its API, despite that being the most requested feature by third party developers. We should expect the Facebook Phone to leverage this data as an exclusive differentiator.

0A. Mobile Maps disrupts GPS navigation

There turned out to be more than ten things, so let’s continue the list in hexadecimal.

60% of the 421 million GPS chips sold in 2009 were put inside a mobile phone.

Google Maps Navigation is a killer mobile app with lots more features than the standalone GPS devices sold by TomTom and Garmin. And it’s free.

On 28 October 2009, the day when Google announced the app, TomTom’s share price fell 20% and Garmin’s dropped 16%.

Recently Nokia (which has invested heavily in geo, including its US$8 billion acquisition of Navteq) announced free voice navigation for its GPS smartphones, resulting in an 11% drop in the share price of TomTom, and a 5.5% drop in the share price of Garmin.

If you are still holding shares in TomTom or Garmin, be aware that Apple is also expected to launch free maps navigation.

0B. VoIP disrupts voice

Apple and AT&T have recently allowed iPhone VoIP calls to be placed over a 3G network connection, dramatically reducing the cost of voice calls, particularly long distance calls.

Previously this was only available over a Wi-Fi connection.

Fring was first to launch its iPhone 3G VoIP app. Skype is expected to follow in spades. And might it be a possibility that Facebook becomes a new entrant in the VoIP market?

And it’s not limited to the iPhone. Any phone with a data connection can potentially make VoIP calls if the telco is willing and able to support it over their data network. It will be interesting to watch how many telcos like AT&T are willing to cannibalize their own voice revenue in this way, and how they will re-shape their voice/data plans to align with this.

0C. Mobile web apps or native apps?

Native apps are great because they currently offer the deepest integration to the full capability of the phone, for example using device APIs to access Contacts, the Camera Roll, an Accelerometer, or the GPS chip.

On the other hand, emerging HTML5-based mobile browsers are aiming to standardise integration to such device APIs, starting with geolocation APIs; meaning that location-aware mobile web apps are now becoming viable.

The deciding factor for me choosing to build a mobile web app for GeoMeme rather than a native app was development speed. A mobile web app enjoys far greater code re-use from the desktop web version, and it is possible to push regular updates and improvements to users, without having to wait for iTunes approval or for users to upgrade.

Looking at recent evidence, mobile web apps are becoming more prevalent than native apps for mobile social applications, shopping and services, while native apps remain preferred for mobile games and entertainment.

It all comes down to the economics of mobile software development and the App Stores. For free apps, including all those funded by mobile advertising, while mobile browsers continue to advance with HTML5, reducing development costs will increasingly outweigh the marginal benefits of native apps. For paid apps, mostly games and entertainment, native apps will survive while the App Stores remain the only way for app developers to make money.

0D. Google Voice disrupts voicemail

Google Voice isn’t VoIP, but it’s still highly disruptive to telcos.

Innovative features include free voicemail transcription and visual voicemail, free SMS, cheap long-distance calls, and (very useful) call forwarding to multiple phones.

Apple controversially un-approved the Google Voice iPhone app, possibly under pressure from AT&T who were reportedly a little bit fed up with all this disruption.

Google has since released Voice as a mobile web app instead of a native app, thus bypassing the iTunes approval process. Touché! The only restriction I can see with the web app is that contacts from your iPhone need to by synced via GMail, because the iPhone Safari browser does not support the HTML5 Contacts API, yet.

0E. Dumb pipe or smart pipe?

One of the common threads here is that telcos are getting a rough deal at the moment, disrupted from all sides.

But the telcos are also busy innovating, adding value to mobile services to become a smart pipe rather than a dumb pipe.

Vodafone and Telstra are among the telcos who have announced App Stores, to leverage their existing billing relationships with subscribers.

And besides plugging an App Store into their billing systems, telcos can also fight back by providing access to their other network infrastructure and information, including subscriber geolocation.

Geolocation can be calculated by telcos even for lower price-point phones without a GPS chip, using triangulation of base station data. Exposing this geolocation data for app developers to build location-based services is a great opportunity for telcos, but also needs to be carefully controlled to avoid privacy abuses.

Another example: at Xumii our Social Stream product allows telcos to play a unique and valuable role in mobile social networking. Push notifications are sent to ordinary mobile phones using telco SMS capacity, and telco authentication systems are used to provide zero-click sign-in to all your social updates from multiple social networks including Facebook, Twitter, MySpace and Flickr.

0F. Hard bloody work

To all the technologists and engineers still reading this; building mobile technology is hard bloody work.

Getting software to run in a tiny memory footprint, with a slow CPU and constrained user interface, then getting the same software to work on 100 other devices, and then on an unreliable telco data connection, forces you to build efficient and elegant and innovative solutions. This is awesome, and mobile is a good place to work if you agree.

10. And there’s more…

Finally, check out WiMax, Augmented Reality, Google Goggles, and Foursquare for more mobile awesomeness, innovation and disruption.

I hope this list has been of interest to those outside of mobile wondering what all the fuss is about.

To those already working in mobile, yes I know this list is incomplete, and biased by my own interests in mobile + geo + social, so let’s discuss what’s missing in the comments or via @hitching

Murdoch had apparently failed to grasp the significance of the interwebs.

However, ten years later Time Warner has regained its mojo and is now trying to offload a spent and jaded AOL. Did Murdoch get it wrong ten years ago, or did it simply take a whole decade for him to be proven right?

In 2009, the mob is rushing once again to the conclusion that Murdoch is losing his marbles, planning to charge for his online content and blocking the Googlebot from stealing it.

Personally I believe that Murdoch should worry less about the Googlebot, and more about how social media is turning his industry on its head.

The problem is that all of those dotcom upstarts have brought us information overload. There has been an exponential increase in the amount of information and content available to us, way beyond the capacity of the human brain to process.

The solution is social media, which empowers us to easily share the content we care about with our friends and contacts, and adds valuable metadata to that shared content, such as Likes or Retweet counts. This metadata helps us filter the signal from the noise, so that we can focus on just the best quality content from our trusted circle of friends.

This works great for movie reviews. People have always listened to the advice of friends when it comes to choosing what movie to watch. Social media simply provides an efficient and scalable way to do this.

The best example of this social filter is currently FriendFeed, although we can expect to soon see something equally impressive on Facebook. Twitter Search could do this even better if only it were possible to search the entire tweet history of just your friends, or a chosen social distance into your social graph, rather then merely search 7 days of the public timeline. I am hoping that the Google Social Search Experiment will enable this sort of social filter when Google completes its Twitter integration.

Back to Mr. Murdoch… Social media also works for the filtering of news content, however it’s more tricky than movie reviews because there is a need for trustworthy fact rather than mere opinion. This is why Eric Schmidt believes that figuring out how to rank real-time social content, perhaps based on a reliable measure of reputation and authority, is “the great challenge of the age“. It also explains why Twitter’s Retweet feature does not allow the original tweet to be modified, because this makes the Retweet count a more reliable indicator of authority.

So my advice to Rupert Murdoch and other media companies struggling with this; worry less about the Googlebot and more about social media. Focus on improving the quality of your content, so that people share it with their friends.

And if your own social media strategy is not delivering any tangible benefits, try moving it from your Marketing department to your Customer Service department. Use social media to listen more carefully to the needs of your customers, so you can improve the quality of your content to the point where a paid online content model becomes viable.

If Marketing and Customer Service argue about who owns the customer relationship, remind them both that thanks to social media it’s actually the customer who owns and controls the relationship with your business. Not the other way around!

There are now some quite interesting public datasets available, and the developer community is hard at work turning this data into useful APIs, and building innovative applications to consume the data.

Some of the notable apps to emerge from OpenAustralia include:

• It’s Buggered, Mate – from the Canberra Hackfest, a geo app to crowdsource the reporting of broken public infrastructure.
• Suburb Matchmaker – the winner of the Sydney Hackfest, a tool to help you find your ideal suburb to live in.
• FridgeMate – currently winning the MashupAustralia contest and only a couple of days away from the $10,000 prize. FridgeMate lets you assemble a map of local public amenities to stick on your fridge door. My advice to the Creative Possums behind FridgeMate would be to look at using the Zazzle API so people could buy the actual fridge magnet.

My own presentation focussed on some mobile, geo and social technologies to create location-aware mobile mashups to share OpenGov content with friends on Twitter, friends on Facebook, and *real* friends on a t-shirt. Here’s the deck:

Visitors to GeoMeme choose a location on the map, and two search terms to compare. GeoMeme then measures and compares the number of matching tweets within the bounds of the map, based on public data from a number of mobile twitter apps.

As an example, GeoMeme can work out that ‘love’ beats ‘hate’ in Manhattan:

GeoMeme is a desktop web application and also a location-aware mobile web app for iPhone and Android phones.

Implementing the mobile version of GeoMeme as a web app has some advantages and disadvantages, compared to building native iPhone &/or Android applications.

Native apps are great because they currently offer the deepest integration to the full capability of the phone, for example using device APIs to access Contacts, the Camera Roll, an Accelerometer, or the GPS chip. For some applications, this deep device integration is essential and so a native application is beneficial.

On the other hand, emerging HTML5-based mobile browsers are aiming to standardise integration to such device APIs, starting with Geolocation APIs; meaning that location-aware mobile web apps are now becoming viable. Aligned with this development is the new version of the Google Maps API. v3 has been greatly simplified since v2, and is now optimized for use on mobile phones. Less is more.

The deciding factor for me choosing to build a mobile web app for GeoMeme rather than a native app was development speed. A mobile web app enjoys far greater code re-use from the desktop web version, and it is possible to push regular updates and improvements to users, without having to wait for appstore approval or for users to upgrade.

I believe this need for development speed is common among a good proportion of mobile apps that are still in ‘rapid iteration’ or ‘release early, release often’ mode, so this post is intended to share some of the techniques used in GeoMeme with developers wanting to build their own location-aware mobile web apps.

Let’s build an example location-aware mobile web app called ‘Here I Am!’, for the photographically challenged. The app will present some local photographs (from Panoramio) which can be shared with friends on Twitter or Facebook.

Where on earth is that mobile phone..?

The first job of a location-aware mobile app is to work out where on earth the mobile phone currently is. Unfortunately, at the time of writing, there is still no universally reliable and accurate solution for a mobile web app to detect the location of the mobile phone it is running on. However the following partial solutions can be combined to good effect:

a) Google Loader

Load the Google Maps v3 API using Google Loader:

<script type="text/javascript" src="http://www.google.com/jsapi?key=YOUR_API_KEY&autoload=%7Bmodules%3A%5B%7Bname%3A%22maps%22%2Cversion%3A3%2Cother_params%3A%22sensor%3Dtrue%22%7D%5D%7D"></script>
<script type="text/javascript">
google.setOnLoadCallback(function() {
    // initialize the mobile map...
});
</script>

Google Loader requires developers to sign up for an API key, however the advantage of this approach is that the approximate location of the user is revealed, based on network IP address.

In the case of a mobile phone user, this network IP address often refers to the mobile operator’s internet gateway, which can be shared between a large number of subscribers spread over an entire country. This technique becomes more accurate for mobile phones which are connected to the internet via wi-fi rather than GPRS, or becomes less accurate for some phones (e.g. Blackberry) which can connect to the internet via international proxy servers.

Generally, this technique can be successful in working out which country the user is in, but cannot be assumed to be any more accurate than that.

Some example javascript to locate a map based on Google Loader:

if (typeof(google.loader.ClientLocation) != 'undefined') {
	var lat = google.loader.ClientLocation.latitude;
	var lng = google.loader.ClientLocation.longitude;
	var position = new google.maps.LatLng(lat, lng);
	map.setOptions({
		center: position,
		zoom: 10
	});
}

b) W3C Geolocation API

The World Wide Web Consortium (W3C) has been working since 2008 to standardise web geolocation APIs.

Mobile Safari on iPhone (since OS3.0) already supports the emerging W3C standard, to expose location information derived from its GPS chip. The new Chrome mobile browser on Android (from 2.0 Eclair) will also support this standard. For example:

if (typeof(navigator.geolocation) != 'undefined') {
	navigator.geolocation.getCurrentPosition(function(position) {
		var lat = position.coords.latitude;
		var lng = position.coords.longitude;
		var position = new google.maps.LatLng(lat, lng);
		map.setOptions({
			center: position,
			zoom: 15
		});
	});
}

The W3C Geolocation API looks likely to feature as part of HTML5 (the next major revision of HTML), and will also be supported by the next generation of Webkit-based mobile browsers, so expect this technique to start working on an increasing proportion of new mobile phones.

c) Google Gears for Mobile

Gears adds a number of HTML5 features, including a Geolocation API, to legacy web browsers. Although it is possible for Windows IE Mobile and Mobile Opera browsers to become location-aware in this way, the bigger opportunity here is that Android phones (from version 1.0 through 1.6) come with Gears already pre-installed. This means that we can detect the location of these Android phones with the following javascript:

if (typeof(google.gears) != 'undefined') {
	var geo = google.gears.factory.create('beta.geolocation');
	geo.getCurrentPosition(function(position) {
		var lat = position.latitude;
		var lng = position.longitude;
		var position = new google.maps.LatLng(lat, lng);
		map.setOptions({
			center: position,
			zoom: 15
		});
	});
}

Google Gears for Mobile works out the location of a mobile phone from the GPS chip in the phone, or by crowdsourcing the location of the cell-tower to which the mobile phone is connected.

… and fetch me some location-based content, fast!

Once your mobile web app is location-aware, the next thing to do is to retrieve some relevant content, based on current location. GeoMeme retrieves local tweets using the Twitter API, but for ‘Here I Am!’ we’ll retrieve local photos from Panoramio (see http://www.panoramio.com/api/ for details of the API).

Google Maps v3 API includes a convenient new ‘idle’ event which is fired when the map becomes idle after panning or zooming, or after automatic geo-location using the techniques above. By listening for this event, we can fetch the most popular local photos from Panoramio whenever the map is moved. For example:

google.maps.event.addListener(map, 'idle', function() {
    loadPhotos();
});

function loadPhotos() {
    var url = 'http://www.panoramio.com/map/get_panoramas.php?order=popularity&set=public&from=0&to=20&size=mini_square&callback=addPhotos';
    var bounds = map.getBounds();
    url += '&minx=' + bounds.getSouthWest().lng().toFixed(6) + '&miny=' + bounds.getSouthWest().lat().toFixed(6);
    url += '&maxx=' + bounds.getNorthEast().lng().toFixed(6) + '&maxy=' + bounds.getNorthEast().lat().toFixed(6);
    url += '&ts=' + new Date().getTime(); // prevent caching

    // use JSONP to retrieve photo data
    // and trigger a callback to addPhotos()
    var script = document.createElement("script");
    script.setAttribute("src", url);
    script.setAttribute("type", "text/javascript");
    document.body.appendChild(script);
}

The above code sends the resulting JSON data to the addPhotos() callback function, which handles the display of the photos on the map using Icons, another new feature of Google Maps v3 API.

For speed, we also implement a performance optimization here. Existing Icons are re-used, rather than simply removing and adding new Icons each time the map is relocated:

var markers = {};

function addPhotos(data) {
	var new_markers = {};

	for (var i = 0; i < data.photos.length; i++) {
		var photo = data.photos[i];

		// for speed and to reduce flicker,
		// reuse existing markers rather than removing and re-adding
		if (photo.photo_id in markers) {
			new_markers[photo.photo_id] = markers[photo.photo_id];
		} else {
			// create new marker
			marker = new google.maps.Marker({
				position: new google.maps.LatLng(photo.latitude, photo.longitude),
				icon: photo.photo_file_url,
				map: map
			});
			new_markers[photo.photo_id] = marker;
		}
	}

	// remove old markers
	for (var photo_id in markers) {
		if (!(photo_id in new_markers)) {
			markers[photo_id].setMap(null);
			delete markers[photo_id];
		}
	}

	markers = new_markers;
}

‘Here I Am!’ – a simple location-aware mobile web application

The final part of ‘Here I Am!’ is a feature to share one of the Panoramio photos to friends on Twitter or Facebook. This is done using ordinary web links to Twitter and Facebook share pages. No complex platform integration is required for web apps to do this because, as they say, “the web is the platform.” Simply click on a photo on the map and follow the prompts.

Visit http://j.mp/lbsdemo on your mobile phone to try out ‘Here I Am!’

The full source code of ‘Here I Am!’ (weighing in at just under 8Kb) can be located here.

The app has been tested to work on iPhone, iPod Touch, Android, and Symbian Series 60 (which remains – for now at least – the dominant device family for mobile data consumption).

I hope you enjoy using some of these ideas in your own location-aware mobile web apps.

This post is one of a series that aims to share some of the technology innovation that can be found in GeoMeme. Other posts cover topics such as using Google App Engine for scalable and fast hosting of your location-based content, and fast map re-location using Google Static Maps v2.

Visitors to GeoMeme choose a location on the map, and two search terms to compare. GeoMeme then measures and compares the number of matching tweets within the bounds of the map, based on public data from a number of mobile twitter apps.

As an example, GeoMeme can work out that beats in San Francisco:

A large amount of geo-data is generated by GeoMeme, and so arises a need shared by many geo apps: scalable, fast, and accurate spatial queries, used to select a subset of geo-data for display as markers on a map, or on Google Earth.

Google App Engine

Google App Engine is an obvious choice for hosting your geo app. The App Engine datastore is built on top of Google’s BigTable technology which scales very well, and is optimized for fast data retrieval. And it doesn’t cost the earth like some traditional GIS database solutions.

Inequality constraint

If you are coming from a background of relational databases, you might think the solution here would be to store the latitude and longitude of all your markers in a database table, and do a simple query to retrieve only those contained within the bounds of the map.

However, the flipside of being optimized for fast data retrieval is that BigTable only allows inequality filters on a single dimension, to avoid the burden of full table scans. For example, the following form of spatial query is not supported because it specifies inequality filters on both latitude and longitude dimensions:

SELECT latitude, longitude, title FROM myMarkers
WHERE latitude >= :south AND latitude <= :north
  AND longitude >= :west AND longitude <= :east

>>> BadFilterError: invalid filter: Only one property per query may have inequality filters

Geohash to the rescue

Fortunately, there is an answer to this: geohash, the geocoding system invented by Gustavo Niemeyer.

My suspicion is that Niemeyer has travelled back in time after working out how to collapse two-dimensional space into a single dimension, but you might want to read the Wikipedia explanation of the algorithm instead.

An example: the location of the Sydney Opera House can be specified in two dimensions as {latitude: -33.858, longitude: 151.215}, or in a single dimension as {geohash: r3gx2ur29zzg7}.

Schuyler Erle has written an open source geohash python module, which enables the following form of spatial query on Google App Engine, because the inequality filter is specified only on a single dimension:

sw_geohash = Geohash((west, south))
ne_geohash = Geohash((east, north))

SELECT latitude, longitude, title FROM myMarkers
WHERE geohash >= :sw_geohash AND geohash <= :ne_geohash

Don’t hash me, coz I’m close to the edge

However…! We’re not done yet, because an artifact of the geohash algorithm is that queries like the one above can often return rogue markers which are outside of the required bounds, when the map spans what we shall call a geohash “faultline”.

This problem is particularly evident near the equator and the Greenwich Meridian, which are the biggest faultlines, but there are actually faultlines all over the place at every zoom level.

Faultline correction

GeoMeme solves this problem using “faultline correction”, an approach that I would like to share here:

• If a spatial query is vulnerable to faultlines, it is split into multiple sub-queries that do not cross the faultline.
• Sub-query limits are approximately weighted according to their relative size.
• Sub-queries are executed in parallel, taking advantage of BigTable’s distributed goodness, and the results combined, so all this happens very fast.
• Even though the sub-queries are executed in parallel without any significant impact on user experience, App Engine CPU costs can increase to around 2x the CPU cost of a single less accurate query. Sub-query results are memcached to reduce this CPU overhead.

Here’s a demo showing the effect of geohash faultlines, and the relative accuracy of spatial queries with or without faultline correction. Rogue markers are shown in the area surrounding the map. Switch between Correction: off / on / double and compare the accuracy.

Note: “double” correction is an advanced option which splits the sub-queries into sub-sub-queries so that they do not cross any faultlines either. This can further increase accuracy, but with further CPU cost (up to 8x the CPU cost of a single less accurate query).

All the source code can be found here, including ffGeoSearch, a python module to handle faultline-friendly geo search, if you want to use this technique on your own geo app.

Enjoy!

This post is one of a series that aims to share some of the technology innovation that can be found in GeoMeme. Other posts cover topics such as fast map re-location using Google Static Maps v2, and location-aware mobile web apps using Google Maps v3.

Visitors to GeoMeme choose a location on the map, and two search terms to compare. GeoMeme then measures and compares the number of matching tweets within the bounds of the map, based on public data from a number of mobile twitter apps.

As an example, GeoMeme can work out that ‘District 9′ beats ‘Inglorious Basterds’ in Manhattan.

As well as offering users the normal pan and zoom controls to move the map around, GeoMeme also introduces an innovative geo-autocomplete control which is powered by the geocoder service from Google Maps v3 API and the new Static Maps v2 API.

This blog post shares some details of how the geo-autocomplete control works, and offers some code so you can build your own geo-autocomplete controls.

1. Based on a partial location typed by the user, obtain a list of possible matching locations:

If the user has already typed ‘San’ into a form field, we can obtain a list of possible matching locations by passing this partial location to the geocoder service from Google Maps v3 API, as follows:

var partial_location = document.getElementById("location").value;
var geocoder = new google.maps.Geocoder();

geocoder.geocode({'address': partial_location}, function(results, status) {
    if (status == google.maps.GeocoderStatus.OK) {
        document.getElementById("results").innerHTML = '';
        for (var i = 0; i < results.length; i++) {
            showResult(results[i]);
        }
    } else {
        document.getElementById("results").innerHTML = 'Geocode was not successful for the following reason: ' + status;
    }
});

function showResult(result) {
    document.getElementById("results").innerHTML += 'It could be: ' + result.formatted_address + '<br/>';
}

2. Decorate these possible matching locations with a Static Maps thumbnail to help the user choose the right one:

The geocoder returns more than just a formatted address. The full response is a JSON object of the following form:

results[]: {
    types[]: google.maps.GeocoderLocationType,
    formatted_address: String,
    address_components[]: {
        short_name: String,
        long_name: String,
        types[]: String
    },
    geometry: {
        location: LatLng,
        location_type: String,
        viewport: LatLngBounds,
        bounds: LatLngBounds
    }
}

geometry.viewport represents the recommended viewport for each returned result, from which we can derive the required Static Maps URL, as follows:

function showResult(result) {
    var src = 'http://maps.google.com/maps/api/staticmap';

    // the visible parameter specifies one or more locations
    // to show on the map. so we need to specify the south-west
    // and north-east corners of geometry.viewport
    src += '?visible=' + result.geometry.viewport.getSouthWest().toUrlValue() + '|' + result.geometry.viewport.getNorthEast().toUrlValue();

    // other parameters as per http://code.google.com/apis/maps/documentation/staticmaps/#URL_Parameters
    src += '&size=100x100&maptype=terrain&key=YOUR_API_KEY&sensor=false';

    document.getElementById("results").innerHTML += '<img src="' + src + '" /> ' + result.formatted_address + '<br/>';
}

Working out the required Static Maps URL is now a much simpler task with v2 of the Static Maps API, because there is no longer any need to manually calculate a zoom level or latitude / longitude span values.

You can see this working on GeoMeme by clicking on the location control at the top of the screen and entering a partial location. When you choose from the list of possible matches, the main map is moved to that location, providing a refreshingly quick way for users to re-position the map.

You can also download a hello world example here, built as a jQuery plugin to work with a modified version of the excellent Autocomplete plugin:

Using this geo-autocomplete plugin is recommended because it includes a number of features which protect the geocoder service from being hit too often. Including; waiting for keystrokes to stop before sending a request to the geocoder, waiting for a minimum number of characters to by typed, and caching geocoder responses to avoid duplicate requests. Options are also available to set the size and maptype of the Static Map thumbnails.

Enjoy!

This post is one of a series that aims to share some of the technology innovation that can be found in GeoMeme. Other posts cover topics such as location-aware mobile web apps using Google Maps v3, and scalable geo apps using Google App Engine.