A phone scrolls four screens to read a board of six

[ExtraToast]

Parent

#922

What happens now

On a phone a board member's slice shows the whole portrait, uncropped, at the picture's own aspect ratio. That was the decision in #988 and it is the right one: every portrait the association has recorded is taller than it is wide, so any landscape crop threw away more than half of each one.

The cost is height. Measured against the real records at a 390px viewport:

Portraits with dimensions recorded	21, across boards VI–IX
Their aspect (height ÷ width)	1.357 – 1.547, most exactly 1.5
A face at 390px wide	529 – 603px tall
An open slice (face + prose)	~850px — a screenful and a bit
A board of six, one open	roughly 3,700px of scrolling

So a visitor reading one board scrolls about four screens to see six people, and the band no longer reads as a band: at any moment roughly one face is on screen.

Why this is a question rather than a defect

Nothing is broken and nothing is cropped. The trade is between two things #986 wanted at once:

• the whole photograph, because a crop discards half of a portrait and the pictures are the point
• a band, something a reader can scan, where the next person is visible and the shape of the group is legible

At 1.5 those two are in tension on a phone in a way they are not on a desktop, where the faces sit in a row.

What could be done

Each of these keeps the whole picture for the member being read, which is the part that matters:

1. Cap the height of a shut slice, keep the open one whole. A shut member is a face and a name — a peek is enough to recognise and choose. The one being read shows the picture entire. Costs: two heights and a transition between them, and a shut slice is cropped after all, though only the one nobody is reading.
2. Cap every face at a maximum height (say 26rem) with object-position keeping the head. Simplest, one figure, but it reintroduces cropping for the tallest portraits — which is what A board member's slice stacks on a phone #988 set out to remove.
3. Leave it. The scroll is long but honest, and a phone is a scrolling device. Revisit if anyone actually complains.

Acceptance criteria

• A decision recorded here, with its reason, before any change is made
• If a cap is chosen: the member being read still shows their whole portrait
• If a cap is chosen: the scroll observer still opens the slice nearest the middle of the screen — a shorter slice changes what dominates the centre band, and A board member's slice stacks on a phone #988 already flagged the observer's margins as the thing to adjust rather than the layout
• The cover layout and the desktop row stay untouched
• Covered at 390px in the board e2e spec, asserting the property rather than a figure — as stacks a member's portrait over their description now does, so a future change of mind does not need the test edited

Notes

Raised from the work in #986 / #988 / #991, all merged in #997. The figures above were measured on the live stack against board IX, not estimated.

Related: #988's own Further notes predicted this and recorded the other half of it — if a taller slice ever stops the scroll observer picking the slice being read, "the observer's margins are the thing to adjust, not the layout". A defect of exactly that shape was found and fixed in #997 (a tap undone by its own reflow), so the observer is already known to be sensitive to slice height.