Laws, sausages and browser geolocation

July 6, 2011 | 7 comments

Compass InlayI was emailed a question about the browser geolocation test I wrote a while back, and I thought I’d respond to it here. If you haven’t seen it, go check it out, and come back.

If you’re not prepared for it, it’s a creepy little feature. How on earth is browser-based geolocation so accurate? Desktops and laptops mostly don’t contain GPS devices, and IP addresses shouldn’t be enough to pin your location down quite so well.

The answer is also more than a little bit unsettling. There are two main companies who provide software-only location services: Skyhook and Google. Here’s an excerpt from Skyhook’s “how it works” page:

To quickly and reliably arrive at accurate location results, the Core Engine collect raw data from Wi-Fi access points, GPS satellites and cell towers with advanced hybrid positioning algorithms. By leveraging the strengths of more than one underlying position technology, Skyhook’s Core Engine provides the best possible location available in any environment.

In other words, they check your GPS equipment, where that exists, and fall back to checking your environment against a complicated database of wireless access points correlated to location.

These databases are hugely strategically important on the application web. You may remember that Google was forced to stop collecting this information with their Street View vans in Germany. At the time, they claimed it was an accident, but Google is actively preventing Android handset manufacturers for incorporating Skyhook technology for data collection reasons. Check out this detail from the lawsuit between Skyhook and Google:

At 10:46 Google’s Mike Chu had replied, saying ” I think we need to understand how much better Skyhook actually is.”

At 2:36 Google’s Zhengrong Ji replied and said “It’s sad to see first Apple, now Motorola moving away from us, which means less collection” for Google’s location database.

In other words, it’s reasonable to infer that Android handsets are quietly still collecting wireless access point information correlated to location. This information is strategically important, and the company with the most accurate information will win.

It’s a simple feature. But behind the scenes, there’s a battle going on. It turns out that browser geolocation is like laws and sausages: it’s better not to see them being made.

Photo: Compass Inlay by Steve Snodgrass, released under a Creative Commons license.

A humble suggestion for HTML5 video

May 24, 2011 | 1 comment

This is an embedded Flash video from latakoo Flight:

If you’re viewing this post on an iOS device, or anywhere else where Flash isn’t supported, you’re not going to see the video. I’d dearly love to use the HTML5 video tag, which iOS devices do support, but I can’t – at least not without some extra work.

Here’s what the HTML 5 video tag looks like:

<video src="video_location" type="video_type">
	Some fallback content if the browser doesn't support the video tag
</video>

WebKit browsers – those on iOS devices, Chrome and Safari – play H.264 MPEG-4 files natively, as does Internet Explorer 9. Firefox and Opera, meanwhile, play videos stored in the open source OGG format. As it happens, I only have an H.264 MPEG-4 copy of my video, but that’s okay, right? Because we’ve specified the <video> tag’s type attribute, Firefox and Opera will understand that they can’t play it, and they’ll use the fallback content!

Wrong.

What actually happens is that the user sees a great big “X” indicating that the video has failed. The only way to use the HTML5 video tag in this way is to either provide multiple versions of the videos encoded with multiple codecs, or to use JavaScript to selectively decide whether to use the Flash or HTML5 video player depending on what kind of video we have. The latter case would be fine, but I want my videos to be embeddable, like I’ve done here.

So in reality, what I need to do is provide an <iframe> tag that in turn loads a page containing a bunch of JavaScript that controls video playback. Yep, we’re using frames for content, just like in 1996. This isn’t a minority kludge; this is what YouTube does. (It’s also what latakoo Flight will do when we make our video embedding public, very shortly.)

May I suggest another way?

It seems to me that the browser should fall back whenever it can’t play the video. That includes when the codec is mismatched, or when there are connectivity issues. The fallback content can contain a Flash player, and of course, Flash embed HTML also contains a fallback for when it doesn’t work. The result is the HTML equivalent of this nested if statement:

if (the browser can play the video) {
	show HTML5 video player;
} else if (we have Flash installed) {
	show the Flash player;
} else {
	show HTML5 fallback content;
}

This would help clean up the mess caused by web video’s current codec issues, and ensure that the user always sees something sensible. Unlike the kludgey situation we have today.

Onflood

March 30, 2011 | 5 comments

OnfloodFriday night was sleepless for me. I couldn’t stop thinking about a simple idea I had, riffing off of Color and some of the technology I’d built for OutMap:

What if you could hook messages, photos, files and metadata to a particular location in space, and create an ad-hoc messageboard with this information based on where you were in the world?

I couldn’t put the idea down – so I built it.

To start, you set a location, either explicitly (by typing in the address) or implicitly (through your device’s location functionality). Onflood looks at the proximity of the messages around you, and sets an appropriate radius that it’ll draw messages from. For example, if there’s a lot of activity right near you, it’ll probably set a tight radius: if you’re on Edinburgh’s Princes St, you’ll only see messages within a mile of you. Meanwhile, more sporadic activity lends itself to a wider radius: at the time of writing, if you’re on Market St in San Francisco, messages are drawn from up to 606 miles away from you. This way no user is ever made to feel alone or like there’s no activity. You can, of course, manually widen or tighten the radius. You can also jump to other locations by entering a new address or clicking on messages around you.

My hope is that it’ll be useful for conference backchannels, neighborhood-specific information, and as a message-passing medium for local swarms like demonstration protests.

Onflood

Onflood takes your location using the HTML5 geolocation API, which means that if you’re browsing on a GPS-capable device, it’ll use that, and otherwise it works out your location based on IP address and other ambient details. All compatible web browsers ask you for this information, so it’s never done behind your back, and you can always choose to manually enter a location instead.

