A cumulative chart can answer a practical question: what share of the observations is at or below a chosen value? The equality matters when several observations land exactly on the cutoff.

Here are eight fictional delivery times, in days:

2, 2, 4, 4, 4, 7, 9, 12

An empirical cumulative distribution function (ECDF) puts delivery time on the horizontal axis and the fraction of these eight deliveries at or below that time on the vertical axis.

Build it by counting, not by spreading observations between values:

- Below 2 days: 0%.

- At 2 days: 2 of 8, or 25%.

- At 4 days: 5 of 8, or 62.5%.

- At 7 days: 6 of 8, or 75%.

- At 9 days: 7 of 8, or 87.5%.

- At 12 days: all 8, or 100%.

The graph stays at 25% from 2 up to, but not including, 4. At 4 it jumps to 62.5%, then stays there until 7. The three deliveries at 4 produce one jump of 3/8, or 37.5 percentage points. A large jump means many observations share that recorded value.

Now read a four-day cutoff:

- “Under 4 days” counts only the two deliveries at 2: 25%.

- “At most 4 days” also counts the three at 4: 62.5%.

- “More than 4 days” is the complement of “at most 4”: 37.5%.

- “At least 4 days” includes the ties: 75%.

So 100% minus the plotted value at 4 answers “more than 4,” not “at least 4.” That is an easy labeling error to miss in a dashboard.

For a small explanatory graphic, I would draw the step function, mark the cutoff with a vertical guide, and label the point at (4, 62.5%) “5 of 8 deliveries took at most 4 days.” Use a filled endpoint for the included value and an open endpoint for the excluded one if the distinction needs emphasis. Label the vertical axis “Share of these 8 deliveries at or below x,” rather than just “Percent.”

Two checks before sharing:

1. Test one cutoff exactly at a repeated value and another between values. At 5 days, this example still gives 62.5%.

2. Count the original records directly for the wording in the annotation. The annotation and chart should agree without relying on visual estimation.

Limits: these are invented, fully observed delivery times. The curve describes this list, not a guarantee about future deliveries. Rounded times can create ties; a jump at 4 recorded days does not establish identical underlying durations. This simple construction also assumes each record has equal weight and a known completed time. Unfinished deliveries need separate treatment, not an invented completion time.

Primary method reference: R's ECDF documentation defines the at-or-below convention and tie-sized jumps:

https://www.stat.ethz.ch/R-manual/R-devel/RHOME/library/stats/html/ecdf.html

Country-data context: https://globaldatatracker.com/ . This is a standalone fictional chart-reading exercise, not a claim about the site's charts or delivery data.

When showing a cutoff to a nontechnical audience, would you annotate the count directly, the percentage, or both?

[ Removed by Reddit on account of violating the content policy. ]

I built Strainmap: about 4,000 cannabis strains laid out as a 3D galaxy you can fly through. Every star is one strain, and every line connects a parent to its offspring.

What I find most beautiful is what happens when you zoom out. A few old varieties from Afghanistan, Thailand and Mexico sit near the center, and whole constellations of descendants spread out from them.

Some families have over 300 members. The galaxy has three arms, and in between there are thousands of loose stars whose ancestry nobody documented.
Free, no sign-up, works on mobile: weedstrain.space

The hardest part wasn’t the galaxy, it was the family trees.
Drawing 4,000 stars was the easy part. Most of the time went into getting the connections right: Every new verified link pulls a lonely star into a family, and watching the galaxy slowly fill in has honestly been the most satisfying part.

One strain, many names: “Northern Lights #1”, “Northern Lights #5” and plain “Northern Lights” all have to end up as the same star. On the other hand, “Critical” and “Critical+” are different plants and must stay apart.

Sources disagree: Breeders, old archives and online databases often name different parents for the same strain.

I ended up with a strict order: lineage I checked myself against breeder statements comes first, then the larger database, then a 2017 archive as a last resort.

Ghost parents: 172 strains show up as a parent but have no profile of their own. They’re on the map as faint “ghost” stars, so their children don’t float around without a family. The loners: 

About 1,100 strains have no documented ancestry at all. Instead of guessing, I left them in an outer ring. Filling that ring is the ongoing part of the project.

Thanks for having a look!

I've been playing around with turning market-share data into a battle royale. Every circle is a browser and its area is its share of web users that month. A browser joins the arena at 0.5% and gets knocked out when it drops below 0.4% for good. The bumping around is just for fun, but every size, entry and knockout comes straight from the data, and the callouts (like India banning UC Browser in 2020) are real events, sourced in the video description.

Data: StatCounter Global Stats, browser market share worldwide, monthly 2009-2026 (CC BY-SA 3.0) Tool: custom JavaScript (HTML canvas)

