Browser as information broker

The phrase "browser as information broker" has been around for a year or so, and finally some of the vision is becoming reality.

My interpretation of that vision is that the browser will link data on a webpage to services that consume it. For example, if a date appears on a page you're browsing, you could drag it to your calendar application - or if a location appears, you can open it up in a map.

It's a powerful vision, and it's actually part of the Semantic Web mission. As Tim Berners-Lee explains, we've already gone from linking computers to linking web-pages. Now we need to take that next step - linking data.

There are three parts to solving this problem - semantics, services, and connections.

Semantics

Firstly, web developers have to mark sections of a page with meaning - this is a location, that is a date, etc, in a standard way that computers can understand.

There are several active approaches

• HTML itself has existing elements (e.g. the "unordered list" element, <ol>) which indicate meaning, and more are being added in HTML5 - e.g. the <time> element.
• HTML has several attributes, especially "class", that can be used in a semantic way. People are trying to standardise class names and HTML structure to indicate data like dates and locations; this is called Microformats.
• Groups can register protocols for various content types. For example, there is a common "mailto:" protocol in HTML links, which commonly opens up an email application. Protocols are established via internet standards.
• The W3C is pushing an ambitious new language, RDF, as the foundation of its Semantic Web vision

In the wild, the first three approaches have good momentum, perhaps because they work well with existing technologies, though they seem to compete with each other. If they hit limitations, RDF will be the obvious choice!

Services

People have to develop websites to manipulate data. Actually, a lot of this has already been done - what is Google Maps except a service to manipulate location data, or Microsoft Live Calendar except a service to manipulate dates & times?

Connections

The browser has to connect the user to relevant services when it spots data. For example, when it spots a location, it should present a nice interface that allows the user, if they desire, to view it in Google Maps.

The forthcoming Firefox 3 enables these connections for protocol handlers. It implements the HTML5 API for registering protocol handlers against a particular website, which tells the browser to use (for example) Yahoo! Mail whenever it sees a "mailto:" link.

It will be fascinating to see how this evolves. To become popular, web developers will have to be confident that high quality services exist around a protocol. What protocols will make the grade?

There are no (or very limited) automated browser connections for any of the other semantic approaches (HTML tags, microformats, and RDF). I would therefore predict that protocols will become the favoured approach to marking up HTML with extra meaning, with perhaps the exception of HTML5 <time>, which will work great with web forms.

Browsers are slow

When Safari 3 was announced, the marketing pitch centered around its 'blazing speed'. Steve Jobs even used precious keynote time explaining a chart comparing browser execution speeds for a javascript benchmark.

That was great news, mostly because it refocus debate on the current shockingly poor state of browser performance. Take any site with a bit of Ajax code, e.g. Gmail, and it's guaranteed to be far slower than a client equivalent.

In the past, javascript speed didn't matter. If you're using a dial-up modem, then the limiting factor is bandwidth, and you don't notice javascript performance. If you're accessing a Web 1.0 site with limited javascript, there won't be a delay.

But the world has moved on. Modern client applications - such as games - ruthlessly use native processing power, including rich graphics and parallel threads. Browsers just haven't caught up.

It's encouraging to see, particularly in the Mozilla community, some serious debate about how to speed things up. Work has started on Tamarin, a project to compile javascript to native code on the fly. Firefox 3 will use the Cairo graphics software library, which can take advantage of hardware acceleration. And there's been great debate about making parallel browsers.

It'll be a few years before most of these efforts come to fruition. In the meantime, Moore's law and a few performance tweaks will help a bit, but we'll be left with great web applications unwritten due to performance concerns.

Writing a browser in HTML

Browsers contain two basic components - a rendering engine (which displays HTML, CSS and javascript), and the chrome (the browser interface, including back button, URL bar, favourites, settings, etc).

Though web developers only worry about the rendering engine, users mostly care about the chrome. Tabbed browsing, the search bar, well organised history and favourites, and full page zoom controls are recent chrome innovations critical to improving the user experience.

But how do browser makers write the chrome? Not using HTML, CSS and javascript - it's like they don't trust their own code!

Instead, they use their own user interface frameworks - Mozilla, for example, has a markup language called XUL. If you look at XUL, it's pretty much a non-standard competitor for HTML5. It's been great for Mozilla until now, of course, but what's the point once you have HTML5 itself? Why maintain code for two separate markup languages?

Using HTML5 to program the browser chrome would make extensions, such as the popular Firefox extensions or even single-use applications like Prism, vastly easier to develop. They would also simplify browser code and reduce its footprint.

