Re: [openstreetmap/openstreetmap-website] Dark Mode for maps (Issue #5328)
> > 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). > > And in order to do that, you have to alter colors. You change the background > color and then you change other colors too, because colors that work well on > a white background usually don't work well on a dark background. Developing a > dark theme requires changing colors. This absolutely can't be the case with a map. On a map, colours are not just an aesthetic preference, they're a precise language to convey informations. Pretending to change the colours of a map without respecting its consistency, but just matching the surrounding graphics, is defeating the whole purpouse of a map. It's like if Wikipedia changed the words in its articles according to the text density chosen by the user, or if turning on dark mode on Flickr would invert the colours of the photographs. They may be easier on the eye, but the message would be lost. This is why it's a mistake to consider the whole UI of OSM (map+frame) as a single graphical unit to which a dark theme should be applied consistently. Strictly speaking, even if they are shown together, the map is not part of the site's UI. The map is an element **with its own graphical rules**, and very specific ones within each style and zoom levels; it's not there to act as a background for the menus (or vice versa). Dark themed maps are absolutely fine, but they are styles on their own with their own consistent language. Some people prefer map style and frame to show consistence, or to act differently according to device, browser, time of the day? Nothing wrong with it, but 1) first develop consistent dark style maps, and 2) even then, the choice of those styles must be left independent from any external condition. They're not equivalent to "light styled maps", just easier at night. It's like assuming the cycle map is good for everyone because, after all, it's conveing pretty much the same information as Carto. > > 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. > > There might be people who want to enjoy dark/light theme without changing > their system settings. Well, as long as we treat map themes separately from frame themes, fine be me. I don't think a lot of people wish to keep OSM's frame inconsistent with their browser's settings, but I'm certainly not opposing an extra choice (mostly because I won't be the one having to work for it 😅). Just don't link the map style to it. > > 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? > > [This > proposal](https://github.com/openstreetmap/openstreetmap-website/issues/5324#issuecomment-2480755496) > would let you easily disable the filters by changing the map theme to light. I am critical of applying this "reading mode" filter feature as a general toggle _to the whole site_. It is again a matter of language consistency. I don't think filters can't provide good consistent results (quite the opposite, I think yours has better potential than some native dark styles). I just strongly doubt a single filter can be optimized across ALL styles. By applying it with a general toggle we would have a wonderful "Nighttime Carto" but also a crappy "Nighttime TTT" or, even worse, a mediocre result for all styles (which is what happened now with dimming). My advice is: quality over quantity. It can work, but first optimize it for one style, keeping in mind the language consistency. Then find a technical way to present it in the list as a style of its own. It would act as a hidden toggle: when the user selects "Nighttime Carto" the site would be switching to normal Carto tiles AND activate the filter. This approach could also solve the problem pointed out by @gravitystorm about the limited resources of smaller projects: they wouldn't have to render and host twice all their tiles, they would "just" need to develop an optimized filter and then let the magic happen locally. A general toggle should be used only if each style have its own optimized dark filter. I'm not against it of course, but I doubt there are resources to develop and maintain all of them... And for the love of Pete, don't link it to browser or OSM frame's settings 😁 -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/issues/5328#issuecomment-2481422710 You are receiving this because you are subscribed to this thread. Message ID: _
Re: [openstreetmap/openstreetmap-website] Dark Mode for maps (Issue #5328)
> I get that people are scared that we will mess up the map. It's normal for > users to be afraid of UI changes even when they are good for them long term. > But just saying that it isn't gonna work isn't productive. It's also not helpful to dismiss other opinions with "people don't know how things work, so they're scared and afraid of change". I explained some technical reasons why messing with the maps appearance means tampering with their message. It's measurable in numbers, don't dismiss it as uninformed fearmongering. -- Reply to this email directly or view it on GitHub: https://github.com/openstreetmap/openstreetmap-website/issues/5328#issuecomment-2487213783 You are receiving this because you are subscribed to this thread. Message ID: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] Dark Mode for maps (Issue #5328)
> 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: ___ rails-dev mailing list rails-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] Dark Mode for maps (Issue #5328)
> I haven't seen any substantial counter-proposal to my "option 4c" suggestion
> ("Cartographers choose") earlier:
@gravitystorm Actually I wrote one, but it got lost in mine and others' wall of
text 😅
I'll rephrase here, also because things changed a lot with the recent (welcome)
introduction of user preferences.
Basically, what we're discussing now are just defaults for unlogged users, as
logged users can now override any setting.
My idea is that "Cartographers choose" is good in terms of choosing _what kind_
of dark version of their style should be shown; so that they can avoid
alterations they don't find faithful to their work.
But still, even if a dark map was developed/approved, I think light map should
be the default presentation.
This is because many (if not most) dark mode users are keeping it as their
default system's setting, for various reasons not directly related to
brightness/contrast/ease of reading, and thus system (or site UI)'s settings
cannot be considered as the relevant factor to decide which style of map should
be presented as a default.
I have one personal reason for this, and a more general one.
Personal one is that I often need to access OSM while not logged in (I don't
want to save my personal credentials in company's devices). Dark system ok,
dark browser ok... dark maps definitely not ok. Which is happening with the
current situation: I'm still plagued by the default gray layer whenever I'm
logged out. At least at home I'm free now.
Also, sometimes I need to access OSM in anonymous tabs.
In general, I think standard map styles should be the default way OSM presents
itself, especially to new users. Dark maps are an appreciable extra feature but
they are usually less rich is information, and less... nice. I think part of
OSM.org success is also due to the featured styles being appreciated for their
colourful and rich way of representing the world. Again, this is unrelated to
reasons for users to keep their system dark.
As a side note: even for logged users, I think it would be better to move the
maps preference to the layers menu, for a quicker switch.
And/or just show Dark Transport as another style offered in the layers menu,
I'd be happy to use it at night 😁
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5328#issuecomment-2542331109
You are receiving this because you are subscribed to this thread.
Message ID:
___
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
Re: [openstreetmap/openstreetmap-website] Dark Mode for maps (Issue #5328)
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
