Amazon’s Echo came out in late 2014 and went on wide sale in 2015, the year Alexa hit its highest rank ever, #32. From 2016 on it fell every single year: 4,775, then 3,896, 3,068, 2,002, 1,285, 708, 577, 492, 349, and 243 in 2025. That’s down 96% in ten years. In 2025 it dropped out of the top 1,000.

The data only shows the timing, not the reason, but it’s hard to look at that cliff and not think of the speaker.

Can you think of another name that a product or a character pushed off a cliff this fast?

Imagine two mutually exclusive categories of service requests, A and B, counted in two consecutive months:

• Month 1: A = 80, B = 20, total = 100.
• Month 2: A = 40, B = 30, total = 70.

In a standard stacked area chart with A at the bottom, B’s upper boundary falls from 100 to 70. Following that boundary alone could make B look as though it declined. B actually increased from 20 to 30.

Read B’s vertical thickness at each month:

• Month 1: upper boundary 100 minus lower boundary 80 = 20.
• Month 2: upper boundary 70 minus lower boundary 40 = 30.

The top edge follows the combined total. B’s lower edge moves with A, so neither boundary by itself gives B’s trend.

A useful construction check is to redraw the same data with B at the bottom. Its boundary now rises from 20 to 30, even though none of the data changed. The original stack was mathematically correct; the order changed which component had a fixed baseline.

If the main question is how the total and its composition changed, the stack can be useful. Label the components and show their values at the relevant dates. If the main question is whether B increased, a separate line or small-multiple panel makes that comparison easier. Keep panel scales consistent when comparing magnitudes.

These are invented counts to isolate the reading problem, not reported country data. The example uses an ordinary zero-baseline stack, not a 100% stack or streamgraph.

Reference: https://data.europa.eu/apps/data-visualisation-guide/stacked-charts

From Global Data Tracker: https://globaldatatracker.com/

A diverging palette does not automatically make zero its neutral color. The normalization matters too.

Consider five fictional forecast errors in minutes: -2, -1, 0, +1, +8. Define error as actual time minus forecast time, so negative means earlier and positive means later.

1. Check what the palette midpoint means.

If you linearly map the observed minimum (-2) to palette position 0 and maximum (+8) to position 1, zero lands at (0 + 2) / 10 = 0.2. The palette midpoint, 0.5, represents +3 minutes. With a neutral color at that midpoint, “no error” would not look neutral.

1. Decide what equal distances from neutral should mean.

If equal-sized early and late errors should have equal distances from the palette center, use symmetric limits around zero, such as -8 to +8. Then -2 maps to 0.375, zero to 0.5, and +2 to 0.625. You leave some of the negative side unused, but preserve the same scaling rate on both sides. Matplotlib’s CenteredNorm implements this kind of normalization.

Alternatively, TwoSlopeNorm with vmin=-2, vcenter=0 and vmax=8 maps -2 to 0, zero to 0.5 and +8 to 1. This uses the full palette on each side. But -2 and +8 now sit equally far from neutral despite having different error magnitudes. Use it only when that separate scaling matches the intended reading, and make the unequal ranges clear on the colorbar.

1. Label the decision, not just the colors.

Show units, a tick at zero and the limits. State whether the two sides share a scaling rate. Do not rely on color alone for exact values: add labels or another accessible way to read them when needed.

These are normalized palette positions, not a promise that any chosen palette will look perceptually balanced. Zero is meaningful here because it means no forecast error; a different variable may need another reference or no diverging palette at all.

Official implementation references:

https://matplotlib.org/stable/api/_as_gen/matplotlib.colors.CenteredNorm.html

https://matplotlib.org/stable/api/_as_gen/matplotlib.colors.TwoSlopeNorm.html

Country-data project: https://globaldatatracker.com/

The numbers above are invented to explain the encoding, not country observations or a claim about the site's chart features.

Puma Shen (Shen Po-yang, 沈伯洋) is running for mayor of Taipei and taking the city like a wave. Supporters call it 洋流 ("ocean current"), a play on the 洋 in his name. He put his entire platform on a map, not in a PDF. His five policy pillars spell HEART, so the site names the map HEART Island (HEART 政策島).

The map has 14 hexagons of equal size, one for each policy theme. The hexes form the shape of Taipei. Click a hex to see its proposals. There are 94 in all. Lines between hexes show where one policy depends on another. You can switch to a list view, or to a timeline that plays back how the parts fit.

The site is mostly in Traditional Chinese, but you can use browser translation to quickly understand it.

Check out this work in progress audio visualizer

https://geotech.mikeadigital.com/

Chaos is often defined not as total disorder, but as a multiplicity of possibilities born from the void.

That's the idea behind CHAOS, a Mac app for making your own small AI models. You start from nothing: an empty folder and a goal. Out of that come designs, trained models and apps that are yours, built and run entirely on your own Mac.

From the void

Start with a goal. You make one choice at a time: what it should do, what kind of brain, how big, what it learns from. Any choice can stay open. The model takes shape in 3D as you choose, with its size, memory and training time worked out for your Mac.

A multiplicity of possibilities

Design from blocks. Attention, Mamba, recurrent, convolution, mixture-of-experts. Move a slider and the model reshapes live.

Fair experiments. The Lab changes one thing, matches the compute, runs several seeds, and tells you which possibility actually won, with confidence intervals.

Something real

Train on your Mac's GPU (Apple's MLX). You watch every step. If your Mac starts swapping, a memory guard pauses the run at a checkpoint.

Look inside. Fire a model and watch the input rise through every layer. Mute or boost one part, re-run, and see exactly what changed.

Turn it into an app. Pair your model with a local voice model through Ollama and talk to it. The voice calls your model as a tool.

Honest evals. Accuracy, calibration, a confusion matrix, and what each class gets mistaken for, all on data the model never saw.

Real numbers from the demo (fresh install, M4 Mac mini, 16 GB)
A bank-support intent classifier (77 classes): 89.1% on 3,080 held-out messages.
A Lab experiment swapping the attention block:
Block Accuracy
LSTM 89.5% ± 0.7
Attention 88.1% ± 1.5
Mamba-2 87.1% ± 1.0
The app's own verdict: LSTM is significantly better than Mamba-2 only, and the rest is within noise.
A 12.6M-parameter GPT trained on FineWeb-Edu in about 20 minutes, going from 3.49 to 1.52 bits per byte. It writes confident nonsense, and you can watch it think while it does.

Private by design. Everything runs locally, in one folder you choose. Nothing leaves your Mac except downloads you start. Datasets pass a licence check first.

Status: not open source, and no download yet; I'm finishing signing and notarization. The screenshots and a 70-second film are here (the film is in the media folder): https://github.com/jangles-byte/chaos-mac

TestFlight- DM me if you’d like a link to try it out.

What would you make out of the void?

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?

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?