Finally, HTML browser chromes would be a real test of HTML5, CSS3 and javascript, overcoming the online / offline schism (the chrome appears even if you're offline) in a novel way.

As HTML5 gets stronger support by browsers, we may see a new tipping point, where HTML becomes the default user interface framework even for local client applications. We'll see an HTML browser chrome in the next few years.

Thoughts on OpenID

Web single sign on has been the stuff of dreams for - well, for as long as the web has existed. Microsoft's much-derided Passport - placing all control in the hands of that institution - was the last serious attempt. Now, finally, we have an open, distributed standard that puts control with the user - OpenID.

Yahoo's implementation of OpenID is a massive filip for the standard. Although Yahoo is only a provider of accounts - it won't read accounts created elsewhere - yet it triples the ecosystem of OpenID accounts, making it ever more likely that the next generation of start-ups will consume these IDs.

OpenID has a key architectural advantage - usernames are URLs, not email addresses. That means you can tell someone your OpenID without getting spammed.

Trouble is, if you are JohnDoe99@yahoo.com, what is the Yahoo OpenID you'll want? http://openid.yahoo.com/JohnDoe99, of course. And if you give that out, people will be able to guess your email account pretty easily...

I have no idea how Yahoo (or anyone else) will prevent this. Perhaps the secret is to have a different email provider to your OpenID provider! If someone asks your email address, it feels impolite to ask them to look it up at your OpenID URL!

It's a social issue as much as a technical one. OpenID has the chance to make lire on the internet so much better, let's hope it grabs its opportunity!

The TV and the Computer

The fight for the digital living room continues. Apple TV, the XBox 360, Microsoft's Home Server, and the set top box all compete to provide multimedia services to the family.

This is horribly wrong. I just can't see the value in having a whirring black box control center in the living room - it's a single point of failure, it's a closed solution (since everything else must plug into it), it's a bottleneck against content on the web, and it forces Dad to play system administrator!

As William Gibson said, "the future is already here, it's just not uniformly distributed". Look at the iMac. Take away the keyboard and mouse, and what does it look like? A TV.

Now imagine it only has one application - the browser - and that it boots up in 2 seconds, like an iPod. Your Flickr photos, Amazon Music and BBC iPlayer programmes are now available, on demand, from the web. You can purchase another TV, put it in the kitchen, and access the same websites - there's no need for a central controller or set top box.

For the remote control, all you need is a wireless mouse! Instead of pressing channel numbers, you navigate between your browser favourites. You can type a new URL or search query using a simple onscreen popup keyboard (unless you really want to connect a full wireless keyboard)

All this is surely feasible today. How much extra would it really cost to include a stripped down Linux OS with Firefox on a $1500 widescreen TV?

The future is putting browsers in TVs. I really don't think that even Apple and Microsoft will be able to stop it.

Apple's strategy: iTunes

With their latest Apple TV product, Apple's strategy is becoming ever clearer: tie everyone to iTunes.

Want to synch your iPod or iPhone? Use iTunes. Purchase new music? Use iTunes. Rent movies? Display photos on your TV? Store your calender, address book and notes? iTunes is Apple's answer to every question about content.

This unsettles me. Apple's customers are tying all their data into a proprietary, closed client application. You might be able now to import Flickr photos into iTunes, but what are your chances of ever exporting them back?

At a time when openness is not just a buzzphrase, but a basic principle of many in Silicon Valley, Apple are probably the only major company still seriously trying to build a walled garden. They truly do 'think differently'!

I personally hope their iTunes strategy doesn't succeed. Their fabulous hardware and awesome user interfaces - in particular, the iPod Touch - are beguiling users into data hell.

Companies like Yahoo and Amazon have a massive opportunity to build a competing stack, based in the browser using open technologies such as HTML, RSS, and even the forthcoming HTML5 audio and video elements. Ironically, these very technologies have superb support in Safari, Apple's browser.

With iTunes, Apple are betting against the web. Time will tell whether this strategy works.

Feeds, set theory, and an Atom DOM

Some time ago I wrote a brief study comparing internet computer science with fundamental maths. I argued that they should coincide, because fundamental maths represents thousands of years of experience about modelling concepts - which after all, is what computer science is all about too.

Missing from the internet (I wrote) was one maths subject, probably the most fundamental of all - set theory, concerning unordered collections of objects. Basic set operations include cardinality (i.e. number of members), union, and intersect - remember those Venn diagrams!

I've belatedly realised, of course, that there is a very important use indeed of set theory on the web - RSS. Feeds are sets! Originally designed to be a blogging platform, RSS (or equivalently, Atom, its better formed sibling) is showing up in all sorts of other places (tagging, email / calendar apps, photo sharing, ...) because it executes perfectly such a simple and powerful concept. The members of a feed set are URLs, which can represent anything - that's why RSS is so powerful.

Indeed, libraries and services such as Yahoo! Pipes have emerged to offer many of the concepts of set theory, including the basics functions of cardinality, union, and intersect, plus slightly more advanced ones.

An Atom DOM

The one thing that maths teaches about sets are that they're critical to pretty much everything else. I would expect web developers to discover the same thing; I wouldn't be surprised if a native browser 'Atom DOM', offering the basic set functions, sprung up. After all, we already have a DOM for XML and HTML, the other two web formats!

What would an Atom DOM look like?

At its most basic level, you'd just need an object to represent the feed, exposing its properties and the elements in the feed, alongside perhaps the feed's cardinality. This alone would save lots of effort for Ajax developers!

For me, the methods of the feed object would be more interesting. Membership, subsets (perhaps created via user-defined filters), union, intersect, cartesian products, power sets, sorts - each would provide a wealth of opportunities for developers.

I doubt that an Atom DOM will exist for several years; the Atom working group has disbanded for a few years, having successfully published its version 1.0 recommendation.

But if an Atom DOM were implemented, it would be tremendously powerful for web developers. Thousands of years of fundamental maths can't be wrong!