e-ink should not assume monochrome

[alerque]

I've been seeing some tagged test releases with setting adjustments targeting e-ink displays. This is exciting and something I've looked forward to for a while. I haven't had a chance to update my tablet(s) and give it a test drive yet, but I plan to.

In the mean time just looking at the code branch I thought I'd point out the setting seems to be conflating two things. Not all e-ink displays are monochrome. In fact there are quite a few color options out there. I don't happen to have one yet, but there are more and more out there. I think it's a bit short sighted to assume monochrome == eink. Most of the adjustments probably apply to both, but

• the biggest common issue is probably refresh rate and the clumsiness of scrolling (c.f. Page flip option for E-Ink devices #282).
• secondarily I think almost all eink displays to date have issues with contrast. Even the color ones are not vibrant and while they have great contrast for reading they don't tend to do mid-tones well. Obviously the monochrome design language, ditching shadows and transition effects, etc. will benefit even color displays because of the contrast and refresh rate
• finally of course many of them are only grey scale.

In naming the setting and grouping UI changes into logical groups I would probably target the e-ink specific issues with more than one setting so that the folks with color screens can actually use them while benefiting from the other UI changes.

[tuomas2]

Yep I have now 2 setting: remove animations and monochrome mode. Do you think those two should be enough for both color and monochrome e-ink devices?

[alerque]

Does the "remove animations" setting also cover things that are not technically animations like static shadow effects? If not I do suggest grouping those with animations not necessarily with monochrome. And if so perhaps naming it "animations and effects" or something so it is clear where those fall.

[tuomas2]

Does the "remove animations" setting also cover things that are not technically animations like static shadow effects? If not I do suggest grouping those with animations not necessarily with monochrome. And if so perhaps naming it "animations and effects" or something so it is clear where those fall.

Not sure if I put shadow removals to monochrome category. Color e-ink does not like shadow effects either?

[alerque]

Correct, at least for the ones I've seen. See above comments about contrast. Even the color eink displays tend to be optimized for high contrast reading, not a wide spectrum of colors or shades. They struggle with having discernible differences in the mid-tone ranges the same way greyscale displays do. Hence things like shadow effects that are usually designed to be not distracting while adding visual depth can show up wildly lighter/darker than expected and degrade the experience rather than adding to it.

Hence why I would group those with animations, not "monochrome". On the other hand if you refocused the "monochrome" setting to be "high contrast" instead that might make more sense to include them there. It probably wouldn't hurt to keep sending color as long as the changes such as not using shaded backgrounds and such were retained. Most greyscale screens do a decent job of picking a grey to stand in for a color based on lightness so it wouldn't matter if you kept some color in the mix as long as all the contrasts were addressed.

At least for my most used device (a Boox tablet) it wouldn't matter if the text were dark grey or dark blue as long as it wasn't paired with a light-tone background that isn't white and hence I end up with a mid-tone against mid-tone with readable contrast. Removing the background entirely and making sure the element is dark enough will fix that it whether it is blue or dark grey—whereas even a middle grey may still be a problem. The issue is contrast more than lack of color.

[tuomas2]

Three new related settings are here:

[tuomas2]

Implemented in #3354