Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crafting a high-performance TV user interface using React

techblog.netflix.com

Post reply on HN
Print view View original

71–80 of 198 posts

Re: Crafting a high-performance TV user interface using React

#71

Post by smnscu »

usaphp wrote: post #34
makecheck wrote: post #26

Interface performance is one of the strangest problems to have in this age of crazy processing power but it is extremely common. Some of the delay is just plain silly and avoidable, like having long and synchronous opening animations in response to an action, which only serve to waste the user’s time. (Oh how I love being on a web site like AT&T and watching their JavaScript poorly zoom open a blank box from the cent…

Especially the lag that you see on some brand new cars, only BMW and Audi seem to have lag free interface, but anything else that involves touch interface is just horrid! I've recently sat in my friend's brand new Honda SUV and the interface lag is just plain silly, for a car that costs $30,000+. Why is that?

Have you seen BMW's Display Key or however it's called? Ridiculous.

Re: Crafting a high-performance TV user interface using React

#72

Post by intrasight »

diggan wrote: post #44
intrasight wrote: post #30

Earlier quoted context omitted.

I often hear that approach mentioned. But it seems so counter to my experience - that computers are plenty fast to run even complex display logic and that I'd never notice the difference. Is there really a benefit for well-written code? Or is this just an easy workaround for poor code?

Well, sometimes is not much that it's poor code but a lot of data to render. For example, imagine rendering a form with 100 elements. If it takes 0.1 second to render that on a average computer, you can make that 0.01 by rendering it on the server instead.

But your server has to render it for the thousands of visitors to you site. I still don't get the rationale.

Re: Crafting a high-performance TV user interface using React

#73

Post by will_pseudonym »

goostavos wrote: post #55
Domenic_S wrote: post #53

Earlier quoted context omitted.

That's just patently false. One of many, many articles to the contrary: http://blog.gigaspaces.com/amazon-found-every-100ms-of-laten...

Uh.. they've already _bought_ the car. What percentage of people will return a car due to a little lag when adjusting radio stations? e-commerce findings from a major retailer are, alas, not applicable to every domain

Lack of performance is an attribute that would contribute to a potential consumer's attitude towards the whole car. It may not have as huge of an impact as it would for Amazon, but saying it has no effect is definitely wrong.

Re: Crafting a high-performance TV user interface using React

#74

Post by robodale »

91bananas wrote: post #49
usaphp wrote: post #34

Earlier quoted context omitted.

Especially the lag that you see on some brand new cars, only BMW and Audi seem to have lag free interface, but anything else that involves touch interface is just horrid! I've recently sat in my friend's brand new Honda SUV and the interface lag is just plain silly, for a car that costs $30,000+. Why is that?

Because Honda at its core is not a software company?

I've worked at several companies where at least one manager/exec says "We are not a software company, we're a ___(their core product/service)___ company".

If an organization creates and utilizes software as part of their ongoing concern...is at some level, a software company.

Re: Crafting a high-performance TV user interface using React

#75

Post by intrasight »

jeremiep wrote: post #45
intrasight wrote: post #30

Earlier quoted context omitted.

I often hear that approach mentioned. But it seems so counter to my experience - that computers are plenty fast to run even complex display logic and that I'd never notice the difference. Is there really a benefit for well-written code? Or is this just an easy workaround for poor code?

I really don't like that argument because it assumes your program is important enough to be the only one running on your user's machines; it rarely ever is. Everything easily wastes 90% of the CPU resources it touches and the task manager is completely oblivious to it, happily reporting high usage. When you have 20+ tabs open and 10+ apps all those "its fast enough" apps combine to create their own variant of hell. A…

We're talking here about the time to render JSON to HTML for one page - the page that this user is presumably looking at. If that takes 90% of your CPU for more that a few milliseconds, then it's time to refactor.

Re: Crafting a high-performance TV user interface using React

#76

Post by squeaky-clean »

andrewstuart2 wrote: post #64
makecheck wrote: post #26

Interface performance is one of the strangest problems to have in this age of crazy processing power but it is extremely common. Some of the delay is just plain silly and avoidable, like having long and synchronous opening animations in response to an action, which only serve to waste the user’s time. (Oh how I love being on a web site like AT&T and watching their JavaScript poorly zoom open a blank box from the cent…

As far as the less-clear cases, this is basically CAP theorem, with some physics thrown in for good measure. In some sense there is always a partition of some length between two points, thanks to the speed of light: the theoretical limit of information propagation through space. So in the presence of this delay "partition," you have three choices, really, and the choice you make depends on the application. A) You can…

I've never connected this to the CAP theorem, it's a good way of looking at it.

I see it as 2 different questions, "Did the computer hear me" and "Does the computer have a response for me.". Most people only make an effort to answer the latter for the user, it indirectly answers the first question anyways. But you can easily answer the first by quickly doing some sort of update, such as a progress indicator, animating a button staying depressed, etc. You don't have to mess with your real model until you get a response (or an error), but then you also don't leave the user confused for 12 seconds while your app loads search results or whatever.

Obviously it doesn't work in every situation. In most video games you want your actions to affect the gameworld immediately, even if the server doesn't know about it yet. However, for most applications just adding fast indicators that the client is aware of your actions (and staying off the UI thread) will make it feel more responsive.

Re: Crafting a high-performance TV user interface using React

#77

Post by lenn0x »

erkose wrote: post #60

Link is down for me, so I'm reacting to the title. I don't have an issue with the performance of the Netflix UI on my PS4. I have a huge problem with the design of the UI. First, there is no reason we can't have more configuration flexibility. I don't ever want a program to auto play and I have no use for the video loops that auto play when I hover over a program. Let me disable these features. I don't want "my progr…

Agreed! I was just looking over their web interface, under Playback settings, they at least now have a way to disable Auto Play

Re: Crafting a high-performance TV user interface using React

#78

Post by Sanddancer »

intrasight wrote: post #72
diggan wrote: post #44

Earlier quoted context omitted.

Well, sometimes is not much that it's poor code but a lot of data to render. For example, imagine rendering a form with 100 elements. If it takes 0.1 second to render that on a average computer, you can make that 0.01 by rendering it on the server instead.

But your server has to render it for the thousands of visitors to you site. I still don't get the rationale.

Smart rendering would involve using a mostly static template that's updated with the relatively few dynamic elements as the page is being readied to be sent over the wire. If 90% of your dynamic content is the same, why put that through your app processes at all?

Re: Crafting a high-performance TV user interface using React

#79

Post by frakr »

city41 wrote: post #28
mcescalante wrote: post #5

Netflix's A/B testing has really screwed me in the past in terms of performance, so much so that I reached out to support to ask if there was a way to manually remove me from the testing group at that time. I'd log in, and the "new" interface throttled my 13 inch retina Macbook's CPU immediately to 100% (or more). Last time it was so bad that I stopped using Netflix on my computer until the testing stopped. That said…

You can opt out of A/B testing. Head to netflix.com, go to your account settings > Test Participation > Include me in tests and previews, and switch it off.

I had to do that after I got put in a group where there was no way to view the description or episode list without also starting to play the selection (in browser). On a console app the other day it would start playing an audio preview of anything selected making scrolling through my options extremely annoying. I quit the app almost immediately. I don't mind being in the testing group but I would definitely like the option to quit a test group. Wouldn't that feedback be valuable to them?

Re: Crafting a high-performance TV user interface using React

#80

Post by johnward »

nodamage wrote: post #70
usaphp wrote: post #34

Earlier quoted context omitted.

Especially the lag that you see on some brand new cars, only BMW and Audi seem to have lag free interface, but anything else that involves touch interface is just horrid! I've recently sat in my friend's brand new Honda SUV and the interface lag is just plain silly, for a car that costs $30,000+. Why is that?

Same with in-flight entertainment systems on planes. They always have terrible, slow interfaces.

This causes people to press harder in reaction and then they are bouncing the person in front of them's head. It's comical if it's not happening to you.
Post reply on HN