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).

Fluid LogoIf 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 transformation into the full-fledged 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 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.

Site-specific browsers and GreaseKit

GreaseKit - Manage Applications

There’s general class of applications that’s been gaining some traction lately in the Mozilla communities built on a free-standing framework called .

The idea is simple: take a browser, cut out the tabs, the URL bar and all the rest of the window chrome and instead load one website at a time. Hence the colloquial name: “site specific browser”.

Michael McCracken deserves credit for inspiring interest in this idea early on with his Webmail app, that in turn lead to Ben Willmore’s Gmail Browser application. Both literally took WebKit — Apple’s open source rendering engine (like Mozilla’s engine) — had it load Gmail.com and released their apps. It doesn’t get much more straight-forward than that.

For my own part, I’ve been chronically the development of Site-Specific Browsers from the beginning, setting up the WebKit PBWiki and releasing a couple of my own apps, most recently Diet Pibb. I have a strong belief that a full featured rendering engine coupled with a few client side tweaks is the future of browsers and web apps. You can see hints of this in Dashboard Widgets and Adobe’s AIR framework already, though the former’s launching flow conflicts with the traditional “click an icon in my dock to launch an application” design pattern.

Anyway, in developing my Site-Specific Browsers (or Desktop Web Apps?), I became enamored with an input manager for Safari called Creammonkey that allows you to run Greasemonkey scripts inside of Safari (ignore the name — Kato, the developer, is Japanese and English is his second language). An input manager works by matching a particular application’s .plist identifier and injecting its code (via SIMBL) into the application at run-time, effectively becoming part of the host application, in turn giving it access to all the application’s inner workings. When it comes to a rendering engine, it’s this kind of injection that allows you to then inject your own CSS or Javascript into a webpage, allowing you to make whatever modifications you want.

This is what Creammonkey did for Safari. And thank god it was open source or else we never would have ended up with today’s release of the successor to Creammonkey called GreaseKit.

Let me step back a little.

When I found out about Creammonkey, I contacted Kato Kazuyoshi, the developer, and told him how excited I was about what he had created.

“But could I use this on Site-Specific Browsers?” I wanted to know.

In broken English he expressed his uncertainty and so I went about hacking it myself.

I ended up with a crude solution where I would recompile Creammonkey and aim it at a different application every time I wanted to make use of a different Greasemonkey scripts. It was tedious and didn’t really work the way I envisioned, but given my meager programming skills, it demonstrated the idea of Site-Specific Browsers with Site-Specific Hacks.

I called this collection of site-specific scripts with a properly crafted Input Manager a “GreaseKit” and let the idea sit for a while.

Some time later, Kato got in touch with me and we talked about rereleasing Creammonkey with the functionality that I envisioned and a new name. Today he released the results of that work and called it GreaseKit.

I can’t really express how excited I am about this. I suspect that the significance of this development probably won’t shake the foundations of the web, but it’s pretty huge.

For one thing, I’ve found comparable solutions (Web Runner) clunky and hard to use. In contrast, I’m able to create stand-alone WebKit apps in under 2 minutes with native Apple menus and all the fixins using a template that Josh Peek made. No, these apps aren’t cross-platform (yet), but what I lose in spanning the Linux/PC divide, I gain in the use of , Apple’s development environment, and frankly a faster rendering engine. And, as of today, the use of Greasemonkey scripts centrally managed for every WebKit app I develop.

These apps are so easy to make and so frigging useful that people are actually building businesses on them. Consider Mailplane, Ruben Bakker’s Gmail app. It’s only increments better than McCracken’s WebMail or Willmore’s Gmail Browser, but he’s still able to charge $25 for it (which I paid happily). Now, with GreaseKit in the wild, I can add all my favorite Greasemonkey scripts to Mailplane — just like I might have with Firefox — but if Gmail causes a browser crash, I only lose Mailplane, rather than my whole browser and all the tabs I have open. Not to mention that I can command-tab to Mailplane like I can with Mail.app… and I can drag and drop a file on to Mailplane’s dock icon to compose a new email with an attachment. Just add offline storage (inevitable now that WebKit supports HTML5 client-side database storage) and you’ve basically got the best of desktop, web and user-scriptable applications all in one lightweight package. I’ll have more to write on this soon, but for now, give GreaseKit a whirl (or check the source) and let me know what you think.

Browsers, the future thereof

Doug Engelbart

When I first realized the web as a medium — like artists found clay — I was someone who built websites. I grew up an artist, dabbling with pastels, sculpture, painting; I took lessons in all the classics. Back when I started out on the web, well, I threw my paint against the wall, watched it dry differently; tried watercolor and salt; mixed in color pencil. I created on someone else’s canvas, beholden to the whims of the Internet Explorers and Netscapes.

It wasn’t until I grew frustrated trying to create a publishing and composition tool for regular folks in CivicSpace that I realized that it wasn’t that the brushes or paint that I was using that were flawed — but that the canvas itself could be streched so much further. And so when the opportunity arose to go work on and set the direction of Flock, I jumped at the chance. The thought that I could take a number of the ideas on content creation that I’d been trying to implement in regular webpages into the browser itself was too irresistible to pass up.

