Ben :: Blog

You'll find me over here.

http://benwerd.com/2007/09/13/the-mobile-web-needs-new-har

One interesting thing about my recent trip to Silicon Valley was the sheer number of iPhones being waved about. Given the price tag (even with the recent drop), I’m genuinely surprised by their popularity - the US doesn’t even have 3G support yet, so consumers are paying through the nose for a very limited experience.

That said, it’s by far the best of a very bad bunch. My own Windows Mobile device - which Orange gave me for free when I renewed my contract recently - is cumbersome to use, and features like WiFi and the on-board GPS flake out if you so much as look at them the wrong way. The question, given this, is how on Earth we can expect the mobile web to take off, if the only devices we have are dodgy or cost the same as a cheap laptop.

Over on Last100, Daniel Langendorf makes the important point that for the mobile web to improve, we’re going to need new hardware. The iPhone is a start, but ultimately I want something that’s cheap (sorry, but I can’t afford to drop $399 + extortionate line rental on a mobile device, no matter how cool it is), flexible, cutting edge (Opera browser, please) and so easy my mother could use it.

Once that’s been achieved, we’re going to start to see a sea change, just like the advent of cheap broadband and cut-price laptops has changed the way we get information. I’m looking forward to programming mobiles interfaces for everyone, but I’m not really into what, for now, is an elitist medium.

I had a great meeting over at the SixApart offices yesterday; there are a couple of interesting conversations growing out of the data sharing summit, and this was one.

I'm flying back out to Britain tonight, energised and really glad of the time I've spent out here. Thanks to everyone for being so welcoming; particularly Marc Canter, David Recordon, and Tony Stubblebine. Also thanks to Kaliya Hamlin for facilitating the best - sorry, the second best - conference I've ever been to. More should be run like this.

I also wrote a two-part report for ZDNet's The Social Web blog: see part one and part two.

I will develop this into a post later, but I have an unfinished thought about semantic discussion vs real world system building.

I'm sat here at the DataSharingSummit, using the free wifi kindly provided by Innovis, eavesdropping on a couple of different concurrent sessions. Yesterday's discussions were very down to earth; today has broken down into a number of different semantic issues.

There's a tension between the people who actually want to build and market a system, and the people who want to have academic discussions about the ideas. Both are important, but I'm very much in the "build something" camp. If you have a bottom line to look after, as I do as the director of a company, there's no other possible solution; you need to create a product that real people can pick up and use. The deeper, longer discussions are good and important, but that's what universities are for. That's not to say that those discussions aren't important; they are (although some are arguably cul de sacs and echo chambers). It's simply not what we do: we create products. Microsoft and Google can afford to have academic research divisions; Broadband Mechanics, Crowdvine, SixApart and Curverider cannot. We can certainly create new ideas and do research, but we do so through building them.

In the educational technology world, where Elgg originally came from, this conflict is obviously in the air. I'm not a little surprised to see it here in Silicon Valley, in an environment so thick with people doing it for themselves.

Thoughts from the summit are over here; I'm typing this from the second day, and will summarise that tomorrow.

At an event a couple of years ago, I made the mistake of claiming to an elearning manager that people would one day search for information through social networks rather than flat text search engines like Google. That was pretty much the end of the conversation; he couldn't believe that this would ever be the case.

Interesting, then, to see Robert Scoble claim that Google will be beaten by the likes of Facebook and Mahalo. In other words, graph based search that provides results based on your interests and relevant connections.

In the linked article, Michael Arrington points out the genuine flaws in some of Scoble's claims, but I think the two search approaches essentially augment each other. The first, traditional set of search, allows for broad information discovery: for example, to find out when the local DIY superstore shuts on a Sunday, or to find alternatives to my broken digital TV service (as I did yesterday). The second allows you to build up a network of trusted sources and mine them for information you trust.

