Quantile Dot Plot

Preview in your theme

status="ready" · 480 Monte-Carlo schedule runs discretised into 20 equally likely deliveries, one dot each. The median lands at 12.5 days, which sounds safe — and exactly 5 of the 20 dots fall on or before the promised date, a 25% chance you can count with a finger instead of estimating off a curve. Hover a column, or tab into the chart and use the arrow keys; click or press Enter to pin one and watch onColumnSelect fire below.

When will the beta ship?

20 equally likely deliveries · one dot = 5% · median 12.47 days · range 6.8 to 22.7 days

5 in 20 deliveries fall at or below 10 days (promised date) — 25%.

at or below 10 days · 5
above it · 15
one dot = 1 in 20 (5%)

Each dot is one of 20 equally likely deliveries: the dots sit at the 2.5%, 7.5% … 97.5% quantiles of the forecast, so counting them reads probability straight off the card.

The grid resolves to 5% per dot; the distribution itself puts this chance at 24%, which is why the dots say 25%. Raise dotCount for a finer grid — it cannot make the forecast sharper than it is.

When will the beta ship? — one row per column of dots. Every dot is one of 20 equally likely deliveries, so a column's dot count is its probability and the running total is the cumulative probability up to that column. A column stands at the centre of the dot-wide slice its dots fall in; the slice it covers is printed, so no position is implied that the data does not support.
Column	Values	deliveries	Share	Cumulative	at or below
1	6.8 days	1	5%	1 · 5%	1
2	7.8 days	1	5%	2 · 10%	1
3	8.9 days	1	5%	3 · 15%	1
4	9.3 days – 9.88 days	2	10%	5 · 25%	2
5	10.3 days – 11.1 days	3	15%	8 · 40%	0
6	11.7 days – 12.1 days	2	10%	10 · 50%	0
7	12.85 days – 13.44 days	2	10%	12 · 60%	0
8	13.9 days – 14.6 days	2	10%	14 · 70%	0
9	15.2 days – 15.9 days	2	10%	16 · 80%	0
10	17 days	1	5%	17 · 85%	0
11	18.51 days	1	5%	18 · 90%	0
12	20.3 days	1	5%	19 · 95%	0
13	22.7 days	1	5%	20 · 100%	0

onColumnSelect → nothing pinned

status="empty" · a valid contract carrying no distribution at all, told apart from loading and from a failed fetch. A single point estimate lands here too: there is nothing to discretise.

When will the beta ship?

Every dot is one equally likely delivery — count them, don't read a curve

No distribution to count yet

This card needs the shape of the forecast — a quantile grid or raw draws. A single point estimate has nothing to discretise into countable deliveries.

status="loading" · a skeleton in the hump shape the real card draws, aria-hidden, honouring prefers-reduced-motion, with no timer involved.

When will the beta ship?

Every dot is one equally likely delivery — count them, don't read a curve

status="error" · the fetch failed. Try again only appears when onRetry is passed, and clicking it flips the card to ready.

When will the beta ship?

Every dot is one equally likely delivery — count them, don't read a curve

Couldn't load this forecast

The data source didn't respond.

Five percentiles in, twenty dots out · the metrics API returns p5 186 ms through p95 764 ms and nothing else. The card builds a quantile function from those five knots and reads 20 equally likely requests off it — 16 inside the 500 ms SLO. It also says two things out loud rather than hiding them: the grid stops at p5/p95 while 20 dots ask for p2.5/p97.5, so the outermost dots are clamped rather than extrapolated into a tail nobody measured; and the grid's 5%-per-dot resolution rounds the SLO's true 79.1% up to the 80% the dots show.

Checkout latency, next hour

20 equally likely requests · one dot = 5% · median 314.5 ms · range 186 to 764 ms

16 in 20 requests fall at or below 500 ms (500 ms SLO) — 80%.

at or below 500 ms · 16
above it · 4
one dot = 1 in 20 (5%)

Each dot is one of 20 equally likely requests: the dots sit at the 2.5%, 7.5% … 97.5% quantiles of the forecast, so counting them reads probability straight off the card.

The grid resolves to 5% per dot; the distribution itself puts this chance at 79.1%, which is why the dots say 80%. Raise dotCount for a finer grid — it cannot make the forecast sharper than it is.

