Dark Mode Testing

[zackkrida]

@WordPress/openverse-maintainers if you enjoy using dark modes, please consider testing Openverse's dark mode implementation at https://staging.openverse.org/?ff_force_dark_mode=on.

@fcoveram, please also review the dark mode whenever you are able to, and share any of your own feedback and suggestions here.

After some discussion here of the dark mode, we can create issue(s) (if needed) to refine the styling and make changes.

I'd like to open a two-week period for testing these designs, so this discussion will close on August 30th.

[zackkrida]

I personally really like this dark mode! One issue I see is that the image loading background color (the "skeleton" loader) is too light in light mode. @fcoveram do you know, is there a darker color that was planned to be used for that?

[fcoveram]

I missed adding a dark version of the skeleton. I should also include an update in the layout, the current reflects the previous masonry grid. Thanks for noticing it.

[kspilarski]

Hi @zackkrida! I tested dark mode and it's working fine - all pages remained with the same black background color all throughout.
When searching, it will first display these blank spaces for 2-3 seconds before loading the images and audio:

While testing dark mode, I came across untranslated texts. Let me know if I should open another issue, but I'm sharing my here feedback on that. When I switched the language from English to Polish, not all contents were translated. For example on this page https://staging.openverse.org/pl/sources this part remained in English, but was translated fully when Deutsch and Espanol were selected:

Some providers have multiple different groupings of content within them. Flickr has sources ranging from NASA to personal photography. The Smithsonian Institute comprises a dozen diverse collections. Wikimedia Commons runs the gamut in terms of content, and is used by several galleries, libraries, archives, and museums highlighting some or all of their digitized collections.

Polish:

Deutsch:

[zackkrida]

Thank you so much! Concerning the translations, you should have seen a banner indicating that the translation was partial:

Do you happen to recall if you dismissed those prior to observing the missing translations? If not, that itself might be an issue.

[kspilarski]

I've tried this again in the same browser in private mode and other browsers too, and the banner on top appeared like in your screenshot. Looks like there is no issue on the translation here! Thanks! :)

[zackkrida]

I found an additional small issue. Text inputs use the white text so are illegible in dark mode:

But when selected:

[fcoveram]

All form components come from the WordPress Design Library.

Given that WP library doesn't support dark mode or other themes yet, it seems reasonable to document the ones used in Openverse in the self Design Library. This will allow better documentation and avoid instance breaks caused by updates that Openverse doesn't need.

If the above makes sense, I will make the components on the image as Openverse components, and include the text area to document how it changes in dark mode.

[josephahaden]

The highlights when hovering are different for each element on the page. This is a hold over from light mode and for some reason it's not as jarring for me there. If this is a design decision based on modern best practices, then please let that override this opinion. :) But for example:

the Load More button

the External Sources button

[zackkrida]

This one's an implementation bug, the focus rings were designed to be a consistent size and color. Nice catch!

[kspilarski]

Hi @zackkrida I have additional feedback on dark mode and sensitive content:

Including "sensitive content" in your search and clicking that sensitive content from the results to expand it, this message appears. The sensitive content warning is hard to read, with the light grey text against the white background:

Only when you highlight the texts, it's more visible:

But in light mode, the sensitive content warning is visible with black texts against the white background:

[sarayourfriend]

Does the placeholder text inside the search box pass contrast requirements? I can barely see it myself 😅

On a small screen, the white background of the analytics banner + the help with translations banner on the homepage will fill a large portion of the screen:

My network is current too slow for me to load figma to check whether this is intended in the designs, but the background colour of the mobile global audio player's waveform is still white, so the unplayed part of the track's waveform is not visible. (In fact, something is so wrong with my connection at the moment that I cannot upload the screenshot to show you, but I will try again in a bit)

[sarayourfriend]

If the correct color does not fix the problem, is it possible to set the font-weight values of regular and bold to a higher level in screens and/or browser settings like yours? Applying this, the UI weight could increase proportionally.

I didn't know about this before, but it's possible to write a media query against the pixel density of the display: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/resolution

I'm curious about this. Does not 16px render as 16px on every screen?

Unfortunately not, neither in the visible size on the screen nor in the literal number of pixels used. MDN describes it this way on the documentation for the px unit:

For screen displays, it traditionally represents one device pixel (dot). However, for printers and high-resolution screens, one CSS pixel implies multiple device pixels. 1px = 1in / 96.

You're probably already aware of that aspect, that retina displays (high pixel density) use multiple physical pixels to represent a CSS pixel.

Beyond that, though, display dimensions also has a role. Consider two 1080p displays, one a 32-inch display and the other 27-inch. Both have the same number of pixels, but they are spread over different physical dimensions. The 32-inch display has "bigger" pixels than the 27-inch, so the same 16 pixels will appear larger on the 32-inch display than the 27-inch display. It's still 16 pixels on each. Crucially, in this situation, I don't think there's a benefit to readability in the larger display. The displays will render the same exact image, which means the 32-inch display makes the smoothing needed to render fonts much more visible (because the aliased pixels are bigger).

When you go up to a higher-density display like 4k, this becomes awkward because you have to choose some scaling factor. Rendering the screen at 1-to-1 pixels on a 4k display at 32-inches is unreadable small. So then you get into the multiple physical pixels for a single CSS pixel, in addition to the differences in display dimensions. Things start to get weird and hard to predict.

