Revise language around bit rate for H.264 settings

[mtlynch]

I was speaking to a customer yesterday, and they mentioned that our usage of the term "Bit Rate" confused them:

Revisiting the language, it is confusing to a person who's not familiar with the term. They wouldn't have a good intuition about whether increasing or decreasing the bit rate would reduce latency/quality.

Should we replace it with a more intuitive term?

One thought I had was to replace it with "Quality" so that we're consistent between MJPEG and H.264. We'd have to come up with some formula for converting a quality percentage to a bitrate. And it wouldn't be a simple linear transformation because we'd probably say 5 Mbps is equivalent to 80%, but 6.25 Mbps wouldn't be 100%.

[jotaen4tinypilot]

Adding some thoughts here, just as I happened to stumble across this:

Did the customer mention what exactly they found confusing? I.e., weren’t they familiar with the concept of bit rates / network throughput in general? Or did they know what it is, but were confused by what effect it would have in this context specifically?

I’d see some caveats with replacing the label “Bit Rate” (which doesn’t mean I’d be opposed to it, I’m rather mentioning it for consideration):

• If we replaced “Bit Rate” with something more abstract like “Quality” (or something else), there is the potential risk that this might then confuse other users, to whom the term “Bit Rate” otherwise would have been sufficiently clear.
• I’d be unsure whether it’s legitimate and transparent enough to transfer the term “Quality” from MJPEG to H.264. In the (M)JPEG realm, “quality” is a well-established term with a universal technical definition. But if we started to use it for H.264 as well, it would have a special, quasi “proprietary” meaning.
• All other sliders / controls in the video settings dialog are modelled in a direct, non-abstract way. So making one of them work in a more indirect, “abstract” way might feel unintuitive to users.

Potential alternative approaches that come to mind (also just for consideration):

• We could consider leaving the term “Bit Rate” as is, but try to find some way of hinting in the UI, that would tell the user what this control does. Basically similar to the “Streaming Mode” dropdown, where we also say “Best Compatibility” for MJPEG, and “Higher Quality, Lower Bandwidth” for H.264. Those two hints also don’t explain what MJPEG or H.264 is, but it probably provides enough information for the user to make a decision.
• We revise the video settings dialog in general, to make it less technical, but try to model it in a more “abstract” way. (Not sure yet how that could look specifically, though.)

[cghague]

A good approach could be to add a brief description to each end of the sliders explaining what each extreme does and why you might want it. I've put together a (hilariously basic) mockup below:

[mtlynch]

I'm punting this until 2.6.4 since I feel like we're kind of overloaded on UX philosophy questions this release, but I've included my thoughts for when we pick this back up.

weren’t they familiar with the concept of bit rates / network throughput in general? Or did they know what it is, but were confused by what effect it would have in this context specifically?

They weren't familiar with the concept of "bit rate." They didn't know that higher numbers meant better quality / more bandwidth.

If we replaced “Bit Rate” with something more abstract like “Quality” (or something else), there is the potential risk that this might then confuse other users, to whom the term “Bit Rate” otherwise would have been sufficiently clear.

I'd expect everyone who recognizes "Bit Rate" to also understand "Quality." Do you have a type of user in mind that would understand "Bit Rate" but not "Quality?"

I could imagine a user who's hyper-aware of their bandwidth, and they want TinyPilot's stream to use exactly 5 Mbps, but I don't think they'd represent many of our users. And even those users should still understand that lower quality means lower bandwidth. They'd still understand how to tune bandwidth, but maybe "Quality" gives them less control than they previously had when they could control bit rate directly.

I’d be unsure whether it’s legitimate and transparent enough to transfer the term “Quality” from MJPEG to H.264. In the (M)JPEG realm, “quality” is a well-established term with a universal technical definition. But if we started to use it for H.264 as well, it would have a special, quasi “proprietary” meaning.

I think it's true that JPEG quality is well-defined, but I think it's still kind of abstract and hand-wavey. Like 99% of users probably don't think about JPEG quantization tables when we show them the quality slider. And my understanding of JPEG is that the numbers are subjective. Like 50% JPEG quality isn't 2x as good as 25% in some objective way, is it?

I think when users see the JPEG quality slider, they're just thinking about the tradeoff they're willing to make in quality to get better latency. So, I feel like we can bring that same idea to H.264.

All other sliders / controls in the video settings dialog are modelled in a direct, non-abstract way. So making one of them work in a more indirect, “abstract” way might feel unintuitive to users.

I'm okay dropping this because I don't think users really care that much about the direct control.

I think most users are just picking numbers by trial and error rather than knowing for sure that they want to allocate exactly 2 Mbps of bandwidth or that JPEG quantization table 77 is optimal for their network connection.

Our goal with the sliders should be that it's obvious to 99% of TinyPilot users which direction to move the sliders if their connection is too slow and which way to move them if the image quality is too low.

We revise the video settings dialog in general, to make it less technical, but try to model it in a more “abstract” way. (Not sure yet how that could look specifically, though.)

Yeah, I think it's worth taking a step back and thinking about whether we can make the whole thing simpler.

When I was researching JPEG quality, I saw discussions about how Adobe Photoshop does quality from 1 to 12, and that makes sense to me. Like we don't really need to give people fine-grained control to choose between 11.15 Mbps and 11.20 Mbps. We could probably simplify it to 8-10 different quality options, and that would be enough.

Challenge of "fast connection" language

I've noticed that maybe 10-20% of TinyPilot users who report latency issues misunderstand the connection to their TinyPilot. They know that they have a 100 Mbps Internet connection, so they think that they should have the fastest settings possible, but these users often fail to consider:

• The latency between their browser and the TinyPilot device is going to be the lower bound on their latency no matter how high their bandwidth is
  • They might have high bandwidth for latency-insensitive tasks like streaming 4K video, but they don't realize they have a high latency to the Internet
  • They might have low latency to the Internet but high latency to their TinyPilot, or their VPN provider could be adding significant latency

So we need to be careful not to tell users that they should choose option X if they have a "fast connection," because I think we'll get even more users who say, "Fast.com says my download speeds are 500 Mbps, so why is latency to my TinyPilot so high?"

Limiting scope

I'm almost tempted to add an "choose for me" button that pings the TinyPilot and downloads 1 MB of random bytes to profile the network connection and then picks the settings based on that, but I think that's going a bit too far down the rabbit hole. Let's limit scope here to what we can do without adding new API endpoints, focusing mainly on how we change the frontend.