The supplied grid covers 5% to 95%, while 20 dots ask for 2.5% to 97.5%: the dots outside that range are clamped to the outermost quantiles supplied, never extrapolated. Send raw samples, or wider quantiles, to draw those tails honestly.

Checkout latency, next hour — one row per column of dots. Every dot is one of 20 equally likely requests, so a column's dot count is its probability and the running total is the cumulative probability up to that column. A column stands at the centre of the dot-wide slice its dots fall in; the slice it covers is printed, so no position is implied that the data does not support.
Column	Values	requests	Share	Cumulative	at or below
1	186 ms – 207.4 ms	3	15%	3 · 15%	3
2	221.6 ms – 249.9 ms	3	15%	6 · 30%	3
3	263.7 ms – 291.3 ms	3	15%	9 · 45%	3
4	305.1 ms – 323.9 ms	2	10%	11 · 55%	2
5	347.7 ms – 371.5 ms	2	10%	13 · 65%	2
6	395.3 ms – 419.1 ms	2	10%	15 · 75%	2
7	472.6 ms	1	5%	16 · 80%	1
8	555.9 ms	1	5%	17 · 85%	0
9	639.1 ms	1	5%	18 · 90%	0
10	722.4 ms	1	5%	19 · 95%	0
11	764 ms	1	5%	20 · 100%	0

The other direction · direction="at-or-above" counts the side above the line, so the headline is the risk rather than the hit rate: 1 evening in 20 reaches firm capacity. The rule sits inside the axis even though almost nothing reaches it — a threshold pushed off the edge would quietly turn "1 in 20" into "none visible".

Peak demand against firm capacity

20 equally likely evenings · one dot = 5% · median 729.5 MW · range 552 to 929 MW

1 in 20 evenings falls at or above 900 MW (firm capacity) — 5%.

at or above 900 MW · 1
below it · 19
one dot = 1 in 20 (5%)

Each dot is one of 20 equally likely evenings: the dots sit at the 2.5%, 7.5% … 97.5% quantiles of the forecast, so counting them reads probability straight off the card.

Peak demand against firm capacity — one row per column of dots. Every dot is one of 20 equally likely evenings, so a column's dot count is its probability and the running total is the cumulative probability up to that column. A column stands at the centre of the dot-wide slice its dots fall in; the slice it covers is printed, so no position is implied that the data does not support.
Column	Values	evenings	Share	Cumulative	at or above
1	552 MW	1	5%	1 · 5%	0
2	600 MW	1	5%	2 · 10%	0
3	622.8 MW	1	5%	3 · 15%	0
4	640 MW – 656 MW	2	10%	5 · 25%	0
5	669.5 MW – 685.7 MW	2	10%	7 · 35%	0
6	700 MW – 712 MW	2	10%	9 · 45%	0
7	724 MW – 735 MW	2	10%	11 · 55%	0
8	749 MW – 769 MW	2	10%	13 · 65%	0
9	782.3 MW – 796.3 MW	2	10%	15 · 75%	0
10	806.2 MW – 824.2 MW	2	10%	17 · 85%	0
11	848.4 MW	1	5%	18 · 90%	0
12	874 MW	1	5%	19 · 95%	0
13	929 MW	1	5%	20 · 100%	1

dotCount=50 on a tight distribution · 800 measured cells discretised into 50 dots spanning barely four minutes, so the columns pile up. The auto-fit shrinks the dot until the tallest stack fits maxStackHeight and then stops — the count on screen is always 50, never 50 minus whatever did not fit. 23 of them finish inside the line takt.

Charge time per cell

50 equally likely cells · one dot = 2% · median 41.6 min · range 39.4 to 43.7 min

23 in 50 cells fall at or below 41.5 min (line takt) — 46%.

at or below 41.5 min · 23
above it · 27
one dot = 1 in 50 (2%)

Each dot is one of 50 equally likely cells: the dots sit at the 1%, 3% … 99% quantiles of the forecast, so counting them reads probability straight off the card.

The grid resolves to 2% per dot; the distribution itself puts this chance at 46.5%, which is why the dots say 46%. Raise dotCount for a finer grid — it cannot make the forecast sharper than it is.

