Fix: Incorrect theme button behaviour

[jogo1818]

theodinproject/spec/components/theme/switcher_component_spec.rb

Line 5 in c4d7cd8

it 'renders the light mode button' do

I'm just starting the program so I don't have the ability to suggest a fix for this myself yet. I noticed the app is not behaving as this code seems to intend, and as I would assume it is meant to. Currently, when dark mode is enabled it is the dark mode button that shows, whereas I believe it is meant to be the light mode button. That way the user sees that they will get light mode if that button is clicked? And vice versa.

Thank you!

[ChargrilledChook]

Hi @jogo1818, I believe the intent of this test is not about the icon but the behaviour of the button - ie, if you're in dark mode you should have a button that toggles to the opposite.

Although I've had the same thought myself before, it does seem to be a common convention to display the icon of the current mode, not the one you're switching to. Two quick examples:

https://tailwindcss.com/
https://rubyapi.org/

These both behave the same way our site does. This is certainly not an area of expertise for me, but it does seem on the surface that this is a fairly common pattern.

[KevinMulhern]

Showing the current theme instead of what the theme it will switch to when clicked was indeed taken inspired by the how the theme switcher works on the Tailwind site.

I've seen a few people bring this up in chat and I wouldn't be against changing this if it's more intuitive to show what theme will be switched to.

Otherwise, I think you're right in regards to the tests not being clear with the behaviour. We probably need something along the lines of:

it "displays the current theme" do
  ...
end

it "will switch to the other theme" do
  ...
end

[jogo1818]

@ChargrilledChook @KevinMulhern thank you for the feedback! I see what you're saying. I still think the tailwinds example is more intuitive as, while it does display the current theme icon, a drop down appears allowing the user to click on the icon of the theme they want. Our current UI forces the user to click on a dark mode icon to get light mode, and vice versa - which (to me - for what that's worth) just doesn't feel like the optimal experience.

I think having it within a drop down menu is what is causing this, as it acts more like a selector rather than a state display as per https://rubyapi.org/ this way.

Basically it seems we are taking inspiration from both those sites and blending them together in a way that may not be the optimal UX?

I would suggest either:

1. leave in the drop down as is, but change to be the opposite icon to the theme currently showing, or:
2. move this into just an icon in the nav bar as per rubyapi.org, keeping the icon showing for the current theme, and can either have state change on click or a selector drop down as per tailwinds (though that's probably not necessary with only two states)

@KevinMulhern re the tests, I didn't even know those were tests, lol sorry - very very new here! I can't really comment on best practice but that sounds like a nice change to me if you just want it to read more intuitively for others.

[KevinMulhern]

move this into just an icon in the nav bar as per rubyapi.org, keeping the icon showing for the current theme, and can either have state change on click or a selector drop down as per tailwinds (though that's probably not necessary with only two states)

I really like this option. At the moment, the theme switcher is located in a different place depending on if the user is logged in/out or on a mobile devise. It's a pain for UX and just to maintain. We've discussed moving to a sidebar nav to open up room for some new features, I think we can roll this change into that. I'll start spiking it.

[jogo1818]

@KevinMulhern ah I see what you mean, yeah when logged out this is actually already as I had described. Sounds good - thank you!

[RyanMcEntire]

I want to voice my support for jogo's suggestion.

Ultimately, the choice of icon is less important to me, as long as the experience has some other level of consistency. I agree with jogo that the tailwind site which was used for inspiration does not behave like the odin site. The tailwind site still presents the user with options to choose from, while the Odin site has you click a moon in dark mode, then click a button again that says dark mode, if you want to switch to light mode. This is a blind jump that is explicitly labelled the opposite of what the buttons actual behavior is.

I would even prefer if it were just an icon you click that switches, instead of the option being nested inside of a menu. If it displays a sun while light and a moon while dark, and jus switches when you click it, that is still preferable to me than putting it behind a drop down and labelling it based on the current state.

Here are some other ways of doing this that make sense:

Youtube, which always displays a moon icon, and the current state in words, but also clearly has an arrow, communicating to the user that there are other options, then the user selects the option they want:

Reddit, which uses a toggle for dark mode:

MDN docs, which labels the theme button with a consistent icon, then gives the user the option to click on the theme they want to change to.

Full Stack Open, which could be described as a competitor course, has a simple button which toggles the theme on click, and uses an icon labelling the state which the user wishes to change to: https://fullstackopen.com/en/about/

I prefer the way Full Stack Open does this out of all options, its the most simple and doesn't require double the clicks, and reflects my intention rather than the already obvious current state. This is assuming the UI doesn't have a third option (reflect system settings, which I would prefer even more, but thats outside this discussion).

Labelling the current state instead of the other option always crosses me as a developer centric intuition rather than a user centric intuition. The reason the user is looking for an icon, is because they already want to change it to something else. The goal they have in mind is the other theme, so it makes sense to me that you'd present them with the other option. They don't need a sun icon to tell them that the current all white theme is the light mode.

Here's one more from javascript.info

[ChargrilledChook]

While I think there might be some more improvements we could make in this area, I've implemented this suggestion:

move this into just an icon in the nav bar as per rubyapi.org, keeping the icon showing for the current theme, and can either have state change on click or a selector drop down as per tailwinds (though that's probably not necessary with only two states)

in order to make the behaviour more consistent and discoverable. This was the simplest change to make for the largest benefit. This should get us 90% of the way there.

Resolved by #3844