Archives for posts with tag: app

Straight from the horse’s mouth

By now you’re probably familiar with the 5by5 podcast network. If not, please do yourself a favor and visit their site. They have some great shows – The Critical Path by Horace Dediu is a house favorite. This week Mr. Dediu was a guest on The Web Ahead (another 5by5 show hosted by Jen Simmons) where he discussed how the forces of disruption apply to the web. It was an interesting discussion as usual, but if you’re pressed for time you should turn your attention to the bit after the sixty-five minute mark, when Horace volunteers some of his thoughts on the web vs. native application platforms.

His points are summarized in the notes below. Additional comments have been added in italic.

  • After the introduction of the iPhone, before the AppStore was born, there was this notion that people would get web apps on the iPhone. (Very true. The iPhone was launched in June 2007 and it wasn’t until mid-2008 that the iPhone SDK and the AppStore were announced. Upon launch, and for an year after that, the web was the official iPhone development platform)
  • There’s merit to the theory that the HTML5 technology will be disruptive to native apps, but nobody has solved the problem of where the money is going to come from. Usually the improvement of a technology comes from profits – the money tells you what’s the path the technology should take to improve itself. Horace calls this “the signal of pricing”. If you don’t have that signal, you’re dependent on intuition and committees (he probably means the W3C and he’s probably right, though HTML5 is more “market oriented”, having been born as a market reaction, in the shape of the WHATWG, to the slow-moving processes of the W3C ), and that doesn’t give you better information than the market does. The problem of HTML5 right now is that it doesn’t  have this “pricing signal” to tell it where to go. As a technology it probably has perfect or infinite potential, but it lacks that signalling. (This is an interesting claim, and while this correspondent is a believer in the efficiency of the markets, isn’t one of the characteristics of disruptive innovation the search for lower value markets that are ignored by an incumbent too busy with his cash cows? Isn’t Apple the incumbent and the AppStore the cash cow in this case?)
  • Native apps, on the other hand, are very well signaled by the marketplace (Signaled yes, very well signaled – well, that’s up for debate). And even if you consider the web technology superior to native technology, there are many examples of “less good” technologies with great market signals beating a better technology with less or no market signals. So HTML5 is an exciting technology with potential to disrupt native code, but we’ll need to see the revenue model.
  • Jen Simmons, the host, asks him to clarify what he means by a “market signal”. In case of apps, the market signal is the app store (you can probably assume he means application stores as a general concept encompassing the solutions from Apple, Google, Amazon and Microsoft and not the Apple App Store specifically). Apps didn’t come with the iPhone, Symbian had apps and Palm had apps. The word ecosystem as applied to an app market was coined by Palm’s marketing people.
  • The AppStore innovation (and here you can probably assume he means Apple’s, as it was the first to market with this model) is providing a central place, as prior to that you had dozens of stores all over the web for Symbian, Palm and Windows Mobile applications. When the AppStore came along and centralized it, it exploded like a supernova. The reason was improved discovery, quick publishing turnaround in a single storefront giving developers the ability to get metrics, actionable data to tweak application performance on the marketplace.
  • What is the HTML5 equivalent of this? You have the app, you have an advertising model, but that doesn’t resonate as well in this domain, so you haven’t solved that puzzle yet. The truth is we don’t know. Someone may figure it out at some point. ( There are web equivalents of some of the features mentioned above, and being centralized isn’t necessarily a boon for discovery. AOL wasn’t better than the web for content discovery, you just need the right tools – i.e. Google. Apple’s treasure trove is their database of hundreds of millions of credit cards and the AppStore billing engine with subscription and in-app purchase models. This is the killer feature of the native application distribution model that the web didn’t figure out yet).
  • On the subject of Google, he believes there are inherent conflicts. Here’s something Google should be nervous about: someone creates a killer app on Android, a content consumption app like Flipboard or Instapaper (call it Flippaper or Instaboard) and people start gravitating towards it, using the browser less and less. Android exists as a platform to enable an ad model and suddenly people are being pulled away from it, from their browsing behaviors that puts them in front of ads. How would Google react to this loss of eyeballs? Would they throttle back their support for apps? (Alternatively, you can ask what would happen if web apps start taking users away from the AppStore. Would apple throttle back their support for the web? Apple’s commitment is unquestionable. From the horse’s mouth: “We support two platforms at Apple. The first is HTML5, a fully-open, uncontrolled platform (…), and we are behind this 100%. It is fully open. The second platform we support is the AppStore.”  But would this level of support continue if the open web starts chipping away at AppStore revenues?)

Nothing that is said above is new to someone who has been following this closely, but it is overall an interesting overview of the Web vs. Native discussion. This is one of the favorite subjects around these parts, by the way, and one of the key battlegrounds on the upcoming web wars (FUD alert). Expect to hear more about it as this battle heats up.


Looks complicated – can you summarize?

