Appearance
Biodata reader — photograph viewing and the opening block (round 4 prompt)
Purpose: three questions the current design does not answer, raised by device testing on 2026-09-10, to be decided in the design before any of them is implemented.
The owner tested the Marriage Biodata reader on Android and asked for three behaviours. Measuring the artboard showed that none of the three is in the approved design, and two of them the design appears to have decided against deliberately. Implementing them in code would have been invented UI/UX, which the standing rule forbids, so they come here instead.
What was measured, and why each is a design question
prototype/consumer/BiodataView.dc.html was pulled fresh on 2026-09-10 and read mechanically rather than from memory.
| Ask | What the artboard actually says | Verdict |
|---|---|---|
| Photographs should auto-advance | No timer exists. The only two setTimeout calls are the toast dismissal (2600ms) and the copy confirmation (2200ms). Slides move by dots (s.onPick) alone. prototype/consumer/Featured.dc.html takes an intervalMs prop, so this project knows how to specify autoplay and did not here | Design decision to revisit |
| Tapping a photograph should open it full screen | Already designed and simply had not been built. Now implemented from the artboard | ✅ closed in code |
| The full-screen view should zoom | No gesture, no transform, no zoom control, and the frame is fit:cover on aspect-ratio:1/1.24, so it deliberately crops | Design decision needed |
| The opening block should appear in the reader | Explicitly excluded: rowsFor filters .filter((f) => f.kind !== 'opening'). The opening renders on the public page instead | Design decision needed |
⚠ One related item is deliberately NOT in this prompt. The owner also asked for screenshot protection. That is an undecided product and policy contract, not a design question: it contradicts copy this design insisted on word for word (PHOTO_CLAIM: "Nobody can stop a screenshot, and we do not pretend to"), it needs a native dependency decision, and browser-level prevention is not achievable at all. Sending an undecided contract to the design is what produced an Ad Manager and an in-house billing engine in this prototype. It stays with the owner until it is decided.
The prompt
Paste the two blocks below together, followed by the PDPR block from the screen coverage mandate.
text
YOU ARE EXTENDING AN EXISTING APPLICATION, NOT BUILDING A NEW ONE.
Three photograph and opening behaviours are being decided for the Marriage Biodata reader that
already exists in the prototype/consumer app. A person using it must not be able to tell where
the existing product ends and this change begins.
STUDY THESE BEFORE PROPOSING ANYTHING. They are the product you are extending.
prototype/consumer/ the folder this change belongs in
prototype/consumer/BiodataView.dc.html the screen being changed. Read its state model first:
slide, lightbox, asTier, viewer released|basic|owner
prototype/consumer/Biodata.dc.html the editor that produces the photographs and the opening
prototype/consumer/biodata-core.js FIELDS, TIERS, PHOTO_CLAIM, MAX_PHOTOS, openingOf,
openingEmblems, look, THEMES. The rules live here, not
in a screen
prototype/consumer/consumer-data.js the seed module and its sections
prototype/consumer/ds-base.js the shared base every screen here imports
prototype/consumer/icons.js the icon set actually in use
prototype/consumer/image-slot.js the image component and its geometry contract
prototype/consumer/Featured.dc.html prior art for an auto-advancing carousel, including its
intervalMs prop
prototype/setu-card/BiodataPage.dc.html the PUBLIC page, which already renders the opening block
prototype/consumer/consumer.prompt.md the persistent context for this surface
BEFORE ANY CHANGE, PRODUCE TWO LISTS.
REUSED every existing component, module, pattern, token and layout rule you will use
unchanged, naming the file.
NEW anything you must introduce, each with one sentence saying why the existing
pattern genuinely cannot carry it. A new pattern with no justification is a defect.
PLACEMENT IS NOT INHERITANCE. Every domain folder here carries its own ds-base.js and
support.js, so nothing is imported unless you say so. Name the modules to import.
DO NOT CREATE A NEW SCREEN OR A NEW FOLDER. All three questions are changes to
BiodataView.dc.html and, for question 3, possibly to BiodataPage.dc.html as well.
DO NOT use em dashes anywhere in generated copy, documentation, labels or examples.text
THE THREE QUESTIONS.
1. SHOULD THE PHOTOGRAPHS AUTO-ADVANCE, AND IF SO UNDER WHAT RULES?
The owner expects the photographs to slide on their own. Today they do not: the dots are the
only way to move, and there is no timer in the screen.
Decide it, and say why. The tension to weigh, honestly, in both directions:
FOR a reader may not notice there are four photographs. The count pill states it, and
a pill is read once and forgotten.
AGAINST a marriage profile is a document a family READS, not a promotion. Content that
moves under the eye while someone is reading the identity lines directly beneath
it is a different kind of surface. Featured.dc.html auto-advances because it is a
discovery strip, and that may be exactly why this screen was not given one.
If the answer is yes, specify: the interval, whether it stops permanently or temporarily once
the reader touches the dots, what happens while the full-screen viewer is open, and the
reduced-motion behaviour. State the reduced-motion answer explicitly rather than leaving it
to the implementation, because the implementation will otherwise choose it.
If the answer is no, say so plainly and say what carries the discovery instead. A decision
recorded is worth more than a change.
2. SHOULD THE FULL-SCREEN VIEWER ZOOM, AND FOR WHOM?
The full-screen viewer is now built exactly as designed: overlay, mono count, close control,
a 1/1.24 frame at radius 28, and PHOTO_CLAIM in the footer.
The owner wants pinch zoom in it. This is not a neutral addition, and the reason is the
disclosure model in biodata-core.js rather than any technical limit:
- a RELEASED family is served the ORIGINAL photograph. They have been granted the profile,
so inspecting it closely is exactly what the release is for.
- a BASIC reader, holding a forwardable link, is served the 720px 4:5 DERIVATIVE. That
derivative exists SO THAT a forwarded photograph is low value. A magnifier over it
invites precisely the inspection the derivative was created to prevent.
- the frame is fit:cover, so today the viewer crops rather than showing the whole picture.
A reader cannot see the full frame at any tier.
So the question is not "add zoom" but: does zoom differ BY TIER, and does the frame stop
cropping? Specify per viewer state (released, basic, owner preview): whether zoom exists, its
bounds, whether the whole frame becomes visible, and what the footer says while zoomed.
If zoom is right for a released family and wrong for a basic reader, say that and design both
states. A control that appears for one tier and not another needs its own copy, not silence.
3. SHOULD THE OPENING BLOCK APPEAR IN THE IN-APP READER?
The editor lets a family choose how the page opens: a collection emblem, their own picture, a
line of words, or nothing. The PUBLIC page renders it. The in-app reader excludes it, and the
exclusion is explicit rather than accidental: rowsFor filters kind !== 'opening'.
The owner configured an opening, opened the in-app preview, and did not see it. The argument
for changing this is the preview's own promise: BiodataView.dc.html exists so the owner can
read "the same document as any recipient reads it", and one of its own card actions is "See it
as a family sees it". A preview that shows LESS than the page it previews undermines that
claim, and the opening is the first thing a family sees.
The argument against, which should be tested rather than assumed: the in-app reader may be
deliberately denser than the public page, and the opening may be considered a property of the
published document rather than of the reading surface.
Decide it. If the opening belongs in the reader, specify where it sits relative to the
photograph card (above it, or inside it above the hero), how the emblem art and the words are
drawn at this width, what the empty and "no opening at all" states look like, and whether the
owner preview shows it differently from a recipient.
If it does not belong, say so, and say what the owner is meant to use to check the opening
before publishing. Today the answer would be "open the browser page", and that should be a
stated design answer rather than a gap.Why these are asked as questions rather than as instructions
Two of the three are things the design appears to have decided against. A prompt that says "add an auto-advancing carousel" would get one, and nobody would ever find out whether its absence had been a judgement. The design is the source of truth for this surface, so the honest ask is for a decision with its reasoning, which is also what a later reader needs.
⚠ The zoom question is the one that must not be answered casually. It is the only one of the three with a disclosure consequence: the 720px derivative is a privacy control, and a magnifier is the natural way to defeat it. That is why the question is posed per tier.