News for hackers. Stuff that matters.
Re:The 64 Milliseconds Manifesto by dahart on Tuesday September 24, 2019 @03:15PM (#21063573)
Yeah it's simplistic and doesn't explain the rationale, but having studied human perception a bit, I know without further explanation that this is targeting the time frames of our human ability to see change. The numbers here are similar to the reasons most movies are 24fps.

> 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.

Re:The 64 Milliseconds Manifesto by jlg23 on Tuesday September 24, 2019 @03:49PM (#21063868)
> It is not saying everything in the world needs to be done in 64ms.

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.

Re:The 64 Milliseconds Manifesto by dahart on Tuesday September 24, 2019 @04:09PM (#21064084)
What are you suggesting as alternatives that will impress you? Would you prefer to have no indication on screen that something is loading, and no indication that acknowledges you even clicked on something? Do you see a better way to show that megabytes of data are on the way but not here yet?

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.

Re:The 64 Milliseconds Manifesto by jlg23 on Tuesday September 24, 2019 @06:36PM (#21065377)
> What are you suggesting as alternatives that will impress you?

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.

Re:The 64 Milliseconds Manifesto by dahart on Tuesday September 24, 2019 @08:10PM (#21066160)
The post's entire point is to say make all actions snappy. That doesn't mean you can finish loading a video instantaneously, it means you can acknowledge the user's request to start loading a video instantaneously.

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.

Re:The 64 Milliseconds Manifesto by mlyle on Tuesday September 24, 2019 @07:00PM (#21065581)
64ms is still not something you're going to be "waiting" for.

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.

Re:The 64 Milliseconds Manifesto by Dylan16807 on Tuesday September 24, 2019 @07:37PM (#21065905)
Disbelief?

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.

Re:The 64 Milliseconds Manifesto by tedunangst on Tuesday September 24, 2019 @03:44PM (#21063810)
How can I show one full screen of content when it takes longer than 64ms for the content to get from there to here? An acknowledgment that the content is coming is not a screenful of content.
Re:The 64 Milliseconds Manifesto by dahart on Tuesday September 24, 2019 @03:53PM (#21063923)
Instead of assuming that "content" must mean "network response", imagine some other possibilities. A full-screen gray-out box with a centered loading spinner over a YouTube thumbnail, along with the thin loading progress meter on the video's timeline is an example of a "screenful of content" that doesn't equate to the network response.
Re:The 64 Milliseconds Manifesto by tedunangst on Tuesday September 24, 2019 @04:10PM (#21064107)
That a loading spinner would count as content is a sad commentary on how little value YouTube video content must have. :(
Re:The 64 Milliseconds Manifesto by dahart on Tuesday September 24, 2019 @04:42PM (#21064397)
It seems like you're still having a hard time imagining what "content" might mean aside from the network response.

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.

Re:The 64 Milliseconds Manifesto by jlg23 on Tuesday September 24, 2019 @03:52PM (#21063911)
64 ms East Coast to West Coast leaves about 20ms for content generation. That's plenty...