.claims — layout options

Fourteen ways to draw the thirteen injury claims — round 1 (C1–C7·b) works the grid, with the four-column version drawn three times because of what four does to thirteen; round 2 (C8–C12) changes the family rather than the arrangement — a wall with no gutters, an index with one preview, a stagger, a strip, a circle. H·a–H·c at the end are not layouts: they are the hover question, drawn at rest and hovered. Every option carries the real thirteen, their real URLs, and the photograph the live claim page itself uses for each — all executed out of gen_injuries_index.py, so nothing here can drift from injuries-index.html.

Thirteen is the constraint, and nothing styles its way out. Thirteen is prime, so every plain grid leaves a ragged last row: four across leaves ONE tile beside three empty cells, five leaves a row of three, six leaves a lone tile on row three. A row of three reads as a row; one tile beside three holes reads as a mistake — which is why the four-column grid is drawn three times below rather than once.

Two options fit exactly, and both do it the same way: by changing the count, not the tile. C3 — a 4-column grid is 16 cells over four rows, a 2×2 lead takes four, and the remaining twelve hold exactly the other twelve claims. C7·a — one claim takes the whole top row, and 1 + 4 + 4 + 4 = 13. Both work only if one claim genuinely leads, and which one is the firm's call, not a layout's. C7·b is the third answer: leave the count alone and centre the short row — one property, all thirteen the same size, and the orphan is still an orphan, just a polite one.
optionheight at 1280tilelast row
C1 — grid, caption under671px230×173three of five
C2 — caption on the image722px230×230three of five
C6 — hexagon tiles945px230×266three of five
C5 — a row per group1018px193 / 302 / 411each row is full
C3 — mosaic, one leading1088px296×220, lead 624×472no hole at all
four columns — 1280 = 4 × 296 + 3 × 32
C7 — four across, as it falls1096px296×222one beside three holes
C7·b — last row centred1096px296×222one, centred
C7·a — first claim across the top1179px296×222, band 1280×300no hole at all
C4 — rows with thumbnails1314px96×72one column, no ragged row
C7 and C7·b are the same height to the pixel (1096) — centring the short row costs nothing but does not save anything either. Measured in headless Chrome at 1440, not estimated — and the first draft of this table was wrong in two places, which is why it is measured: C2 looked like the short one because it has no caption band, and C3 looked like the tall one because its lead tile is the biggest thing on the sheet. Neither is true.
Two things are settled and identical in all six, so the comparison is about layout. Tone: eleven of the thirteen photographs are already black and white on the live site — measured as mean per-pixel chroma, not read off filenames like blackandwhitemiata — so all thirteen are filtered to match rather than the cyclist and the pedestrian reading as mistakes. Colour: names brown 10.87:1, hover #A94A29 5.68:1. Brand orange is 3.03:1 and carries no word anywhere here; it is a rule under a hovered tile and nothing else.
The two portrait photographs are anchored, not centred. The motorcycle source is a rider's-eye view with the machine in the lower half — centred, the tile showed an empty road and no motorcycle — and the dog's open jaw centres slightly high. Every option inherits both anchors, so no option is being judged on a crop the others do not have.
Page weight, the same in five of six. The tiles display at 230px and the media library's nearest derivative is 768px — 3.3× what is needed, 2,427 KB for thirteen images. The 300px set is 379 KB but soft on a retina screen, and the originals are 6,942 KB (Pedestrian's alone is 5472×3648 and 3.78 MB). The size that is actually right, ~461px, does not exist: registering a 460px image size in WordPress is the fix, and it is a setting rather than a layout decision. C4 is the exception — at 96×72 the 300px set is already more than enough, so that option could ship at a tenth of the weight today.
C1grid, caption underheight 671px

The page as it stands. Five across on the team page's bench module — 230.4px cell, 32px gutter — so people and claims are drawn by one card rather than two that nearly match. Thirteen leaves a row of three, which reads as a row rather than an orphan. The caption band is what makes it 671px; every other grid option here spends that space differently.

C2grid, caption on the imageheight 722px

