web standards – Factory Joe

Fluid, Prism, Mozpad and site-specific browsers

Matt Gertner of AllPeers wrote a post the other day titled, “Wither Mozpad?” In it he poses a question about the enduring viability of Mozpad, an initiative begat in May to bring together independent Mozilla Platform Application Developers, to fill the vacuum left by Mozilla’s Firefox-centric developer programs.

Now, many months after its founding, the group is still without a compelling raison d’être, and has failed to mobilize or catalyze widespread interest or momentum. Should the fledgling effort be disbanded? Is there not enough sustaining interest in independent, non-Firefox XUL development to warrant a dedicated group?

Perhaps.

There are many things that I’d like to say both about Mozilla and about Mozpad, but what I’m most interesting in discussing presently is the opportunity that sits squarely at the feet of Mozilla and Mozpad and fortuitously extends beyond the world-unto-itself-land of XUL: namely, the opportunity that I believe lies in the development of site-specific browsers, or, to throw out a marketing term: rich internet applications (no doubt I’ll catch flak for suggesting the combination of these terms, but frankly it’s only a matter of time before any distinctions dissolve).

If you’re just tuning in, you may or may not be aware of the creeping rise of SSBs. I’ve personally been working on these glorified rendering engines for some time, primarily inspired first by Mike McCracken’s Webmail.app and then later Ben Willmore’s Gmail Browser, most recently seeing the fruition of this idea culminated in Ruben Bakker’s pay-for Gmail wrapper Mailplane.app. More recently we’ve seen developments like Todd Ditchendorf’s Fluid.app which generates increasingly functional SSBs and prior to that, the stupidly-simple Direct URL.

But that’s just progress on the WebKit side of things.

If you’ve been following the work of Mark Finkle, you’ll be able to both trace the threads of Web Runner’s transformation into the full-fledged Prism project, as well as the germination of Mozpad.

Clearly something is going on here, and when measured against Microsoft’s Silverlight and Adobe’s AIR frameworks, we’re starting to see the emergence of an opportunity that I think will turn out to be rather significant in 2008, especially as an alternative, non-proprietary path for folks wishing to develop richer experiences without the cost, or the heaviness, of actually native apps. Yes, the rise of these hybrid apps that look like desktop-apps, but benefit from the connectedness and always-up-to-date-ness of web apps is what I see as the unrecognized fait accompli of the current class of stand-alone, standards compliant rendering engines. This trend is powerful enough, in my thinking, to render the whole discussion about the future of the W3C uninteresting, if not downright frivolous.

A side effect of the rise of SSBs is the gradual obsolescence of XUL (which already currently only holds value in the meta-UI layer of Mozilla apps). Let’s face it: the delivery mechanism of today’s Firefox extensions is broken (restarting an app to install an extension is so Windows! yuck!), and needs to be replaced by built-in appendages that offer better and more robust integration with external web services (a design that I had intended for Flock) that also provides a web-native approach to extensibility. As far as I’m concerned, XUL development is all but dead and will eventually be relegated to the same hobby-sport nichefication of VRML scripting. (And if you happen to disagree with me here, I’m surprised that you haven’t gotten more involved in the doings of Mozpad).

But all this is frankly good for Mozilla, for WebKit (and Apple), for Google, for web standards, for open source, for microformats, for OpenID and OAuth and all my favorite open and non-proprietary technologies.

The more the future is built on — and benefits from — the open architecture of the web, the greater the likelihood that we will continue to shut down and defeat the efforts that attempt to close it up, to create property out of it, to segregate and discriminate against its users, and to otherwise attack the very natural and inclusive design of internet.

Site specific browsers (or rich internet applications or whatever they might end up being called — hell, probably just “Applications” for most people) are important because, for a change, they simply side-step the standards issues and let web developers and designers focus on functionality and design directly, without necessarily worrying about the idiosyncrasies (or non-compliance) of different browsers (Jon Crosby offers an example of this approach). With real competition and exciting additions being made regularly to each rendering engine, there’s also benefit in picking a side, while things are still fairly fluid, and joining up where you feel better supported, with the means to do cooler things and where generally less effort will enable you to kick more ass.

But all this is a way of saying that Mozpad is still a valid idea, even if the form or the original focus (XUL development) was off. In fact, what I think would be more useful is a cross-platform inquiry into what the future of Site Specific Browsers might (or should) look like… regardless of rendering engine. With that in mind, sometime this spring (sooner than later I hope), I’ll put together a meetup with folks like Todd, Jon, Phil “Journler” Dow and anyone else interested in this realm, just to bat around some ideas and get the conversation started. Hell, it’s going on already, but it seems time that we got together face to face to start looking at, seriously, what kind of opportunity we’re sitting on here.

Wither web standards? And a call for new browser wars

