> and if we implement some straightforward preferences (e.g. auto/light/dark
> prefs for UI and/or maps) then I think most people will be reasonably happy
> with the outcome
> That's what you'll get if there's an option for the map mode independent of
> the ui mode.
@gravitystorm @AntonKhorev
Is there any possibile conflict in giving users both a Dark UI toggle **and** a
Dark Map choice?
The only one that comes to my mind is that some cartographers may oppose any
alteration to their style, to the point of refusing any kind of dark mode for
their layer (despite being given freedom to develop or choose one).
Is it possible to reach out to cartographers and ask for their opinion before
further interface discussions? Maybe they just don't care and the problem
doesn't even exist. Or maybe they're so much against alterations to their
styles that no Dark Map will exist at all until someone develops one from
scratch.
In this latter extreme scenario, it would all boil down to who's preference
should prevail: users who absolutely want a Dark Map no matter how, or
cartographers who absolutely want their style untouched.
I suspect cartographers have more power in this, as they may pull back their
style from the project (o even escalate into a legal dispute?).
Users can always develop their own dark style, if they care about it... and
remember we're talking about the extreme situation of an absolute refusal by
the cartographer. If they develop a dark version or accept filtering, the
problem doesn't exist.
In any case, this is one more reason why I would not implement a general Dark
Map toggle overriding all styles, but instead present dark map styles to the
user as individual choices in the Layers menu (no matter if the dark styles are
native or by filtering, I'm not debating this).
If you implement a general toggle for all styles then you have to work out a
way to override it for specific layers.
If the choice is via Layers menu... then it's just one less item in the list
(and, remember, users can easily bookmark "Light OSM" and "Dark OSM" to launch
whatever style fits them at any time of the day).
> @Wilhem275 If your opinion isn't just based on fear, then you should have no
> problem pointing out what specific issues you've noticed with the proposed
> solutions. I don't mean to criticize you, though. It's common for users to be
> against significant UI changes. I'm just saying that we shouldn't let that
> fear stop us from adding new features.
@pkrasicki I think I already gave an extensive answer
[here](https://github.com/openstreetmap/openstreetmap-website/issues/5328#issuecomment-2481422710).
To cut it short: developing a filter to adapt a single style is already a risky
business, but it can work. What can't work is having one single filtering rule
that can work well for ALL styles.
Map styles are based on the mathematical relationship between the colours of
all different elements. Within a single style, they're already a large number
of relationship to manage trough one general set of rules.
Multiply this by all styles and their variations at different zoom levels, it
becomes a staggering number with many conflicts.
It's not a fear, it's an absolute certainty that the output will be a mess 😄
Exactly what's happening here:
One size can't fit all.
As an alternative, you can develop specific filters for each style (and each
zoom level...), this could work. But, can you guarantee to develop and maintain
specific filters for each layer?
And by "develop" I mean also trialling them with a large number of users, not
just launching into production a result satisfying you, me and four people in
here. One by one, for each zoom level.
Seems quite a big job to me...
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5328#issuecomment-2496037126
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/issues/5328/2496037...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
