Author Archive

I’m excited to announce that SitePen is hiring in our R&D department, which roughly translates into “do research on how to improve the Open Web, make it a reality through Open Source software, and get paid to do it”. If that sounds like your dream job, we want to talk to you.

Here at SitePen, we’ve got some pretty deep experience with building apps for mobile devices and having seen the issues first-hand, I firmly believe that Apple is doing a great thing (in the medium term) for the world by making the Open Web the way to deliver apps to their phone. In the short term, they’ll be doing millions of people a huge favor by letting them replace their Treos with a device that doesn’t reboot when exposed to air, sunlight, or text messages.

There are interaction problems yet to be solved (how do you “thingify” a web app for the iPhone? offline? etc.), but fundamentally the iPhone puts the onus on the browser to mediate hardware access better. This is the right race to be running since it forces every one else to one-up Apple on openness and immediately cuts out the idiotic middle man situations that Brew and even J2ME create through oligopoly and ineptitude, respectively.

(more…)

As Chief R&D Monkey here at SitePen, my work primarily revolves around ensuring that Dojo rocks for our customers and that we take what we learn from building apps and ensure that the toolkit evolves to encompass those lessons. Early this year it became clear that for folks building Dojo apps, the question of “what is Dojo?” was becoming increasingly hard to answer. Each individual user might be working with a different subset and therefore they don’t share a common definition, which makes sharing what you know about the system harder than it needs to be.

In response, we’re in the middle of a huge undertaking: rethink the entire API surface area of Dojo from the ground up and split it up into 3 different top-level projects. With R&D dollars and time coming from all corners of the Dojo universe, 0.9 is shaping up to be smaller, faster, more coherent, and easier to understand. I’ll be doing a regular “where are we now?” set of posts here on the SitePen blog for folks who don’t have time to follow all our mailing lists and forums or watch the commit flow.

So, where are we now?

(more…)

At last month’s Open Ajax Alliance meeting in New York, a good chunk of time was dedicated to revisiting what, if anything, OAA should do about “Mobile Ajax”.

I’m something of a pessimist about what most people mean when they say “Mobile Ajax”, but the OAA meeting included several bits and pieces that gave me a lot of reasons to be less grumpy. Firstly, the device manufacturers are starting to get it. One of the attendees made the prescient point that the content devs, the phone vendors, and users alike are all trying to route around the OpCo’s. This suddenly put a lot of things in perspective for me: is wifi a stupid thing to put in a phone? You bet. But it beats the OpCo network. The list of cat-and-mouse features like this goes on and on. At some point something’s gotta give.

At the meeting someone was passing around a very slick Nokia device that has done more to convince me that that the web on phones isn’t dumb than anything else I’ve seen in the last year. Clearly, the UI issues are horrendous, but good screen + beefy CPU + wifi + thumboard makes a lot things bearable. Better yet, there was word that many of the issues I’ve raised about what’s useful input and output in a mobile web context (hint: text is no longer king) is starting to be addressed by the phone vendors. Better yet, there’s rewnewed work at the W3C to address some of the most pressing issues. In fact, it seems that the mobile browser vendors might be attacking the problem of rich content types better/faster than their desktop counterparts. An 18-24 month handset turnover rate will help make up for a lot of lost time.

But I mentioned Ajax and not just the web.

Ajax/DHTML lives in the nexus between a lot of the various web standards which means that it’s subject to the vagaries of all of them. No matter what the specs say, the lowest common denominator of what the clients ship is what the “standard” really is. The mobile browser market has been hugely fragmented for a very long time, but that looks to be changing. I think it’s pretty safe to say that in the next 3 years we’ll be down to three major rendering engine “flavors” in smartphones and that KHTML/Webkit derived browsers will probably carry the day for folks not on MS or Blackberry devices. Frankly, I didn’t expect it to happen this quickly, but I’m gald of it. Clearly, there are major issues still to overcome, but relative standardization on browsers brings the mobile web into alignment with a world that desktop web devs can approach. The sooner good browsers trickle down, the sooner we can start the painful process of forgetting what we think we know about doing webapps and building better idioms for mobile apps.