There’s been a flurry of activity in web standards land lately, with Opera taking on Microsoft in Europe over their failure to conform to web standards, while Andy “Malarkey” Clarke calls BS on the whole CSS Working Group thing, pointing to the complicity and corruption that comes with entrenched vendors having little to no incentive to innovate at the speed of the web and Mozilla’s Dave Baron getting fed up with backdoor dealings. In support of his case, Alex “Dojo Toolkit” Russell suggests that we abandon the W3C altogether (and Zeldman-kind too) and start burning [our] standards advocacy literature and start telling [our] browser vendors to give [us] the new shiny. Jeff Croft jumps in as well, asking whether we should return to the browser wars of yore.

I attempted to leave a comment on Jeff’s blog, but since I was over his 3000 character limit, I’m blogging it here, without the normal care that I usually take with posts here. Take it as you will:

As much as I appreciate your perspective and agree with the goals that you, Andy M and Alex share, I am at the same time dismayed that it means we’re going to end up essentially with “privileged web experiences” and “unprivileged web experiences” if you take this path.

It also means that the fight against Silverlight and Flash essentially comes to a draw and developers have to pick sides (if they haven’t already) and “standardize” their own work to one of four choices: either two of the above or, confusingly, HTML-compliant and HTML-incompatible. So while you might be able to do some shiny things into the forceable future, it does seem to me that you’re going to wind up creating more work for developers to have to test against and support both HTML variants (not to mention the long history of browser incompatibilities), in which case they might as well just jump the open web standards ship altogether and get in bed with Microsoft or Adobe, given their ability to crank out tools AND formats that rival most of their open alternatives.

It seems to me that rather than necessarily abandoning web standards or, as Alex said, “start burning their standards advocacy literature”, I suppose I’d like to see how we can begin to commoditize the more attractive aspects of Silverlight and AIR/Flash with open formats and standards. Unfortunately we are up against massive marketing dollars and entrenched positions, but in the end, open always wins.

If you’re really serious about this, and I think Alex, with his relationship to the Dojo project is in the perfect position to do so, I think the job of folks who have grown disillusioned with the web standards path should begin to develop “community conventions” that can be implemented today, using what leading browsers support (Opera, Firefox and WebKit/Safari) (see microformats, leading this approach, as well as OAuth). I think rewarding those browser makers by exploiting the features that they ARE implementing is a good way to go, and I also think that developing rich interface libraries in CSS and Javascript will continue to be important to advancing the state of the “unprivileged web”. We’ve made a great deal of progress in a relatively short amount of time with jQuery and similar libraries that deliver effects previously unthought of in regular web pages… it’s just a matter of time before we approach this as a more concerted effort to make web applications compete with their proprietary brethren.

With site-specific browser generators like Todd Ditchendorf’s Fluid and Prism coming out, I think we’re also moving much more quickly towards local desktop integration than you’ll be able to get out of full-fledged generic browsers. In fact, I’m most hopeful about those kinds of application for the kind of innovation you’re talking about.

I think I’m just about as fed up as you with the centralized, top-down web standards process. But then again, I never believed in it from the beginning. Your frustrations to me only indicate that the way of old skool, top down bureaucracies have had their day; the way forward is the way of open source and open communities that produce results. And given that we do already have a body of standards that we can build on top of, I do worry that a lot of effort will be wasted paving a new path towards an uncertain future, when there is still so much potential and opportunity to be had with the technologies that are available today but are simply underutilized and have yet to be exploited.

Did the web fail the iPhone?

Ian might be right, but not because of Steve’s announcement today about opening up the iPhone.

Indeed, my reaction so far has been one of quasi-resignation and disappointment.

A voice inside me whimpers, “Don’t give up on the web, Steve! Not yet!”

You have to understand that when I got involved in helping to plan iPhoneDevCamp, we didn’t call it iPhoneWebDevCamp for a reason. As far as we knew, and as far as we could see into the immediate future, the web was the platform of the iPhone (Steve Jobs even famously called Safari the iPhone’s SDK).

The hope that we were turning the corner on desktop-based applications was palpable. By keeping the platform officially closed, Apple brought about a collective channeling of energy towards the development of efficient and elegant web interfaces for Safari, epitomized by Joe Hewitt’s iPhone Facebook App (started as a project around iPhoneDevCamp and now continued on as iUI by Christopher Allen, founder of the iPhoneWebDev group).

And we were just getting started.

…So the questions on my mind today are: was this the plan all along? Or, was Steve forced into action by outside factors?