Charge time per cell — one row per column of dots. Every dot is one of 50 equally likely cells, so a column's dot count is its probability and the running total is the cumulative probability up to that column. A column stands at the centre of the dot-wide slice its dots fall in; the slice it covers is printed, so no position is implied that the data does not support.
Column	Values	cells	Share	Cumulative	at or below
1	39.4 min	1	2%	1 · 2%	1
2	39.8 min	1	2%	2 · 4%	1
3	40.1 min	1	2%	3 · 6%	1
4	40.2 min – 40.4 min	3	6%	6 · 12%	3
5	40.5 min – 40.7 min	3	6%	9 · 18%	3
6	40.8 min – 41 min	4	8%	13 · 26%	4
7	41 min – 41.2 min	5	10%	18 · 36%	5
8	41.3 min – 41.5 min	5	10%	23 · 46%	5
9	41.5 min – 41.7 min	5	10%	28 · 56%	0
10	41.8 min – 41.9 min	4	8%	32 · 64%	0
11	42 min – 42.2 min	5	10%	37 · 74%	0
12	42.3 min – 42.5 min	5	10%	42 · 84%	0
13	42.6 min – 42.8 min	3	6%	45 · 90%	0
14	42.9 min – 43 min	2	4%	47 · 94%	0
15	43.1 min – 43.3 min	2	4%	49 · 98%	0
16	43.7 min	1	2%	50 · 100%	0

Same forecast, finer grid · dotCount=50 with a lower ceiling and smaller dots. The resolution goes from 5 percentage points per dot to 2, which sharpens what you can read off the card — it cannot sharpen the forecast itself, and the card keeps saying what the distribution's own number is.

When will the beta ship?

50 equally likely deliveries · one dot = 2% · median 12.41 days · range 6.22 to 25.65 days

12 in 50 deliveries fall at or below 10 days (promised date) — 24%.

at or below 10 days · 12
above it · 38
one dot = 1 in 50 (2%)

Each dot is one of 50 equally likely deliveries: the dots sit at the 1%, 3% … 99% quantiles of the forecast, so counting them reads probability straight off the card.

When will the beta ship? — one row per column of dots. Every dot is one of 50 equally likely deliveries, so a column's dot count is its probability and the running total is the cumulative probability up to that column. A column stands at the centre of the dot-wide slice its dots fall in; the slice it covers is printed, so no position is implied that the data does not support.
Column	Values	deliveries	Share	Cumulative	at or below
1	6.22 days – 6.9 days	2	4%	2 · 4%	2
2	7.4 days – 8.11 days	3	6%	5 · 10%	3
3	8.5 days – 9.1 days	3	6%	8 · 16%	3
4	9.3 days – 9.92 days	4	8%	12 · 24%	4
5	10.1 days – 10.8 days	5	10%	17 · 34%	0
6	10.96 days – 11.54 days	4	8%	21 · 42%	0
7	11.7 days – 12.3 days	4	8%	25 · 50%	0
8	12.53 days – 13 days	3	6%	28 · 56%	0
9	13.4 days – 13.98 days	4	8%	32 · 64%	0
10	14.24 days – 14.8 days	3	6%	35 · 70%	0
11	15.1 days – 15.6 days	3	6%	38 · 76%	0
12	15.9 days – 16.1 days	2	4%	40 · 80%	0
13	16.7 days – 17.1 days	2	4%	42 · 84%	0
14	17.6 days	1	2%	43 · 86%	0
15	18.37 days – 18.99 days	2	4%	45 · 90%	0
16	19.8 days – 20.5 days	2	4%	47 · 94%	0
17	21.4 days – 22.06 days	2	4%	49 · 98%	0
18	25.65 days	1	2%	50 · 100%	0

Loading preview…

"use client"

import * as React from "react"

import { cn } from "@/lib/utils"
import type {
  ChartQuantileDotPlotData,
  ChartQuantileDotPlotDistribution,
  ChartQuantileDotPlotThreshold,
} from "./chart-quantile-dot-plot.contract"

