Peter Robinett shows you the HTML5 money:
However, to return to the original question of whether HTML5 could (or should) include anything that creates a business model for app makers, I say no. HTML5 is (should be) a technology standard, not a way to directly make money. Who runs the HTML5 App Store? Who charges the user and passes on money to the developer? The W3C? Looking at it from another way, there’s no reason you can’t drop in PayPal, Amazon FPS, or something similar to your web app and charge for the app or special features (in-app purchases) today.
Of course, the point is that Apple has created a system where the technology is tied to the platform API which is tied to the discovering, sales, and delivery mechanisms. The general web doesn’t have this, both to its detriment and benefit.
Ok, so on to Pie Guy:
Pie Guy is available for totally free from http://mrgan.com/pieguy. Hit that on your iPhone, install once, and play forever. By the way, if there are updates to the game and you’re online when you launch it, the updates will be automatically installed. Web apps, dudes.
P.S. If you’d like to tip your developer, why not buy a shirt. Or, heck, buy anything else on my Amazon Store.
I’m trying it out right now, haven’t used it enough to come to a conclusion. Installation was certainly painless, and the app looks incredibly smooth for a non-native piece of code. But even though I somewhat buy the engineering model, the “buy a shirt” business model doesn’t strike me as credible.
The app store makes money for developers because of how good a job Apple did on making it easy to purchase apps. Apps are cheap and the shopping experience is excellent, so that buying an app is the same kind of quick satisfaction as picking up a candy bar at a newstand that you happen to be walking by. I don’t *mind* coughing up a few bucks for the developers of a cool app, actually I kind of enjoy it. Tipping by buying a shirt or exploring a random Amazon store is not in the same league.
13 thoughts on “HTML5 iPhone game”
I don’t see how standard payment APIs are any more inherently “out of scope” for HTML5 than, say, geolocation APIs. I think the reason there isn’t any attention paid to this aspect of the web is due less to some essential division between technology and commerce than to the persistent “information wants to be free” ideology among many technologists, and the interests of the companies driving web standards.
Ok, so what would the payment API look like? I can conceive of such a thing in the abstract but when I try to come up with specific features I draw a blank.
HTML is about the formatting of a published work. That is a PRODUCT, a public good that is free to all members of the public who can access it.
Payment is something that is arranged in an agreement PRIOR to the manufacture or supply of the product.
It is only copyright that creates the notion that payment can occur over a century after production and publication but before another member of the public is permitted to receive/view a copy of such a published work.
This is why a payment API is as fundamentally inappropriate to HTML as copyright is to the Internet.
The only thing you need is a means of (as securely as possible) identifying a work and its author and provenance. There is scope for standardising this in HTML.
Given a published work and details of its author and provenance there is ample information available to would be patrons of that author and those whose shoulders they’ve stood upon, e.g. “I wish to patronise this author’s future production to the tune of £5 per subsequent work in this series or class – until further notice”.
Crosbie, HTML5 is no longer about formatting. It’s about building web applications. That’s why it has stuff in it like geolocation and background threads. Now we can argue about whether payment is a critical core functionality for web applications or not, but your argument about published works and copyright doesn’t really apply.
Lucas, I have no idea what a payment API would really look like. I’m imagining something like this: I configure my browser so that Citibank is my preferred payment handler (or more likely a wizard script on the Citibank site does this for me). The payment API just exposes a function for passing a payee ID, amount, and callback to my preferred payment handler. How Citibank chooses to structure the interaction after that is up to them, but once the transaction is cleared the callback is called with some sort of token and my MP3 starts playing, or my ebook loads, or whatever.
Ryan, it seems to me that the charter is to improve the payment and fulfillment process on the open web, in order to remove enough friction that content producers can make a living.
This is similar to Playdar, in that it’s a standard API to any number of music providers.
This should go without saying, but the question is how the open web can support the business goals of content developers as well as the app store does. Support needed may be HTML5, but it may also be HTTP or just an independent web service.
I think you’ve got it exactly right. Getting paid on the web should be as easy as publishing, and shouldn’t bind you to Apple, Amazon, Google, or any other single provider.
Ryan, geolocation and background processes are in support of presentation.
How is payment in support of presentaton?
I can see that details of the author/producer for any presented object and even their preferred payment service may be appropriately described in HTML5.
However, payment is about exchange. What do you have in mind that is to be exchanged and by whom?
Then perhaps we can consider how HTML5 can be used to help express and execute such an exchange (or enable the browser to).
I had assumed you had in mind some way that HTML5 could be used to attach micro-paywalls to presented objects or something like that, e.g. “This content or full functionality can be downloaded/unlocked for $5”.
A geolocation API can be used to conditionally present content based on the user’s location. A payment API can be used to conditionally present content based on whether the user has paid for it or not.
Look, I don’t necessarily believe that HTML5 should have a payment API, though I do think that the open web should support getting paid in a way that bind people to a single company. My argument is that declarations like “a payment API is fundamentally inappropriate to HTML” reflect an ideology, a belief about the way the web should work, rather than an essential truth about the way the web can work. At one time a lot of people would have argued that “a geolocation API is fundamentally inappropriate to HTML” based on a belief that cyberspace should transcend physical location. Clearly that belief is no longer very popular in the face of the money to be made with location-based advertising.
Note that I’m not trying to cast aspersions on ideology. I don’t think a non-ideological, “purely technical” stance on the web is possible. You can’t design the web without some set of beliefs about how the web should work. But we should try to avoid claiming that those beliefs are determined by the technology and thus not up for debate.
Hmm. It does sound as if rather than a payment API you’re after a licensing API, e.g. Conditional downloading of content based upon the presence of licenses on the browser’s system.
There’s a difference between adding value and subtracting value.
Using geolocation data to prevent the display of content unlicensed for the viewer’s location, is quite different to making the presentation of information more appropriate and useful in the context of the viewer’s location.
On a related tack one could argue that DRM’s only detractors are politically or ideologically driven. I think that is to misunderstand a far more fundamental reason why DRM cannot work.
As a software engineer I’m not persuaded by ideological arguments as to what is feasible or not. 18th century privileges that require information to remain uncopyable such that its distribution can be commercially licensed are not only ideologically unsound, they are also unsound from a software engineering perspective.
I’m all for facilities that help people exchange money with each other, but I’m always wary of ideological premises based on payment for ‘content’. It’s like proposals for perpetual motion machines. They’re attractive, but there’s a good, non-ideological reason to discount them.
Even so, don’t let me discourage you from explaining more about the payments you suspect HTML5 could facilitate and how it could do so.
Payment doesn’t imply DRM, except to libertarian software engineers who have been conditioned to equate the two. Software engineers ( I am one too) always claim to not be persuaded by ideological arguments. Usually this just means that they’re failing to acknowledge the unstated ideological arguments by which they’ve been persuaded.
Ryan, I mention DRM only as a comparator, as an example of ideology driven technology – “We don’t care how much it costs, but you WILL find a way to make music and movies uncopyable!”. Of course, if you have unyielding faith that DRM is a fundamentally sound proposition then any detractors will be seen as doing so from an ideological standpoint (instead of one informed by computer science) – you cannot afford to recognise the possibility that DRM may be a flawed proposition.
If you similarly start from a belief that it must be possible to enable recipients to be charged for the ‘content’ they receive, and HTML5 can provide a standard means of doing so, then you have started from an unsound proposition (one informed by copyright – an unnatural and unachievable constraint on the reproduction of intellectual work).
Just as there was plenty of well paid work in the development of umpteen DRM technologies, so there could be well paid work in the development of content charging/licensing technologies.
However, not all software engineers are mercenaries happy to be well paid to waste their time attempting what they know to be impossible. Making a computer intelligent is possible. Making information impossible to copy is not.
There remains plenty of scope however, for standard ways of expressing monetary exchange agreements. And that’s exchanges of work for money rather than liberty for money.
I’d check out http://www.replicounts.org for one avenue to explore – as something that indicates what kind of payment system might one day be appropriate to incorporate into HTML.
I found a database for html games: http://www.html-5-games.net. Not that good, but its a start to a revolution in browsergames ;D