🎨 Add color to treemap.

[paulirish]

An exploratory attempt to add some color to the treemap. :)

Screenshot:

I don't think this'll work well for everyone's treemap, so we can bikeshed a bit on the colors and depths.

Are folks interested in this?

ref #21

[danvk]

To get the bikeshedding going:

• These colors make it easier to see which files are at the same depth in the directory tree. Why is this something I'd care about?
• I think they're a bit garish!
• Another way to use color would be to flag potential issues. For example, if there are five copies of underscore in your bundle, maybe we should color them all red.
• We could also use colors to highlight a module and all of its dependencies, ala Jeff's example from Add background coloring to treemap view #21.

[paulirish]

Yah good call on everything.

Depth isn't right signal as nesting already communicates that. 👍

Earlier this morning I thought it'd be worth coloring based on the identity of the parent. That's the model used by a few of D3 treemaps I've seen.

Here's the ugliest possible version of that:

(teaches you well for thinking Math.random() will get your colors with decent adjacent contrast :)
It's interesting but it's not right, they are not identifiable as groups too clearly.

I also really like the idea of having more distinctive coloring for modules (ie. explicitly one level with "node_modules")

I'm convinced there exists a coloring algorithm that makes sense for deep nesting in treemaps, that maintains good adjacent contrast, but also visually branches more clearly.

[danvk]

I do like the idea of coloring by directory under node_modules. Identically-named directories (which are presumably duplicates) could get the same color.

There are lots of resources on designing high-contrast color schemes. http://graphicdesign.stackexchange.com/questions/4300/where-can-i-find-examples-of-high-contrast-combinations-for-websites

one example is dygraphs, which uses equally spaced points around a color wheel:
https://github.com/danvk/dygraphs/blob/c76d4b2aaf806895ff8693d1060d58ce9f83c0ae/src/dygraph.js#L953-L985

I wonder if that treemap would look better with the saturation toned way down?

[danvk]

Also, let me know if you'd like to be added as a project owner!

[Hypercubed]

Maybe this should be a PR on evmar/webtreemap.

[Hypercubed]

I think I would prefer to use $symbol for the color. source-map-explorer could generate a triple: Source, Size, $symbol. Then in the CLI you can choose what to use to generate $symbol (level, size, name, etc).

[addyosmani]

<3 the idea of colorizing entries with the same name. Duplicate dep detection is one of the reasons I use source-map-explorer.

Another bikeshed suggestion: should dependency size be a factor in how things get colored? 🏋️‍♀️

When trying to trim my dep tree the first thing I look at is what the largest areas of the s-m-e graph are and then start digging further. I tend to care less about deps that make up 2% of my bundle (they may still be important to someone however) :)

I wonder if that treemap would look better with the saturation toned way down?

👍 It would be interesting to check whether this would be visually more easy on the eye.

[techniq]

webpack-bundle-analyzer currently uses a different file per bundle (file) but uses lightness to indicate size. I think this helps draw attention to the larger assets.

What if material colors were uses, which gives 19 unique colors (which can be reused) and 10 levels per color. Each color could be used for each dependency, and then the color lightness could be used for each file, bucketed into the 10 shades (50, 100, 200, ..., 900).

[danvk]

I'm going to close this out since the discussion has stalled out, but I'm still very interested in suggestions (and PRs) to add meaningful colors to the tree map.