B. Mann Consulting

I'm catching up on some mobile-related blog reading today, and was spurred to write something by Tim Bray's Mobile Blues and Dean Bubley's re-post of an article by David Wood. (And thanks to Roland's Google Reader Shared Items, where I am getting a wealth of mobile and food related links)

Canada (and the world in general) is caught up in a storm of mobile imaginings based on the launch of the 3G iPhone. Recent results of app sales potentially point to a future where carriers *don't* have a chokehold on the mobile handset experience: for the first time, your average non-technical end users can easily buy and install applications for your mobile fun. Except, of course, it's just another kind of walled garden, just one run by a computer company instead of a carrier.

Tim in particular has issues with that, as well as with having to learn yet another development environment to program native apps for the iPhone:

But there’s a little problem and a big problem. The little problem is that I don’t wanna learn Objective-C and I don’t wanna learn a whole new UI framework. I acknowledge that lots of smart people think Objective-C and Cocoa are both wonderful, and quite likely they’re right. I don’t care. I’m lazy; I know enough languages and enough frameworks. You’re free to disapprove, but there are a whole lot of people like me out there.

The big problem is this: I don’t wanna be a sharecropper on Massa Steve’s plantation. I don’t want to write code for a platform where there’s someone else who gets to decide whether I get to play and what I’m allowed to sell, and who can flip my you’re-out-of-business-switch any time it furthers their business goals. …

OK, points taken. You don't *have* to learn another programming environment, but every experience I've had with Java on every single phone I've ever owned has been .... terrible. Use Java if you want to quickly prototype an app for your enterprise ... but the usability and UI for the average end user, never mind the install process, is terrible. Most people go to native platform code for that final bit of polish (IF that polish is needed for your target market).

I don't have much to say on the locked platform aspects: you make your choices. In some ways, writing native apps for *any* platform is a level of lock in. That is, shouldn't we rail against OS X native only apps in the same way?

And here we finally come to the punchline hinted at by the title. For desktop operating systems, there are now a couple of site specific browsers (SSBs [wikipedia link]): you enter in the URL of a website / webapp and it is bundled into a separately clickable "application" that you can run like any other native program on your desktop. I use Fluid, based on a WebKit engine, and there is also Prism, based on a Mozilla engine.

So, somewhere between widgets and full blown native applications, can an SSB engine for mobile operating systems reign supreme? Bubley's summarized thoughts on this are:

…for many applications, Mobile Web will be the way to go, for ease of development, cross-platform support, rapid update and so on.

But for some the most important and demanding applications, there will still be a need for native development, even if it comes with a dose of pain.

The mobile web, with advanced, compliant browsers available on smartphones like the iPhone or various Nokia phones, is the Internet. Various UI niceties and formatting to fit the screen factor aside, this is regular ol' HTML and AJAX, no new platform to learn here.

So, I'm looking forward to "Fluid for iPhone" or "Prism for Series 60": I can think of a web app developer or three that would be VERY interested in exploring a potentially very quick way to have apps on these smartphone platforms, without the full pain of native app writing. Actually, paging Handimobility -- there might be a very nice business in there...

ongoing: Purple Pilcrows:

When everyone from Lauren to Aaron Swartz is whining at me to make the #-marks go away, I have to listen. I’ve adapted Simon Willison’s brilliant hack, and a couple of remarks are worth making.

These "purple numbers", where individual paragraphs are able to be linked to, is an interesting concept (I've linked to Tim's post because he has pointed to most of the other interesting discussions around this, and because generally I enjoy his "take" on things). But, since anchors aren't actually first class citizens, I would say that a way to link to (and only display) relevant paragraphs is more useful and powerful. This could also be used for TransClusion -- including content from other places locally. An iframe is an ugly way of doing this -- you would likely need some wiki-like framework to make it possible.

So, you need a dynamic system where you can point to an entire article (e.g. /article-name/), and then a way to get just individual paragraphs (e.g. /article-name/p/1). You could probably do ranges of paragraphs this way as well: /article-name/p/1-3.

The more we link, the more we get enmeshed in other people's thoughts and ideas: I think this is a good thing.