export interface ChartQuantileDotPlotProps
  extends Omit<React.HTMLAttributes<HTMLDivElement>, "title">,
    ChartQuantileDotPlotData {

Installation

npx shadcn@latest add https://ui.zyeon.ai/r/chart-quantile-dot-plot.json

Prompt

Build a React + TypeScript + Tailwind "ChartQuantileDotPlot" card in plain SVG
with zod. Recharts has no dot-plot primitive and the layout is a binning and
stacking problem rather than a cartesian series, so the quantile function, the
binning, the dot-size fit and the axis are small pure functions beside the
schema. No new dependency.

Contract
- One zod schema is the source of truth:
  { status: "loading" | "empty" | "error" | "ready"; title: string;
    unit?: string; axisLabel?: string;
    outcome?: { one: string; many: string };
    dotCount?: number (int, 5-100, default 20);
    distribution:
      | { kind: "quantiles"; values: number[]; probs?: number[] }
      | { kind: "samples";   values: number[] };
    threshold?: { value: number; label?: string;
                  direction?: "at-or-below" | "at-or-above" } }.
- The two distribution shapes exist because callers have one or the other: a
  posterior / Monte-Carlo sample, or the five percentiles a metrics API
  returns. Both collapse to ONE question — "what value sits at cumulative
  probability p?" — and every dot is one answer to it.
- `probs` is what lets a five-number summary be re-quantised into twenty dots,
  and it is also what tells the component that the tails beyond p5 and p95 were
  never measured. Omit it and the values are read as an equal-probability grid,
  value j standing at (j + 0.5) / m.
- superRefine: a ready card needs at least one usable number; quantile values
  must ascend (a quantile function may flatten, never descend); probs must pair
  up with values, sit strictly inside (0, 1) and strictly increase. Guard every
  access — sibling refinements all run, so a ragged payload must produce an
  issue rather than a TypeError thrown out of safeParse.
- Props = z.infer of the schema plus dotRadius (default 13, clamped 2-20),
  maxStackHeight (default 150, clamped 60-420), onRetry, onColumnSelect,
  className and the div's native props, forwardRef to the card.
- Export the maths so it is testable and this prompt can describe it:
  quantile(), buildQuantileSource(), dotValues(), binDots(), fitDots(),
  stackHeight(), buildQuantileDotModel(), niceStep(), buildScale().

Behavior
- THE DOTS ARE THE MESSAGE. Draw dotCount equally likely outcomes at the
  MIDPOINTS of equal probability slices, p_i = (i + 0.5) / dotCount. Midpoints,
  not edges: edges would ask for p = 0 and p = 1, which for most distributions
  is not a number at all and would make the two extreme dots claim a certainty
  nothing measured. One dot is therefore worth exactly 1/dotCount, and the card
  prints that ("one dot = 1 in 20, 5%") next to the chart.
- Samples are read with the R type 7 quantile (numpy/pandas' definition, so the
  card agrees with the histogram and box plot next to it). A quantile grid is a
  piecewise-linear inverse CDF between its knots, CLAMPED outside them — never
  extrapolated — and when the clamp bites, the card names the range the grid
  actually covers against the range the dot grid asks for.
- BINNING is Wilkinson's: walk the sorted dots and open a new column whenever
  the next value sits a full dot pitch past the value that opened the current
  one. Data-driven, so a gap in the distribution is a gap on the card rather
  than an empty lattice cell.
- A THRESHOLD IS A HARD BIN BOUNDARY. Bin the two sides separately, and walk
  each side AWAY from the line: below it a column hangs off its highest dot and
  covers (high - pitch, high], above it off its lowest and covers [low, low +
  pitch). Both halves are load-bearing. Binning across the line two-tones a
  column — one x position claiming both answers. Binning both sides from the
  same end leaves the last column before the line standing at "first dot + half
  a pitch", so a dot just under the threshold is drawn PAST the rule: coloured
  as counted, positioned where the reader counts it against. Walking outwards
  puts every column centre at least half a pitch clear of the line, so the
  counted dots are all on the counted side at any dot size, dot count or
  threshold position, and the rule stands in the 6% lane between two columns.
- A column is drawn at the CENTRE OF THE SLICE its dots fall in, never at the
  mean of its dots. That is what makes two column centres provably at least one
  pitch apart, so stacks can never overlap; the price is that the position is a
  slice rather than a point, so the slice each column covers is printed in the
  readout and the table instead of being implied.
- DOT SIZE IS FITTED, NOT CONFIGURED. Walk a ladder of radii down from dotRadius
  to the smallest legible one and take the first whose tallest stack fits
  maxStackHeight. A descending scan, NOT a bisection: the height is not monotone
  in the radius, because a wider dot moves the bin boundaries as well as filling
  them, so a slightly wider dot can split a cluster and come out shorter — and a
  bisection reads that dip as proof that everything above it overflows, handing
  back a dot much smaller than what fits (or calling the card overflowed when it
  is not). Every rung the scan returns is a size measured to fit. Then the field
  is exactly as tall as
  the dots need: empty air above a dot plot is a bar chart pretending to be
  one. When even the smallest legible dot does not fit, the field GROWS past
  the ceiling and says so. Nothing is ever clipped, dropped or overlapped: the
  number of circles on screen must always equal dotCount, because "count them"
  is the entire claim.
- THE THRESHOLD splits the dots by value, and the binning splits the columns by
  the same comparison, so a column is one colour or the other and never both.
  The card reports the count first ("5 in 20 deliveries fall at or below 10
  days — 25%") and
  then, when it differs by more than a tenth of a dot, the distribution's OWN
  probability ("the forecast says 24%; the grid resolves to 5% per dot"). Two
  numbers, both true, and never one dressed up as the other. If the input
  cannot pin the exact probability down — a threshold outside a supplied
  quantile grid — say that instead of guessing.
- The axis is the dots' extent WIDENED TO HOLD THE THRESHOLD (a rule pushed off
  the edge would quietly turn "1 in 20" into "none visible") plus a 6% margin,
  deliberately not rounded outwards. Ticks on the 1 / 2 / 2.5 / 5 x 10^n ladder,
  one per ~92px, explicit "en-US" locale, compact notation past 100,000, first
  and last labels anchored to their ends.
- INTERACTION. One transparent hit rect finds the nearest column itself and
  converts through its own client box, so it stays correct when the SVG scales
  below its minimum width; the click handler re-runs that search rather than
  trusting hover, because a tap is not guaranteed to send a pointermove first.
  Keyboard: the plot is a role="listbox" with tabIndex 0 and
  aria-activedescendant — one tab stop, not one per column — Left/Right walk,
  Home/End jump, Enter/Space pin (onColumnSelect), Escape releases.
  preventDefault fires only for keys that were handled, so Tab still leaves.
- Four first-class branches of one card: loading (a deterministic skeleton in
  the same hump shape, aria-hidden, plus one sr-only role=status line), empty
  (worded so a point estimate lands there knowing why), error (Try again only
  when onRetry was passed), ready. A ready payload with nothing drawable
  renders the empty branch.
- CLEANUP: one ResizeObserver, disconnected on unmount and whenever the node
  changes. No timers, no rAF, no simulation.

Rendering & styling
- Semantic tokens only: bg-card / text-card-foreground for the panel, border
  for the axis and grid, muted for the skeleton, muted-foreground for axis and
  footnotes, destructive for the error headline, ring for the focus rect,
  var(--chart-1) for the counted side and var(--chart-2) for the rest. The
  threshold rule and its label are --foreground, because it is the one mark
  that is not a category; the label carries a --card halo via paint-order:
  stroke so it stays readable over a grid line.
- The rule is drawn OVER the dots. No dot can sit on it once the threshold is a
  bin boundary, so drawing it last hides nothing countable — and it is the only
  way the rule survives a dense stack pressed against it: underneath, the
  hairline --card ring of the nearest column eats into the lane and the line
  breaks up exactly where the reader is counting against it.
- Each dot takes a hairline --card stroke, so two touching neighbours still read
  as two — the difference between counting 5 and counting 4.
- ACCESSIBILITY: do not put role="img" on the plot — children-presentational
  would silence every column. role="listbox" labelled by the heading and
  described by an sr-only paragraph that states the finding in words: how many
  outcomes, what one dot is worth, the median, the split and whether the dot
  grid rounds it. Below the plot an sr-only WRAPPER DIV (never sr-only on the
  table itself: CSS width is only a lower bound for a table box, so width:1px
  does not hold one back and a narrow viewport picks up real horizontal scroll)
  holds a row per column: values covered, dots, share, running total, and how
  many are on the counted side. The visible readout line is aria-hidden,
  because the focused listbox already announces the active column.
- Motion: the only animation is the skeleton pulse and a 150ms opacity fade on
  the dimmed columns, both carrying motion-reduce. Nothing else moves.

Customization levers
- dotCount: the chart's resolution. 20 dots resolve to 5 percentage points and
  are countable at a glance; 50 give 2 points and start to read as a shape; 100
  is a histogram made of dots. No number of dots makes the forecast sharper
  than it is, which is why the card keeps printing the distribution's own
  probability beside the count.
- dotRadius / maxStackHeight: the two knobs for density. Big dots and a low
  ceiling give a wide, chunky, "count me" card for a dashboard hero; radius 5-7
  with a 200px ceiling packs a tall hump into a sidebar. Both are ceilings the
  auto-fit may lower, never raise.
- threshold: drop it for a plain distribution card (every dot then takes
  --chart-1), flip direction to count the other side, or drive value from a
  slider upstream — the split, the headline and the table all follow one prop.
- Palette: MET_INK / REST_INK are one line each. Point them both at --chart-1
  for a monochrome card, or key MET_INK off a status token when the threshold
  means pass/fail rather than one side of a line.
- Wording: `outcome` is the noun the whole card counts in — deliveries,
  requests, evenings, patients — and it is what turns "0.25 probability" into a
  sentence someone can act on. `unit` and `axisLabel` do the same for the axis.
- Interaction: onColumnSelect carries the whole column (values, count, running
  total), so it can drive a linked table, a "what if we ship a week later"
  panel, or a second card sharing the axis.

Concepts

Frequency framing — the card answers "how likely" with a number of things rather than a probability. A density curve asks the reader to integrate an area by eye; twenty dots ask them to count, which is a skill everyone already has. The whole component exists to keep that count honest.
Equal-probability discretisation — dots sit at the midpoints of equal probability slices, p = (i + 0.5) / N, so every dot is worth exactly the same 1/N and none of them claims the impossible certainty at p = 0 or p = 1. That is what makes "3 dots in 20" a probability statement rather than a drawing.
One quantile function, two inputs — raw samples and a five-percentile grid are the same thing seen from different distances: both are asked "what value sits at probability p?". Samples answer with the R type 7 quantile; a grid answers with piecewise-linear interpolation between its knots, and clamps outside them, because a p5/p95 grid knows nothing about the outermost 5% and inventing a tail there would be the chart making data up.
Non-overlapping by construction — Wilkinson binning opens a new column once a value sits a full dot pitch past the one that opened the current column, and the column is drawn at the centre of that slice rather than at the mean of its dots. The mean would be truer to the data and would let two stacks collide; the slice centre cannot, so the position is honest about being a slice and the exact span is printed instead.
Fitted, never clipped — the dot size is stepped down a ladder of radii until the tallest stack fits the ceiling, and if no legible size fits, the field grows instead. It cannot be bisected: a wider dot shifts the bin boundaries as well as filling them, so the height dips and rises as the radius grows, and a binary search would stop at the first dip and shrink the dots for nothing. A quantile dot plot that hides a dot to make a card fit has broken the only promise it makes, so the number of circles on screen always equals dotCount.
Threshold as a split, not a filter — the rule divides the dots by value, and the binning obeys the same comparison, so the colour a dot takes and the side of the line it is drawn on can never disagree. That takes two things: the threshold is a hard bin boundary (a column is never two-toned), and each side is binned away from the line (below it a column hangs off its highest dot, above it off its lowest). Bin both sides from the same end instead and the last column before the rule stands half a pitch past the dot that opened it — a dot counted as "at or below" drawn on the far side of the very line it was counted against, which is the one error a card that says "count them yourself" cannot survive. Walking outwards keeps every column centre half a pitch clear, so the rule stands in the lane between two columns and is drawn over them; the axis is widened to hold it, because a threshold nobody can see turns "1 in 20" into "none visible".
Counted number vs. exact number — the card leads with what you can verify (5 of 20 dots) and then, when they differ, prints what the distribution itself says (24%) with the grid's resolution named. Rounding to the nearest dot is the price of countability; pretending it did not happen would be the chart lying about its own precision.

Quantile Dot Plot

When will the beta ship?

When will the beta ship?

When will the beta ship?

When will the beta ship?

Checkout latency, next hour

Peak demand against firm capacity

Charge time per cell

When will the beta ship?

Installation

Prompt

Concepts

On This Page

When will the beta ship?

When will the beta ship?

When will the beta ship?

When will the beta ship?

Checkout latency, next hour

Peak demand against firm capacity

Charge time per cell

When will the beta ship?