Both geocoding latitudes and longitude coordinates from place names, and reverse-geocoding names from coordinates, are handled by OpenStreetMap’s awesome Nominatim API. I’d previously used Yahoo APIs for OutMap, but I found the OpenStreetMap endpoints easy to work with, largely accurate and developer-friendly. Plus, of course, you can run Nominatim from your own servers as well as OpenStreetMap’s hosted version. Open source wins out here.

So what’s to come? Right now, authentication is handled solely from Twitter. This is clearly something that I intend to change – OpenID and, yes, Facebook are to follow. I also have yet to implement photos and files (which will both be stored using Amazon S3). Finally, RSS and ActivityStreams feeds are also required.

You can think of this as a starting point. I’ll keep it up and running, and will continue iterating it. If there’s demand for it, I even have a solid business model in mind that will make it more than self-sufficient without annoying existing users.

Give it a try, and let me know what you think.

So why do we need apps anyway?

April 29, 2010 | 3 comments

Ebooks don’t cut it: everyone wants an app

NB (May 20, 2010): A lot of my suggestions for web-based apps are part of the Google Chrome Web App Store. In fact, the .crx file used there is a zip file with very similar characteristics to epub. (I assume, as Chromium is open source, that .crx files are also open source – so the web app store is not limited to Google.) This post can be reread as an argument for building for the Web App Store.

At Intersection: Publishing in London the other week, there was a lot of discussion from publishers looking at mobile apps as their mobile publishing solution. Rather than creating ebooks, there seemed to be a general feeling that dedicated applications presented more of an opportunity for richer content, while closing the door to pirates and ensuring that publications remained a paid commodity.

The piracy argument is kind of spurious: although app stores tend to be locked down, this presents a false security blanket for publishers. It only takes one person to crack a store for piracy to be generally possible; technology only ever becomes less secure over time. A cynical person might suggest that the piracy argument is largely spread by the people who own the app stores or provide related services. The people who will suffer are authors and publishers.

Why apps rock

However, there’s definitely an argument for using apps – not just for publishers, but for anyone who wants to create dynamic content. Anyone who’s ever owned an iPhone will tell you that native applications can still provide a smoother, more consistent experience than a web app, without the hassle of remembering website addresses or waiting for pages to load. Tweetie is a million miles better than Twitter’s mobile website – something they themselves acknowledged when they acquired the iPhone application last month.

Mobile vs app

Above, mobile Twitter is on the left; Tweetie is on the right.

  • The app doesn’t need to load its interface from the web; only the underlying data is downloaded, meaning the app can appear instantaneously, loads data faster, and provides a better user experience.
  • The mobile web app needs to sit within the browser chrome (URL and search boxes, browser buttons on the bottom, and in my case, a debug toolbar). The app, on the other hand, has a full-screen UI dedicated to Twitter.

Why the web rocks

The mobile landscape right now is a bit like the personal computing landscape circa 1985. There are a bunch of different platforms to code for:

  • Apple iPhone and iPad
  • Android
  • Symbian
  • Windows Phone
  • Blackberry
  • WebOS (now more important in the wake of HP’s acquisition)

Each of these platforms is different under the hood, and must be developed for separately. Most developers and publishers can’t afford to do this – there isn’t a way to write once and cross-compile to many platforms at once. In fact, Apple recently specifically forbade this: if you’re developing an Apple app, you’re doing so natively, or you’re violating that platform’s terms of use.

However, each of these platforms have one thing in common: they support the web.

HTML5 and ePub: a new platform for apps

As you’re probably aware already, the upcoming HTML5 standard revises the web platform to become far more suitable for apps. Improvements include:

  • Methods for offline and cached usage (so interfaces can load immediately)
  • Built-in databases and storage (so web pages can natively store their own data)
  • A paintable canvas element and WebGL 3D graphics functionality (so web pages can display interfaces more like real applications; the 3D shooter Quake II has already been ported to native HTML)
  • Native video and audio support (no Flash required)
  • Websockets (a more efficient way to connect to Internet data from web pages)
  • Built-in support for advanced functionality like geolocation

This is a big deal. Compliant browsers like Firefox, Safari, Chrome and even the upcoming Microsoft Internet Explorer 9 will be able to run applications that look and feel like native software but are powered by web standards. Between those browser engines, that’s most of the mobile platforms covered: those that don’t have an HTML5 browser built in by default should have one available to download. What’s more, both Firefox’s Gecko HTML rendering engine and the WebKit engine that powers both Chrome and Safari are open source, so anyone can pick them up and build software around them.

So sites on the wider web can be more like applications. That’s fantastic news in itself, but what about the app store model? A lot of people depend on that for revenue, and there’s no reason why that should be incompatible with using web standards.

Luckily, it turns out that ePub – the ebook standard – is really just a bunch of XHTML 1.1 pages drawn together in a specialized way and bundled up in a modified zip file. There are already established best practices for buying and selling ebooks.

If the ePub standard was updated to allow HTML5, it would evolve into a format for self-contained, multi-platform apps that could be sold in the same way as ebooks, music, videos, or apps in something like the iTunes App Store. Except app publishers would only need to build once to support many different kinds of mobile platform, thereby reducing the barrier to entry and allowing their budgets to be concentrated on building just one really awesome piece of software instead of spread across multiple devices.

This would be in a lot of peoples’ interests: app publishers, device manufacturers, browser vendors and consumers alike. There’s a lot of money tied up in a venture like this. The only question is, will the International Digital Publishing Forum, which controls the ePub standard, be foresighted enough to see this opportunity?

Update: Steve Jobs weighs in

Apple’s CEO has written a little about why HTML5 is the future of mobile apps (albeit in the context of his platform’s refusal to support Flash):

HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member.

[…] Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.

[…] New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

Make no mistake: HTML5 is the platform to bet on.