Site theme switcher (dark mode toggle)

[fcoveram]

Designs for Dark mode project (#3592)

Description

Given that users need to set the site theme from any part of the site, the most affordable area is the site footer. It already has the language selector, that behaves equally, and adding the action there is the more logical solution.

Mockups

For the current arrangement of pages in both footer content and internal, the following version is the one that convince me most.

The switcher is placed next to the language selector and it behaves equally. The options displayed are Light, Dark, and System in the OS/browser popover.

Footer

Content footer is on top and internal footer at the bottom.

Middle- and long-term idea

With the design explored (#3564) to make the internal pages area more simple, I would like to bring again the opportunity we have to make the footer even more simple by putting the general/site settings in a unique config menu.

The benefits of this idea is twofold:

• It puts Openverse in a better position with regards to privacy by making the toggle more visible
• It's the first step towards placing settings in a single menu once user profile-related actions are needed in future features.

I personally would like to consider the implementation of this middle/long-term component. What do you think?

[openverse-bot]

Subscribe to Label Action

cc @WordPress/gutenberg-design, @WordPress/openverse

This issue or pull request has been labeled: "🖼️ aspect: design"

Thus the following users have been cc'd because of the following labels:

• WordPress/gutenberg-design: 🖼️ aspect: design
• WordPress/openverse: 🖼️ aspect: design

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[jasmussen]

Generally looks good! Location seems good.

The border around the dropdown button makes it feel at home next to the language dropdown. But this button up here only has that same border type on hover:

Is there some heuristic we can apply for when the dropdown button is outlined vs. not? Optical balance can be fine, but just noting the opportunity.

Entirely separate observations:

• The dropdown chevrons feel a bit chunky and big to me, and the space between icon or label and chevron is a bit bigger than it might need to be. This is a bit more visible with the cog icon addition.
• In the block editor core project, we put toggles on the left of the label, as opposed to the right. I'm aware that toggles on the right is a relatively common practice especially in mobile, and I think it can work, but in the core project we had to move them to the left in part because under the hood it's a re-skinned checkbox, and those are usually preceding the label.

[jasmussen]

Oh, and I quite like the dark mode switcher on Rich's site. I don't know that it entirely works for Openverse, but it's fun.

[AetherUnbound]

I think I'd advocate for the mid/long-term solution myself too! I think, as you say, puts us in a better position going forward for anything else we'd like users to be able to configure. Both designs look excellent though!

[fcoveram]

Thanks @jasmussen for your thoughts. Here my responses.

The header is the only component that buttons showing border in hover state. I designed the element aiming for simplicity and reduce visual elements as much as possible to prioritize results content and keep the surrounded area of search input clean. In that vein, the border style in inactive button competed with the gray background of search input.

This behavior detail captures my idea more accurately.

The dropdown chevrons feel a bit chunky and big to me, and the space between icon or label and chevron is a bit bigger than it might need to be. This is a bit more visible with the cog icon addition.

Reducing the spacing between icons sounds good. I made a quick test and the outcome is nice. In the case of icon and label, the reduction looks tight compared to the rest of the UI. It seems that a rule for "icon + label" and "icon + icon" can be applied easily. Adding this to my backlog.

In the block editor core project, we put toggles on the left of the label, as opposed to the right. I'm aware that toggles on the right is a relatively common practice especially in mobile, and I think it can work, but in the core project we had to move them to the left in part because under the hood it's a re-skinned checkbox, and those are usually preceding the label.

This is interesting. I didn't notice this position change between desktop and mobile. I quickly checked a few apps I used and they change the toggle position. I would add this to my backlog to discuss it with folks.

And yes! I also noticed Rich's implementation and it looks nice. The motion when switching style is great. I tried something similar for a toggle of three options, but it overloaded the screen.

[zackkrida]

I'd personally like to start with the theme switcher directly in the footer. Since we plan to keep light mode enabled by default I think making the element prominent in the footer makes the feature more discoverable.

It also keeps the scope of the dark mode project smaller, as the new "settings" panel feels like a larger change that we may want to consider more carefully and/or spin into its own dedicated project to answer questions like "How does it scale if we have 4 more settings?", etc.

[fcoveram]

True. Let's keep it simple and go with the basic version. I will update the design file and come back once assets are ready for dev.

[fcoveram]

Mockups are ready for dev. Since the change involves mostly changes in components, I requested them in #4232