JD on EP

nb: I wrote this Saturday, but couldn't post it until this evening. Other folks have had additional observations since then, but I haven't factored that into this text. This post is already a little dated. ;-)

"Single-site browsers (SSBs) aim to bring the best of the desktop to web applications. Rather than running programs in normal web browsers like Firefox or Safari, wedged in a tab between New York Times articles and TechCrunch posts, each app is given its own dedicated browser..."

The term "single site browser" still seems oxymoronic to me, like "dehydrated water". If it doesn't browse among sites, why call it a browser?

(I agree that it can be useful to have a particular trusted website work outside of the rest of the web-browsing experience... agree on the need, it's just the "SSB" moniker that makes me wonder.)

"Web developers can add special hooks to their code so that these bells and whistles are automatically included whenever someone spins the app off onto their desktop."

Makes sense to me, that site owners might want to offer optimized experiences for different viewing environments. But doesn't this conflict with the desire to make validated "web standards" pages? When Microsoft urges new HTML in advance of group agreement it would be bad, but when Mozilla does it, it would be good? (Me, I'm okay with people innovating, and believe HTML engines should be liberal in what they accept, but I'm having difficulty why some people object to "non-standard HTML" but this particular use seems to be some type of exception.)

"Superfluous elements like the back/forward buttons, generic browser menus and the URL bar can be hidden away, reducing user interface clutter."

The passive voice "can be" hides the subject here. I'm guessing that the eventual goal is to have both site creators and site viewers be able to customize the interface. But this is never stated directly, and so I'm unsure whether all see the implication here.

"AIR is similar to Prism in many ways, although it is based on the open source WebKit rendering engine (also used by Apple’s Safari browser on the Mac and iPhone)."

The brand of HTML renderer itself shouldn't matter much. I get confused when I see this listed as the primary distinction.

"The other big difference when compared to Prism is that AIR, in addition to web standards like HTML, CSS and JavaScript, supports Flash and another proprietary Adobe language called Flex."

Misunderstanding here. Flex's XML-based layout language MXML is never sent to the client; it is compiled during production to SWF. Assuming Prism supports standard Netscape Plugins, it should render SWF content too. When I read a sentence like this, I wonder if the speaker is under some misapprehension of the subject under discussion.

I haven't checked into the Mac-only "Fluid" application, but the emphasis on Greasemonkey in this section, and its lack of mention in the introductory section, makes me wonder whether Prism does not support it. But then he makes positive mention of future dual-creator development:

"In the long term, web developers will hopefully make modified SSB-friendly versions of their apps available, but in the meantime userscripting can be used to pimp them out directly on the client."

This is the interesting question for me -- how do we take existing in-the-browser experiences, and customize them for a particular non-browsing experience, while still allowing useful user modification of that experience too? That HTML page will also likely have to do double-duty for mobile devices and other non-laptop formfactors, and the needs of special audiences also impose needs to consider the audio-only presentation of the site, as well as the low-visual or motor-friendly presentations of the site. How should all these different presentations be represented in a single, human-readable HTML file? How do we regard HTML projects which do not offer particular representational hints? This is a discussion we need to have.

I don't see Google Gears in the same category, because it is a browser plugin which adds predictable logical abilities to a variety of web browser brands, and it has no user-interface elements of its own. It modifies an existing type of experience, rather than uniquely houses a new type of experience.

I'd hope that the Mozilla Prism runtime would accept the Google Gears browser plugin, just as it would accept the Adobe Flash browser plugin. I'm not certain about the political correctness of adding Gears-specific instructions to a webpage's JavaScript, but that's for other people to work through, not me.

(The article's introduction from Michael Arrington mentioned Microsoft's Silverlight, which still doesn't belong in any beyond-the-browser discussion. Once it finally arrives it will still be a browser plugin, like Gears or Player. Silverlight has nothing to do with the desktop, and it's a mystery why Mike still tosses it in with projects which do.)

"Offline functionality is key piece of the site-specific browser puzzle. Internet connectivity may one day be ubiquitous, but in the meantime web apps need to function offline if they are to compete with their desktop brethren."

This reads oddly to me. The "site-specific browser puzzle", for me, is still how something browses when it doesn't, but I suspect the speaker intends something else here. The need to support "occasional connectivity" and synch-upon-reconnect was outlined in the original whitepaper for rich internet applications... does this mean that "SSBs" must support the needs of RIAs?

After that, the goal "compete with the desktop" doesn't scan for me... you shouldn't care about "competing with native-code platform-specific locally-stored applications" so much as finding the new types of application support we need in this age of working among multiple machines and storing data in the cloud. The addition of this phrase makes it sound like the goal is to "compete with the desktop", instead of finding a real human need and filling it. I read it, I ask "Why...?"

"It’s pretty early to call a winner in the site-specific browser space, especially since heavyweights like Apple and Microsoft are probably poised to enter the game as well. But Prism has one big advantage: a killer app in the form of Firefox."

Again, this seems like a strange sense of priorities to me... the need to "be a winner" outweighing discussion of user needs and potential workflows. If I heard someone inside Adobe talk like this I'd feel uncomfortable, and would want to learn why and how they saw the world in such a strange and zero-sum way.

"AIR, on the other hand, has the advantage of using Flash and Flex to add sizzle to web app user interfaces, at the price of requiring potentially significant adaption on the part of the web app developer."

No, with AIR your existing HTML/JS/CSS in-browser apps can be very easily moved into standalone packages, and desktop APIs (for storage, windowing, notifications etc) can be added to that base HTML as you wish. Your webpage remains your webpage, but you can also make a separate, desktop-savvy package of those markup and scripts too. (You don't have to use any SWF at all in AIR.)

I think that the above quote is technically true (AIR can employ SWF's richer-than-JS/HTML media and interactions, but to use such richer abilities requires skill), but misleadingly implies that proficiency in SWF is needed for AIR. It could be phrased more clearly.

Matthew engages in the comments (kudos!), and here's another line which give me pause:

"My point about AIR is that, to get the full benefit of that platform, you need to use Flex/Flash. "

That's like saying "To get the full benefit of Firefox, you need to use Flash." Nitpickingly true, but many people create very satisfying web experiences without using any of the Adobe Flash technologies.

We've got a risk here because there's public confusion, and the above seems to imply that you need to learn both Flash and Flex in order to use AIR, which is not true at all.

For me, the top difference between the Adobe Integrated Runtime and what I currently understand of Mozilla Prism is the balance between creator choice and user choice. AIR lets you create a predictable beyond-the-browser experience; Prism lets the developer indicate how they'd like the presentation to appear, but the enduser can still modify the markup, scripts and styles they choose to package up in Prism. Two different types of contract between creator and consumer.

Any existing webpage can be repackaged and modified in Prism; any web developer can create desktop-optimized experiences in AIR. There's still an open debate up ahead on how to modify existing webpages to add Prism-specific features, which can then be modified by the consumer.

Beyond that, AIR 1.0 already has local storage and many other beyond-the-browser features. There's a current (and significant) difference in total functionality, although the specifics of the differences will presumably change over time.

Anyway, I'm glad that Mozilla Prism has another contributor, and I look forward to its success. I like the project, and am mostly concerned above with how we talk about and understand these technologies.