1ec5
commented
1 year ago Multilingual support – text should adapt to the user's browser languages (doing great on this already, keep it up!)
Tracking the rest of the UI in #744.
High-contrast – overlapping colors should be easily distinguishable (might require an alternate color scheme to satisfy all cases)
We don’t make much use of fill patterns yet, but they can be very useful for minimizing the number of colors we rely on to communicate characteristics about a feature. We do use line dash patterns, but the lack of data-driven styling for dash patterns makes it difficult to scale these treatments to more features: maplibre/maplibre-gl-js#1235.
High-contrast – overlapping colors should be easily distinguishable (might require an alternate color scheme to satisfy all cases)
I think this is a worthy goal even with the current design motif. Currently, Americana has much better contrast than openstreetmap-carto in well-mapped areas. To keep up that contrast, we would need to be very selective about the kinds of fills we introduce to the style. In my opinion, this is an argument for leaving out many of the physical geography distinctions that openstreetmap-carto makes – good grist for a more topographic-oriented “layer” that this application could perhaps switch to dynamically.
Dark mode - light-on-dark alternative style (yes, this is designing an entire second color scheme; might be a longer-term idea)
Some users also like dark mode for aesthetic or ergonomic reasons. There isn’t much precedent for this in our usual design sources, other than turning off the passenger-side overhead reading light. But if we can get away with only making the style slightly darker, not quite based around a black background, then I think this is quite feasible. I even have some print maps in my collection that have fairly dark gray or brown backgrounds and even darker water. These maps don’t overwhelm the eyes, but the amount of ink they use probably isn’t very environmentally friendly either. 😅
Scalable font sizes – users should be able to make labels bigger while the map zoom remains the same (most browsers have a text-only zoom feature we can follow)
text-size-adjust looks useful for the overall UI. Is there a DOM equivalent that we can feed to the style and use directly in the shield generation code? (Related: mapbox/mapbox-gl-native#7030.)
Cross-browser support – always an uphill battle, would be nice to automate tests somehow
We could use some help on this front. We’ve been managing so far by sticking to conservative dependency choices and maximizing our use of these dependencies rather than rolling our own UI, but eventually we’ll probably run into browser compatibility challenges like any other project.
Low-performance devices - should be usable on old hardware and with slow internet connections
This is our greatest challenge as we push the boundaries of what’s possible in the styling language. As we profile the style’s performance, improvement could be upstreamed to the dependencies to make our use case more achievable on lower-end devices.
quincylvania
Accessibility should be a fundamental consideration for any widely-distributed software, but it can be easy to sideline. When I worked on iD, I started a document cataloging the app's compatibility with different systems and its usability by people with different abilities and backgrounds. The doc drove development by identifying major holes in usability that had gone unnoticed by devs for years.
Americana is already pushing the state of the art for OSM map tiles with inclusive features like dynamic multilingual labels. I propose we keep the energy going and set clear goals for accessibility. This would help new contributors and aid in decision-making, similar to #385.
Some general ideas:
I can see Americana one day becoming a standard-bearer for OSM cartography and ending up in all sorts of places we can't imagine yet. Thinking about this stuff now puts us on stronger footing going forward.