jerakeen.org

“

In the mobile world, what have we done? We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen

”

http://mobileopportunity.blogspot.com/2008/02/mobile-applications-rip.html

Wow. Pity they never released any of that stuff and we had to put up with Windows Mobile and Symbian.

This doesn’t undermine the core argument, though. Web applications suck on mobile devices - when you’re underground, or there’s no signal, you just can’t use them. And mobile web browsers (other than the iPhone’s) are nasty. None of this matters, because they’re easier to write, easier to deploy, and I don’t have to faff for 3 weeks to get a developer certificate to sign my app so it’ll run.

Aside - last time I tried to get a Symbian developer certificate (naturally, the free ones are IMEI-locked and you have to pay money if you want to distribute something) the website was utterly broken, took minutes per page load, and eventually told me that they weren’t giving out developer certificates this week and please try again later. When it’s easier to jailbreak your iPhone and write apps for it than it is to legitimately develop for Nokia phones, something is wrong.

This is why I believe that the iPhone SDK will be nothing cleverer than off-line enabling of web apps. Recent buzz is sounding like it’s closer to being a Real SDK, though. I think this would be a pity. I’d much rather have a standards-based platform that could be implemented by other phone providers at this point.

A side-effect of all this Google Social lunacy is that I’m seeing a lot of URLs for people that I wouldn’t normally have put in their Address Book entries. For instance, Simon Wistow’s Vox page links to his gestalt page which in turn links to his use.perl page, so I see all of these URLs in Shelf. It fetches the pages, and discovers that there’s a single RSS feed advertised on the use.perl page - http://use.perl.org/index.rss. But this RSS feed is nothing to do with Simon’s page - it’s the main use.perl article feed. Shelf doesn’t know this, of course, so Simon’s display in my Shelf window contains all recent use.perl articles.

The HTML spec seems to imply to me that rel=”alternate” links are for linking to the same content, but represented in a different way, not some completely unrelated content that happens to be hosted on the same domain. This is very annoying.

I’m picking on use.perl unreasonably here, of course. Lots of people do it. use.perl is just the first one I noticed. Followed by search.cpan.org (author modules pages have an RSS feed of the master module upload list). But there are others.

The current trunk version of Shelf uses the Google Social Graph API to figure out who owns the web page you’re looking at. If it can’t find a person in the local address book who owns the URL, Shelf can now ask Google if there are any other pages on the internet that link to that page with a rel=”me” relation, and look for those pages in the local address book. So for instance, if I visit my linkedin profile page, Shelf will display context about me, as linkedin links to http://jerakeen.org/. Likewise, any page that I link to from jerakeen.org will be considered mine as well. This elevates Shelf’s context-finding ability to practically magical levels in some cases.

Alas, there are disadvantages. Most superficially, the context-deriving part of Shelf was never designed to make long-running network queries, and so lives in the GUI code. Calling the Google API blocks the GUI thread. This sucks. Fixable, of course, but it makes the current development version somewhat choppy.

More serious is that Shelf now sends the URL of every web page I visit, and the homepages of everyone who’s twitters I read, and the base URLs of every RSS feed I read, to Google. I want to look for context in the email signatures of people that send me mail too, so soon it’ll be sending the homepages of everyone who mails me as well. Some people would consider this creepy. Actually most people would consider it creepy. And I don’t blame them. I don’t really have a solution for this one either, other than a big clearly-labeled option to turn it on.

On the API

For this sort of use the Social Graph API is great. Although all this information is available through just fetching the source of the current page and looking for links myself, there’s no way I’d want Shelf as a local GUI app to be doing that sort of thing. Google aren’t exposing anything I couldn’t have found out myself, but they’re doing it in a simple and fast manner, and using the API is trivially easy. No API keys, dealing with XML, registering my app or anything. I love that they just went with JSON as the format, and hang everything else.

Where’s the next release?

On a related note, Shelf development has been a little slow recently. Partially I’ve been distracted by shipping important features for Dopplr, but mostly it’s because I’ve hit a sort of psychic barrier of progression. Shelf needs a decent caching layer. And a threaded context discovery layer. And a much better event-driven model for display stuff, so it makes a more controlled number of network requests to fetch RSS feeds. Basically, now I’ve explored the problem, I want to rewrite the whole thing to take advantage of my understanding. And that’s boring. So I’m not doing anything. I’ll get over it.