Bugzilla

(In reply to :Gijs (he/him) from comment #3)

> Actually, reviewing the spec again, it seems that the font number is supposed to be px, and the width number %, but that wasn't implemented. That'd probably improve this. I can't tell what the line height number is supposed to be.
> 
For the width number, % of what exactly - it isn't the viewport width, because resizing the window seems to have no effect. 

For the font number, I'm definitely not seeing a 1px font while reading, so it isn't just that the units weren't implemented, the numbers themselves aren't meaningful. 

> Anyway, the numbers would still help in terms of orienting users what settings they're comfortable with - we show the zoom percentage on the regular zoom controls even though the difference between 110% and 120% is probably not numerically meaningful to people - the result is. Even so, the numbers help orient people, and would have made talking about e.g. bug 1578454 a lot easier.

Zoom percentage is meaningful because there is a base to compare it to and people have experience with it. A number like "2" for font when the font size is actually 20px is completely meaningless. I would have less of an issue with the numbers if they were meaningful, but the fact that the meaning now seems incidental rather than essential makes me feel like the benefit is of limited value. If it were truly important that the numbers meant something, we wouldn't be talking about the number not being meaningful, we'd be talking about it being *wrong*, like if a 130% zoom actually showed 175%.

In addition, if these numbers are so valuable, why is the "Listen" controls also not using numbers? That is using a range slider, which seems just as valuable. I don't see in "Listen" that I am listening at 125% speed - that would actually make sense, given that users are also familiar with speeding up a base playback rate from podcast apps. 

If the type controls were using range sliders with a fixed number of steps, one can also see that "I am a the midpoint of allowable font size and 25% of allowable width".

My feedback:

* the value matters less than the position in the range, something recognized by the "Listen" control
* arbitrary values are not meaningful
* if range position is valuable, we are using the wrong control

(In reply to :Gijs (he/him) from comment #3)

> Actually, reviewing the spec again, it seems that the font number is supposed to be px, and the width number %, but that wasn't implemented. That'd probably improve this. I can't tell what the line height number is supposed to be.
> 
For the width number, % of what exactly - it isn't the viewport width, because resizing the window seems to have no effect. 

For the font number, I'm definitely not seeing a 1px font while reading, so it isn't just that the units weren't implemented, the numbers themselves aren't meaningful. 

> Anyway, the numbers would still help in terms of orienting users what settings they're comfortable with - we show the zoom percentage on the regular zoom controls even though the difference between 110% and 120% is probably not numerically meaningful to people - the result is. Even so, the numbers help orient people, and would have made talking about e.g. bug 1578454 a lot easier.

Zoom percentage is meaningful because there is a base to compare it to and people have experience with it. A number like "2" for font when the font size is actually 20px is completely meaningless. I would have less of an issue with the numbers if they were meaningful, but the fact that the meaning now seems incidental rather than essential makes me feel like the benefit is of limited value. If it were truly important that the numbers meant something, we wouldn't be talking about the number not being meaningful, we'd be talking about it being *wrong*, like if a 130% zoom actually showed 175%.

In addition, if these numbers are so valuable, why is the "Listen" controls also not using numbers? That is using a range slider, which seems just as valuable. I don't see in "Listen" that I am listening at 125% speed - that would actually make sense, given that users are also familiar with speeding up a base playback rate from podcast apps. 

If the type controls were using range sliders with a fixed number of steps, one can also see that "I am a the midpoint of allowable font size and 25% of allowable width".

My feedback:

* the value matters less than the position in the range, *especially* when the values are not meaningful
* arbitrary values are not meaningful
* if range position is valuable, we are using the wrong control