I’ve build a candidate version of Prism 1.0b2 (based on the latest Gecko 1.9.1 sources) for Ubuntu. Please let me know if you encounter any difficulties with it. I’ll try to get it onto the official site by the end of the week.
I gave a talk at OSCON last week entitled “Prism, Bringing Web Applications to the Desktop”. I’ve posted the slides with my script inline.
(As an aside, this is the first time I’ve ever written down a script for a talk. Usually I just run through the slides a couple of times to practice and then wing it on stage. I found it very helpful to write down the text and practice it verbatim, although I didn’t actually read it during the talk. One big bonus is that people who didn’t attend the talk will be able to follow it by reading the slide notes.)
I’ve built new versions of Prism based on the same Gecko 1.9.1 sources as Firefox 3.5. I also updated the Prism for Firefox extension so it runs on Firefox 3.5. I’d like to get these onto the official Prism site as soon as possible, but would appreciate if interested folks could give them a quick spin beforehand and let me know if they run into any problems.
I’m traveling right now, and my Linux setup is having some issues that prevent me from using it remotely. So for now I’m only posting builds for Mac and Windows. If someone Linux-savvy wants to volunteer to give me some quick technical support on IRC, that would help me to get the Linux build up as well. (Or if someone else wants to build it, I can explain how to do so.)
Google Chrome has achieved striking success considering that it has yet to celebrate its first birthday. Mike Arrington at TechCrunch claims that the browser now has 30 million users (citing Google as a source). [Update: The Google OS post mentions this in the second sentence so I'm not sure why I blamed Mike.] Market share figures vary wildly depending on who you ask, but it seems likely that Chrome now has at least 3-4% of the browser market. It is firmly ensconced in fourth place, behind Internet Explorer, Safari and Firefox. The latter, in second place, is a phenomenon in its own right, while the others are bundled with the two most popular operating systems and piggyback on their success.
Perhaps even more impressive is how effortlessly Chrome has carved out a recognizable niche for itself in a crowded, mature market with strong incumbents. All of its proponents that I’ve spoken to praise its small footprint (both in terms of screen real estate and system resources) and speed. Some may not agree that the browser should strive to be as minimalistic as possible, but it’s a defensible idea (and very smart positioning).
And now Google has taken the logical next step, announcing the Chrome Operating System. From their blog post this sounds like the minimum required to tie Linux (universally accepted as the open source kernel of choice) to the browser. The goal is to “re-think what operating systems should be”, adapting them to a new era where apps will run on the web exclusively.
This leaves Mozilla as the only major browser vendor which doesn’t have an operating system. Does it need to address the threat by coming out with an OS of its own?
One counterargument is well expressed by Mozilla CEO John Lilly:
Google, when they launched Chrome, the name Chrome was an ironic title. It implied they wanted to build a browser that didn’t have any chrome, that didn’t have any user interface – they just want to be a pane of glass to the Internet. Setting aside for a minute whether that is even possible, we think the technical term for a browser is a user agent. We think the browser can do much on behalf of users – it can help you find stuff, it can help you figure out what you want – but it can also mediate between what’s on your desk and what on the Web. It can meld those two together, mash them up so to speak. I think the browser sits at the interesting interface of client and cloud and there will always be that interface.
I brought up another in relation to Google Docs and other web-based software:
So now I know why Google Docs hasn’t encroached more significantly on Microsoft’s turf: it kind of sucks. Don’t get me wrong, I don’t need or want the zillions of bizarre features that traditional shrink-wrapped vendors insist of pushing on users in order to drive revenue from useless “upgrades”. But something as basic as table management should just work, and the exported output should look like the original document, dammit.
Despite Arrington’s assertion (in the above-linked post) that “you won’t miss Office” thanks to web-based alternatives, the opposite is true at present. I talk to people constantly who won’t even switch to Mac Office because it isn’t compatible enough with the Windows version.
That said, I believe that the shift of software to the web is an inexorable trend. Google recognizes this, and they are tailoring their strategy to the world five to ten years out. This is sensible since it will take that long to put together a viable alternative to mature operating systems like Windows and OS X. By extension, Mozilla may find itself in an untenable position in this timeframe. If Google is successful with its strategy (which in practice means OEM deals that will see its OS and browser shipped pre-installed on new computers), Firefox will be the only major browser that has to be explicitly downloaded and installed by its users.
Firefox isn’t in any immediate danger. But if Mozilla wants to protect its turf over the longer term, it may want to follow Google in developing a lightweight operating system focused on the web, just as it has started to take the mobile space more seriously in the wake of Mobile Safari and Android.
A couple of Prism-related links via Mark Finkle:
Any other interesting Prism sightings? Let us know in the comments!
In a blog post about the recent Prism 1.0 release, Lifehacker expresses confusion about some of the new Prism features:
Mozilla’s caught on to this kind of open-when-needed use, adding built-in support for tray icons (on Windows) or system dock shortcuts (on Macs), along with minimizing the sites to those areas. The other good new things are font control and private data clearing for each window (which was a not-too-small complaint about the previous Prism), and support for notifications and icon updates when you’ve got a new message, chat, or other ping from your web applications (for those sites that support it). I couldn’t quite figure out how to get new mail notifications or icon indicators showing up, but the Prism Features page touts them as present. Anybody want to show us how in the comments?
Like some people’s love lives (if Facebook is to be believed), the answer is: it’s complicated. Adding a tray icon to your application (on Windows) is simple enough. Just set the value of trayicon in the webapp.ini file to true. The application will automatically hide in the tray when you minimize it. Okay, perhaps this wouldn’t pass the “mom test”, but it’s all relative, and making use of many other Prism features is currently less straightforward.
Getting your mail client to display popup notifications when new mails arrive, for example, is more difficult because some knowledge is required of how the web app works. How does Prism know when to display a notification? Either the application has to tell it, or a third-party developer has to use Prism’s customization features to do the same. (If you don’t have at least some notions of and/or interest in software development, you might want to mumble “javascript schmavascript” now and skip to the last paragraph.)
To make the first option possible, Prism defines a new property called platform on the ubiquitous window object found in every web application. Various functions can be called on the window.platform property. (I must admit shamefacedly that the source code browser for Prism is updated only sporadically and is currently a bit out of date, something I hope will be addressed soon.) For example, to display a popup notification you can say:
window.platform.showNotification(
"My notification",
"I'm your app and I just wanted to say hi.",
null
);
Since window.platform is available to web content (as long as the user is running Prism), developers could add statements like this to their apps to make them more Prism friendly. Realistically this is unlikely to happen unless some sort of standardization occurs around this type of API, and browsers that support it become quite popular (both are likely, in my opinion, but not in the short term). In the meantime, a magic file called webapp.js lets you graft code onto an existing web app that adds support for fancy Prism features. (I won’t get into details now since I am planning a tutorial on this topic.)
The bad news is that you need to be a fairly determined and ingenious programmer to get the most out of Prism right now. The good news is that once someone has gone to the trouble of customizing a specific web app, their work can be packaged as a webapp bundle and distributed to other users, much like Firefox extensions. Now that the 1.0 release has given us a robust set of features under the hood, our next task is to foster an ecosystem of webapp bundles for popular web apps, so that end users and not just developers can get the most out of Prism.
To prepare for the major new Prism release that is currently in the works, I’ve created release candidates of both the standalone app and the Firefox extension. They can be downloaded using the links at the bottom of this post. We’d love it if people would download these builds and give them a spin. Let me know by commenting here or filing bugs in Bugzilla (in the Mozilla Labs/Prism component) if you run into any difficulties.
Some important notes:
I’ll post a followup describing the new features since the last update. I use Prism right out of the box for a few of my most important web apps (Gmail, Facebook and SlimTimer), and it’s darn useful just to have the apps running in their own process with their own icons in the OS X dock. But where Prism really comes into its own is when the apps are customized to use all its fancy features. I’m hoping that some developers will overlook the sparse documentation and give this a shot. If you want to add tray icons, tray/dock menus, drag-and-drop support, popup notifications and the like to your favorite web app, let me know. I’ll be happy to provide some guidance.
Prism standalone version 0.9.9 RC for Mac, Windows and Linux
I was chatting recently with the founder of a high-profile startup that is making strategic use of Mozilla technology. “People keep telling me that WebKit is the future,” he complained. “Have we made the wrong choice?”
I did my best to reassure him of course, providing arguments that support their choice and pointing him to a blog post by a GNOME developer that gives a fair and balanced assessment of the merits and drawbacks of the two platforms. The truth, however, is that the second wave of the browser wars — the platform wars — is now in full swing, and so far WebKit is winning.
WebKit has decisively chalked up a few early battles. Apple choose WebKit as the engine for Safari back in 2002. Mozilla would have been a logical choice, but those were early days, and even Mozilla insiders say they probably weren’t ready to serve as the foundation for another major browser. Google’s decision to use WebKit in its Chrome browser is more telling. The reality is that, although Mozilla now has a stellar platform, they have made it clear that their primary focus is on Firefox. WebKit, on the other hand, is first and foremost a platform, and as such has an inherent appeal to software developers looking to build their own browser or embed browser functionality.
Well, so what if a bunch of products adopt WebKit over Mozilla? (Flock is the latest to plan a switch, if you believe the rumors.) Firefox is a hugely successful brand, with steadily growing market share that recently topped 20%. And competition in the browser market is a good thing, as Mozillians are quick to point out, and will only serve to accelerate innovation to the benefit of end users.
Mozilla has established principles that imply a custodial role for the internet at large. It is becoming increasingly clear that software that provides some browser functionality (but may not be a browser in the traditional sense) is going to play a bigger role in the future of the web. From media browsers like iTunes and Songbird to single-site browsers like Fluid and Prism, people will be accessing the web via a variety of products in the future. If Mozilla fails to compete effectively in the platform space, it will see its market share decline even if Firefox holds steady among traditional browsers.
This means that Mozilla will be less able to pursue its stated mission. It will be handing control to large corporations like Apple and Google.
Mozilla knows this of course, and they’ve done many things recently to respond to the WebKit threat. The Fennec mobile browser is clearly a huge strategic priority, an attempt to counter the current dominance of WebKit in that space. Firefox’s memory consumption, long a sore spot, has been dramatically improved. And a few individuals have made heroic efforts to make Mozilla more appealing as a platform, rationalizing the code base and rearchitecting Firefox so that it runs on top of XULRunner.
I think more is needed. In particular, I would love to see a reversal of Mozilla’s decision not to “invest in a pre-packaged or stand-alone XULRunner at this time.” This is as much about public relations as anything else. They already offer nightly builds of the platform SDK. (Can we have debug mode though, pretty please?) The platform documentation is so improved it brings tears to my eyes. But hardly anyone outside of the Mozilla community knows about these things. A big loud honking public statement that the platform is being actively developed and marketed, as a product, would in itself be a huge help in getting people to choose Mozilla for their software projects.
The other area screaming for improvement is platform evangelism and developer relations. A funny quote in the TechCrunch story about Flock dumping Mozilla (true or not) cites a “source” complaining that they feel like the “red headed stepchild of the Mozilla development community.” This might seem a bit overboard, but the last open forum I witnessed between Mozilla and users of the platform rapidly descended into a heated shouting match that I thought, for a while, might come to blows.
I don’t want to be seen as airing dirty laundry here. There are tensions inside any developer community, and not all of the complaints (expressed loudly by a few individuals) were fair or reasonable. When I was new to the community, I found Mozilla employees to be exceptionally welcoming and helpful. But I still believe there is a lot of room for improvement. It would be fantastic if Mozilla would appoint at least one individual whose specific role it is to act as a liaison with developers using the platform. A clear go-to person who can help developers to get their patches landed (or explain to them in clear, diplomatic terms why they won’t be) would be invaluable. This person could also help to evangelize use of Mozilla as a platform.
I’m not too worried about Mozilla’s technology. WebKit may be the shiny new toy, but on balance Mozilla stacks up well in terms of performance, stability, standards compliance and features. More to the point, a lot of folks smarter than me are aware of the technology’s shortcomings and are continuing to improve it on many fronts. What is missing so far is clear, public recognition of the strategic value of having a competitive platform.
I’ve posted the slides for my FOSDEM 2009 presentation entitled “Prism: Wherefore and Where to?”.
I’ve read the Economist religiously for over 15 years. For many of those years I bought a copy every week at the newsstand, and I’ve subscribed for the past couple of years. A few weeks ago, I let my subscription lapse. The reason is a web service-cum-iPhone application called Instapaper. Dragging their bookmarklet into your browser’s bookmark bar adds a button labeled “Read Later”. Click this button on any webpage, and it is added to your reading list. Sync to the iPhone app, and the article is available for reading on your mobile phone.
This approach has two particularly appealing aspects. First of all, the articles are formatted for easy reading on a small screen. Images, sidebars and the like are stripped off, leaving the raw text in a nice big font. Secondly, the text is stored on Instapaper’s server and downloaded to your phone when you sync. This means that you don’t need a live net connection to access it, nor do you have to put up with MobileSafari’s slow loading times and inadequate caching behavior. The latter is particularly irksome because I don’t always read an article in its entirety in one sitting. With Instapaper, my reading list is accessible at the click of a button, and when I select an item that I was already reading, it pops up immediately in exactly the spot where I left off.
I did a bit of hacking on a very basic Firefox extension called Instabutton that adds a toolbar button (rather than a bookmarklet) with the “Read Later” functionality described above. So now I have a context menu item in Firefox called “Instapaper” that I can select for any link on a webpage. When the Economist comes out on Friday, I go to their website and load up the table of contents of the new issue. With a click, select, click, select, I cruise through the articles picking the ones that catch my eye. The whole process takes a few minutes. The Economist erudite prose sits alongside various other publications and blogs in my Instapaper reading list, meaning that I have access to a broad range of material whenever I have my iPhone with me. Which is always.
With all the morbid commentary about the imminent death of the publishing industry, my first reaction was to see this as further proof that traditional newspapers and magazines are doomed. The few remaining advantages that print has to offer — convenience and portability — are vanishing with the advent of portable reading devices (something I predicted five years ago). Now that I can get my weekly Economist fix in my pocket for free, why would I waste my money on dead trees?
My second reaction was to see this as a huge business opportunity for publishers and for enterprising software developers looking to attach combine an Instapaper-like app with an iTunes-like payment model. This is particularly easy to imagine in the specific case of Apple and the iPhone. Naturally publishers would have to restrict free access to their content in some way, but assuming they do, wouldn’t readers be willing to pay a fee for the great user experience I now enjoy, in the same way they’ve shelled out billions for songs on iTunes thanks to the full service convenience of Apple’s service?
Not according to Clay Shirky they won’t. In a post entitled “Why Small Payments Won’t Save Publishers“, he argues that publishers will not be able to save themselves by charging for their content. (And he helpfully links to a number of articles in the mainstream press that outline ideas very similar to my own, if only to debunk them.) Clay’s post did not convince me that the charging for textual content is a non-starter, however. Quite the contrary, the piece struck me as ideal fodder for a merciless fisking.
As background for his argument, Clay first contends that the term “micropayment” is misplaced in describing a putative paid content system, citing an upper limit for payments that are truly micro that I suppose he extracted from somewhere in the nether regions of his anatomy. Well, who cares? Whether we choose to call them micropayments or floozlebeezies has no material impact on the potential merits of such a system.
His second piece of background is that small payments won’t fly because users don’t want them:
The other key piece of background isn’t about small payments themselves, but about the conversation. Such systems solve no problem the user has, and offer no service we want. As a result, conversations about small payments take place entirely among content providers, never involving us, the people who will ostensibly be funding these transactions.
The implication is that paid content can only succeed if it is actively sought by us, the “users”. Perhaps I’m missing something, but in this context I don’t see any difference between paying for content and paying for anything else. Carmakers charge for cars because they need revenues to pay for capital, labor and to provide value to their shareholders. Car buyers aren’t clamoring to pay for vehicles, in fact I’m quite sure that few indeed would say no to a free SUV or Prius. Publishers have costs and shareholders as well, and it is quite natural that they would like to charge for their wares whether their customers want to pay for them or not.
As far as the analogy to successful paid content systems like iTunes is concerned, Clay rejects it by claiming that these systems have thrived only because they rely on “closed systems” that give consumers no other choice than to pay for a particular good (ringtones, online avatars or whatever). Regarding iTunes, he states that:
Apple’s ITMS (iTunes Music Store) is perhaps the most interesting example. People are not paying for music on ITMS because we have decided that fee-per-track is the model we prefer, but because there is no market in which commercial alternatives can be explored. Everything from Napster to online radio has been crippled or killed by fiat; small payments survive in the absence of a market for other legal options.
Potentially convincing if it were true, but the evidence suggest that it isn’t. Rhapsody, for example, is an all-you-can-eat music subscription service that has some passionate adherents. In iTunes I can choose from dozens of free online radio stations offering music. If iTunes has succeeded with a pay-per-download model, this isn’t due to lack of competition. It is because listeners consider the product and user experience to be superior to alternatives.
The meat of Clay’s argument comes in the last few paragraphs:
Meanwhile, back in the real world, the media business is being turned upside down by our new freedoms and our new roles. We’re not just readers anymore, or listeners or viewers. We’re not customers and we’re certainly not consumers. We’re users. We don’t consume content, we use it, and mostly what we use it for is to support our conversations with one another, because we’re media outlets now too. When I am talking about some event that just happened, whether it’s an earthquake or a basketball game, whether the conversation is in email or Facebook or Twitter, I want to link to what I’m talking about, and I want my friends to be able to read it easily, and to share it with their friends.
In other words, articles hidden behind a paywall will fail to attract readers because we can’t link to them or share them with our friends. Searchability and linkability are certainly important, and publications that charge for articles currently tend to address this by offering the first few paragraphs of an article for free so that it can be linked to and crawled by search engines. But still, the point is valid. If heaping servings of free content are only a google away, getting people to pay for your content is going to be a daunting challenge.
One thing I don’t like about this line of reasoning is that it implies that all content is basically created equal. Any plan to charge for articles rests on the inherent assumption that that content has a particular appeal that can’t be satisfied elsewhere for free. If that isn’t true, then Clay is absolutely right, and no payment system for textual content will ever make it off the ground. It beggars belief, however, that readers will abandon well-written, well-researched journalism and commentary written by professionals for amateur blog posts rather than pony up cash for the former. The reason print media is now struggling is primarily due to competition from the very same publications’ free websites, not from the amateur blogosphere. Otherwise, why are folks willing to pay for the latest Bruce Springsteen or Madonna album when there is plenty of free amateur music from wannabe rockstars available online?
Successful implementation of a payment system for online articles will be tricky. Proponents will have to get a lot of things right, just as numerous music services came and went until iTunes found the right balance of inobtrusive (and now non-existent) DRM, convenience of purchasing and smooth integration with portable listening devices. It will also require that a critical mass of content comes on board (another point I made a few years back). Publishers will start by dipping their toe into the waters of paid content, but when the proverbial tipping point is reached, and finding quality content for free is no longer trivially easy, they will dive in en masse.
It won’t be easy, and it will take a while to get right. Considering the surprising success of the iPhone as a reading device, coupled with its unique track record of confecting the right user experience and its existing content distribution and payment systems, Apple is a leading contender to be the first to market with a viable offering. Amazon, who is making headway in this market already with the Kindle, is another strong candidate. (Maybe I should mention that I own shares in both these companies, but then I only bought them because I believe them to be so well-situated to take advantage of ongoing shift to paid digital media.)
Rather than being a lost cause, payment for online articles has an air of inevitability. Clay underlines this point himself when he states, quite correctly, that “if small payment systems won’t save existing publishers in their current form, there might not be a way to save existing publishers in their current form.” Can you imagine a world without the well-crafted prose of the Economist or New York Times, without the type of informed journalism that depends on the deployment of trained professionals across the globe? I certainly can’t. And this alone is sufficient reason to believe that, one way or the other, we’ll be paying for much of what we read online at some point in the not so distant future.