Proposal for design goals and guidelines - part 1 #2446
Conversation
|
|
||
| ## Legibility | ||
| 4. **Clarity** - This is strongly and directly related to legibility but more specifically means the map should be readable with as little effort as possible and be pleasant to look at both with high and low levels of interest and concentration. |
There was a problem hiding this comment.
I see 4. as a subset of 1. - maybe it needs just some rewording to show how it is different (and worth different item)? "Pleasant to look" might be this difference, but the name of this item suggests something else.
There was a problem hiding this comment.
Yes, you can consider this part of legibility. My idea was that 1. just means the map can be read and understood by the user while 4. aims for this being easy and possible without much effort. This is much harder to achieve and usually does not play much of a role here.
There was a problem hiding this comment.
Map which can't be understood wouldn't make much sense, I read "intuitively readable" from 1. exactly as "can be easily understood".
There was a problem hiding this comment.
Intuitively does not mean easily - it just means you don't need additional information to figure it out, it might still take a lot of effort.
In general i think we should do this based on suggestions. If you think something should be changed make a suggestion to change it. This way we'd make better progress than by arguing about the meaning of words.
There was a problem hiding this comment.
OK, sure. My proposition for now is that 4. should be removed and "pleasant to look" moved to 1.
|
Looking good! I think you're interpreting legibility too narrow. For example, the old Luxembourg bus map is perfectly intuitively understandable, but very hard too read. In comparison, the new Luxembourg bus map is much easier to read. Perhaps under Diversity, or as a separate point, you could also add that the map does not cater to one specific type of user (car drivers, cyclists etc.) but tries to be useful for all? |
My idea was that the top goal that stands above all others is the basic legibility. Ease of use is more what i had in mind with the Clarity goal. But if preferred we can combine them and put them on top as general legibility including ease of use. Currently however my impression is that being easy to read often does not have priority over mapper feedback - we would do more geometry processing then for example.
Maybe just add or to special thematic interests of users at the end of the diversity goal? Alternatively feel free to add it as you see fit, the idea in general is very good. |
|
To be honest I'm a bit skeptic about us being able to order the goals in terms of priority. Otherwise we'd end up having to block big progress in one area because it would mean a small regression in another area. I'd be more comfortable with an unranked list. |
| * It's an important feedback mechanism for mappers to validate their edits. | ||
| * It's a major part of the public face of OpenStreetMap, for many people the map on osm.org rendered with this style _is_ OpenStreetMap. | ||
| * It's used in many map applications as a general purpose map. | ||
| * It's an examplar stylesheet for rendering OSM data. |
There was a problem hiding this comment.
I would add here that openstreetmap-carto plays an important part in tag usage behaviour of mappers and in tag hygiene.
There was a problem hiding this comment.
I don't think that is separate from the mapper feedback purpose but it could make sense to rephrase that point to make it clearer - any suggestions?
|
Very good work and very good starting point. Yes, a ranking is maybe a bit hard to obey. But on the other hand things like feedback-loop/feature-richness and clarity/aesthetics always get us into trouble. A ranking would help to indicate a general direction. This could be also indicated at the end of a unordered list. A long term goal should be to reduce the central importance of openstreetmap-carto for OSM by having more different main styles. But this might require basic changes to the rendering infrastructure and is of course out of scope here. |
|
Keep in mind the purpose of this is not to set constraints for us to obey - we set the goals, we can also change them. The main purpose is to help contributors understand what the basis is of the design decisions we make. So if the goals have an order of priorities for us we should document that, even if practically this ordering is very weak. Maybe we could just collect a set of opinions from the maintainers if and how the different goals have priorities for them - like 'all the same importance to me', '2 is most important but the rest is all the same to me', '1,4 and 7 are slightly more important than 2,3,5 and 6' or a fully sorted list. But before we do that we might better think about if we missed any important goals. |
|
A bit off topic, because we lack place to discuss general things (do we want to have one?): I've just found a journey planner which uses osm-carto with different colors, that's an example of 7. (adaptability). |
|
I think the performance of the rendering is also one of the design goals. Making style changes gets harder and harder the longer stylesheet parsing takes. |
I think this journey planner (or at least the polish version e-podróżnik) is around longer than osm-carto, so it's more likely based on the style preceding osm-carto. |
|
Looking at some osm-carto specific problems (#688) their style has been updated at some point. |
|
Regarding performance - this in my eyes has three components:
Technically the first and last points are mostly about style rendering performance while the second is more about code complexity and parsing performance. We could acknowledge these goals with the following additions:
|
|
Sounds good to me. |
|
Our meeting of the goals needs to balance them against each other. An unordered list might make this clearer. |
|
This might belong in a follow up discussion and PR, but these are thoughts I've been having on what we render. Features should be
So a specialized shop not of general interest would not need its own icon, but somewhere to eat does. |
|
IMHO, the order proposed by @imagico looks appropriate and there are principles of a certain depth. I would also suggest, when possible, that the standard style should tend to give more priority to features with wide social and cultural relevance and to basic topographic features (meaning the ones that are of common usage and that can be usually found on generic maps to physically describe the territory) rather than business elements (like shops, malls or factories). |
|
I made a change with the following modifications:
From my side this would be a reasonable first version but subsequent adjustments will of course likely be necessary. Also some proof reading regarding language and orthography would likely be good. I still think it would be good to have an idea where the maintainers stand regarding the priorities of the different goals even if we don't want to define such an order for the project. But i don't want to push this. Please speak up if you think we should do this. Regarding decisions on what to render and what not to render - i have a few considerations on this in my notes for more specific guidelines i will put in a supplement proposal. But in general this is fairly difficult, especially if it goes into subjective concepts like usefulness. @Ircama - relevance is a problematic concept here - this is always highly subjective. I try to concentrate on things here that are at least to some extent objective so contributors can check their idea aginst these goals and guidelines without the inevitable frustration that would occur if you consider something highly relevant but find out that the maintainers do not. There will of course always also be subjective decisions but we can at least try to document the basis for those which are not. |
|
I have a first version of the second part ready now - i can add it here but it might be better to merge this first and start a new PR. |
👍 If none of the other maintainers merge it, I'll have a last read through in the morning when I've had more sleep. |
|
|
||
| ## Purposes | ||
| This is an attempt to outline the goals of this style and the principles under | ||
| which the maintainers make decisions. These rules are not set in stone, they |
There was a problem hiding this comment.
Extra space between sentences.
| This is an attempt to outline the goals of this style and the principles under | ||
| which the maintainers make decisions. These rules are not set in stone, they | ||
| can change and they may not be followed in all cases but contributors should | ||
| be able to expect they are generally the guiding principles design wise. |
There was a problem hiding this comment.
expect that they are generally
|
|
||
| Firstly, this is a map, not merely a colourful 2-dimensional visualisation of the database. Colours should be chosen based on their effectiveness and to make things look nice, not chosen for distinctiveness. | ||
| There is no ranking of these purposes. To allow serving all of them and to |
There was a problem hiding this comment.
Extra space between sentences
|
|
||
| Colour definitions should, where useful, be put into variables at the top of the file, to enable easier customisation. | ||
| The following goals need to be balanced against each other to serve the purposes | ||
| above. There is no fixed order of priorities. Apart from these goals there are |
There was a problem hiding this comment.
Extra spaces between sentences.
| * **Legibility and clarity** - The map should be intuitively readable by users with some general experience using maps without a map key, preferrably with relatively little effort. A map key or more extensive experience using this map style can be required for clearly identifying minor differences or the exact meaning of certain features but in broad strokes orientation and identification of map elements should be possible on an intuitive level. We also aim for the map appearance to be esthetically pleasing. |
There was a problem hiding this comment.
Extra spaces between sentences.
| * **Legibility and clarity** - The map should be intuitively readable by users with some general experience using maps without a map key, preferrably with relatively little effort. A map key or more extensive experience using this map style can be required for clearly identifying minor differences or the exact meaning of certain features but in broad strokes orientation and identification of map elements should be possible on an intuitive level. We also aim for the map appearance to be esthetically pleasing. | ||
| * **Being understandable and supportive for the mappers** - To serve as feedback for mappers and encourage correct mapping this style needs to render the data in a way that allows mappers to understand how the data produces a certain rendering result based on basic observation without in depth understanding how map rendering works or looking at the style implementation. |
There was a problem hiding this comment.
I would leave out the in the mappers. ... supportive for mappers
| * **Legibility and clarity** - The map should be intuitively readable by users with some general experience using maps without a map key, preferrably with relatively little effort. A map key or more extensive experience using this map style can be required for clearly identifying minor differences or the exact meaning of certain features but in broad strokes orientation and identification of map elements should be possible on an intuitive level. We also aim for the map appearance to be esthetically pleasing. | ||
| * **Being understandable and supportive for the mappers** - To serve as feedback for mappers and encourage correct mapping this style needs to render the data in a way that allows mappers to understand how the data produces a certain rendering result based on basic observation without in depth understanding how map rendering works or looking at the style implementation. | ||
| * **Diversity** - The style should represent the diversity of the OSM community and geography in general. The most obvious element to serve this goal is showing the local names everywhere on earth in their respective scripts. This goal however goes beyond labels. Both physical and cultural geography differs a lot globally and the aim is to represent this variety with equal determination - well mapped areas are not supposed to have more weight here than less mapped parts of the world. This also means the target map user is the potential global map user and no special consideration is given to the current geographic distribution of actual map use. |
There was a problem hiding this comment.
Maybe worth clarifying that diversity does not mean that we render the same things differently in different parts of the world e.g. street colours.
| * **Being understandable and supportive for the mappers** - To serve as feedback for mappers and encourage correct mapping this style needs to render the data in a way that allows mappers to understand how the data produces a certain rendering result based on basic observation without in depth understanding how map rendering works or looking at the style implementation. | ||
| * **Diversity** - The style should represent the diversity of the OSM community and geography in general. The most obvious element to serve this goal is showing the local names everywhere on earth in their respective scripts. This goal however goes beyond labels. Both physical and cultural geography differs a lot globally and the aim is to represent this variety with equal determination - well mapped areas are not supposed to have more weight here than less mapped parts of the world. This also means the target map user is the potential global map user and no special consideration is given to the current geographic distribution of actual map use. | ||
| * **A rich map** - This style deliberately creating a fairly rich map showing a significant number of different features. This way it shows the richness of OSM data and gives a broad recognition to the mappers' work. The aim is not however to show all or even most of the OSM data. |
| * **Diversity** - The style should represent the diversity of the OSM community and geography in general. The most obvious element to serve this goal is showing the local names everywhere on earth in their respective scripts. This goal however goes beyond labels. Both physical and cultural geography differs a lot globally and the aim is to represent this variety with equal determination - well mapped areas are not supposed to have more weight here than less mapped parts of the world. This also means the target map user is the potential global map user and no special consideration is given to the current geographic distribution of actual map use. | ||
| * **A rich map** - This style deliberately creating a fairly rich map showing a significant number of different features. This way it shows the richness of OSM data and gives a broad recognition to the mappers' work. The aim is not however to show all or even most of the OSM data. | ||
| * **Maintainability** - The implementation of this style should not be too hard to maintain. This refers to both the volume and complexity of the code and how fast the style can be parsed when rendering it, which is very important for efficient development work. So the amount of code should be kept small and complex and fragile interdependencies should be avoided. If the code is difficult to maintain this would ultimately seriously affect all of the above goals. |
There was a problem hiding this comment.
A theme that comes up frequently is that it should not be too hard for new contributors to get started. Worth mentioning?
|
Changed some formulations based on suggestions by @nebulon42. What i did not change is
|
|
Thanks - part 2 is in #2462. |
I have started with a draft of putting together some design principles for this style that hopefully help contributors in the future to better understand the direction of development.
This first part contains two of three sections i structured this into. These two are the description of the style purposes and a list of the main goals derived from these. I plan to supplement this with a section with more specific guidelines on style decisions with - from my side - subsections on colors and zoom levels - which can be supplemented by others on further subjects like for example icon design.
This structure is meant to show that the specific principles listed are not arbitrary but are meant to serve the described goals which are followed to make the style serve its purposes.
Mostly i tried to put together ideas that i hope we can mostly agree upon. But there are also a few things that might be more controversial. The most significant probably is that i put the goals into an order which - as i put it at the moment, is quite a bit different from the current priorities. In my eyes point 5 and 6 currently have a much higher priority while point 3 is often less important.
To give an example (just an example, not meant to reopen the discussion) the decision to close #1853 was based on the maintainability aspect although in my eyes the change was a significant improvement regarding at least goal 2 and 3.
I am open to changing this order based on arguments discussed here, alternatively we can also make this an unordered list but an order of the goals would of course make priorities clearer for potential contributors.
The ordering as i put it for the moment represents the priorities the different goals would have for me - but of course we should ultimately put them in the order that represents actual practice.