A static example of this current approach is Google News, which I use daily to check out different takes on current events. (The CNN version of a story often has information that the Guardian doesn't, and vice versa.) News sites are, in effect, a subgroup of sources that I might want to mine for information. But what about people in the tech sphere, if I want to find out about approaches to programming a particular kind of project? Or how about finding information relevant to my business from my colleagues? (Or taken from the global search and edited for relevance by their actions?)

These types of search are underdeveloped and underused, in part because everyone wants to ape Google. As Arrington points out, the next big thing may be from Google itself; we just need someone to think outside the box and push the concept forward from its current, stale incarnation.

This just goes to show: you can add all the features and complexity you want, but they won't necessarily make the user experience better.

So, 24 hours without Skype access later, and I still can't get on (although apparently some can).

This has been an important lesson in single point of failure (which is one of the core reasons I'm always harping on about decentralised services). We use Skype pretty much universally to talk to each other; although alternatives exist, it's the one that almost everybody is almost guaranteed to be on. The alternative is the traditional phone network, which is nowhere near as cost effective.

It's forced us to create a new communication plan, and I'm certain we're not the only tech company in the same boat. The Internet has meant that we can resource people from all over the world; it's no good if we then can't talk to them.

Annoyances aside, my thoughts go out to the Skype team, who probably haven't slept at all in the last day. They're going to be under serious pressure from both their millions of users and their parent company; I hope they work it out and can get some rest soon.

Update: here's a plausible explanation for the mess.

To everything, at least.

OpenID is a fantastic little protocol that lets a user log in with their username from another service. It means you can log into Explode with your AIM screen name; you can also log into Livejournal with your Explode profile URL. The OpenID client site shoots the user's web browser over to the OpenID server site, authentication is performed, a token is passed back to the client, and bob's your uncle.

As far as this goes, it's simple, powerful, and very clever. If you're building a new web application, I highly recommend including OpenID functionality - even if you don't switch it on for everybody. But what happens if you want to do something behind the scenes?

The larger web applications are typically built around a number of server architectures, which each perform a different task. One might process some data on the back end; another might be reserved for displaying thumbnail images. If all the servers are owned by one body, they can each be passed a token (maybe even a cookie if they're all subdomains of the same parent domain), and poll the authentication server for the current user's details.

Now imagine you want to build a decentralised version of that using web services which are all owned by different organisations - but web services that need to know about who you are. One might provide storage, another might provide a profile, a third might be a messaging application. How do you provide a generalised way of passing authentication across, if there's no central authentication authority (as there isn't in OpenID, or in a decentralised system), and you don't want to go through the user's web browser each time?

Don't say Shibboleth.

None of the standards out there match the simplicity of OpenID, and therefore stand a chance of being as widely adopted. SAML, nominally the standard, requires SOAP, which brings its own problems. Even OpenID, when you examine the number of supported services, is very far away from becoming a mainstream standard. Federated identity is tough, but I think part of that may be to do with the way these standards are created; often they're the products of committee development, either in an institutional or corporate field. In both cases, the demands placed on the spec by the various stakeholders are inevitably going to cause bloat and inefficiency; the two surefire things that will prevent standard adoption. OpenID, meanwhile, has a very small spec, does what it's supposed to and nothing more, and even has pre-written code classes available via JanRain.

This is one of the issues we'll be bringing up at the Data Sharing Summit next month; I'd be interested to hear your ideas. Project Higgins looks to have a very healthy (user-centric, protocol-agnostic) attitude towards identity federation, and they may be one to watch.

Dave Winer gushes about Facebook adding a handful of RSS feeds. I'm less enthralled, which is underlined by some of the quotes from commenters he points out:

Jeff Sandquist says, "I suspect this will allow me to send my Facebook status updates to Twitter."

Seriously, I think I just threw up a bit in my mouth. Surely there are more interesting applications we can find for web application interoperability than Facebook to Twitter? We have the potential to build a far-reaching, global, open platform that is available to anyone with a connected device. People are building networks and clouds and new devices we won't have even thought of yet; RSS on Facebook seems like just a bit of an anachronism.