[openstreetmap/openstreetmap-website] Dark Mode for maps (Issue #5328)
Wilhem275
notifications at github.com
Sun Nov 17 12:31:14 UTC 2024
First of all I want to thank all devs for their works. As I stated in the OSM board I have zero experience in programming, so I can at most nag about... ahem, offer my personal advice on choices 😁
@gravitystorm please help me understand the difference between Option 1 and 4.
>From what I get, in both cases the map is unaltered, cartographers are left free to develop a dark alternative for their layer, but in (1) the choice of layer is manual and up to the user, in (4) it's automatically linked to browser settings (4b reverting to 1 if alternative is not available). Did I get this right?
If so, for me it's Option 1, and now I'll explain why.
I second the "Map is like a photo" approach. Dimming and filtering mess up with contrast and general balance of tiles, as we're seeing (struggling 😄), and inversion messes up with well established meaning of colours and the reasoning behind them.
> So why have dark mode if the main element of the app isn't dark? If you want to have an option to configure this, I can understand that, it might be a good idea. But having a dark map in dark mode seems like a sane default for a **map viewer** application.
Because the main purpouse of dark modes is not to alter colours altogether, it's to avoid large fields of pure bright white. As you'll find in Wikipedia or default Gmail's backgrounds (or Github, now that I see it).
In OSM's UI those pure white fields existed only as **non-map elements**, and turning them to dark gray is being welcomed unanimously. It's actually a very good implementation! Better than what Wikipedia did, if you ask me.
This was done so well that, I think, a toggle switch is NOT needed at all. I don't think you'll find any dark mode user wishing to keep OSM non-map elements white.
Right now I added a toggle to Firefox to circumvent the dimming but, believe me, I miss the new dark header already.
The **map background** in OSM didn't have this problem because it's almost never "white", it's at worst a light shade of grey/green/blue, more often a darker shade of them.
This is why, in most styles, many roads are pictured in white/light yellow, and it works well. If the background was actually too bright... bright pictured roads would have been abandoned a long time ago.
In other words, the map didn't need dimming because it was already kind of dimmed in itself.
This is also the reason why you shouldn't worry too much about harmonizing the map brightness to the surrounding elements.
The map already was, and will be, halfway between the full-white and full-dark surrounding elements. It's not a big issue.
Now, I see that map brightness depends a lot on the layer style being applied.
Carto tends to be quite bright in itself, and this is one of the reasons why I recently moved to TraceTrack Topo with great satisfaction (to the point that I think it should be the default presentation for OSM...).
TTT is in itself less bright and more contrasted than Carto.
The only layer strongly based on "light background, dark elements" is Transport, and for that one I see the need for a dedicated dark alternative.
This was already addressed:
> > @gravitystorm Do you plan to make your dark transport map available on the osm website?
>
> Sure, I'm happy if we want to use that. I don't want to set accidentally set expectations for other projects though, since it's much easier for us to make and host alternative styles than it is for volunteer groups to do the same.
IMHO you can do it without much worries, because for Transport a dark rendering is a "necessity", for other layers not so much.
I see also TT is experimenting with some dark versions, surely other projects are doing so.
This is why I would avoid Options 2 and 3 at all.
Now, about 1 vs. 4, it should also be pointed out that many (if not most) dark mode users are keeping it by default, unrelated to the time of the day, for some it's even just an aesthetic choice. This is why I suggest NOT linking the layer choice to the browser settings, even if a light/dark alternative is offered by a layer.
The reasons for a user to choose between light/dark map layers are mostly unrelated from the reasons why the same user will choose their browser's settings. Imposing a fixed automation would again create a hostile response.
Good news: no need to develop a new toggle, the layer choice menu is already doing the job. It's also easier for users to save dedicated bookmarks to open OSM straight into the layer they find proper for day/night.
To sum my 2 cents up:
- non-map elements: great work with dark mode, keep it as it is, it's good that it's linked to browser's setting, I don't think a toogle is needed
- map elements: remove all of the dimming as soon as possible (don't disperse energies looking for some level of compromise, it's just a wrong way to go, "ruined just a little" is never a good answer), don't alter anything, leave it to the cartographers to develop proper dark layers
- leave to users the choice of style through the current menu, don't force anything
Also, @pkrasicki examples with filtering are actually quite good for night reading, but again I wouldn't like to have them forced on my permanently dark-set browser. I understand they operate at site level, but is there a way to channel them as a layer choice instead of forcing them upon any layer?
> When you're talking about inverting the colors, I hope you don't mean literally just that? We've already made at least 2 better proposals 3-4 years ago: [#2332 (comment)](https://github.com/openstreetmap/openstreetmap-website/issues/2332#issuecomment-727266980) 
>
> [#2332 (comment)](https://github.com/openstreetmap/openstreetmap-website/issues/2332#issuecomment-867821340) 
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5328#issuecomment-2481248152
You are receiving this because you are subscribed to this thread.
Message ID: <openstreetmap/openstreetmap-website/issues/5328/2481248152 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20241117/a4981dc5/attachment-0001.htm>
More information about the rails-dev
mailing list