And that’s how it started for me — working first on the side of web content developers — and then on the side of the actual rendering context and application. I doubt that I was qualified to work on either, but that’s besides the point, since that’s where I found myself (and artists worth their weight are hardly what I would call experts).

So now, a few months out after leaving Flock, a few heady announcements about microformats, a new Firefox Beta to toy with, a number of webkit-based apps to ponder over and an emerging identity standard coming to the fore, I’m starting to see the future materialize in front of me. From where I sit though, there is a lack of clarity as to what it’s all about, what’s really going on and what’s missing in between to glue it all together and — perhaps most importantly — a sense for what we can learn by focusing on the negative space of our current situation.

I’ve been reading about Doug Engelbart lately and the stuff he was doing in the 60s with his Augment system. He’s now collaborating with my buddy Brad Neuberg on a system he calls “Hyperscope”. I can’t help but see disjoint parallels between his ideas and what’s emerging today. Simply put, there is no grand theory or unifying concept that will bring it all together, just as there’s no single design for a tree — in fact, it takes many to make a forest, and we’re only now beginning to see the emergence of the forest in spite of the individual trees that seem oh-so-important.

And we don’t even have the benefit of LSD. Man, how are we to escape what we already know to imagine what’s possible? Oh well.

Anyway, lemme get down to brass tacks, coz I can tell you’re getting bored already. I almost am, striking out at some kind of point out of this rambling.

When I was at Web 2.0™ (I think) I mentioned to Jason Fried — as I’ve done to others since — my desire to have a webwide conversation about what the future of web browsers should look like. This was the work that I thought I’d started at Flock, but the reality is that they’re a business and not an academic institution and need to pay their employees (a harsh reality that I’m now realizing owning my own company and having a payroll). I left because of this — and maybe for other personal reasons — but primarily because my vision for the future wasn’t exactly compatible with where they needed to go in the short term. Hey, bills, remember?

Anyway, let me put it out there: I don’t get where Firefox is going. I don’t think it’s going anywhere actually. I think it’s strong, it’s stable, it’s a great platform. But it’s not innovative. It’s not Quicksilver. It was a response to IE and now IE7 will come out, co-opt everything that makes Firefox great or interesting and we’ll run through another coupla years of stagnation. Blah.

There is a solution though — you’d be surprised maybe, but you can find it in Safari and I’m dead serious about this. The number of webkit-based apps being released is growing by the week. Pyro, Gcal, Webmail, Hiker (thanks Josh!). There was talk about the future of the merged Internet-desktop as, quite clearly, this is where we’re going — but the choice of user agent is sadly coming down to facility over featureset or robustness. Why isn’t this happening with XUL Runner or Firefox (you figure it out)?

At Flock, this is where I saw things going. I didn’t see Flock as a monolithic package of integrated apps like Netscape or Office — bundled up with unmaintainable software sprawl… but with a solid underlying platform that these secondary apps could be built upon (yeah, Lucene, yeah, Microformats, yeah IM, yeah video and audio and all the rest). Speaking RSS, microformats, Atom and other syndicated content natively, you’d be able to universally star anything for later sharing… you’d be able to upload anything… be able to have any AJAX’d experience offline with a super-cache that could handle the sporadic network connectivity that most of the world puts up with (or that we put up with when we travel). And hell, with OpenID, we’ve even got a way to sync it all up together. Toss in a platform that is built on and around people people people and you’ve got something to really take us forward into the next evolution of Things As We Know Them™.

I wanted Firefox to be my Chariot, Flock to be my Sun.

Such as it is with Open Source, trying to inspire end-user interface innovation is often a losing battle.

(As an aside in parentheses, I think this is biological; I met Tara’s 2-year-old niece this weekend and she mimicked everything we did; thus it’s developmental and inherent — yet the problem remains: how do we bring the majority of user interface innovation to the open source space?)

So anyway — Safari; webkit apps… the future.

For the benefit of everyone involved, whether Mozilla, Flock, Microsoft, Opera, and so on implements any of this stuff… there needs to be some major advancements made in browser technology, both for normal humans and for web… um… painters. This stuff, seriously, is still way too opaque, and way too obscure for most humans for whom “delicious” still means “tastes good”. I want to have that web-wide conversation about the future of the web but somehow, my instincts tell me that the venue to have that conversation isn’t going to be on the web… it’s going to be in barber shops and gas stations and restaurants and the places where normal people really hang out.

If we’re ever going to bear witness to the promise of Doug Engelbart’s achievable vision, it has to be this way. And, to paraphrase walkway wisdom: nothing worth doing is easy. And so I challenge you — those who give a shit — look at what’s out there — and more importantly — what’s not out there — and begin to think seriously on what comes next… on what’s missing… on where this medium needs to be stretched in order to make the most of what’s possible.