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.

It didn’t take long, however, for Apple to bow to pressure to release a native SDK, and they have done so with much fanfare. Considering Steve Jobs’s history for obfuscating his strategic plans, it’s quite possible that the whole “Safari as SDK” idea was just a smokescreen. On the hand, Apple’s ongoing work implementing HTML5′s application-centric feature and the inclusion in the iPhone 1.1.3 firmware of a feature to add Web Clips to the phone’s home page suggest that a web-based SDK is still in the works.

But does this even make sense? One of the biggest advantages of web apps is that they can be run from any computer equipped with a web browser (i.e. any computer not housed in the Smithsonian). This is clearly a moot point in the case of mobile devices since by their very nature they are with you at all times. Accessing apps on someone else’s computer is a dying practice anyway. When I first arrived in Prague, there was seemingly an internet cafe on every street corner. They are now few and far between as the population has become affluent enough for widespread private computer ownership. And a growing proportion of computer sales are for laptops that obviate the need to use another machine when on the road.

The other argument for web apps is that they enable the same code to be run on a multitude of different devices. Once again, this premise deserves close examination. Ajax-based apps require a lot of tweaking and testing to run properly in different browsers. Diverse form factors like mobile phones and TV set-top boxes require further customization. And while the open web crowd may froth at the mouth at the very notion, it isn’t clear why it would be in Apple’s (or any other manufacturer’s) interest to encourage development of portable apps when they can lock developers into their ecosystem.

Meanwhile, tools for web app development continue to lag behind those for native apps  (XCode, Visual Studio, etc.). Apple’s own online productivity suite, launched with its new MobileMe service, is a case in point. They’ve managed to create an impressive user experience, but you have to be a virtual rocket scientist to achieve this with Ajax techniques and tools. It’s much easier to use a proprietary framework like Flex which is designed for cross-browser compatibility and offers visual user interface design tools and the like.

As computing’s center of gravity shifts away from general-purpose desktop machines to mobile devices, set-top boxes, game consoles and the like, are native apps poised to stage a comeback?

Now, based on some tests run by one of its readers, The Unofficial Apple Weblog is suggesting that the next iPhone firmware release will include support for offline storage.  As speculation goes, this is pretty plausible. If true, it would represent a huge step forward for Safari as an alternative to the recently announced iPhone SDK. Once I can run my apps without constant network connectivity and store data locally where appropriate, the advantages of web apps will start to shine through: ease of installation, adherence to standards, multiplatform support and the like. Many web developers who might be disinclined to learn XCode and Cocoa will be in a much better position to get their apps on the iPhone, with the assurance that they will also run on OS X and even Windows (provided users succumb to the pressure to install Safari).

It’s interesting that Apple is relying on HTML 5 to launch its attack. In a way this positions it as an ally of Opera and Mozilla, the other vendors most committed to the standard. Interoperability with other browsers will be a powerful stick to beat up Adobe and Microsoft. And Apple doubtless believes that its formidable engineering muscle and control of the iPhone platform will give it a leg up when it comes to gaining market share down the road from its current comrades-in-arms.

Turning back to the iPhone, don’t expect support for Adobe’s Flash technology anytime soon. The full-blown PC Flash version “performs too slow to be useful” on the iPhone, and a mobile version called Flash Lite “is not capable of being used with the Web,” Jobs said. Without an option that falls in between, it sounds like Flash is not going to be supported on the iPhone until the performance of the underlying hardware improves.

For some reason the tech press picked this up as a full-scale smackdown. Kind of strange since a more rational way of interpreting his remarks would be to conclude that the iPhone is to blame, since it is too slow to run Flash properly. I friggin’ love my iPhone but it is kind of slow, even when running plain old JavaScript. When I last wrote about this, I cited an article in iPhone Atlas (another CNet property) that backs up Jobs’s assertions on every point, including the fact that Flash Lite is used by cellphone vendors as a tool for developing slick mobile user interfaces, not as a lightweight replacement for Flash on the web. It’s probably true that someone in a secret lab in the bowels of Cupertino has a Flash prototype running on the iPhone, but that doesn’t mean that it’s ready for primetime consumption, theories of a devious corporate blood feud notwithstanding.

Here’s my theory: Jobs felt the need to explain why Flash doesn’t run on the iPhone, so he did. How boring.

Our guess? If Apple does implement Flash support on the iPhone, it will be extremely limited — perhaps only including the ability to playback embedded Flash videos encoded in the H.264 format within MobileSafari but aggressively restricting the types of content that will load (there’s already a bookmarklet dubbed iTransmogrify! that will launch embedded YouTube content in the iPhone’s native YouTube player). Interactivity and full support for sites displayed with Flash simply don’t make sense on the current iPhone generation.

This is easy to believe in light of the poor JavaScript performance of Mobile Safari. We might have to wait for the next generation of hardware to get full-blown Flash support. There is a silver lining however: I care less about having Flash on my iPhone since Scrabulous has been forced to shut down.

