Legends
ivanmalagon opened this issue · 27 comments
Summoning here @makella
I know legends are a pending issue in Builder, where we lack the proper way to render several of them. I couldn't find a central place or issue where all the right legends are explained but I recall seeing one of your presentations with a legends list. I remember one with the line thickness, for instance.
It'd be great to start publishing the right legends as components in Airship. Can you provide us with more info in this issue ticket, please, so we can make up our minds about the work to do?
Yes!
I will compile the tickets here that I know about, and direct you specifically to things that I think we can do better w/ legends.
When will the legend work start? (just to give myself a timeline)
thanks for the ping!
In the next dev cycle we'll continue with Airship. It'll start on September for Airship. There's no need for rush about legends definition. I just want to have a issue to get a grasp on all the work to do with legends and then create the proper issues and prioritize the work from there.
perfect, thanks, @ivanmalagon! I will start compiling resources and post here over the next week or so.
hi @ivanmalagon
There is A LOT of discussion throughout the repos on legends. I linked some of the relevant pieces through my summary below.
A great place to start is reading this summary of "Legend pains" by @ramiroaznar:
https://github.com/CartoDB/product/issues/35#issuecomment-376550515
I went through and jotted down everything I could think of to improve what we currently have. Sorry if it is a lot and if you need any clarification on any of it, please let me know.
Once we have a definition of all the map types that we need to cover (assuming carto.js and VL), we can do a cross-check and make sure that we've defined all of them.
There are also more advanced legend techniques have been implemented into CARTOframes, but I think first, we should make sure we are covering all the basics and then get into the more advanced.
Points
Basic representation
In the legend, keep the style properties of the points displayed on the map. For example, if we have a red point symbol that is 20px, with a black outline, the legend should reflect that exact style.
By value: Color
When symbolizing points by color, we want a point legend :)
The only reason I say that is because we have the opportunity to define some different behaviors than what is in Builder.
Categories
- Each category symbolized with the appropriate style properties as mentioned under "Basic representation.
- the style properties are important in this context too because some categories might be symbolized with a white outline and others with a black outline (for example). In addition, a category of point could potentially be larger than other categories. Keeping all of this information (that helps interpret the map) in the legend will be really great.
Numbers
- Each class symbolized with a point (the default in Builder is to go to a gradient legend) with the appropriate style properties.
- For how these stack, I'd say we can keep them vertical as with category legends.
- For labels, I'm not sure what you guys are thinking but it is useful to have the ranges for each class break. People will want to edit these (because raw values as you know can be ugly), so I think by default, having range labels
Images
- Standard image legend like we have but with the ability to bring the other styling components like size in the legend too.
- Image markers can be bivariate so one component could represent type (color) and another through size.
By value: Size
- The biggest thing here for our "bubble legends" is that the sizes of the circles don't match those on the map! This, I think is one of the things I hear most often.
- Another important thing is that we actually need legends for two different map types especially now that we have interpolation built-in for VL
- classed maps
- here, similar to the colored points legend, we will want each class break's circle size in the legend with the associated range. A lot of the legends for this kind of map are very similar to what we used to have in Editor:
- classed maps
- unclassed maps
- A really great paper written by a famous cartographer
- on the first page, you will see a list of requirements
- There was a discussion in the past, but it never went anywhere. This would be a big win for us!
Lines
Basic representation
Let's have lines in the legend! You can see some work @elenatorro has been doing with VL legends and what a difference it makes
- CartoDB/carto-vl#869 (comment)
Similar to the comments above for points, we should keep the style properties of the lines on the map.
By value: Color
Numbers and Categories
Follow similar guidelines for color by value in the points section. Also bring in additional style properties from the map.
- for example, see @ramiroaznar example here https://github.com/CartoDB/design/issues/477)
By value: Size
We've had a lot of discussion about a sized line legend and even mock-ups! You can see those and the discussion here: https://github.com/CartoDB/design/issues/296
- Similar to points, we will have classed and unclassed lines.
- For the classed lines, we can do the horizontal legend where you see each class break:
- for unclassed, we would likely expect to see something more like this one:
By value: size and color
- Combining size and color combinations
- think of road types colored and sized differently but condensed into one legend (vs. the two that you get currently w/ Builder)
Polygons
Basic representation
- Let's use squares for the legend!
- Let's take over the styling properties to the legend!
Style by value: color
Style by value: numbers
Similar to points and lines, we will need two legend types
- Classed maps
- traditionaly, you see color chips for each class (like we used to have in Editor)
- Unclassed maps
- the gradient legend that we currently have is more suited for this map type since the colors are ramped from start to end along all of the values in the data
cc'ing @elenatorro for visibility as she has been working on getLegend() for VL. Some of the things that we want to add for legends there we are thinking will be part of Airship.
@elenatorro if I have missed anything, please feel free to add.
@ramiroaznar you too!!
I'm revisiting this ticket to come up with actual tickets and I have a doubt about point legends by size.
Would this design fit both classed and unclassed maps?
I think this solution (based on your suggestion in other ticket) would fit the case where the actual sizes are pretty small. But I don't know if it can used for both kind of maps.
Hey @andy-esch could you check the legends above and see if you miss any specific ones for CARTOframes. Also, if you can point it which ones are the most important ones from your point of view, that'd be great
After speaking with @makella, this seems like a minimum viable set for legends:
- numeric color with class breaks (points, lines, polygons)
- continuous color (points, lines, polygons)
- category (points, lines, polygons)
- size with class breaks (points, lines)
- continuous size (points, lines)
Using this issue as the meta issue for Legends.
These are the first set of legends we aim to cover first, each with their individual issues for tracking comments
- Point size, classed #584
- Point size, unclassed #585
- Line size, classed #586
- Line size, unclassed #587
- Polygon color, classed (color steps) #588
- Polygon color, unclassed (gradient) #589
- Bivariants Choropleths (square grid) #590
This is the working document: https://docs.google.com/document/d/1fYFWV9vVRyfpDjcu30lGm7Fr5qZKoaTOaHfmqtGYfLE/edit?ts=5c9cf373
@kukukaka as discussed. We can make progress but we'll need design's help for the look and feel.
I don't know if this the best place to leave this comment, but I've done some thinking about the display of numbers on legends and want to make sure it helps inform the dev/design process. From CartoDB/cartoframes#544:
In cartoframes vl, values should be in scientific notation, i.e.,
1.5e-3 - 2.5e-3so we can avoid mistakes like I made when i just rounded to two values. We can have numbers that are less than 0.01 but still be very meaningful. E.g., if the data range is 0.00001 to 0.006 we need to ensure the legend displays that data meaningfully.
Now I'll put the legends in each corresponding issue (as well as some doubts I have), but this is an image of how they are for now.
Hello!
@makella and I have moved forward on Legends design!
Here is an InVision with the Legends and two examples of them in a Jupyter Notebook layout (with and without scroll).
Cheers!
Beautiful!!!
One quick question: How do you envision negative numbers appearing in the ranges? E.g,. -20 - -30? Will the separator be wider than the negative symbol?
good point, @andy-esch
@newLadyAga taking a closer look and based on andy's comments, two things:
General spacing between ranges and dash
-
we probably want to put a space between the end of a number, the dash, and the beginning of the next number.
- I see that in the classed polygon range labels:
. - but not in the classed line range labels:
- or the classed point range labels:
- I see that in the classed polygon range labels:
Are there constraints with the latter two for the space?
Treatment of negative numbers and range labels:
-
I see two options (with either one we will probably need to take a second look at alignment, but just for a quick reference):
- as @andy-esch mentions, using an em dash:
- or another common alternative is to replace the range dash with the word
to:
Thank you for your comments, @andy-esch and @makella!
Yes, I think is a good idea to put a space on both sides of the dash, as it improves the readability a lot and there aren't space constraints.
Regarding the treatment of negative numbers and range labels, I find interesting the dash replacement with the word "to". Since the font size on labels is quite small I think this variation would be clearer. Do you like it too, @andy-esch?
hiii @newLadyAga I think @andy-esch is out of the office for a few days. if you think the "to" makes sense, let's go ahead with that idea and see how it would look in the mocks.
let me know if there is anything i can do to help!
thanks!
Perfect, @makella!
Let's try then what the separate ranges look like with the "to". I think they work well for both positive and negative numbers.
Let me know your thoughts!
Thank you!
I would try to avoid using "to". I think we should try to avoid as much as possible English in non-customizable strings of any Airship module if we have other options language agnostic.
Yes, it makes sense. We have to use a dash then.
After a few searches I found that the most appropriate representation for ranges would be to use an "em dash" without spaces, however, I think this solution doesn't work well with negative values, even if the dash has a softer color.
I put the tests here. I would opt for the third one, with space between the values and the dash and all the text in the same color.
I just wanted to comment here about the dash and negative numbers on the legends!
i was working with @giuliacarella on a series of weather-realated maps in CARTOframes where the case of using something other than a dash (for example the em dash or the word to) would make this a lot more legible.
I thought we were going with the em dash?
anyway! just figured it would be good to put in some real-world examples for us to evaluate if and when we have the opportunity.
thanks!
Hi!
Nice to see a real-world example!
Yes, definitely the simple dash isn't working well with negative numbers.
I also think we were gonna go with the EM Dash.
This is a test with the EM Dash in bold, to see if it helps visualize it even better.
Thank you!
@elenatorro Let's keep this in mind, in case we fix anything more in the library. If we don't have that need soon, we can always derive this to RT.
Can we close this issue? It's been inactive for more than one year
(I'm cleaning up my GitHub open issues)
🖖
🚀
🔥
I have talked about Legends this morning.... just saying 😛
(💋 💋 to everyone involved here)