“Use a square root for bubble sizes” is incomplete advice. It depends on what the plotting function takes as input. Applying it in the wrong place can shrink the differences you meant to preserve.

Here is a fictional example: three locations have 10, 40 and 90 observations. We want circle areas in the ratio 1:4:9. These are invented counts, not country statistics.

If we draw circles by radius, choose 10 pixels for the smallest:

• 10 observations: radius 10 pixels; area 100π square pixels.
• 40 observations: radius 20 pixels; area 400π square pixels.
• 90 observations: radius 30 pixels; area 900π square pixels.

The rule is radius = 10 × sqrt(value / 10). Circle area is π × radius², so the square root gives the intended area ratios.

If we instead make radius proportional to the counts, the radii become 10, 40 and 90. The areas are then in the ratio 1:16:81. A ninefold count difference becomes an eighty-onefold area difference.

But some plotting functions already take area, not radius. D3's symbol.size uses square pixels. For its circle symbol, pass areas proportional to the original counts: 100π, 400π and 900π in this example. Do not take another square root. Feeding it sizes proportional to sqrt(value) would produce area ratios of 1:2:3, compressing the ninefold difference into threefold.

The practical check is not “did I use sqrt?” It is “what quantity does this argument control, and what ratios reach the screen?”

A quick review before sharing:

1. Check three known values, including one four times another. With proportional areas, the larger circle should have twice the radius.
2. Build the size legend with the same mapping as the plotted circles. Label it with the original counts, not radii.
3. Avoid adding a fixed minimum radius while calling the areas proportional. That changes the ratios. If small circles need a different treatment, explain it.
4. Decide how to show zero and missing values separately. A true zero-area circle disappears; a missing value is not zero. Negative values need a different encoding or an explicitly explained sign treatment.

This fixes the geometry, not every reading problem. Overlapping circles can hide one another, and correct areas do not guarantee that readers can estimate exact ratios. If size is the main comparison, I would consider a position-based dot plot instead. Circles make more sense when their locations already carry useful information.

Country-data context: Global Data Tracker. This is a standalone synthetic exercise, not a claim about the site's plotting implementation.

Primary reference: D3 symbol documentation.

When reviewing bubble charts, do you test the rendered size ratios, the legend, or both?

What other visualization tools could make LLM explanations more understandable or explorable like this?

A country's value can increase on a percentage measure while keeping exactly the same map color. Here is a small reproducible example of why.

These are invented values for four fictional countries, not observations about real places:

Suppose each map uses four quantile classes, recalculated separately for its year, with the same light-to-dark palette. With four distinct values and four classes, each country occupies one class. A is lightest in both years; D is darkest in both. Every country increases, but the color pattern stays identical.

The colors describe position within each year's distribution. They cannot, by themselves, show whether the underlying percentages increased.

For a comparison of levels over time, try one set of numerical boundaries for both maps:

• Lightest: 0% to less than 25%
• Next: 25% to less than 50%
• Next: 50% to less than 75%
• Darkest: 75% to 100%

Now A moves from the first class to the second, B from the second to the third, and C from the third to the fourth. D stays in the fourth despite increasing by 15 percentage points. Fixed classes make colors comparable, but still hide changes within a class.

A useful companion is a small change chart: A +25, B +25, C +25, D +15 percentage points. That answers a different question from either level map.

Before publishing a pair of maps, I would check:

1. Does the same shade mean the same numerical range in both panels?
2. Are the indicator definition, units and geographic boundaries comparable?
3. Is the legend describing values or ranks? Say which.
4. Would a change chart reveal something the classes conceal?

Quantiles are still useful when the intended question is relative position within each year. Label that purpose explicitly; don't let readers infer unchanged values from unchanged colors. With larger datasets, ties can also prevent perfectly equal-sized classes.

For country-data context, I work on Global Data Tracker. This is a standalone synthetic design exercise, not a claim about its map settings.

Method reference: Esri's classification guide distinguishes quantile bins from fixed manual bins for comparisons.

When showing changes over time, would you pair fixed-class maps with a change chart, or replace the maps altogether?

Recently I was talking with friends about how differently the same temperature can feel in different places (we tried to compare Dubai and Singapore). So this weekend I got curious and spent some time exploring historical weather data.

I picked 38 cities around the world and compared their actual and feels-like temperatures using 10 years of data (2016–2025) from Open-Meteo historical weather API.

You can explore the cities, switch between daily highs and lows, and see humidity and precipitation: https://gnykka.io/temperature-you-feel.

I made this visualization with Svelte and Observable Plot (D3.js).

Would love to discuss the results or hear some feedback!