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/2481248...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
