> What is advised when these rules, especially the "full screen of content" cannot be met because of things like external dependencies out of the site's control?
This is missing the point, and many people here seem to be attempting to pick the same nit. You never have to wait for external dependencies to show changes on screen. This is how browsers and well designed high traffic websites like YouTube already operate. When you take action, you are shown UI changes on-screen that indicate the action is in progress. The manifesto is saying to acknowledge the user action so the user knows the application received the request. It is not saying everything in the world needs to be done in 64ms. Applications can always acknowledge the request immediately, and yet some still don't.
Well, most actually could be. And a snappy "acknowledgement" only impresses me the first time. The second time I stare at the loading indicators in disbelief, while waiting for the not-so-snappy action to execute.
Loading indicators are simply one single example of how to respond to user actions on-screen. The idea is more broad than this, the idea is for clients to respond immediately to any inputs. This is true for opening menus, clicking buttons, typing, pushing on the D-pad, waving the Wiimote, pressing on your MIDI controller, waving your arms for the camera... it applies to any and all input devices for all applications.
This idea is not in the least bit controversial, I'm surprised by the amount of push-back here in this thread. Devs of games and interactive apps have always done this. If the machine doesn't acknowledge user input immediately, the user doesn't know if the input was captured, and very quickly decides the machine is slow or buggy.
In contrast to "not-so-snappy actions"? Snappy actions.
As I tried to say before: Instantaneous feedback is great (even necessary) for first time users. But once I get used to an app, waiting for the termination of a loading indicator is just as annoying as waiting for {page|script}-{load|parse|eval}.
Edit: > This idea is not in the least bit controversial.
I agree that content generation in one-digit milliseconds is not controversial.
Waiting for termination of a loading indicator on a web page is irrelevant to this post, it's a tangential topic completely.
"content" in the post is not referring to web page content, it's referring to UI content. We're not talking about content generation in the web page sense.
Typical human reaction time is 200ms or so. This effectively means that for 200-264ms you're not priming to repeat the action or wondering whether it "took", because there's an immediate response and the action itself does something useful quickly.
You get upset when buttons have a 'clicked' state, or something?
It's hard for me to picture how acknowledgment of input isn't a good thing.
In the context of a UI element or screen layout, "content" is the appearance of the UI elements on screen. The post, and my comment, isn't referring to web content or video content, it's referring to UI content.
Twisting my words to comment on YouTube's quality is funny, but irrelevant to interaction latency.
- 16ms: one frame
- 32ms: two frames
- 64ms: four frames
So it's really 1, 2, 4. Maybe we could have 1, 2, 3, but I'm guessing the "48ms Manifesto" wouldn't sound too great: they probably preferred to have a nice power of two.
And if I may, I think the manifesto is basically right. Something I have to wait several frames for before it reacts feels sluggish. When I type a character, I want it now, not 5 frames later. When I move the mouse, I want it in sync, not lagging behind my hand. Touch screens are even more exacting. They only feel perfect when latency falls under one millisecond. But that last one isn't achievable in practice on current stock hardware…