The name moves onto the photograph, so there is no caption band — and that room goes straight back into the picture, which grows from 173 to 230px tall, a third bigger. It does not make the section shorter: 722 against C1's 671, because 57px of extra picture on three rows costs more than three caption bands saved. The scrim is the contrast, not decoration: white on rgba(0,0,0,.86) measures 8.8:1 over a mid photograph and 6.0:1 over the brightest of the thirteen. A lighter scrim would fail on the bright tiles only — the worst kind of failure, because it looks right on whichever ones you happen to check. Cost: a name over a picture is always harder to scan than a name on white.

C3mosaic, one claim leadingheight 1088px

The only option here where thirteen fits with no hole, and it is arithmetic: a 4-column grid is 16 cells over four rows, a 2×2 lead takes four, and the remaining twelve cells hold exactly the other twelve claims. It also answers a question the flat grid cannot: the thirteen are not peers — car accidents is the claim most people arrive for — and the lead tile is 624×472, the only place on the page a photograph is big enough to be a photograph. Cost: 1088px, and which claim leads is the firm's call, not a layout's.

C4rows with thumbnailsheight 1314px

The photograph becomes a 96×72 thumbnail and the name becomes the row. The most scannable by far — thirteen names in one column, read top to bottom in one pass, with sentence-case names at 17px instead of thirteen shouted capitals. It is also the tallest of the six at 1314 — thirteen rows is thirteen rows. Cost: it spends the pictures. At 96px a photograph is an identifier, not an image, and four of these thirteen (the dog's jaw, the seatbelt, the crosswalk) are close crops that stop reading at that size.

C5a row per groupheight 1018px

Each group fills the full 1280, so the tile size IS the group size — six across at 193px, four at 302, three at 411. The grouping becomes legible without a single label having to explain it. That is also the cost: Road Accidents ends up with the smallest tiles because it has the most claims, which is exactly backwards if importance is what the size is saying. And the grouping is home_v1's proposal, not the firm's — this is the option that breaks if the taxonomy changes.

C6hexagon tilesheight 945px

The brand's shape carrying the photographs, on ratio: 230.4 / 0.8660254 = 266.03. The most unmistakably League-and-Williams of the six. Cost is in the shape itself — a hexagon mask cuts four corners off every photograph, and none of these thirteen was framed for it; the dog and the motorcycle are already crops of crops. It is also the tallest per row, so it buys its identity with vertical space.

C7four across — the orphan as it fallsheight 1096px

Adi asked for a four-column grid, and this is it, drawn honestly: 1280 = 4 × 296 + 3 × 32, tile 296×222. Four is the column count thirteen likes least — 4 + 4 + 4 leaves one claim alone on a fourth row beside three empty cells. Five leaves a row of three, which reads as a row; one tile beside three holes reads as a mistake, and no amount of styling changes that. What the width buys is real though: at 296px the tile is 28% wider than C1's 230, so the photographs are the biggest of any even grid here.

C7·afour across, the first claim across the topheight 1179px

The orphan cured by changing the count, not by stretching a tile. The first claim takes the whole top row at 1280×300 and the other twelve fill three rows of four exactly — 1 + 4 + 4 + 4 = 13, nothing left over. Same trick as C3 and the same question behind it: this only works if one claim genuinely leads, and which one is the firm's call. Cost: the band is 1280px of photograph, and only two of the thirteen sources are wide enough not to be cropped hard to fill it.

C7·bfour across, the last row centredheight 1096px

The orphan cured by moving it. Flexbox rather than grid, so the short row centres itself; the three full rows are untouched, because 4 × 296 + 3 × 32 is exactly 1280 and there is nothing to centre until the row that is short. The cheapest fix on the sheet — one property — and it keeps all thirteen the same size, which C7·a does not. Cost: a centred single tile still announces that the count did not divide; it just does it politely.

C8the wall — no guttersheight 640px

Zero gap, so the thirteen read as one photographic block rather than thirteen objects on a page. Five across is 256px — the home page's own lattice, 5 × 256 = 1280 — and the last row's three divide the same 1280 at 426.67 each, so every row reaches both edges and the ragged last row simply does not occur. That is a different answer to thirteen from C3's and C7·a's: not change the count, change what a row is. Cost: no air at all between one accident and the next, which on this subject matter is a tonal decision as much as a layout one.

C9index, one previewheight 559px

Thirteen names and one photograph: the picture changes with the cursor instead of thirteen competing at once. Pure CSS — the previews are siblings of the names, so :nth-child(n):hover ~ :nth-child(n+13) reaches the right one and no script is needed. It is also the only option on the sheet that fixes the 2.4 MB, because twelve of the thirteen images can be loaded lazily and most visitors will never ask for them. Cost, and it is a real one: there is no hover on a phone. On touch this needs a tap-to-show or it degrades to a plain list — which is C4 minus the thumbnails.

C10staggeredheight 776px

The same 230.4 cell as C1 with every second column half a tile lower, so the eye reads a rhythm instead of four straight rules across the section. The stagger is a translate, not a margin, so the grid still lays out as a plain grid and nothing has to be reordered for it. Costs 105px — half a tile — and nothing else. Cost that is not in pixels: a staggered grid is harder to scan than a straight one, and this is an index.

C11filmstripheight 223px

One row, scrolled sideways: 13 × 230.4 + 12 × 16 = 3,187px of strip in a 1,280px window, so about five of the thirteen are visible at once. By far the shortest thing on the sheet, which matters if this section has to sit under a hero and above a footer without owning the page. Cost, and on an index it is the objection that decides: it hides eight of the thirteen. A visitor who does not drag never learns the firm handles dog attacks.

C12circlesheight 844px

A different shape family from C6's hexagons, and the arithmetic is worth having before either is rejected on cropping: a circle keeps π/4 = 78.5% of its frame; the hexagon keeps exactly 3/4. Circles crop less than the brand shape does. What a circle costs instead is the brand — it is the one shape on this sheet that says nothing about this firm — and it suits faces, which is what circles are usually for, better than it suits a crashed car.

C13the triage checkerboardheight 840px

home_v1 has no hero — its first screen is .triage, a gutterless checkerboard of white type cells and photographs, 5 × 280px, tone alternating orange and teal, with a hexagon marker that scales in under the cursor. That construction is lifted part for part. Seven claims arrive as a photograph and six as a word, and which six is decided by position, not importance — so, borrowing the triage's own flip, a type cell reveals its own photograph on hover and no claim is left without one. One thing is deliberately not copied. home_v1 sets these headings in brand orange and brand teal at 21px weight 300: on white that is 3.03:1 and 2.60:1, and 21px at weight 300 is not large text, so the floor is 4.5:1. Both fail; teal fails even the 3:1 large-text floor. Here the heading is brown (10.87:1) and the orange and teal move to the rule and the marker, which are non-text and need only 3:1. The alternation survives, the failure does not — and the same fix is owed to the homepage. Cost beyond the checkerboard: thirteen still does not divide by five, so the block ends two cells short on the third row. C8 cures that by letting the last row divide the full width; doing the same here would break the 256px module the triage is built on, so it is left visible rather than fixed with a trick borrowed from another option.

H·ahover → the colour comes backheight two rows, hover round

The literal request, and the measurement is the answer: eleven of the thirteen photographs are already black and white in the source file, so filter:grayscale(0) returns nothing on eleven of them. Look at the hovered row — only the cyclist and the pedestrian change. A hover that works on two tiles in thirteen is worse than no hover, because the reader learns the rule from whichever tile they touch first and the other eleven then look broken.

H·bhover → a brand duotoneheight two rows, hover round

What the request actually wants, delivered on all thirteen. An orange layer with mix-blend-mode:color takes its HUE from the brand and its LUMINANCE from the photograph, so it does not care whether the source had colour: every tile warms identically. It is also the only version that is the firm's colour rather than whatever the stock photograph happened to be shot in. Cost: it is a strong effect, and orange over a dark photograph goes muddy — the dog and the passenger tiles are the ones to judge it on.

H·chover → the photograph liftsheight two rows, hover round

No colour at all: brightness(1.18) contrast(1.06), so the tile brightens under the cursor. Works on thirteen for the same reason H·b does — it asks nothing of the source — and it keeps the page monochrome, which is the tone every other page in this rebuild is already in. The quietest of the three, and the only one that survives the November shoot changing every photograph.