My laptop screen, for example, has a pixel density and size such that 200% scaling leaves everything too cramped. 100% is unreadable. So I have to use something like 150 or 175%. If you look up Hi DPI display scaling issues, you'll see lots of people struggling to find a good balance. My spouse's laptop has a similar size screen (it is slightly wider) but is a 1080p panel. It has much lower pixel density. When I set my computer to 150~175% the same UI elements will roughly match. But my spouse's laptop is using 50 to 75% fewer physical pixels to render those elements. For thin fonts, that means a higher ratio of pixels of a given letter used to smoothen it.

Which I guess all of this is to say that when the contrast of a UI element is "on the edge" of readability, these differences in the physical aspects of the display become more prominent. They get harder to account for, and things get more complicated.

---

I think the best thing to do here would be to just fix the colour issue, and then accept that as good enough for now. With the changes we've made to the way the styling code works, we can accommodate further variations on the UI, like adding another mode for high-contrast. I enable high contrast designs whenever I can because I struggle to read what is considered "normal" contrast. Unfortunately, this search box, even with the right colour, is difficult for me to read. But I think focusing too much on this specific instance and my experience, if the correct colours pass the contrast test we use, risks over-complicating things too early.

I propose we fix the colour and confirm it passes the basic contrast test we use, and open an issue to consider an additional high-contrast mode. That way, we can separate the trade-offs that high-contrast requires in UI "boldness" and such things.

If no one else is having an issue with this UI element than me, and if the only solutions are conditional on things like physical screen properties, then I don't think it's worth the complexity. For context: I have a hard time reading many of the UI elements on GitHub even though I've enabled their high contrast theme. On GitHub's UI it is very bad, there are large sections of text (like these discussion comments) where it hurts to read unless I zoom the UI in a lot. It isn't unusual for me to come across things like this on websites and applications (Slack is also annoying for this). The Openverse dark mode is pretty much fine everywhere else I've looked. I'd say I spend about as much time in GitHub as I do on the Openverse website, so I don't think it's a difference in familiarity, in this respect.

In other words: one UI element that I personally experience as too-low contrast is not unusual when I interact with contemporary UI. I don't want to get too hung up on this if the ways of addressing it will be overly complex in code.

[fcoveram]

Thanks for the explanation. I had no idea about the @media resolution property.

…The 32-inch display has "bigger" pixels than the 27-inch, so the same 16 pixels will appear larger on the 32-inch display than the 27-inch display.

Interesting. I thought that was already solved by weightening resolution, pixel density, and display size to reach an standardized physical size.

I propose we fix the colour and confirm it passes the basic contrast test we use, and open an issue to consider an additional high-contrast mode. That way, we can separate the trade-offs that high-contrast requires in UI "boldness" and such things.

+100 to this. A high contrast should be "easy" to design given the alias defined. I wonder if the mix "light/dark mode + high contrast" makes sense. If so, an "Enable high contrast" checkbox sounds sufficient to add in the settings.

[sarayourfriend]

I wonder if the mix "light/dark mode + high contrast" makes sense. If so, an "Enable high contrast" checkbox sounds sufficient to add in the settings.

That's about what I had in mind as well. Here's an issue for high contrast mode: #4853.

[fcoveram]

Thanks for creating the issue 🙏

[zackkrida]

I just wanted to share a massive ➕ to the proposed solution of a high-contrast mode for the light and dark themes. I am really glad this discussion led to such an idea 😄

When I think about reasons why a project like Openverse should exist, and the benefits of 'centralizing' such a solution, as opposed to the innumerable different sources of CC-licensed works out there, trying to create the most accessible and reliable user interface for the largest possible audience ranks high! Frontend development is so increasingly complex and with many nuances that many sites lack the resources and expertise for and I think it's an area we of course still have much room for improvement in, but also an area we can really shine in.

[fcoveram]

The implementation looks wonderful. Congratulations 👏 I saw correctly almost everything and just a few minor styles showed up. Here are the thing I found out.

Incorrect color in focus rings

There are a few elements where the focus ring have the wrong color

Section	Screenshot
Header items
Clear button in search input in Search header
Footer items
Source in audio details page

Focus rings with white halo

The elements listed below have a white ring in addition to the primary one. I wonder if we should remove it instead of applying the bg color as over other colored background the error will still exist.

Section	Screenshot
Image result in All content results
Audio result in All content results
Links in body content in all internal pages
Link in filter safe browsing section
Link to license in media details page
Links in Attribution box

Incorrect focus ring

The toggle has an incorrect ring

Dark snackbar

The snackbar remained dark instead of changing to its lighter version. There is also a white ring that might relate to a section above.

Hover style of search input

The search input changes the background color when it should just change the placeholder color. This is incorrect in both themes, yet reporting it to address it in parallel.

Audio control is not visible

When focusing the wave area to jump between seconds, the control is not visible.

The machine-generated thumbnail doesn’t follow the theme

The designs don't have this documented, but based on the color scheme defined, the dark dots should be bg color.

Disabled style in button

The pointer seems to announce that the report button is disabled. If this is correct, then the disabled style is incorrect in both modes. Reporting it here as a note for addressing it in the future.

[zackkrida]

This all looks excellent @fcoveram.

As for the report button, it is disabled until the required 20 characters are typed in the textarea.

[fcoveram]

Yes. Looking at the gif again, I noticed the "Report" button is slightly bigger. I will create an issue pointing out the necessary changes.

[zackkrida]

Thank you all for the feedback! Testing is over and the suggestions have been moved into a new issue: #4911