"10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect."
Read on crystal clear explanation of why this is and how to build around if load time is a must:
The most important things are often very banal. Most people don't like to be banal, they like to be fancy. So they end up ignoring the most important things (both in business and their private life).
Maybe this is why Jakob Nielsen is so hated: he allows himself to be banal, he allows his web-design to be banal, he allows his conclusions and suggestions to be banal.
I'm a huge, huge news junkie. I read the NYT and WSJ daily. (NYT online, WSJ in the APP). I also read several magazine via Zinio, and get the new Yorker, economist, and wired apps on my iPad.
There is no easy way to say this - the first revision of "The Daily" is an embarrassment. When I pick up the WSJ - it's about 10 seconds after I launch that I start reading that days paper. The Daily not only takes so long to start, that I've _already_ lost interest in trying to read it, the total download time is so excessive that I never bother to let the entire thing download. WSJ is quick, snappy.
I realize a lot of this is because of the massive video / photo content - but they need to do something about this App quickly or their going to lose 80% of their potential audience before they even _try_ reading the darn thing.
To be fair, when the WSJ app first launched on the iPad it took at least a minute to download each issue. They had no 'staged' loading so you had to sit there and watch a progress bar before you could read a single article.
I noticed that Amazon has (relatively) recently changed their results pages so that it preloads the first 4 results of the next page. When you click next, the next 4 results show immediately, and then the rest of the results start loading. I wonder how many hundreds of thousands of dollars that small change is earning them...
I sense you might be making a joke, but just in case: I'm pretty sure he means that three issues of The Daily have come out in the three days since the app's debut.
Here in Austria, I've heard some people call it the "Psychosemmel" (a Semmel being an Austrian kind of bread roll... do a GIS and you'll see the resemblance).
Imagine a paper newspaper that was wrapped in an envelope, and the envelope was so difficult to open that it took over a minute before you could see the front page of the issue. Who would buy that newspaper? No one, that’s who.
It takes me longer than a minute twenty to walk to the curb and back to pick up the wall street journal. Perhaps Gruber has figured out the reason that no one has ever read newspapers?
I think the important difference is that you are actively doing something while getting the paper. You go outside, and have something to look at while you are waiting. Perhaps if he opened it a bit before he knew he would need it, and did something in the meantime it would be easier to wait.
"It takes you several minutes to go and buy a physical newspaper" - this is not an argument. The dynamics of a mobile app is so different than real life's. Imagine you play one of Zynga's games and wait 2 physical years for the animal to grow up. There's no doubt any mobile app showing you instant and hot content should start blazing fast, so that it serves your impulses. We are reading news out of our impulse; although we may alocate specific times of the day for it, it's not a programed action like reading a thousand pages fanatsy novel; therefore if a news app fails to satisfy that impulse (quickly, efficiently, in critical time and dimensions) then you may say the app is not serving you well enough.
In my opinion, it doesn't matter the name of the author, he's got a point.
I think what this really points to is the need for a background content-fetching API in iOS. Battery life spent loading is battery life spent loading whether the user is there or not; the key is to integrate it into the push framework so that battery life isn't wasted on polling.
Exactly the opposite. The content should be fetch as-needed. Background fetching would get all the content whether or not it's ever read. If all the apps I've grown tired of are still fetching data in the background, that IS more battery life. Or if I only read one section of the Daily when it's downloaded it all. Having background fetching available would just let the Daily off the hook for designing the app the way it should!
Other news apps have solved the problem. Safari can retrieve the entire internet without background fetching. Surely the Daily's problem is easier than Safari's.
Seems pretty unlikely, though would be awesome. One of the major problems Jobs has insisted on abstracting away from the consumer is battery management. Time spent loading is time spent loading, but Jobs wont stand for customers being confused between their battery being broken and just having a lot of background content downloading without them noticing.
The problem with background content loading is that you never know if it's content the user is ever going to look at. It would be pretty easy to install a few apps to try out that you never wind up looking at again, and then your device spends a lot of time and battery loading the content overnight, and you wonder why your battery is dying even though you're not using it much.
There's a simple solution to this: Restrict push-downloads to one unread at a time. If the user hasn't relaunched the app since the last download, nothing else comes through until they do.
He's dead wrong that it doesn't download in the background. Most reviewers commented on the sluggish cover flow without realizing it's still downloading for quite some time once you get the first pages.
Watch the spinner in upper left. Most of the issue downloads AFTER you can interact.
> He's dead wrong that it doesn't download in the background.
You're reading this wrong. What you're describing isn't what he was talking about. He's talking about letting it download in the background, as in, iPad is sleeping, and it automatically downloads over night, without having the app open.
He does mention background downloading how you describe it. He does, however, mention that waiting a minute twenty to even get to that stage is annoying. Basically, he says that it should open up within 10 seconds, and download in the background as needed. Not a minute twenty.
> I’m saying they need to engineer the app so that it can start showing something interesting in 10 seconds or less — and then keep downloading the rest of the issue, piece by piece, in the background.
And that's exactly what it does. It keeps downloading the rest (most of it in fact), piece by piece, in the background. Just takes too long to first interaction.
No, that's not exactly what it does. It starts showing something in 80 seconds, and still downloads. He doesn't say it doesn't download things in the background. He excplicitly says it does that. What he's saying is the implementation is poor. You misread it.
> He doesn't say it doesn't download things in the background. He excplicitly says it does that.
Where does he explicitly say it downloads things in the background, or even vaguely imply it?
At no point does he acknowledge it downloads anything after the initial spinner. "Watching a splash screen rotate a “Loading…” spinner for 80 seconds isn’t it."
Full quote: "I’m not saying The Daily needs to magically make an entire new issue download to an iPad in 10 seconds or less. I’m saying they need to engineer the app so that it can start showing something interesting in 10 seconds or less — and then keep downloading the rest of the issue, piece by piece, in the background."
He's specifically not -- and neither was I -- talking about downloading in the background when the app isn't running: "I realize", he says, "that iOS has no mechanism that would allow The Daily to have issues download automatically in the background, overnight."
Instead, his last two paragraphs are asking for them to "engineer" a mechanism to show something quickly and download more after. He points out other apps that have such a mechanism, and accomplish it in varying amounts of time. This app also has such a mechanism, but no phrase acknowledges that. If he knew it was doing that, he could have said, "Like Flipboard and others, The Daily is downloading most of the issue in the background, but since they already have that mechanism built in, they need to get the new issue's cover shown in 10 seconds instead of 80."
Instead, he says, "they need to engineer the app so that it can start showing something interesting ... then keep downloading the rest of the issue piece by piece", as though it weren't already "engineered" to do such a thing, just choosing to get too much.
As an aside, something's up with his broadband. I'm in NYC. Not sure what's wrong with his connection, but here's how long it takes on my iPad which is slow on WiFi with the 4.3 beta 2 dev build:
0 - 10 seconds: splash screen (app itself is loading)
44 seconds: cover image and adjacent pages viewable, interactivity enabled
Note that this is roughly half the time he's experiencing.
45 seconds to completion: spinner changes to 0% - 100% progress pie chart, issue can be browsed while this is downloading the rest of the issue.
He may in fact mean what you're saying, but that's not what he wrote. He wrote a lot of copy about engineering a mechanism to show something and download more later, without once acknowledging it has such a mechanism already.
Final proof I'm not misreading:
"I noticed yesterday that it took way too long to load the day’s new issue. From the time I tapped the icon on my home screen until I could read a single page, today’s issue took one minute and twenty seconds."
No. At the time you can read a single page, it has not downloaded "the day's issue". It has downloaded enough for interactivity to begin. It downloads most of "today's issue" after he stopped the timer.
> Where does he explicitly say it downloads things in the background, or even vaguely imply
Sorry, I was mistaken about that.
Still, everything else I said still stands. It's not downloading in 10 seconds and letting you use it. It's downloading in 80 seconds and letting you use it. Both cases allow for continued downloading. You asserted that currently the app downloads and is usable in 10 seconds. It is not. That's my contention, based on DF, and that is where the confusion lied in your comment.
More precisely, it's not the downloading in the background that's important, rather, the interactivity within 10 seconds that is.
> You asserted that currently the app downloads and is usable in 10 seconds. It is not. That's my contention, based on DF, and that is where the confusion lied in your comment.
On the contrary, my first comment was:
"He's right it's slow to let you interact. He's dead wrong that it doesn't download in the background."
Furthermore, I provided my own timings, none of which "asserted" it's usable in 10 seconds.
Again, I agree with Gruber it's slow. I disagree with you that I read him wrong. He did fail to acknowledge the app is engineered to download most of the issue in the background after (too slowly, whether 45 seconds or 80) allowing interactivity to begin.
Discussing this any further risks becoming circular.
Possibly getting the visual thumbnail index, cover, toc, and if they're nuts, intro video (talking head telling you what stories are in the issue). There's an option to autostart the talking head, they think it's that cool.
To add insult to injury, the quality of the cover flow images is horrendous. The JPEG artifacting makes the sub-headlines difficult to read, so it's not just an aesthetic complaint; it is yet another usability problem.
PS - I decided to open up The Daily to confirm that the JPEG artifacts do not go away after further loading. They do not. However, it is a little after midnight for me now, so when I opened the app, I hit the "A new issue of The Daily is being delivered" wait screen. How poetic.
The good news is that this is software, so they can definitely fix the issues with the app itself. What remains to be seen is how high the quality of the writing will be and if they can sustain it.
Atomic Web Browser, Mercury Web Browser, iCab Mobile, Terra and Opera Mini are some examples of alternative browsers that have additional features to the standard iPad Safari install. There are many others.
Not that an alternative browser would matter in this case, because The Daily is an app, not a website.
The Daily is actually all images on no text (like quite a few other magazines on the iPad). This is so incredibly stupid and such a horrible step backwards. It balloons the file size (that’s probably one of the major contributing factors to the long wait time), it introduces ugly artifacts (they seem to be using JPG), it doesn’t allow the user to copy or search text and it’s an absolute abomination when it comes to accessibility. iOS has a great built-in screenreader and it just doesn’t work with The Daily. All that for something that’s not even that beautiful.
We desperately need better HTML5 authoring tools, something like InDesign. It would be so nice if The Daily were using Webkit.
This is not unique to The Daily. Popular Science and Wired are exactly the same (maybe others, too). (This is not an excuse. They all suck equally in that respect.) I suspect that they all use some sort of InDesign plugin or something similar.
Is this a joke? Text displayed as artifact-y JPGs? What was Apple thinking. (And don't tell me they weren't involved).
edit: If Apple is giving them early access to the subscription API and Apple is using The Daily to show off the power of the subscription API and tout the Apple ecosystem... it just screams of something that Apple would be intimately involved in. If they weren't, it's equally silly. I'm not saying its fair, but Apple has certainly jeopardized the perception of this portion of their platform due to The Daily's shortcomings.
Apple was obviously not involved in the development of this app (except for providing News Corp. with early access to their subscription API). Why would think they were?
Personally, I would like to see an app like Instapaper combined with a licensed AP news feed. I don't really need images or fancy graphics or movies; I just want to read the news.
Doesn’t look like it is. I can’t download it in the German App Store.
(This is so stupid. I certainly don’t want to buy The Daily but it’s not the only offender in this regard. I would assume that making The Daily available in every App Store in existence is a matter of clicking a checkbox or something like that. What’s stopping them? Are there legal issues?)
And when, at some point in the future, iOS gains the ability to do downloads while the phone is in your pocket, Gruber will salute this as yet another crushing evidence of Apple's innovative spirit, forgetting that Android has been able to do this since 1.0.
I understand that my comment may look like the sort of thing that would appear on a lesser news aggregation / community website that shall remain unnamed, but I promise I never intended it as such. Nor did I attempt to attract the kind of fire-poking (flaming, trolling, or whatever the cool kids call it these days) responses that usually follow such comments, but I guess there's only so much we can convey in text when we don't take the time to elaborate.
The Daily is a collaboration between Apple and News Corp. I'm not going to post links to various sources here that state that fact. Google is an excellent resource for finding out such things - I regularly consult it before attempting to shoot down people's comments (just in case my argument is unfounded). I also respect HN's rules about posting links all over the place.
Although John Gruber has been critical of Apple in the past, he is thought of by many (especially of late) to be Apple's unpaid mascot; solidly supporting their opinions on the Flash situation and the WebM/H.264 debate. To be honest, my comment was more to do with my feelings on his recent behaviour, because I connected more with the John Gruber that brought us Markdown and other great things, rather then John Gruber the Apple fanboy. I just wish we got to see more of that side of him, but it seems to be fading.
I don't appreciate your congratulations. I never entered the ugh pageant, and nobody likes to win the 'doubly wrong' prize, especially when they're not.
I think that next time I'll provide a bit more information, lest someone think that I'm here to spout sensationalist drivel.
Apple did the subscription stuff (Gruber was not critical of that), the app and its content (which Gruber is criticizing) is wholly developed and created by News Corp. An endorsement by Apple and some collaboration on the subscription APIs does not make this an Apple offering in any way.
And Gruber still is critical of Apple. That’s not a thing of the past. Just because he doesn’t agree with some of your personal opinions about something doesn’t make him an fanboy (which is a stupid word anyway and should never be used to describe anyone. It’s a lame dismissal of serious debate, a conversation stopper.)
His complaint about Apple in this instance wasn't about the app itself. It was with their APIs which limit background loading that he took issue with. Perhaps this post was in some way a reaction to people who share my opinion about his recent writings, but I suspect he doesn't really care.
The reason Apple did the subscription stuff was because only they could. They simply do not allow anything on the app store to have in-app payments unless they pass through the app store itself and they get their tasty 30% cut.
As an aside: I dislike the word fanboy too. I do however like extremist, zealot, fanatic and dogmatist. They just roll off the tongue - fanboy is just too modern in comparison.
I never once claimed that Gruber has never had a bad word to say about Apple. I follow his blog, and I agree with you that he's as impartial as I am about the things Apple either produce or endorse. What I do claim however is that in recent debates over open web standards, he has fought Apple's case without so much as an acknowledgment of the opposing arguments.
As for the "extremist...." remark, I wasn't insinuating that Gruber was any of these things. I was trying to appeal to the sensibility of someone who thinks "Hey, you are doubly wrong, congratulations!" is somehow a more constructive response than my initial comment. I've clearly failed in this regard.
This app fails to show something, anything, within the first ten seconds, and the problem is that it can't download issues overnight? No, the problem is that it fails to show something in the first ten seconds.
This argument is a false dichotomy, suggesting that the only two options are download things overnight or wait a huge amount of time to show something. Other apps show something in the first ten seconds, so clearly there are more than two options possible here, and given that iOS doesn't allow overnight downloading, the criticism here is that the developers failed to choose the best option of those available.
Arguing that Apple should allow overnight downloading is interesting, but not related to what these developers should do.
I agree. I feel that an app that has had Apple's good name attached to it should have at least went through better testing, perhaps even by Apple themselves. The suggestion that Gruber makes about the app having a page that slowly populates with content over time is great. I hope the developers consider something along those lines.
The important thing is not your opinion about who is to blame but Gruber’s opinion about who is to blame and he clearly thinks that Apple is not to blame. Hence, the comment is wrong.
"10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect."
Read on crystal clear explanation of why this is and how to build around if load time is a must:
http://www.useit.com/papers/responsetime.html