Once upon a time there was hypertext, as imagined by Ted Nelson. It was to become an enabler of a distinct kind of media, named, not surprisingly, hypermedia. An upcoming boom of non-linear entertainment was upon us. Every written work would come in “choose your own adventure” format and new modes of storytelling would be created. As digital media evolved, people experimented with it, with varied levels of success. If you’re old enough (and geeky enough), you’ll remember Pepe Moreno’s Hell Cab. Or maybe Laurie Anderson’s Puppet Motel.

And then came Tim Berners-Lee and the World Wide Web. It soon became the first (some would say the only) real, widely distributed, mainstream application of hypermedia. Soon everybody was consuming internet-based hypermedia content through the magic of the Web. And though content adapted itself to the new medium, it wasn’t exactly revolutionized by it. A Wikipedia article has a beginning and an end. You may choose to jump from article to article without reading them whole, but you also could easily print an article and read it while sitting on a Chesterfield sofa with a Calabash pipe hanging from your lips and a trusted old corgi at your feet – like you would with an article from the Britannica, if the Britannica had an article on Furry Fandom.

[A somewhat related sidenote: Berners-Lee was very invested in the content creation side of the web. His first web client was both a browser and a content editor. In his book “Weaving the Web”, he describes how much time he spent prodding the makers of the early browsers like Viola and Mosaic to add content creation features to their browsers. He wasn’t very successful at that and it wasn’t until the advent of modern blogging tools that the less technically inclined became really able to publish on the web.]

But hypermedia isn’t dead (this correspondent was surprised to discover that Adobe is still shipping Director). And with the advent of “post-PC devices” (an euphemism for “the iPad”), now we have a myriad of hypermedia titles available – only we call them “apps” . Of course, some apps actually perform some sort of task, but many are storytelling programs that use hypermedia to deliver content. American Presidents or 50 Places of a Lifetime are good examples. This is the kind of software you would buy in the multimedia CD-ROM section of CompUSA in 1993.

But given the widespread availability of the technology enablers, hypermedia was supposed to replace books, or at least that’s what they told us in the nineties. This  is clearly not happening, though. While there are a bunch of hypermedia titles disguised as apps in the App Store, people are still massively going after the good old linear e-books acquired via iBooks or the Kindle store, and consuming them pretty much the same way books have been consumed since the St. Cuthbert Gospel was published.

That’s the market opportunity Citia wants to address.

From a user interface perspective, the solution is quite clever – Citia’s app lays out a book’s content as a 3D landscape, called the “glyph”, subdivided in the main ideas of the text. The main idea sections contain several “decks” which are then subdivided in “cards”. The cards are bite-sized concepts from the book and contain links to videos, other sources and additional text. If it feels familiar, that’s because it is – it’s a rehashed implementation of the old hypermedia promise. This time, however, it is quite well executed and pleasurable to use and read, with the exception of a few messed up UI affordances (it took this correspondent a little while to figure out how to change pages in the decks), and some weird UI oversights (the app doesn’t chart your progress through the text, so there’s no clear indication of what you have already read).

But the UI is only part of the problem, and usability issues are not the reason why hypermedia still doesn’t pose a credible threat to books. The proof of the pudding is in the content, and that’s where Citia still falls short. They have only one title out, “What Technology Wants” by Kevin Kelly. And while this is a fantastic book, that’s where things get a little funny. For the hefty price of $9.99 (in the deflationary app economy, any price about $0.99 is hefty), you won’t get a copy of the book, but a glorified CliffsNotes of it. The app offers you a summary of the main ideas of Kelly’s book in hypermedia format. If you enjoy it, there are convenient links to several bookstores where you can purchase the whole work for an additional $9.99 (if you’re getting it from Amazon). Nicholas Negroponte said “the value of information about information can be greater than the value of the information itself“. You should keep that in mind to avoid thinking you were just swindled out of ten bucks.

The promise of hypermedia is well known. Ted Nelson has been talking about it since the 60’s. And while the underlying technology to make it possible is finally here, the content is mostly not. And Citia’s approach doesn’t seem poised to solved that problem.

fuck you, pay me

(Part 1 here)

The road to success in technology is a bumpy one. Some rise to stratospheric heights and are acquired for a billion dollars by Facebook or (this just in) by Microsoft. Some are called scumbags by John Gruber.

Readability is in the latter group.

All the “Read Later” apps work pretty much the same, but what made Readability controversial was their original business model. It was a simple idea: collect a subscription fee from users, starting at $5 (users could voluntarily increase that value). Readability would take a 30% share and the remaining 70% would be distributed to the content providers users pulled content from  (30/70 is Apple’s revenue share model, so it’s by definition as perfect and precious as the golden ratio). This payout from Readability would compensate content providers for the lost eyeballs and maybe generate more revenue than the banners ever would.

This looks fine in principle, until you start digging deeper. There were issues with this proposed model, which have been raised by several commentators around the web, in different levels of virulence:

  • Readability was collecting money on behalf of publishers, without their acknowledgement. Users payed their monthly subscriptions, thinking they were supporting the creation of their favorite content, but publishers whose content was being consumed via Readability could be completely unaware that someone, somewhere was paying for their content to someone else.
  • Publishers had to opt-in to receive payments from Readability. So publishers  in the previous example, totally unaware that their users were paying for their content to a third party, would never collect a check because they just didn’t know Readability had forcibly inserted itself into their value chain.
  • The money Readability collected from subscriptions had a theoretical grace period. It was unclear what Readability would do with the money nobody showed up to claim.

