1637843 - Numbers in Reader View Type controls popover are not meaningful

Status: NEW

(Toolkit :: Reader Mode, defect, P3)

Description

[Asif Youssuff]

The numbers in between the increase/decrease font size, increase/decrease content width, and increase/decrease line height are not meaningful and should be removed.

I could understand if the content width was in ems or pixels, but the way it is, it is more like a slider with a range of values, but the values aren't really meaningful to users.

The previous iteration didn't have this and I don't really understand the value that this brings.

Comment 1

[:Gijs (he/him)]

(In reply to Asif Youssuff from comment #0)

The numbers in between the increase/decrease font size, increase/decrease content width, and increase/decrease line height are not meaningful and should be removed.

I could understand if the content width was in ems or pixels

The values are sort of ems, perhaps with a different multiplication factor. Put differently, I don't think having pixels or ems would make the values any more or less meaningful to 99% of users, because pixels and ems are also "just numbers".

The previous iteration didn't have this and I don't really understand the value that this brings.

It gives immediate feedback and it makes it more obvious that when you get to "1" you cannot reduce the number further.

Abe, is there anything we want to do here?

Comment 2

[Asif Youssuff]

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

(In reply to Asif Youssuff from comment #0)

The previous iteration didn't have this and I don't really understand the value that this brings.

It gives immediate feedback and it makes it more obvious that when you get to "1" you cannot reduce the number further.

The controls already give immediate feedback (the page changes), and the control gets "grayed out" (unlike the previous iteration). There is a minor bug here in that the control remains sensitive to user input once it is no longer going to do anything, which seems much more valuable than simply stopping to increment a number.

If numbers were so valuable here, we could append one to the forward or back button to show how many pages there are in the tab stack in either direction. That doesn't feel very valuable either.

The values are sort of ems, perhaps with a different multiplication factor. Put differently, I don't think having pixels or ems would make the values any more or less meaningful to 99% of users, because pixels and ems are also "just numbers".

I agree. Numbers here aren't really meaningful at all - this isn't a page layout application, I just want to read, and I can modify the view based on how the view changes. It doesn't really add anything and is superfluous. Without any clear value, it should be removed like the prior iteration (why do something if it isn't better)?

Comment 3

[:Gijs (he/him)]

(In reply to Asif Youssuff from comment #2)

I agree. Numbers here aren't really meaningful at all

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.

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.

Comment 4

[Abraham Wallin]

Taking a closer look there are a few things that could be improved. Specifically making the numbers more meaningful.

• Ideally the number value would correspond to the font size similar to Google Docs or other tools where a users adjusts font size. The numbers provide value in a few ways. 1. As mentioned they give a reference to the bottom limit (and could do something similar for an upper limit if they better matched a traditional font size scale). 2. They provide a reference to users who want a quick way to find/return to a setting they preferred in the past. 3. In a potential future version we can allow users to type their size preference avoiding the need to click multiple times to find their size of choice.

• The value between increase/decrease width should be a percentage (e.g. 60%, 70%, etc) not a number value which would make it more meaningful.

• For line height the numbers should correspond to a multiplier of the default line height. So, we'd have something like 1, 1.15, 1.5, and 2.

Looks like there's also a minor bug for the vertical alignment of the number and another I'm encountering where the line height doesn't change and menu closes when pressed.

Comment 5

[Asif Youssuff]

(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

Comment 6

[Asif Youssuff]

Attachment: Screenshot from 2020-05-17 13-29-04.png

Attached is a screenshot of Foliate, a GNOME eBook reader. Here, numbers are used and are meaningful. There are also labels - something that might be useful if numbers are desired - labels include: font, spacing, margins.

In Firefox, there are no visible labels by default, only on hover, and not on the numbers, but on the buttons.

Comment 7

[:Gijs (he/him)]

(In reply to Asif Youssuff from comment #5)

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

The width is implemented as being in em, but we deliberately avoid causing a horizontal scrollbar by limiting the width to that of the viewport minus body padding. Because it uses em units the visual width is also affected by the font size, I don't think having this be in % as designed is going to be possible, unless we change the implementation.

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.

I meant that the transformation from the internal number to px, or the line-height number to something that resembles normal text editor notation, wasn't implemented.

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.

I think this is probably valuable as a separate feature request.