State of CSS TODO

[SachaG]

Demographics

• Participation by Country
• Salaries
• Average Salary per Country
• Years of Experience
• Company Size
• Source Breakdown
• Gender Breakdown
• Job title (how to normalize "other" option?) horizontal bar chart ranking
• JavaScript Proficiency (waffle/vertical bar chart?)
• Back-end Proficiency (waffle/vertical bar chart?)

Features Overview Template

• Intro
• Overall scatterplot/bubble chart?
• Top 20 most used (?)
• Top 20 least used (?)

Features Template

Introduction

• Make intros shorter

Scatterplot

• Weird to have % vs absolute units?
• Add labels
• Make axes easier to understand

Feature Blocks

• Use waffle charts?

Units & Selectors

• horizontal bar chart rankings

Tools & Methodologies

• Overview (stacked bar chart?)
• Tool blocks (horizontal stacked chart)
• Other answers
• Salary (?)
• Experience (?)
• Company size (?)
• Usage by country (?)

Other Tools

• Horizontal bar char ranking

Environments

Browsers/Form Factors

• horizontal bar chart ranking
• Other options

CSS for Print/Email

• vertical bar chart/Waffle chart?
• Other options

Resources

• horizontal bar chart ranking

Opinions

• vertical bar chart?

Awards

Conclusion

• Conclusion

[SachaG]

Misc questions/issues:

• why is labelTextColor set on ResponsiveBar props instead of coming from theme?
• why is font family specified in theme?
• should years of experience, company size, etc. all be refactored into the same component instead of all having separate files?
• refactor SalaryPerCountryMapChart and ParticipationByCountryMapChart into same component?

[plouc]

• labelTextColor can inherit from bar color, theme or be a static color, that's why.
• font family is defined in theme because canvas doesn't care about stylesheets :)
• Maps could use the new @nivo/geo package's Choropleth component

[plouc]

Refactoring years of experience, company size, … means using an abstract bar component, I'm not sure it's required as nivo already provides the abstraction.

[plouc]

Regarding labelTextColor, please have a look at this guide (Single color property)

[SachaG]

Regarding refactoring, I think the biggest thing we're missing is some kind of generic block and component for things like bar charts. Looking at DemographicsSalaryBlock for example, I don't see why it needs to have its own component?

And then same thing with DemographicsVerticalBarChart, it could just be a generic VerticalBarChart?

[SachaG]

• Where do we get the tools descriptions (block.sass.description) from? If it's not automated, we might as well remove them?
• Browsers/Form Factors/resources/etc.: can we combine main options with "other" option in a single chart?

[SachaG]

• Is it useful to specify blocks in the raw sitemap for pages like Demographics since we also list them out in the component itself? Isn't that redundant?

[SachaG]

• We need to harmonize names between the sitemap and data. For example the sitemap uses company-size but the data has company_size

[plouc]

Yes, because we wanted to use company-size for urls, but it's not valid in elasticsearch

[SachaG]

• It's also a little inconvenient that the data isn't always nested under the same property name. For example salary data is at salary.ranges but source data is at sources.by_source.

[SachaG]

• Another related issue: do we want to compute just the data relevant to a single block first and then pass that to the block; or else pass the entire page's data to the block and let it extract the relevant data? Currently we're doing approach Interactive results visualization / work in progress #2 but it feels a little messier maybe…?

[plouc]

We could use the same terminology as elasticsearch which use the buckets property, but I liked to have more meaningful names :) It might be easier when consuming the data for a single chart, but when manipulating it, it's really unpractical

[plouc]

I prefer the first approach, isolating the block's data, unless we have blocks which depends on each other