The Weekly App→
Meal-kit POC that turns Coles recipes into a consolidated trolley.
Follow-up to v1 (six layouts) and v2 (mandatory imagery, auto-tint, writing differentiation). This doc pins Layout A — top third strip as the card structure and asks: does it hold up across all six visual types, and what happens when the screenshot is a mobile app?
Two decisions baked in before this doc opens a single card: (1) Layout A is fixed — every card has a 160px top strip with content below. v2's concern about mixed-species grids is resolved because imagery is now compulsory on every card. (2) Numerals and monograms render in the card's register colour, not the signature gradient. The gradient is reserved for the gradient-mark type and featured cards — overusing it on text marks weakens the visual system and turns the page into soup.
Each pair shows a work card (royal) beside a writing card (violet). The strip is 160px tall, spanning full card width. Content below is identical across pairs so the only thing that varies is the imagery treatment. Same hover state across all six: background lift + border change to the card's register colour. No per-type one-offs.
mix-blend-mode: color. Author drops in any screenshot, component forces it into palette.Meal-kit POC that turns Coles recipes into a consolidated trolley.
Why every portfolio image should be captured at render time, never baked in.
GTD planner with persistent SMS, four-layer spend protection, and a killswitch that works.
Convention-based spend discipline fails under pressure. Structural choke points don't.
When no screenshot or diagram fits the brief, the numeral carries the card on typography alone.
Writing-register numeral in violet only — never the gradient. Pure register signal, no dilution.
Tokens-first architecture applied across three projects. Gradient-mark carries the abstract weight.
When the content IS the palette — gradient-mark is the only imagery that makes sense here.
Quarter-by-quarter breakdown of a two-year B2B sales cycle from raw Salesforce exports.
The posts that forced me to understand what I was actually claiming about the systems I was building.
Short-code lockup — the fallback when diagram and screenshot both feel forced.
Monogram in violet only. Good for index pages where many cards need to feel like siblings.
v2 rendered the numeral with background: var(--grad-rv); -webkit-background-clip: text. That looked great on a single card. It looked muddy on a 2×2 grid because every text mark became the same gradient, regardless of whether the card was work or writing. The register split collapsed into visual noise.
The rule now: text marks inherit the card's register colour. Work gets royal-10. Writing gets violet-10. Nothing in between. The gradient still exists — it lives on the gradient-mark type and on featured card borders (see v2 §4) — but it doesn't leak into every card that happens to use a numeral.
Gradient fill. Pretty in isolation; works against register signal in context.
Writing card — but the gradient is indistinguishable from the work card on the left.
Royal-10 numeral — same colour family as the kicker and the arrow. The card reads as one thing.
Violet-10 numeral. The writing register is now carried by three coordinated signals, not one gradient.
Layout A's strip is ~420px × 160px on a 2×2 landing grid (~2.6:1). A mobile screenshot is ~390 × 844 (~1:2.16). The strip is about six times wider than tall, relative to the phone. Cover-cropping shows ~18% of the screen; contain-sizing leaves a 72×156 phone floating in a sea of padding. Neither reads as intentional.
Six options below, each rendered as a real strip so you can judge them directly. Same fake phone markup in all of them — the only variable is how it's placed inside the frame.
Feels fine in isolation. Weakness: the phone looks cut off, not framed.
M2 — the phone is honest about being a phone. Reads as "here is the product".
Weakness: the phone is small — UI detail reads as "something" but not "this specific thing".
M3 — the tilt converts "cropped phone" into "composed phone". Most editorial.
Weakness: applies one "art direction" gesture per card — starts to feel like a trick if every work card uses it.
M4 — good for products with a two-screen story. Overkill for single-screen apps.
Weakness: requires two screens that pair cleanly. The author has to do art direction, not just capture.
M5 — strongest editorial feel. Meta label anchors the card, phone supplies proof.
Weakness: the numeral now duplicates the kicker number. Redundant if both are shown.
M6 — doesn't pretend to show the whole app. Shows the exact moment the card is about.
Weakness: requires a crop decision per card. No automatic answer from "here's the screenshot".
| Option | Author effort | Honest to UI | Grid rhythm | Read |
|---|---|---|---|---|
| M1 · Top slice | low | partial | clean | Safe default. Reads as "cut off" when the app bar isn't load-bearing. |
| M2 · Contained | none | yes | clean | Honest but tiny. UI detail disappears at grid scale. |
| M3 · Tilted bleed | medium | partial | clean | Best balance. Composition signals "this is a product shot", phone reads as intentional. |
| M4 · Dual cascade | high | yes | mixed | Great for two-screen stories, heavy otherwise. Save for hero cards. |
| M5 · Meta split | medium | yes | mixed | Strong editorial feel, but duplicates kicker number if the meta shows the same digit. |
| M6 · Detail zoom | high | yes | clean | Highest craft ceiling, highest author cost — requires a crop decision per card. |
Lock Layout A (top third strip, content below) as the card spec. All six visual types render cleanly in it, the strip is big enough to carry meaningful imagery, and the content-below pattern is the most familiar scan order.
Adopt the text-mark colour rule: numerals and monograms use the card's register colour (royal-10 for work, violet-10 for writing). The signature gradient lives only on the gradient-mark type and on featured card borders. Treat gradient-mark as a deliberate reach — suitable for featured cards and posts where the palette is the subject, not as a filler for cards that have no better image.
For mobile screenshots, make M3 tilted bleed the default and M1 top slice the fallback. Document both in the imagery standards so the author has a one-sentence rule: "Mobile case study → tilted bleed. If the bleed composition fights the content, fall back to top slice."
Open question to resolve before closing this doc:
image.kind: "mobile-screenshot" sub-types in the Card props API, or just leave them as capture-time decisions handled by the imagery standards doc? Sub-typing in TS makes the system louder and harder to misuse — but also harder to evolve.