Playboy bypasses Apple's App Store, makes a web app instead
businessweek.com
businessweek.com
* Have to sign in every time you load the app.
* Herky jerky animations & orientation switching
* No offline access!
* Low-res images that are tough to read... in a magazine app
Granted these issues could be remedied in whole or in part if the web app was built with a little more thought & care, but the fact is that it wasn't: this is the user experience people will get when they view this web app.
I work on the web, and I build native apps for the iPhone & iPad. The reason I like building native apps is because the user experience is better. Everything's faster and smoother. If developers in here are putting technopolitics above the user actually using the app, then I think people need to re-evaluate why they build software in the first place.
My arguments for using open web technologies are purely based with the end users in mind, it may require some short term compromises in some areas of user experience (performance), but that doesnt mean we arent arguing for the best user experience possible.
The App Store is one tap away. Hundreds of thousands of apps all neatly categorized and sorted a bunch of ways. User reviews right on each listing with an overall rating count that's impossible to miss. One-touch purchasing, or, if free, one-touch downloading. It downloads in the background and can be paused/resumed whenever you want.
So exactly how will open web technologies (existing now, or in the future) be a better experience for users than the App Store?
I am not arguing about the user experience involved in using the appstore
- Consistent used experience, the same app can be built for every device, not duplicated (at least) 3 times which will lead to inconsistencies.
- Intercommunication, I can right now, open a web app on my mac, start using it, then send my current screen to my phone
- Availability, I have an app on my phone with my data that works offline, I still want to be able to access thing same thing using someone elses computer / phone.
Thats a few quick ones off the top of my head, we all know the common benefits of web applications, they dont need to be thrown out the window because of some low hanging fruit that can be fixed in the frontend, I mean not having offline access is not a fault of being a web app, it is purely a technical issue that can be fixed on playboys side.
Unfortunately, this also means that every application will offer an inconsistent UX to their users, as there is no adherence to any platform standard.
> - Intercommunication, I can right now, open a web app on my mac, start using it, then send my current screen to my phone
The ability to save state on a server is not constrained to applications running in a browser.
> - Availability, I have an app on my phone with my data that works offline, I still want to be able to access thing same thing using someone elses computer / phone.
You can do this with native applications as well, however, one of the significant market shifts that has occurred is that you don't have to.
Logging into websites from public computers was always a significant security risk and a trade-off between user experience and convenience; it was simply an inefficient solution to the problem of not having your own, locally trusted hardware.
With the introduction of lightweight, high-performance mobile computing devices using always-on internet access, the need to access your Yahoo mail from a 3rd party's computer has all but disappeared for a large (and growing) percentage of the population.
First, that's now what he said. "My arguments for using open web technologies are purely based with the end users in mind," and "but that doesnt mean we arent arguing for the best user experience possible."
Basically, you want to know this: "So exactly how will open web technologies (existing now, or in the future) be a better experience for users than the App Store?"
In context, it allows app makers to build the apps they want for their customers without requiring Apple approval that could/would prevent said app from being deployed.
Any discussion of iOS development and native v.s. web apps must include the app store and it's conditions. If your app cannot commit to those conditions, then you cannot release an app.
You could ignore the answer, but then you are faced with answering the question: How are native apps a better option for all cases? The answer, of course, is they aren't. Any argument otherwise is being dishonest.
These app stores, the Mac App Store, Android Market, the App Store, they give you very little considering the gigantic margin they take from you. It's almost intolerable. It seems it is intolerable for at least one major enterprise, Playboy.
Apple started high at 30%. If competition dictates, they can lower that percentage at any time.
They're also free to renegotiate a lower rate with specific content producers.
We were talking about the web. If there's a risk of webapps becoming competitive with native applications on the basis of that 30%, Apple is free to lower it.
Given that our clients have been discussing implementing webapps (in addition to their existing Android and iOS applications) entirely due to the 30% issue, this isn't that crazy.
> You may think developers will be more prone to writing apps for the Android exclusively but they won't because they would still be missing out on their 70% revenue from the iOS app store.
I'm not sure what you're basing this on; Android is a rapidly growing portion of our media clients' in-app purchase business.
How much you want to bet when that happens, Apple will release an update for iOS that cripples Safari and takes away some functionality in order to force developers to write native applications.
> I'm not sure what you're basing this on; Android is a rapidly growing portion of our media clients' in-app purchase business.
When you mentioned competition I just assumed you meant developers abandoning iOS and developing exclusively for Android (thus making customers want an Android device more and drive market share away from iPhone). I didn't think the competition you were thinking of was more and more web apps coming up to circumnavigate the 30% cut.
No, the real reason Playboy is going the webapp route is because Apple would never approve the content of the app. Apple knows that the web app experience is sucky compared to native apps regardless of the HTML5 hype. Even after a year passed after Jobs' pro-HTML5 and anti-Flash post, HTML5 still sucks, and Apple seems to be in no hurry except to pay lip service. After all, they have financial stake in native apps being better, especially for subscription based content,
That's been proven untrue with walled garden providers over and over again. Ever see a commercial for an Apple product? Apple has one thing in mind: the farming out of development to tens of thousands of little starry-eyed developers scattered around the world. As long as those guys keep cranking out things that make Apple look good and advance corporate policy, they're there to help both you and the user.
If you want to write inside the walled garden, have fun with it. Providing value to the user is the goal, right? In some scenarios it probably makes sense to develop in that fashion.
But not in every scenario. Don't go into this thing either blinded against using an AppStore or blinded towards using one. The truth is a lot more complex. I could list a dozen scenarios that easily would lead me to choose a stand-alone web app. "Technopolitics" or my personal opinion of Apple has nothing to do with it.
I'd be curious to know what those scenarios are, and whether your choice would actually be user-experience driven rather than based on developer preference or business constraints (such as insufficient resources).
For instance, why would you have to sign in every time? You can easily use cookies or HTML5 database to solve that in Mobile Safari.
Low Res images, too - since when is Mobile Safari constrained in that respect?
Also very cool of Playboy to prominently show the historically significant "Lenna" in their advertising.
Very fitting indeed.
http://i.playboy.com/index2.html http://en.wikipedia.org/wiki/Lenna
Yet it also states that Woody Allen also used the image in the film Sleepers in the same year.
Woody Allen hardly got the idea from reading academic conference literature.
Makes me think that the image must have made an enormous impact on its release in 1972. Makes you wonder what was cropped, although her face is very nice
While 'not really needed' is a literally true statement, the same could be said for running water and in-home heating.
Native applications are 'needed' if you want to provide the best possible user experience; Playboy is simply doing the best they can given the constraints under which they're forced to operate. This isn't the "right" direction, it's simply the only one available to them.
I don't talk about e.g. games or navigation apps nor am I denying the polish which went into the different native mobile frameworks/platforms.
I, for one, welcome our heterogenous appscape.
But why didn't Playboy use offline cache or something? Is it because the Mobile Safari is limited in that regard? I have a feeling Apple will hold off improving that feature for a long time.
The Gmail web app (along with some others I've forgotten now) seem to start extremely quickly when you bookmark them to the home screen.
Using the cache will automatically cache the index page by default, as it is the master file that is telling the browser to cache according to the cache manifest. Therefore, every time the browser accesses this file, it will be served from cache, even if you are online. That means that if you want dynamic content, you will have to make an ajax request to refresh the content on the index page. This proves especially frustrating if you have a lot of areas with dynamic content. And forget about doing logged in/logged out functionality.
Furthermore, when the cache manifest file is updated and the browser redownloads all the files, the updated files will not show in the navigator until after a refresh. So let's say you updated your index page and bumped the cache manifest to tell the browser to update the index page. It will first serve the old index page from the old cache, and then serve the new index page from the just-updated cache upon the next refresh.
So should the offline access store the entire history of articles? Or should it store, say, the latest accessed ones? If you just store the latest accessed issues, you would have to update the cache manifest file when a new issue has been updated, and then MobileSafari will need to re-download every single image file and asset over again. No diffs. Yuck.
There are a lot of compromises you need to make when building offline caching with MobileSafari using the application cache, and there is always the risk of the occasional refusal to cache which will require the user to manually clear the application cache in the settings (few will ever do that). Offline functionality is possible, but you will need to make serious concessions and work around the problems that caching currently has. Not to mention the little space given on disk for caching.
The way I tried to work around it, which is not foolproof but at least it's Windows XP compared to the Microsoft BOB of going all offline cache, is to use offline cache for assets (css, js, index file), use ajax to populate dynamic elements when online, and for the storage and retrieval of raw data, use the (now deprecated) Web SQL database. This is the approach Google uses for offline Gmail (screenshot for the curious: http://winning.markbao.com/6xyM/Screen_shot_2011-05-22_at_7....). This only works on iOS devices, though, and would not work for Playboy since their data isn't text, but jpegs.
tl;dr caching sucks.
"Using the cache will automatically cache the index page by default" => "...cache the page that you put the cache manifest reference to"
"This only works on iOS devices, though" => "This only works on Webkit devices, though"
In any case, this new subscription service only affects repeating payments right? So Amazon could still release the Kindle without that feature and it would still work with books that you have bought from the store.
Actually lets get some numbers for that.
Gutenberg ebook 11 (Alice in Wonderland) is available in kindle format 131kb. It is a short childrens book.
Gutenberg ebook 2600 (War and Peace) is available in kindle format 2mb. It is properly longer than most books though.
A tale of two cities (ebook 98) is also available, 506kb.
Anna Karenina (1399) is also available, at 1.1mb.
Twenty Thousand Leagues Under the Sea (ebook 2488) is 551kb with pictures, 518kb sans pictures.
So lets say the average book is going to be about 750kb and most people only need access to their three most recent books. That is only about 3-4mb - can't a web app store that much, client side?
They don't seem to stand a fighting chance as long as they are not indexed by the App store.
I expect to see more and more apps like this move to the web. It's easier to iterate and simplifies multi-platform support. Apps will be coded to native apis because they really need that kind of access, and not just because people expect software to be delivered that way.
You then make a similar note on the homepage.
Now if you don't have a magazine you can advertise on, it becomes a little harder.
The app store changed all this. Suddenly, downloading apps was cool and fun. With this new web-app paradigm we're back to square one unless Apple steps in.
I've got both a Galaxy S with Android 2.3 and an iPhone 3GS and I do use a lot of apps, but I knew about the existence of every one of them from -- the WEB.
I mostly search for brands (I'm sure a lot of people do), like Skype, Facebook, Flickr or Angry Birds. For my Android I couldn't find an official Flickr client, therefore I haven't installed one, preferring to use the web interface instead.
That's not to say that I haven't discovered apps through the app store, but their usage was less than a single day. And when I searched for a number blacklister for my Android, I had to search the web to find a reliable one, as there are at least a dozen in Google's app store with big ratings that don't work properly and none in iTunes (through the web I found out that I have to jailbreak my iPhone).
Really, the app store is good for providing a payments system and maybe getting some inspiration from available reviews when in doubt, but the reviews are kind of unreliable as devs found ways to spam or workaround bad reviews (like uploading the app under a slightly different name). It's terrible for finding stuff and it's useless for finding out what's possible/allowed.
How hard is it to get people to be aware of Playboy's website? With a brand like that, and money to market it, and high visibility through other publications, not at all.
Assuming it is, building a mobile website without a framework, be it jquery mobile, sencha, or sproutcore, shows how unaware the developers are of mobile browser quirks.
Even if it's iPad only at this point its rather nearsighted to assume they'll never want it to work on other devices.
And the people who built it have done a lot of graphics heavy lifting in javascript in the past.
Ian Gilman i.playboy.com: https://twitter.com/iangilman/status/71255767684100097
firefox panorama: https://twitter.com/iangilman/status/60395010868264960
deep-zoom/seadragon: https://twitter.com/iangilman/status/22789135248920576
Ditto Aseem Kishore: http://aseemk.com/projects/
I don't think this is intentional malice, merely simple neglect from Apple. Unfortunately, the result is the same. :(
It'll be interesting to see how Apple responds if they do get to be a huge success/poster girl (hah, see what I did there?!)