freeCodeCamp
freeCodeCamp copied to clipboard
freeCodeCamp
Use System Default for Initial Theme?
Describe the Issue
I had an issue with another website that was fixed by clearing my browser cache. As a result, I had to log in to all of my sites again. I ended up on Reddit which defaulted to light mode for unauthenticated users, and realised that freeCodeCamp does the same.
Affected Page
https://freecodecamp.org
Steps to Reproduce
- Log out.
- See light mode?
Expected behavior
I'm wondering if we should leverage the user's system setting to determine if we should default to light or dark mode.
Screenshots
No response
System
The only relevant thing here is that I'm on Windows, I think.
Additional context
No response
Yes, we default to light mode.
... we should leverage the user's system setting ...
I'm not against this - although, I think the bigger issue is that you can only switch the theme if you are logged in. Seems like you should be able to switch regardless. I don't recall if there was any reason that we don't allow that.
@moT01 Wouldn't it be more helpful to have night-mode for non-logged in user as well, and also it defaults to system's theme?
So the logic should be the followings: // if user has a set a preference, set the theme // else if system setting has a theme, set the theme, // else set the theme as default.
We could set the theme in the localstorage and pull it up on the upcoming sessions. Reference: https://github.com/gaearon/overreacted.io/blob/master/src/html.js#L21-L48
Do we want to allow non-authed users to switch to night mode using the menu? I feel like we should. If so, we may not need some of this logic (or, may need more).
I think we should allow non-auth users to switch theme. If users have not set a preference in the localhost and have a theme preference on their record, we could pull that data and set it accordingly if possible. Moving forward we would not want to use the user records for theme switching.
To resolve this issue in the short term:
- If the camper has set the theme to
night: We should display night mode (the current behaviour) - If the camper has set the theme to
default: We should respect the system settings for the theme.
@ahmadabdolsaheb, @ojeytonwilliams, @raisedadead. I want to bring back the discussion to the issue, and finalize the solution before the implementation.
I have a looked into different implementation, and the one from Mozilla foundation seems the most fitting to me and want to discuss it with you.
What do you think of 3rd option for OS system? So people can have an opt-in system option, when the ability to store data hinder the camper experience, because they want to have different themes in different devices.
@ahmadabdolsaheb, I lost the notes because of the holiday so I am not sure, we didn't want the themes to be a dropdown, but just buttons for now.
Was that about the menu or the setting picker? I am not sure.
We can keep them as buttons. Also, we could remove the theme switching from the navigation entirely.
My two cents:
- They should be a drop-down on the settings page. Dropdowns make it very nice and clear of the selection and not to mention easiest to maintain (a11y and UX wise, etc.).
- There was a very strong argument to keep the theme in the nav and was a very common request. I wonder if the toggle can be converted into a similar UX as the language selector, then we would be set.
They should be a drop-down on the settings page. Dropdowns make it very nice and clear of the selection and not to mention easiest to maintain (a11y and UX wise, etc.).
We can come back to the dropdown, when we add new themes. Maybe we create a different component that display part of the page in different themes instead, like GitHub. So let's not spend our effort on this yet, while the one we're currently having something that is working. 👍
They should be a drop-down on the settings page. Dropdowns make it very nice and clear of the selection and not to mention easiest to maintain (a11y and UX wise, etc.).
I am worried that we will run into the issue of it being obscure, like what we have in the language selector.
We can come back to the dropdown, when we add new themes.
A wise man (Quincy) once said, you should avoid introducing big changes to UI. If you have to, then delay and introduce them all at once, because you WILL get called out for doing something radical. Might as well do it fewer times.
Point being, if you are building something that you are going to throw away (and you know it), you are doing it wrong. 🤷🏽
Themes switchers seems to be the convention in blog/documentation website navigations. As the app gets more complicated, the theme switcher gets relocated to the settings.
The language selector is moving to the top navigation. If we rely on the settings page's theme switcher, we could remove related section from the dropdown navigation entirely. That being said, if there is a lot of demand for it, we should keep it around in the nav.
If we keep the theme switcher in the nav, it makes sense to use a component that looks good on mobile such as a dropdown so we could reuse it in the settings page as well.
Based on discussion with @ojeytonwilliams:
- it's possible to add the theme values to local storage and set the default theme of the pages based on them.
- it's possible to have system theme if the local storage store third value
- it's possible to clear the flash with the usage of local storage
If the logic seem convoluted, feel free to lay it down in pseudo code. Once everyone is in agreement, we can proceed with the implementation.