If this were the case all along, I’d be getting pretty fed up with these kind of costly and duplicitous shenanigans. For godsake, Steve could at least afford to stop being so contradictory! First he lowers the price of the iPhone months after releasing it, then drops the price of DRM-free tracks (after charging people to “upgrade their music”), and now he’s promising a software SDK in February, pledging that an “open” platform “is a step in the right direction” (after bricking people’s phones and launching an iPhone WebApps directory, seemingly in faux support of iPhone Web App developers).

Now, if this weren’t in the plan all along, then Apple looks like a victim of the promise — and hype — of the web as platform. (I’ll entertain this notion, while keeping in mind that Apple rarely changes direction due to outside influence, especially on product strategy.)

Say that everything Steve said during his keynote were true and he (and folks at Apple) really did believe that the web was the platform of the future — most importantly, the platform of Apple’s future — this kind of reversal would have to be pretty disappointing inside Apple as well. Especially considering their cushy arrangement with Google and the unlikelihood that Mac hardware will ever outsell PCs (so long as Apple has the exclusive right to produce Mac hardware), it makes sense that Apple sees its future in a virtualized, connected world, where its apps, its content and its business is made online and in selling thin clients, rather than in the kind of business where Microsoft made its billions, selling dumb boxes and expiring licenses to the software that ran on them.

If you actually read Apple’s guide for iPhone content and application development, you’d have to believe that they get the web when they call for:

Understanding User-iPhone Interaction
Using Standards and Tried-and-True Design Practices
Integrating with Phone, Mail, and Maps
Optimizing for Page Readability
Ensuring a Great Audio and Video Experience (while Flash is not supported)

These aren’t the marks of a company that is trying to embrace and extend the web into its own proprietary nutshell. Heck, they even support microformats in their product reviews. It seems so badly that they want the web — the open web — to succeed given all the rhetoric so far. Why backslide now?

Well, to get back to the title of this post, I can’t but help feel like the web failed the iPhone.

For one thing, native apps are a known quantity for developers. There are plenty of tools for developing native applications and interfaces that don’t require you to learn some arcane layout language that doesn’t even have the concept of “columns”. You don’t need to worry about setting up servers and hosting and availability and all the headaches of running web apps. And without offering “services in the cloud” to make web application hosting and serving a piece of cake, Apple kind of shot itself in the foot with its developers who again, aren’t so keen on the ways of the web.

Flipped around, as a proponent of the web, even I can admit how unexciting standard interfaces on the web are. And how much work and knowledge it requires to compete with the likes of Adobe’s AIR and Microsoft’s SilverLight. I mean, us non-proprietary web-types rejoice when Safari gets support for CSS-based rounded corners and the ability to use non-standard typefaces. SRSLY? The latter feature was specified in 1998! What took so long?!

No wonder native app developers aren’t crazy about web development for the iPhone. Why should they be? At least considering where we’re at today, there’s a lot to despise about modern web design and to despair about how little things have improved in the last 10 years.

And yet, there’s a lot to love too, but not the kind of stuff that makes iPhone developers want to abandon what’s familiar, comfortable, safe, accessible and hell, sexy.

It’s true, for example, that with the web you get massive distribution. It means you don’t need a framework like Sparkle to keep your apps up-to-date. You can localize your app in as many languages as you like, and based on your web stats, can get a sense for which languages you should prioritize. With protocols like OpenID and OAuth, you get access to all kind of data that won’t be available solely on a user’s system (especially when it comes to the iPhone which dispenses with “Save” functionality) as well a way to uniquely identify your customers across applications. And you get the heightened probability that someone might come along and look to integrate with or add value to your service via some kind of API, without requiring any additional download to the user’s system. And the benefits go on. But you get the point.

Even still, these benefits weren’t enough to sway iPhone developers, nor, apparently, Steve Jobs. And to the degree to which the web is lacking in features and functionality that would have allowed to Steve to hold off a little longer, there is opportunity to improve and expand upon what I call the collection of “web primitives” that compose the complete palette of interaction options for developers who call the web their native platform. The simple form controls, the lightboxes, the static embedded video and audio, the moo tools and scriptaculouses… they still don’t stack up against native (read: proprietary) interface controls. And we can do better.

We must to do better! We need to improve what’s going inside the browser frame, not just around it. It’s not enough to make a JavaScript compiler faster or even to add support for SVG (though it helps). We need to define, design and construct new primitives for the web, that make it super simple, straight-forward and extremely satisfying to develop for the web. I don’t know how it is that web developers have for so long put up with the frustrations and idiosyncrasies of web application development. And I guess, as far as the iPhone goes, they won’t have to anymore.

It’s a shame really. We could have done so much together. The web and the iPhone, that is. We could have made such sweet music. Especially when folks realize that Steve was right and developing for Safari is the future of application development, they’ll have wished that they had invested in and lobbied for richer and better tools and interfaces for what will inevitably become the future of rich internet application development and, no surprise, the future of the iPhone and all its kin.