If the fact that the paragraphs above are written in the past tense isn’t enough of a hint, here’s what happened: Readability dropped the whole model, won’t collect subscriptions anymore, and will donate the unclaimed publisher payouts to charity. In the end, they couldn’t resist a wave of widespread criticism that befell them, and had to pull the plug on the whole thing. Unfortunately, the loudest criticism didn’t come from publishers, but from people close to Marco Arment and to the Apple Khmer Rouge (feel free to use that term liberally). While some of the criticism was valid and Readability seemed interested in addressing it in good faith, they had to pull back as the situation became potentially harmful to their reputation. Which is what happens when someone who owns a very large megaphone starts saying your company “is run by scumbags”.

What this loud group of critics conveniently forgets is that the ethics of the “Read Later” category is murky by definition. These are systems designed to copy and repurpose third party content in an unauthorized manner. They do so by using the capabilities provided by an open web environment, and while nothing should be done to prevent these systems from working the way they work today, a player who seeks to compensate publishers fairly nonetheless should be praised and not vilified.

TL;DR – at least Readability was trying  to get people paid.

Readability’s decision is understandable, but unfortunate. There might be escrow alternatives Readability could have explored, and those could have cleared the most concerning ethical issues, while still providing a revenue opportunity for content partners. But alas, the environment just got too toxic. Now the “Read Later” segment is again composed of Instapaper and its copycats. And some think that’s just the way it should be.

(The image that illustrate this post is taken from an article on the Nieman Journalism Lab with an interesting take on this discussion from a content provider’s perspective)

Oh no he didn’t

In the beginning Jobs created the iPhone. Now the iPhone was fine and all, but had no apps. And Jobs said “let there be a native SDK and a cloud-based content repository with a delivery and payment mechanism”. And Jobs called the cloud-based content repository the AppStore, and people started downloading apps left and right and nothing that happened before that point matters anymore.

In the advent of the iPhone native SDK, of the AppStore, and of Apple’s treasure trove of a metric fuckton of stored user payment data, mobile development came out of the dark ages and a mobile application renaissance was upon us. One can easily think of some examples of poster boys of this movement. Rovio and its sullen poultry comes to mind. There are old examples like Smule and their Ocarina and newer examples like OMG Pop and their Draw Something. But this correspondent believes nobody represents the zeitgest as well as Marco Arment and his brainchild, Instapaper.

Arment came up with Instapaper as a side project while he was working as CTO of Tumblr, of which he is a co-founder. By reading the previous sentence you have already figured out he is not an ordinary developer. He’s an extraordinary entrepreneur, and his work is the driver behind two very successful products. Instapaper, for example, generates enough revenue to justify Arment quitting his position at Tumblr and dedicating himself exclusively to the app and the web service behind it.

Instapaper is very simple and useful. Let’s say you’re using your desktop browser and see an article on the web you want to read later. Just click on the “Read Later” bookmarklet and it will clean up the article’s mark up, remove advertisements and the site chrome, extract the content and store it online. The next time you open your Instapaper client on you phone or tablet, it will download the article you selected. There are a bunch more features, but this describes the gist of it. The app generates revenue through advertisement, a $4.99 download price on the AppStore, and an optional subscription of $1/month. The fact that there are who people actually pay this subscription is a testament to human generosity, since the paid version enables no real useful features. All the core features of the app are available with the one-time payment of $4.99 to download the app.

With the success of Instapaper, along come the copycats, like Read It Later and Readability. Read It Later is just a copy and its only claim to fame is being available on Android earlier (Arment only launched an official Instapaper Android client this month, after years of categorically stating his disgust for the Android platform, the business opportunity it presented and the wretched scum who used it.

Readability had other ideas. A company with some cred of its own, it has the backing of  people like Jeffrey Zeldman and Anil Dash. Readability wasn’t content with being a copycat – they wanted to innovate in the business model, and if you wish to believe their spiel, they wanted to save the print industry and the content provider, who has been arguably getting the short end of the stick in the brave new world wide web.

It’s important to understand that the “Read Later” category of apps operates in a legal (or at least moral) gray area. From the content provider’s perspective, the silent agreement with the content consumer in the web environment is that the content will be provided, but a set of constraints about how it will be consumed also needs to be respected. If the content was provided to the consumer in a 500 pixel-wide column with a 200 pixel-wide sidebar containing ads and links to related content, it is expected that the content will be consumed in this format. Of course this amounts to nothing more than an honor system, and in practice people do whatever the hell they want, and that’s the beauty of the web. They use browser extensions to strip out the ads, they screen-scrape and reuse page content in ways not authorized by the content provider and, of course, they user Instapaper or Readability.

Readability had a novel idea. They would repurpose, repackage and redistribute content like any other “Read Later” app, but they would also create a  subscription program and would share the subscription revenue with the content providers. Of course the devil was in the details, and that was the beginning of their problems.

(Part 2 here)