Dark mode feature introduction flow

[fcoveram]

Designs for Dark mode project (#3592)

Description

In order to have users updated with the latest improvements on the search, I have the following idea.

The "what's new" message is displayed in a modal with a blurred background that shows an image or gif, text content introducing the feature, and one action to enable/explore the feature and one to close the overlay dialog.

For the dark mode feature, all texts are pending and need comms revision, and the visual placed above text content will show how the feature works in production (discussed in #4155).

Here is a prototype that simulates all interactions expected.

CleanShot.2024-04-18.at.16.15.36.mp4

Mockups

Figma file: Dark mode

[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]

Beautiful work as always. As I think we discussed in a chat, there are a few ways to do this:

1. Roll this out with system set by default, don't inform anyone
2. The same but with a modal
3. The same but with a notice
4. Above options, but defaulting to "light"

Of those, 1 appeals to me because it's very simple. I also have a slight aversion to welcome modals that get in my way, though I like that you've positioned this as a "What's new" modal: ooh new goodies!

Whether it's a notice or a modal, I'm happy to defer to you and everyone else, both can work fine. The notice gets less in the way, though, so the main question to answer is: is dark mode a substantial enough feature to warrant the modal instead of the notice? My instinct: probably.

[stacimc]

I've added priority: medium as I believe that's the given priority for the project, but please feel free to update.

[AetherUnbound]

I like the idea of the modal and how you've presented it here! I worry though about how we might be able to actually manage showing the modal only once on an implementation level. Currently I feel like I have to dismiss our existing analytics banner quite frequently when using the search; it would be unpleasant to have to dismiss the modal multiple times across different devices or even multiple times on the same device depending on how we save session state information.

I do think rolling dark mode out with system as default would be a good alternative to this though! It doesn't solve the more general feature introduction flow though.

[zackkrida]

I also think this looks fantastic, but think it ultimately might be too intrusive. The main use case I'm concerned with is first-time Openverse users and the added barrier of making a search.

The majority of our traffic is on desktop and our homepage is fixed-height, so the control will immediately be visible to users.

I do think that defaulting to system would work well to fix this issue. Any user who is sufficiently tech-savvy enough to enable dark mode on their system or browser will 1. probably appreciate Openverse's dark mode, and 2. if they do not like it, should be able to find the footer control to disable it.

[sarayourfriend]

Agreed on the intrusiveness of it. Is there an option where we somehow highlight the toggle itself, maybe with a tooltip indicating the feature is new?

If we do anything for this, I'd like also to have a timeline defined for when we would deprecate the feature. It should not live indefinitely.

Currently I feel like I have to dismiss our existing analytics banner quite frequently when using the search; it would be unpleasant to have to dismiss the modal multiple times across different devices or even multiple times on the same device depending on how we save session state information.

My request for this is a bit off-topic, but @AetherUnbound can you create an issue for this and describe how to reproduce it? Doesn't sound right you're needing to re-close these on a regular basis; but I can reproduce it for the analytics banner for sure. Might be an SSR issue? We shouldn't discuss it here, but it definitely needs an issue to investigate as a bug.

[fcoveram]

I have another less intrusive idea I can go back to, and also try something as minimal as possible.

First-time users is definitely a concern, but I also think it's good to consider a system for introducing features no matter the expertise level. This tech-savvy feature is simple in terms of steps required, but the additional search views involve more screens and we didn't consider an introduction stage when outlining the project.

[fcoveram]

Coming back here after a few days to share a new version. Before diving into details, here is a recording of a prototype.

CleanShot.2024-05-06.at.13.13.25.mp4

The idea main idea behind this proposal is showing a whats-new message in the home page while stand out the theme switcher until the user clicks on it. The homepage's banner is a link that takes you to the latest release page on Github where more details are added.

The glowing button meets the WCAG requirements, and for the motion reduction settings, we can set the border in dark (text-primary color) and change its width from 1.5px to 3px without the transition effect.

We can reuse this pattern in upcoming features that impact the UX more significantly. In cases where the feature is a set of views or flows that are not afford through a single UI's component, we can safely skip the glowing button and rely on the release page. There we can include recordings and mockups describing what changed and how users can use it. I'm thinking this scenario specifically for the #410 project where we missed this introductory stage.

For a more real interaction, you can check this prototype.

[AetherUnbound]

This is... so cool. I love it, I think it's an excellent approach for showcasing new features without being too intrusive. Amazing!! 🤩

[sarayourfriend]

That's great! It's definitely less intrusive on desktop, and looks like a pattern we can use moving forward. Nice work, Francisco!

I am keen to see how it comes across on mobile, and whether it's less intrusive than a banner. On a small phone screen the homepage is pretty tight.

[fcoveram]

The dark notification message intends to be intrusive. For that reason is that I suggested not overusing it in other scenarios and instead finding more in-context manners of announcing changes.

However, that screen @sarayourfriend definitely looks overloaded. I was thinking of adding the announcement banner on both desktop and mobile. But I agree there is room for improvement in having a cleaner layout.

[sarayourfriend]

However, that screen @sarayourfriend definitely looks overloaded. I was thinking of adding the announcement banner on both desktop and mobile. But I agree there is room for improvement in having a cleaner layout.

Looking at the screenshot again, I wonder if for mobile we could put the language and colour scheme selector on the same row, so that each are only half the page? Some longer language names might not fit, but very few are that long. Because the screen is so much smaller on mobile, with the highlight effect, the colour scheme button would be pretty noticeable (it isn't far from the main content so that you could miss it, like it is on desktop).

[fcoveram]

I wonder if for mobile we could put the language and colour scheme selector on the same row, so that each are only half the page?

Yes. The change requested in #4155 includes the footer in this way. Here is a screenshot from the dark mode file where footer variants are added.

[fcoveram]

I created the mockups for the smallest breakpoint, and here is the outcome.

The mockups has the following changes:

• Announcement banner has a shorter version of the main text.
• h1 has a smaller font-size for a cleaner layout.

While revisiting the current homepage, I noticed other minor text styles we could correct in the PR. In addition to that, I also think we could include text-wrap: balance in h1 to have a harmonious white space on the text's right side.

The assets are ready in the Mockups page.

[fcoveram]

Replacing the design: in discussion label with design: ready

[sarayourfriend]

@zackkrida Does this need an implementation plan ticket or will it be a one-off issue? It looks like there could be individual components related to this, but I'm not sure if they're separate PRs, necessarily.

We probably need to fix the problem @AetherUnbound identified in this thread, which I reproduced in this comment as well: #4157 (comment)

My concern is whether whatever we use to indicate this visitor already knows about this feature would cause the experience to differ?

Although, I'm wondering if this is potentially related to the change we made in Cloudflare regarding session cookies and cache bypass 🤔

[zackkrida]

@sarayourfriend I believe the issue @AetherUnbound identified is updated as of the session cookies and cache bypass changes we made. As of this issue: #4308, user color mode selection will be stored in the existing UI cookie which is already being used to bypass the page cache.

I think we should dismiss this "dark mode feature notification" effect when:

• The user clicks "See more" in the homepage announcement pill-banner-thing
• The user clicks on or taps the theme switcher at all

I will amend the existing implementation plan to include this feature introduction and add it to the task list. I'll also include the other changes I've made to the IP when drafting the issues, like those mentioned in #4308.

[fcoveram]

We could include a third case: if user doesn't click on the banner or the switcher, both elements disappear after 2 weeks. What do you think? Both elements are not intrusive and that time span sounds reasonable to me.

[zackkrida]

@fcoveram that is potentially a bit more complex to implement but is probably a good idea.

Interestingly, I've also had a thought. We really only want to introduce a feature to existing users, right? For new users, they are unfamiliar with all of Openverse's functionality. So we also might want to:

• only show the feature introduction to users with existing Openverse cookies
• only show the feature introduction for a fixed period of time (2-3 weeks)

[fcoveram]

…We really only want to introduce a feature to existing users, right?

I wasn't sure about this, but the more I think the idea, the more I like it. +1 to the suggestion.