Update: A reader points out that Scrabulous is still running. I assumed that it had been taken down in response to the cease-and-desist letter that Hasbro sent to its developers, but apparently not. Sorry, I should have checked my facts. Oh, and Scrabulous developers, thanks a lot. You ruined my punchline!

Ryan Stewart speculates that these new features prove that Apple is “very serious about an RIA strategy that seems browser based.” They still have a long way to go to compete with the likes of AIR and Prism. In particular, there is no mention of a mechanism for creating desktop shortcuts for web applications so they can run in their own process, independent of the browser (perhaps that’s what Ryan means when he describes Apple’s approach as “browser based”). What’s more, the SQL storage (which was integrated months ago into the WebKit engine that powers Safari) is only for application-specific data, not for code, so presumably this still won’t allow web apps to run without internet connectivity.

Nonetheless, I’m sure Ryan is right to speculate that Apple is brewing up a complete RIA platform. It will be interesting to see whether they create their own markup language for creating rich user interfaces (powered by QuickTime?), analogous to Flex and XUL, or whether they stick to the HTML5 spec. I’d also like to know when these new features will make their way into Mobile Safari for use on the iPhone. It’s worth noting that the latest 1.1.3 firmware lets you create desktop (well, Springboard) shortcuts, so the addition of offline storage (for code as well as data) will finally make their vaunted web platform viable as a proper iPhone SDK.

Update: A commenter points out that CSS transforms and animations are not part of HTML5. The same appears to be true of downloadable fonts. Needless to say, I put in these errors intentionally from time to time to check if people are paying attention.

Some of these devices offer a set of custom-tailored applications, specially designed with big honking fonts to be used from across the room. Apple TV is a good example, with its sparsely slick interface for navigating through a library of films, TV shows and music. What we haven’t seen so many of are general-purpose web browsers that run on the television. The Wii is a notable exception, with its Opera-powered Internet Channel controlled using the motion-sensing Wiimote.

My Mac Pro is hooked up directly to my TV set. When I’m sprawled on the couch watching a video, I’m not keen to move for anything less than an urgent call of nature. So it’s a drag that I can’t stop the video and surf the web without all that tedious getting up, walking across the room and sitting in front of the screen like a grown up. As more people find themselves with a computer of one sort of another connected to their television, this problem is bound to become more prevalent.

What’s interesting is that the TV’s form factor is not so different from that of a cellphone. It might seem odd to draw a parallel between a 3″ and a 40″ screen, but it terms of space occupied in your field of vision, the comparison holds up. The implication is that a pan-and-zoom interface like that of the iPhone would port nicely onto the family set. In the longer term, the growing number of websites that offer a simplified interface for mobile devices should be relatively easy to adapt for the browsing pleasure of couch potatoes like myself.

The iPhone browser, in particular, is ripe for an overhaul. Already it’s the only way to get the true unadulterated web in your pocket (unless you wear baggy cargo pants, in which case you could spring for an N800 as well), but this is Apple and I demand nothing less than perfection. Here are the first ten things that popped into my head.

1. Copy and paste

Yeah, I know, everyone is asking for this. A recent experience I had illustrates the need perfectly. I was in the airport trying to connect to the T-Mobile wifi hotspot. Since the Big T is my regular wireless carrier, I can request a login via SMS and have the charges tacked onto my phone bill. Unfortunately, the password is an implausibly long string of random letters, numbers and weird symbols. Without a clipboard (or pen and paper on hand), I was forced to memorize it, switch quickly over to the browser window and peck it in before I forgot it. Needless to say, this took me four increasingly frustrating attempts.

For those who haven’t seen it, this video gives a reasonable suggestion for how the feature could be implemented, as well as a cute reminder of the lengths to which Apple fanatics will go to demonstrate their obsession with the company and its products (right down to the Jobsian attire):

2. Flash

There are probably good technical reasons why Flash wasn’t included in the initial iPhone release. On the other hand, Adobe has Flash Lite, which is explicitly designed for devices with limited memory and processing power, and someone at Adobe told me that they had actually seen Flash (an early prototype, at least) running on the iPhone. I suspect that the motivation for this omission was strategic as well as technological. The fact that Apple has been touting MobileSafari as the phone’s application development platform suggests that it is planning a move into the Rich Internet Application space. This would put it in direct competition with Adobe.

Nonetheless, Flash has become an essential part of web infrastructure, too important to be used as a pawn in a corporate power play. What I mean by this is that without Flash support, I can’t play Scrabulous on my iPhone. That’s simply unacceptable. Or will Apple just go ahead and buy Adobe?

3. Better caching

It’s nice that Apple has made it possible to open multiple pages simultaneous in MobileSafari. But I want to be able to jump around between the pages at will, a habit that I’ve doubtless picked up from copious use of Firefox tabs. Often I want to look up something referenced in a page I’m reading, so I jump over to another tab before picking up where I’ve left off. On the iPhone, the old page is gone and has to reload. Like the lack of Flash, this is presumably a technical limitation, since holding web pages in memory takes up generous dollops of memory. Unfortunately it might be optimistic to hope for a fix in the current generation of the device.

