At the moment, the feature is behind the devtools.inspector.color-scheme-simulation.enabled pref, which defaults to false on all platforms.

We may check if the current UI is sufficient enough to enable it or if that should be updated.
We might have multiple steps, and enable it on Nightly/DevEdition to gather feedback.

The current implementation of this feature is a four-state toggle between light, dark, no-preference and default.

In the time between when that implementation was first discussed, the spec has changed slightly, and the no-preference value has been removed, so that state should be removed from the toggle as well.

This leaves us with a three-state toggle, but as the page will always read a preference of either light or dark, it feels like it would be sufficent to reduce this to a two-state toggle, where when disabled the page uses the default OS-level style, and then when enabled it forces the page to use the opposite style. On the old bug some people argued against this by talking about e.g. Windows light mode, but as far as I see it that would mean that the page would be light by default and then become dark when the toggle button is clicked, which seems coherent to me.

In any event, the number of states needs to be reduced, because at present it is confusing. Alternatively, we could show a pop-up menu similar to Chrome's when the button is clicked so that the user can select the state that they want, however I do not think that this is necessary.

Regarding the UI of this feature, please see bug 1678949.

Sebastian

I don't think there's any blocker anymore.

https://hg.mozilla.org/mozilla-central/rev/af9e0cac8a0e

I just realized that this feature got enabled by default for all channels. Somehow I thought it was still only for Nightly.

I have to say that the UI with the three state button is very obscure because it only changes the colors and there is no other visual or textual hint for its state. This especially applies when you are using the dark theme of the DevTools, where basically only the brush changes its color.

Therefore, I advise to put it back behind the pref (at least for stable and beta) until bug 1678949 is fixed to avoid a poor UX.

Sebastian

Julian, please see my comment above and let me know whether it is still ok to ship this feature without changing its UI.

Sebastian

I completely agree, thanks for the ping :sebo.
I'll file the bugs right away.

Florens designed something that should be better that what we have and not too long to implement: https://twitter.com/fvsch/status/1359924610976907265
I'm going to give this a try today so maybe this can ride the train

That being put aside, I felt like the current UI was "good enough" as people might want the possibility to simulate light/dark mode , but I agree that having something better would be nicer :)

(In reply to Nicolas Chevobbe [:nchevobbe] from comment #10)

Florens designed something that should be better that what we have and not too long to implement: https://twitter.com/fvsch/status/1359924610976907265
I'm going to give this a try today so maybe this can ride the train

That being put aside, I felt like the current UI was "good enough" as people might want the possibility to simulate light/dark mode , but I agree that having something better would be nicer :)

To be clear here, we don't need to fully change the UI.
Just adding titles to the various states is enough IMO for this to ride the trains.

FWIW as a novice I found the new UI for the buttons really really confusing. It is fine if I toggle between the two buttons, but if toggle the dark button in dark mode (say) nothing happens and it felt like it was broken.

Perhaps hide the dark button in dark mode (and light in light mode) so that the transition is between light mode on and off (in dark mode), or dark mode on and off (in light mode). If there is a state where you might not get either mode from the OS and the browser has no default it might make sense to display both buttons - but I don't know if that is possible.

PS Not doing this for fun; trying to document it for FF87

The information requested is "what am I missing that makes this a good UI?"

The information requested is "what am I missing that makes this a good UI?"

Sorry, re-read that and realised how rude it sounds. Just a bit confused.

The UI already got improved in bug 1678949 from a three-state button to those two separated buttons. Though I agree that the UI/UX can still be improved. The discussion for that is happening at https://github.com/firefox-devtools/ux/issues/129.

For a first version I thought it is still good enough to ship, which in the end happened in bug 1692272, btw., so I removed the dev-doc-needed flag from here now.

I'll keep the ni for Emilio if he wants to add something to that statement.

Sebastian

Not really, I don't have super strong opinions on what ui is better here.

Can you please check the image in this section to confirm I understand the feature correctly:

https://github.com/mdn/content/pull/2562#issuecomment-786420642

Seems like nicolas commented but let me know if you still need something from me. Thanks!

@emilio Thanks very much - I think we're good.

Nicolas says that we have two buttons, only one of which can be set at a time. If neither are set then the simulator does nothing and the value used for media queries is whatever the OS default is. FWIW that confirms my initial impression - the UI is madness: https://github.com/firefox-devtools/ux/issues/129#issuecomment-787531387