Wired’s new iPad app was released on May 26, 2010 and instantly became Apple’s iPad App of the Week. It has been touted as the future of magazines and a bold step forward for digital and interactive content. Indeed, someone who works in the publishing industry has even said, “It is, ultimately, the best digital magazine on the best platform yet for digital magazines.”
Before I get to the real focus of this article, I’ll list some of the features and technical specifications:
Exclusive iPad content.
Interactive features.
It supports portrait and landscape modes.
It costs $4.99.
It’s a 527MB download.
Wait, what? 527MB for just one issue (June)?! What could possibly take up so much space? It turns out I wasn’t the only one that had the same thought. Layton talks about how the app is structured in his recent article. In another, more technical article talks about how the app could be implemented using HTML 5. Here is another interesting and in-depth article. (I made a lengthy comment to that last article. This post is based on that comment.)
The Technical Stuff
The other articles describe in various details how the app was implemented, and since that’s the foundation of my post, I’ll briefly describe what it’s doing.
At its core, the Wired app is basically an image viewer with a few extra features. It supports portrait and landscape reading and also has some limited interactive elements (playing videos, showing an animation of 3D rendered characters, and so on).
There is a generic viewer app, which, to be fair, is tiny. The exe and supporting interface images is a mere 571KB.
There is full-screen video included in the bundle, but the total size for those is only 138MB. MP3 audio files consume another 24.1MB
You might be wondering by now what’s causing the bundle to be so large. It’s the content pages. (For those keeping track, we’re talking about 360MB.)
One of the main reasons that the interface is so pixel-perfect is because every page is a PNG image. A graphic artist created the layout (perhaps using the same layers as the print edition as a starting point), flattened it to an image, and handed that off to the programmers for integration into the app. Maybe a tool was created to simulate what the app does so a programmer might not even be needed. The graphic artist did this twice for every page in the issue. Once for portrait, and again for landscape.
In addition to those two versions are four additional copies of every page. There is a thumbnail and a preview version used for navigation.
Every article (not individual page) gets an additional image for the table of contents preview. Think of it as an icon for each article that the table of contents list displays next to each entry.
In the example below, I have shown all permutations of the front cover plus the thumbnail.
Wired App Cover Images
I processed these images and was able to reduce their footprint by 40% without changing the bit-depth. If done over the entire set of (over 4100) images, I think the savings would be significant.
All of the data is contained in a 1.5MB .XML file that describes each page in its various forms. It’s good to see the engineers have taken a data-driven implementation. This allows for a generic player to present issue-specific content and paves the way for future issues.
I find it curious that there is no feature reverse-pinch to zoom in. Why not? Since they’re images, it would be pretty straightforward to implement.
The Real Issue
There are some things that we as developers need to discuss: When does download size start to become a problem?
Somewhat intertwined with this notion is this fundamental question: does the user care what the download size is? From the comments I have seen in my research for this post is that no, the user DOES NOT CARE about download size, as long as the experience meets their expectations.
As developers, we have been trained to do things as efficiently as possible. (This is actually debatable now. Recent trends indicate that developers on ‘capable’ platforms don’t care about efficiency. A topic I will address in a future post.) That always becomes a trade-off between time, cost, and quality. My question to those users that don’t care about download size is, “WHY don’t you care about download size?”
Why do we developers (granted, I am a game developer, but in this case, software is software) spend so much time on making everything perform as efficiently as possible when the user doesn’t really care? I think for me, the driving factor is what other developers think of the solutions I have engineered.
What I don’t respect is the solution the Wired developers have implemented. To me, there is something fundamentally wrong with a magazine that is over 500MB. It’s just a stylized image viewer. Surely there’s a better way to implement it than images.
Wired is not the only popular app that uses a similar solution. Alice for iPad is an example. No one really noticed because it was a relatively lightweight (when compared to Wired’s certainly) because it only supports portrait, has far fewer pages, etc. However, the implementation is the same: highly stylized pages essentially presented as a slideshow.
Are you from The Future™?
The Wired app has been touted as the (possible?) future of magazines, but is it really? As developers, is this what we have worked so hard for? Get the artists to render every single page 6 times and slap them in? In my opinion, this doesn’t push our craft forward. Quite the opposite, in fact.
Do the users care? Mostly not.
Does Apple care? Not in the slightest because the Wired app instantly became the iPad App of the Week.
Do the developers care? Obviously not (right now) because they implemented this solution…and they’re seeing their app become the Top Grossing App. Perhaps it was purely a time constraint with this first digital issue and they’re going to address the problem in future issues. Only they would know that. Given the recent news, one can only hope they will. The official Adobe page on digital publishing was unveiled today.
You might have noticed that I haven’t talked about the cost. I did this for a reason: I don’t care what the cost is and it’s not related to the point I’m trying to make. It could be free and I would still not respect the implementation decisions.
I would love to hear what other developers have to say. Are you OK with downloading 500+MB of images? What motivates you implement an elegant solution?
How about you, consumers? When does app size start becoming a problem for you? Have you ever not downloaded an app because it was too big? Which ones?
UPDATE RE: VERSION 1.1
The v1.1 update to the app was just released (June 30, 2010) and the download size is MUCH smaller than v1.0. Just a mere 5.5MB. What they have done is only included the player, and not the content. The content is available as an in-app purchase. If you have purchased v1.0, the content to the June issue is free.
The size of the June content is still 500-odd MB, so I suspect the same holds true for the July issue. However, it is promising that they have used the techniques described in my earlier post and are slowly coming to grips with the problem of download size.
As a developer myself (though not very experienced) I can’t even imagine using images for everything! If this is the future, then I am staring a resistance group of developers that actually use code. I admit I still can’t code anything utilizing graphics for the most part, but the solution the wired developers used is a perfect example of how not to make a program. Why do so few developers now not even try for the challenge of efficiency, to use solutions nobody else previously had? It’s not just about making the program, but also about challenging yourself to have better code, to improve your skills.
Michael Niehoff (Kitcat490)
I don’t understand why they wouldn’t include the largest image only, and then a set of instructions in the XML to generate, as needed the thumbnail/other image formats they needed. Build them on an as-needed basis, but store the results so they don’t have to be rendered another time. This would reduce the workload on the designers, allow for more flexible and different sizes/formats to be generated through instructions in the future, and finally, reduce the download size.
Libraries for resizing and resampling images exist on the iPhone. Use them.
Once that is done, you have an even more flexible and powerful engine with which to show the same type of content (pages of a magazine) in many different ways…ways you haven’t even thought of yet.
half a gig matters a lot – what if others took this approach? i want my expensive storage for music and videos, not a magazine. and back issues aren’t viable like this either.
I think size is really matters for me as a customers. I almost buy this app until i realize that the size is big enough to download.
There also an app with “amasing” size. XE the Element, the app size is 1,7 GB
My worry about a technical push for a more efficient presentation of magazine content is that it would make it harder for the designers at Wired to push unique editorial layouts into each issue. There is a huge visual difference (and value proposition for consumers) between the generic article page layouts of Wired.com and the same articles shown in this format.
500MB is huge, but so is the visual appeal of the app. I think efforts to reduce the issue size should be made, but not at the expense of the visual experience. Outside of flat layout images, I’m not sure how a time and resource constrained publisher could get a unique issue out on a monthly basis.
Size certainly matters. It mattered when Netscape was 1.0 and every image needed buttering to be efficient. Users could only wait 2 or 3 minutes for a page to load. :-) It matters today. So what if we have high network speeds? This doesn’t mean that one should needlessly fill the pipe.
It’s no wonder that carriers have issues with tethering. If developers seemingly don’t care, and users seemingly don’t care or don’t know how or why a file size is the way it is, I wouldn’t allow tethering on my network either.
If the file is .5gb x 1000, 10000, or 100,000 downloads, that is A LOT of wasted bandwidth. I would argue that the InDesign file prior to output to a PDF might be 500 mb. An iPad simply doesn’t need all the unnecessary bits.
Developers definitely need to add ’smallest download size’ to the list of project ‘to-do’s’.
Like you say, everyone is saying how the Wired app is the future of magazines on the iPad.
Has no one who says that bothered to look at Popular Science? I know it’s not necessarily as mainstream as Wired, but the implementation is thousands of times better from what I’ve been hearing. I havnt bought the Wired app, and to be honest, I’m not going to.
But I will keep buying Popular Science because it is a joy to read, with crisp text and fantastic quality pictures, and fraction of the download size.
I guess most users don’t bother too much about the size until it is perceived as “not worth the associated time and trouble”.
Contributing to the later is:
- an update happens, requiring twice the original size to install
- the update has features some users don’t perceive as improvement
- downloading takes long
- you don’t get a “what’s new” list BEFORE clicking “download new version”
An example is a T-Mobile branded edition of a navigation software in Germany.
It was updated not with fixes and navigation related features but social networking integration.
Based on the comments it seems it became a perceived problem for a vocal group of users to
- re-download around 2GB of data
- make room on the phone to allow upgrading (requiring twice the app size) instead of installing an 2GB app
- on the weekend, based on iTunes comments the download rate was not up to the theoretical limit, making it a multi-hour download
I think they (Wired Mag) purposely made the magazine this big.
I am sure they knew of ways to make the App size smaller.
But think of the Buzz that they are getting, its free marketing.
Everyone is talking about the BIG HUGE Wired Mag App.
pages are written about it on various websites.
They will probably come out with a lighter issue a few months from now and say ” NOW only 256MB!”
Then people will start again to Toot Wired Magazine for being able to make the app smaller with the same amount of content……
I think it might be a Marketing plan….