4. Better scrolling

As you scroll down a long web page, the iPhone displays a translucent gray bar in the right margin to show you where you are. Nifty. But this is no use if you want to jump directly to the end of the page. Somehow it should be possible to grab the bar and drag it with your finger. I don’t know exactly how, but I’m sure Apple’s design geniuses can figure it out. In related news, tapping on the thin bar at the top of the screen opens the URL and search fields, but has the nasty side effect of scrolling all the way to the top of the document. This always seems to happen to me when I’m three quarters of the way through a massive article or blog post. The fact that there’s no way to scroll down quickly to where I was makes this doubly annoying.

5. Phone number editing

When the iPhone browser sees a string of digits that might be a phone number, it automatically turns it into a hyperlink. Tapping it calls up a dialog with two buttons: Call and Cancel. Oftentimes the number has (or lacks) a local prefix and requires some tweaking. The only way I’ve found to do this is to call the number, quickly hang up, go to the list of recent calls, add the number to my contacts and edit it there. Hardly ergonomic. What we need is an additional Edit button that lets the user modify the number before using it.

6. Offline storage

I’ve already said plenty about this. Perhaps I was a bit harsh in dismissing the new webmarks and jiggly homepage icons out of hand. They’ll be a whole whack more useful, however, when I can turn web pages into real apps that load from the disk and store their data locally.

7. Saving files to disk

The web isn’t just web pages. It’s frustrating that I can’t store files to disk for later use.

8. Make it faster

This is another “if only” type request. I realize that the slow page loading and rendering of the iPhone is inevitable with current technology in a device so small. It’s a miracle that they’ve achieved the very acceptable user experience that the phone does provide. But hey, this is my wish list, and I make churlish and unreasonable requests if I want to. After all, it often takes a good 20-30 seconds for a page to load to the point where I can start reading it.

9. Open pages in another window

When reading on the web, I don’t want to interrupt what I’m doing every time I come across an interesting link. On my desktop computer my finger is constantly twitching over the middle mouse button, which in Firefox opens a link in a new tab without leaving the current tab. When I’m done, I can go and read the pages I opened. (Or more likely I’ll move onto something else, leaving them to multiply uncontrollably until the TiVo anxiety gets too much for me and I close them unread.) Double-clicking on a link in the iPhone’s browser should do the same thing, opening the page in another window so I can read it later.

10. Sync bookmarks/pages with PC/Mac

As I mentioned, I’m a tab maniac and self-confessed information overload victim. What better way to save myself the inevitable pangs of regret I experience when I’m forced to institute a mass tab purge than to take the pages with me and read them on the go? It’s somewhat ironic that I can sync music, podcasts and even full-length movies to the iPhone, but I can’t copy over a handful of web pages (the storage requirements of which are trivial in comparison). I should be able to flag pages right in my desktop browser and have them copied to the iPhone’s disk next time I sync so I can read them at my leisure without having to download them again.

This is one of those cases of an enthusiastic developer answering a question theoretically. There are no current release plans for Opera Mini or any version of Opera for iPhone.

Translation:

I’m constantly telling company management to keep the developers tied up and gagged in the basement. Letting them out to interact with other people is only asking for trouble.

Regardless of the true status of these rumored plans, Michael then cuts to heart of the matter:

Safari is a great browser and all, but many are itching to see other browsers like Opera, Firefox and Internet Explorer (don’t scoff, there are plenty of reasons) running on their Apple gadgets.

[Michael, I'm scoffing. What are these reasons of which you speak?]

Are we headed to another round of the browser wars on the iPhone, or is it a broader war to be waged on multiple devices?

If so, who wins? On the iPhone in particular, Apple already has a head start. Who’s to follow next?

I discussed this informally with some Mozilla folks yesterday. Apparently they did consider porting Firefox to the iPhone but couldn’t see the point. Apple is clearly hoping that devices like the iPhone and Apple TV will expand their potential user base, the market for personal computers being inherently limited by their complexity. Seen in this light, the last thing you’d want is for grandma to be swapping out something as fundamental as her phone’s default browser. Naturally some technology fanatics won’t sleep until they get Emacs/W3 running on the iPhone, but then some people can’t wait to take a blowtorch to their brand new Porsche. This isn’t going to hit the mainstream. Ever.

At the same time, it’s an observable fact that the browser wars are going mobile. Competition between Microsoft, Opera, WebKit and Mozilla for inclusion on new devices is fierce. But the battle is for OEM deals, not for the hearts and minds of consumers. As with its Macintosh line, Apple is betting that its tightly integrated hardware/software combo will carry the day. WebKit is rocking and rolling, most recently as the browser of choice for Google’s Android platform. Microsoft is Microsoft. And Mozilla is finally taking the mobile space more seriously (with its engine already shipping on the Nokia N800). As on the desktop, the spoils will go to the vendor best able to make its browser a great platform for deploying applications, not just a vehicle for surfing the web.

UPDATE: Michael responds.