A better article would be "Why Wired Didn't use HTML5 for their iPad App". Since that probably wouldn't have the same link-bait worthy title, I'll write one here.
Why didn't Wired use HTML5?
1) a) it was built by Adobe who build it on Flash to begin with, b) the tools just aren't there yet. c) because of #2.
2) Why is the app 500MB? Because all the rich content (images, movies, audio) are bundled into the app so you do not need an internet connection to view it. I think we can all agree that downloading a "magazine" before you leave the house, then finding you can't view most of it, would be an uber fail.
If the app had been based on HTML5 it would have been a 'mare to cache all of the content locally for offline viewing. HTML5 does offer local storage, but not in a way that would allow sites to cache 500MB of content. And even if they could, do you really want to wait 20 minutes for that Pixar feature to download over 3G?
I suppose you could have created a native app with everything bundled locally and a UIWebView for rendering the HTML5 content, but really what do you gain from that?
Why is the app 500MB? Because all the rich content are bundled into the app
The article says that rich content isn't the source of the bloat:
Each full page is a giant image – there are actually two images for each page: one for landscape and one for portrait mode.
If the app stored text as, you know, text then presumably it would require significantly less space. Eliminating the portrait/landscape duplication would also save space.
The crazy layouts wired is somewhat famous for hardly translate to plain text with a few graphics. I don't know what they use to layout their magazine (or what they used 10 years ago!) but it's not html5. Translating, migrating, converting, or adapting their content to anything other then an image (except maybe PDF!?) would be extremely non trivial.
Perhaps I'm being overly cynical, but if their intent was to show what a load of nonsense Apple's insistence that native apps are better is, it sounds like they couldn't have done a better job.
Yeah, I'm saying that from what I'm reading they must have intentionally been looking to create a completely native app that is worse than the Flash-compiled one.
That or the descriptions of the app are somewhat overcritical.
To entertain your reasoning: Adobe certainly could have intentionally created a "sucky native app" to contrast their "awesome Adobe iPhone OS compiler" but they mostly left out features and released a bloated (size) app. If they truly made a native app with HTML-based text and image optimization, or use their compiler, they could have equally reduced the size of this app and increased the functionality beyond what they have done here. Thus, the current implementation does NOT do a good job of proving that their compiler could have been better than a native Objective-C app.
Even so, if Adobe did want to throw a laughing cog at Apple via their clients, they're doing Wired a disservice, and frankly, that's terribly insane. They just couldn't throw a high profile partner/client under the bridge just to amuse some tantric executive war between Adobe and Apple.
Lastly, although hard to believe a company fairly technology agnostic as Wired would use their financial line (their money making product) as a way to experiment with dissing a technology giant, let's pretend Wired and Adobe both wanted to stick it to Apple for the 3.1.3 clause. They would be simply shooting themselves in the foot, as their customer is who really loses out here, not Apple.
It just make any sense at all, although I will give you that it's a romantic idea. More likely, they rushed a replacement implementation, since they couldn't use Adobe's compiler. Conde Naste clearly upholds Wired to the same deadlines as their other high end properties, and want to see a ROI for all the R&D they've had, perhaps. Becausethis certainly looks like a rushed implementation, or at a minimum, one done by amateurs.
If the app had been based on HTML5 it would have been a 'mare to cache all of the content locally for offline viewing. HTML5 does offer local storage, but not in a way that would allow sites to cache 500MB of content. And even if they could, do you really want to wait 20 minutes for that Pixar feature to download over 3G?
You can build an iPhone OS app that contains all of the data to be rendered by a Webkit UIWebView. Apps built on Phonegap use this technique, for example. It's possible to build a pre-packaged app that's basically a glorified Web browser with all of the content embedded inside as resources. The interactive elements could then have been made with JavaScript, rather than pre-rendered.
That's funny. As far as I can tell all the tools that are used for HTML (text editors and IDE's mainly) seem to be working pretty well for HTML5. And if you mean WYSIWYG then that market is dominated by Dreamweaver and even that has added HTML5 support.
Because you CAN churn out HTML5 in different text editors (or Dreamweaver) doesn't mean they're a GOOD way to generate rich content.
While I think Flash (the authoring tool) is a bloated mess, it's light years ahead of anything that exists for creating interactive content with HTML5/CSS/Javascript. There are no good tools for generating something like the Wired app in HTML5.
Actually, the Flash Builder app in CS5 can output to Canvas, but unfortunately, the latest version of mobile webkit that renders UIWebViews still has fairly poor Canvas rendering capabilities and performance.
Odd. I don't remember seeing that. My apologies :-)
I don't agree the tools are non-existent, but to the "wwhat do you gain from that" part: distributing a packaged "Web site in an app" has significant App Store and UI benefits over a paywalled Web site.
Ain't nobody talking about downloading the thing as you read it.
All of the content for an HTML 5 version could be stored offline, you'd be gaining massive size savings - which on limited mobile devices (not just the iPad) would be huge gains.
I'm actually considering writing an open source objective-c framework for specifically this purpose, I would hate for Adobe to get a foothold in this and kill the promise.
"I suppose you could have created a native app with everything bundled locally and a UIWebView for rendering the HTML5 content, but really what do you gain from that?"
An easy jumping off point for cross compatibility with Android, Windows, and OS X?
I just read through this issue of Wired on my iPad while on a plane. It was neat to be able to have the videos and such without an internet connection.
However, the real reason it is 500MB is the same reason the paper copy is so many pages...
More testing needs to be done on the Application Cache(http://www.w3.org/TR/offline-webapps/#offline), but you know it might just be possible to cache video content, and if not now it might be possible in the future.
There's absolutely no reason for it to turn out smaller. The meat of the app is in the media.
I make cocoa apps, and I'm pretty sure that the 'native' part of the app — the part of it that could be ditched by linking to WebKit instead – weighs in way under 10 megs
Because whatever software they use to layout the magazine can't export to HTML5. Since they're optimizing for time-to-market, they don't have time to retrain their designers to use different software, rewrite/extend it, or wait for the creators of that software to add export-to-HTML5 functionality, and so this was the most reasonable move. Give it some time, and they'll either move everything to HTML5 or a similar format with the features they need (their style of pagination, control over scrolling/swiping details in the UI, etc).
How have they optimized for time to market given that they have a large team of HTML-savvy web designers in house?
And what is the point of optimizing for time if you fail to deliver something that delights your market?
I haven't tried this thing, so please correct me if I'm wrong, but if every page is an image, how does one copy text? If there is text in a column, Double tapping ought to maximize the text to fit the column. I don't imagine that works either.
So they're making something that looks like a web page but offers less functionality. That's a very poor trade-off. Those 90s CD-ROMs made money for people back when browsers couldn't deliver that experience. They offered more functionality than the web.
Today, stuff like this offers less functionality. That's a big sacrifice to make.
hrm, presumably whatever layout tool they use can export to pdf, and presumably it would be possible to then use Scribd's html5 tech (or license the right to use it) to then make it html 5?
I specifically did not purchase the Wired app because:
1) It's freakin' 500MB! Even though I have a 32GB iPad, I want that space for music and videos, not a magazine that I'll probably read once or twice for each issue.
2) It was super unclear how much future issues would cost, how they would be delivered, and how much space subsequent issues would use.
I've been very unimpressed with what the media has been able to create with the iPad. I think Apple needs to host a traveling "Developer Days" focused purely on the media, helping them to create really killer shit.
After all, these failures only lend ammo to the anti-iPad Kindle worshippers, when the problem is really the ability for media to innovate.
Applications must be originally written in Objective-C, C, C++,
or JavaScript as executed by the iPhone OS WebKit engine
This means that any "interactive" elements must either be written directly in Objective C, or you're confined entirely to WebKit.
If you don't fancy building new Objective C apps every time you roll out an issue of your magazine, you have two options.. do it entirely in WebKit or pre-render everything and spew it out with a simpler native reader. Looks like Wired took the latter option. I'd always wondered how magazines would get around this issue - guess we've found out.
I don't really understand your point, can you elaborate? That's all that's being discussed here - native app vs. HTML5 (or some hybrid, which is perfectly valid under 3.3.1).
In an ideal world, your magazine app wouldn't be solely using Webkit, because you might want to create elaborate and performant interactive elements.
However, creating these "by hand" in Objective C for each issue would be time intensive. Instead, you'd usually use a scripting language or a framework like Flash to create interactive elements that are beyond JavaScript's reach. 3.3.1 invalidates this approach requiring you either go Webkit, totally native, or, well, nowhere. There is no middle ground for scripting within apps beyond JavaScript on Webkit.
Because consumers are not trained to pay for web sites, whereas they're trained to pay AppStore-delivered apps, that's why.
80% of iPhone/iPad applications, both accepted and rejected ones, would work great in HTML5; the figure is of course much higher for applications that might have been written in flash.
But discussions about Apple's languages, SDK or even hardware platforms are moot; the game changer for companies is the AppStore, and access to this AppStore is the only thing they truly care about. They can, but don't want to, distribute most of their stuff over plain old HTTP. What they can't is getting paid for doing so.
As explained elsewhere in this very thread, you can create App Store apps in HTML; there are already a ton of them in the store. Therefore the HTML vs. ObjC issue is orthogonal to the paid app vs. free Web site issue.
Watching all of the iPad demos, it appears very likely that publishers see this "new" format as an opportunity to monetize content that the web (HTML) has been marginalizing. At the moment, most users just want to read good articles and content, which is freely available on the web. Publishers, Wired in this example and many more likely to follow, are looking for a way to differentiate their content by building an engaging experience around it. No one really knows for sure how this work out in the long run, but I do agree with the author in that it is very reminiscent of the CD-ROM era.
We can watch 1080p video via YouTube, there is zero reason you can justify keeping it a non html5 app wih large downloads. Making an HTML5 magazine/blog/ipadzine is like a candy store to me.
If we purchase that, can we export it and read it in reader using an open and free format? I suppose again, we can't use it and are forced to go in p2p to fetch a converted and open version.
I'm always willing to buy e-books in open format and they always end-up in broken or/and proprietary formats that you can't read on your platform.
I get Wired magazine delivered to me by mail. The user experience is great, the pages turns just like real paper. The thing is indestructible too; I can drop it down a flight of steps without even a scratch showing up on it. My dog chewed up my first copy and it only cost me a few bucks to replace it. I can roll it up stick it in my pocket and read it at the beach, I don't even worry about getting sand in it. Can HTML5 deliver that experience?
The iPad edition of the magazine was originally made in a beta version of Flash CS5, relying on its ability to output iPhone OS apps. When Apple banned third-party runtimes, Adobe built Wired this horrifying hack. I think it's an InDesign plugin. The idea is that Wired's designers won't have to learn anything about the iPhone OS to create the app, but this is a pretty atrocious implementation.
No inside knowledge or anything like that, just from the description in the article above of what they're doing internally. Converting each page of the layout into two JPEGs, one for portrait and one for landscape. That's really wasteful and destructive, they're ruining the usability of text and turning their paid app into an inferior product compared to their website.
What the heck with the downvotes? Aren't the iPhone and iPad Operating Systems based on one another? I just thought it was funny that, at first glance, my brain saw something completely different than "iPhone Operating System".
The fundamental argument is flawed - I find it extremely hard to believe that anyone could create the same seamless experience as the iPad Wired app in HTML5. I certainly haven't seen any demo's that would imply it's possible, saying "you could do that in HTML 5" if very easy to say, a lot harder to do.
Maybe if the authors of these kinds of posts provided us with a demos I'd start taking these missives seriously.
It really is pretty much a slideshow. Even if you write it using webkit, you can ape whatever wonderful interactions you seem to be having (that I must have completely missed) using multiple UIWebView's and some good ol CoreAnimation.
You can also extend UIWebView with straight up Objective-C, further adding in the ability to do pretty much whatever you want.
There are a shit ton of HTML 5 demo's on the web. Try google.
I've seen a "shit ton" of demos and nothing I've seen is applicable to this problem. Wired is one of the most visually rich magazines around, it's layouts are complex, the visuals are rich, it's won many design awards - hundreds of people are involved in creating a beautiful design artefact. Writing an article that goes "wired sux, they didn't do it in HTML5" implies that the level of finish of the Wired app is possible, but I haven't seen any demos that are anywhere near the size and complexity of a magazine like Wired - if they exist I'd love to see them
Why didn't Wired use HTML5?
1) a) it was built by Adobe who build it on Flash to begin with, b) the tools just aren't there yet. c) because of #2.
2) Why is the app 500MB? Because all the rich content (images, movies, audio) are bundled into the app so you do not need an internet connection to view it. I think we can all agree that downloading a "magazine" before you leave the house, then finding you can't view most of it, would be an uber fail.
If the app had been based on HTML5 it would have been a 'mare to cache all of the content locally for offline viewing. HTML5 does offer local storage, but not in a way that would allow sites to cache 500MB of content. And even if they could, do you really want to wait 20 minutes for that Pixar feature to download over 3G?
I suppose you could have created a native app with everything bundled locally and a UIWebView for rendering the HTML5 content, but really what do you gain from that?