S14: Landing page messaging, order and hero

Date: 2026-10-25. Baseline: website/index.html at 22e0908. The newest iteration comes first; earlier iterations follow as history, and an independent critic reviews each iteration. The canonical decisions land in the design system; this page keeps the evidence and the reasoning behind them.

The owner's brief: the design language stays, but the messaging, the order of arguments, the opener, the hero visual and the visual alignment need work. Which assumptions does a visitor have at which point, where does the page answer each, and what is each section for?

Iteration 3: the release candidate

Date: 2026-10-25. Inputs: a third independent critique and three owner rulings. Where this section conflicts with iterations 1 and 2 below, this section wins.

Owner rulings

• Brand: OpenXet everywhere the page names the product; lowercase openxet only for identifiers (the command, crates, OPENXET_*, paths, schema ids, the domain and URLs).
• Written as launched: the page describes the full planned product (design §12) as available. Limits that stay: no invented numbers or output, no logos or testimonials, and every call to action lands on what works (the quickstart; the waitlist form for hosting). Recorded in design.md and AGENTS.md.
• The Git analogy for the opener.

Opener

Tested against “what is it, and why do I care?”; line counts measured in Chromium with the page's fonts.

Pill: OpenXet · open source · Apache 2.0 (the brand is in the first screen; HF keeps its name in the H1, a new name can't do that job). Subhead: “OpenXet is open-source Xet storage for large files and datasets, in repositories and buckets. git push and hf upload send only the chunks your server doesn't have, not the whole file as Git LFS does. Run it yourself or on openxet.com.”

Hero

The whole hero fits the first screen at 1440×900, proof strip included (it ends at y ≈ 706). The long transcript is gone. A compact command card was allowed, but the first row (Repositories) shows the same commands one scroll below, so the hero has no visual, as on huggingface.co/storage; the proof strip takes the logo strip's place. CTAs: Get started (filled, the quickstart) and Start on openxet.com (outlined, the waitlist form).

One measurement everywhere

The page quoted four figures for one experiment (1.2 MiB, 1.1 MiB, 1.09 MiB and 1,125,507 bytes). It now quotes only 1.09 MiB (1,141,116 bytes, stock hf_xet 1.7.0, empty cache), from site/measurements.json:

• compat/tests/test_storage_only.py::test_fresh_cache_edit_bytes_recorded asserts the bytes equal the fixture whenever the installed hf_xet is the fixture's version. The input is seeded, so the figure is deterministic: re-run on 2026-10-25 it gave 1,141,116 bytes again.
• site/test_measurements.py, run by scripts/build-site.sh, checks that the display matches the bytes, that the named test exists, that every x.xx MiB on the landing page, the other pages, the social image and the llms.txt template is the fixture's, and that the landing page names the test.
• The agent panel shows a captured download --json error and its correction, so it carries no second transfer figure.

Sections

Seven rows, a security band and tiles (the critique's map): Repositories, Xet, Use cases, Buckets, Self-hosting, Platforms, Agents. Compatibility, Hosting and FAQ rows are gone: clients are in Repositories, backends in Self-hosting, hosting in the hero and tiles, savings in Use cases. Rows for features without a measured run (Repositories, Buckets, Self-hosting, Platforms) show commands or diagrams only, no output. Each row's panel has its own hue; in dark mode elevation runs frame < panel < card (panel to frame about 1.2:1, borders about 1.4:1 against panels).

Pixel items from critique 3

1. Proof strip off the first screen: now its bottom edge.
2. Four numbers: one fixture (above).
3. Rows centred, so pills floated 81 to 125 px below hairlines: both cells share one top padding; every pill sits 56 px below its hairline at 1440 px.
4. Dark panels invisible, inverted elevation: new panel and card tokens.
5. and 6. Hero terminal and the python line: removed.
6. The floating “vs”: removed; the two cards stack directly.
7. The toggle between visual and legend: moved above the cards, the legend under them.
8. Test names wrapping mid-word: smaller chips that break only at underscores.
9. Compatibility contradicting its panel: row removed.
10. Empty FAQ column: row removed.
11. 0.0.0 in the terminal bar: bars now read “terminal”.
12. Status line under the CTAs: removed.
13. Tinted first tile: tiles are equal, each with an icon.

llms.txt

Its run steps stay factual (agents execute them) and now say that the website describes the full product while the steps are what runs today. The generator moves the Project part (design, ADRs, research, plans) under ## Optional, with a test. The # openxet heading belongs to the brand rename in site/.

Recommended quickstart line

The quickstart (owned by the brand rename) should open with: “What runs today: the OpenXet storage server with Hugging Face's hf_xet client and the openxet command line. git push, hf upload and buckets arrive with the Hub API; this page is the path that works now.”

Open questions for review

• “Start on openxet.com” lands on a waitlist form. It is the ruling's allowed destination, but the label promises more than the page delivers.
• The Repositories and Buckets commands are shown as working; the quickstart line above is what keeps “Get started” from being a dead end.
• Re-capture Repositories with real git push and hf upload output the day M2 merges, and Buckets the day buckets do.

Iteration 2: closer to Hugging Face Storage, generic

Date: 2026-10-25. Inputs: the owner's direction ("we must be closer to https://huggingface.co/storage but not so close to models etc but more generic … they know what they did there"), an independent critique of iteration 1, and the coordinator's rulings. Iteration 1's analysis below is kept as history; where it conflicts with this section, this section wins.

What the Hugging Face Storage page does

Studied in headless Chromium at 1440 px on 2026-10-25:

• Centred hero, no side visual: product name as the H1 with the second half in accent colour, a two-line subhead, two pill CTAs, then a logo strip as the bottom edge of the first screen.
• One framed two-column grid with visible vertical rails for every section. Left cell: a pill tag, a benefit H2, two sentences, three check bullets. Right cell: a softly tinted panel with exactly one product visual.
• One concrete visual per claim: a light terminal card (hf buckets create, hf sync with "62% deduplicated" and a progress bar), "8 / 8 chunks uploaded" against "1 / 8", price bars against S3, a folder list, a bucket fanning out to clouds, a globe, an agent terminal, then four security cards and three closing tiles.

The rhythm is the design: every section shares the same two edges and centre line, so the page reads as one system.

What changed, and why

Opener, tested against "what is it, and why do I care?"

Section order, one job each (iteration 2)

Re-capturing the terminal transcripts

Both terminal cards are captured, not composed. On 2026-10-25 they came from the openxet debug binary built from commit b1394d1 (an M2 branch; serve, upload and download behave as in M1), on an Apple M3 with macOS 15.6.1. The cards show only commands that exist today, with comments added, file tables omitted and hashes shortened. Random data moves chunk boundaries, so each run sends 1.1 to 1.2 MiB; the recorded compat measurement (1,141,116 bytes) is the figure the page quotes elsewhere.

openxet serve --data-dir openxet-data --port 0 > serve.out 2> serve.log &
export OPENXET_ENDPOINT=$(grep -o 'http://127.0.0.1:[0-9]*' serve.out | head -1)
export OPENXET_TOKEN=$(cat openxet-data/dev-token)
export HF_XET_CACHE=$PWD/home-cache
head -c 104857600 /dev/urandom > data.bin
openxet upload data.bin
python3 -I -c "import os; f = open('data.bin', 'r+b'); f.seek(50 << 20); f.write(os.urandom(1 << 20))"
openxet upload data.bin --cache-dir ./empty-cache
openxet download "$(openxet upload data.bin --cache-dir ./empty-cache --json | python3 -I -c 'import json,sys; print(json.load(sys.stdin)["files"][0]["hash"])')" --output restored.bin --cache-dir ./another-empty-cache
cmp data.bin restored.bin && echo identical
# agent card: one more 1 MiB edit at offset 10 MiB, then
openxet upload data.bin --json
OPENXET_TOKEN=oxt_expired openxet upload data.bin --json

Output of that run, verbatim, before shortening:

Uploaded 100.0 MiB of 100.0 MiB (0% deduplicated).
Uploaded 1.2 MiB of 100.0 MiB (98% deduplicated).
Downloaded aab0307f0b73a12ca5e9508d6d857970fdf02544f3e9fc8ed7a28716c46a46a4 to restored.bin (100.0 MiB).
identical
{"schema":"openxet.upload.v1","files":[{"path":"data.bin","hash":"7a49591d90711a87b0f930ebea1db29babe225140af835e8606a6793ce0c215a","size":104857600,"sha256":"72731ae06ddeacf1fea2fc7a17b04194111f31d7458ea2aeb2ac359eff0e6386"}],"bytes_uploaded":1125507,"bytes_deduplicated":103732093}
{"schema":"openxet.error.v1","code":"unauthorized","message":"http://127.0.0.1:58241 refused the token (401 Unauthorized)","hint":"Check that OPENXET_TOKEN is a token for this server, not revoked or expired. A dev server prints its token on startup and keeps it in <data dir>/dev-token."}

The error exits with status 1, as exit codes documents. A CI job that re-captures these into a fixture is a candidate follow-up, so the cards can't drift.

Alignment fixes in iteration 2

All eleven items of the critique's pixel list:

1. Hero tops misaligned: the hero is centred, single column.
2. Trace row baselines: the trace is retired.
3. Ragged right edge at 768 px: every visual fills its row's panel.
4. Uneven column bottoms in How it works: rows are one grid; both cells stretch to the row height and centre their content.
5. Proof label baselines: the strip uses a three-row grid per cell (figure, label, link), so links align.
6. Integration links on no column: the integration row is gone; the platform has a tile.
7. Band rhythm: every row is white copy beside a tinted panel.
8. Empty FAQ column: the FAQ is a row like the others, its heading centred against the questions.
9. Mobile route row: retired with the trace.
10. Card border peeking above the 375 px fold: on phones the proof strip follows the CTAs, so the first screen ends in proof, then the terminal.
11. Final heading inset: the final section is centred with full-width tiles inside the frame.

Also: the header's brand, the frame's rails and the footer share one 75 rem edge; long test names break only at underscores; terminal lines wrap instead of hiding the result on narrow screens.

Open questions for critic 3

• Length. Nine sections against HF's ten; is Use cases or FAQ the one to fold?
• Terminal on phones. It wraps to about 30 lines at 375 px. Show a shorter variant on phones, or move it below the proof strip as now?
• Hero H1 "Large-file storage that uploads only what changed." Does "Large-file storage" read as generic enough for logs and backups?
• Captured from an M2-branch build. The behaviour shown is M1's, but a re-capture from a release build would be cleaner.
• llms.txt gained an agent decision block; moving ADRs and research under "Optional" needs a generator change and is not done.

Iteration 1

What was wrong with the page

Read top to bottom, the previous page said:

1. Large files. Lighter uploads. True of every dedup product, including huggingface.co itself. Nothing said openxet is a server, that it is Xet, or that Hugging Face's own client works with it.
2. An eight-part toy diagram, labelled illustrative, as the hero. It taught dedup, which Hugging Face's own Storage page already teaches, and showed nothing openxet does.
3. Three steps of dedup.
4. Hosting choices, with the waitlist (a service that does not exist yet) as the featured card and the primary action.
5. Only in the fifth section: what works today, and that hf_xet works.
6. Evidence as three links with no numbers, though the repository has measured numbers with methods.

So the differentiator (an open-source Xet server that stock clients talk to) and the proof (measured bytes) both arrived after the visitor had been asked to join a waitlist. The page answered "what is dedup?" first, a question most arriving visitors do not have.

Research: 19 landing pages

Accessed 2026-10-25 with WebFetch, and curl where pages render client-side. XetHub and Oxen through the Wayback Machine (captures 2024-02-08 and 2026-08-26). Supabase, Neon and Turso serve WebFetch a separate agent-oriented Markdown page; the human HTML was checked with curl. Long subheads were cut by the fetch tool where marked "…". Observations describe the pages, not their conversion.

Patterns that hold for an open-source server with a hosted option

1. Anchor the opener on something the visitor already knows. Postgres (Supabase, Neon), SQLite (Turso), S3 (Tigris, R2), pip (uv), Git (git-lfs). Abstract slogans (Forgejo, lakeFS, MinIO) explain nothing. For openxet the anchor is Xet and Hugging Face's client.
2. The first proof is measured and carries its method. uv opens with a captioned benchmark; HF Storage and XetHub show a real transfer. Without customers to name, a reproducible measurement is our proof.
3. Compatibility is shown as the tools people already run, not claimed as a percentage (uv's pip interface, Gitea's Actions, R2's S3 APIs). Our version: which stock client works today, which is next.
4. The working open-source path is the primary action when the hosted one is not live. No reviewed page made a pre-launch waitlist its main hero action. DVC shows what an upsell in the hero costs.
5. Self-host vs hosted is a short, equal choice ("Your infrastructure or ours", Turso's paired cards), framed as one journey, and open source doubles as the no-lock-in promise (Supabase).
6. Agents get a peer path, not a footnote (Tigris, Neon, HF Storage).
7. Honest labels build trust (PostHog's "Illustrative demo", Zed's scoped beta banner, uv's captioned workload).

Visitor model

Who arrives, from where, and what they bring.

What each assumes and doubts as they scroll, and where the page answers:

Section order, one job each

Old anchors #dedup, #hosted, #integrate, #review and #roadmap keep working.

Opener alternatives

Pick A, with the anchor carried by the category line ("Open-source Xet storage server") and the lead (names Hugging Face's hf_xet, "unmodified"). This follows pattern 1 within one glance without putting HF's name in the headline. When hf upload works against openxet (M2), re-test D: the stock hf CLI is the strongest anchor there is.

Hero visual

It must make obvious in three seconds: a tool I already know (Hugging Face's client) talks to a server I run, and only a sliver of a large file crosses the wire, while the whole file comes back.

Concept, picked: a measured upload trace. A route row (hf_xet, "Hugging Face's, unmodified" → openxet serve, "On your machine") sits above three to-scale bars from one real test (compat/tests/test_storage_only.py::test_fresh_cache_edit_bytes_recorded, recorded in the competitive matrix):

• Edited file, 100 MiB, with the 1 MiB edit marked amber at its true position and width (1%).
• Sent to the server, 1.14 MB: an empty dashed track with an amber sliver of its true width (1.09%).
• Downloaded back, 100 MiB, whole (the test checks the sha256).

The caption gives the exact byte count, the client version, the empty cache, "bars to scale", and links the method. It keeps the design system's grammar (blue stored, amber new, the whole file stays whole) and the single elevated object.

Alternatives considered:

Alignment fixes in iteration 1

From screenshots of the previous page at 375 to 1920 px:

• Section intros split into a heading column and a paragraph column at 50%, while the grids below split at thirds; nothing shared an edge. Intros are now one column on the content's left edge, and every two-column layout (hero, how it works, agents, FAQ, hosting) splits on the same centre line.
• The FAQ's summary used flex, so inline code broke the line into three flex items; summaries now wrap their text in one element.
• Hero buttons at 375 px were two different widths on separate lines; they now stack at full width below 576 px.
• Orphans in the lead, availability line and headings: text-wrap: pretty on paragraphs, balanced H1 lines per sentence.
• Proof links next to their paragraph squeezed it at 1024 px; they now sit below it.

Open questions for the next iteration

• Primary hero action. This iteration makes "Run it locally" primary and the waitlist secondary (the header keeps "Join the waitlist"). That bends design.md's waitlist-first state; is that the owner's intent?
• Mobile hero. The visual sits below the fold at 375 px, after the actions. Is a compact version of the bars worth showing earlier?
• Four-line H1 at desktop. Shorter alternatives lose either the benefit or the differentiator.
• Proof density. Four figures plus the hero's measurement repeat 1.14 MB twice; would a different fourth figure (the 1 GiB round trip, SIGKILL survival) serve better?
• Not tested with people. The ten-second comprehension test in the website research still has not been run.

Read this page as Markdown · Report a docs issue