Decision: Person Info sheet scope + document source #9

Closed
opened 2026-07-23 14:46:25 +02:00 by cloudbot · 1 comment
Collaborator

Decision — Person Info sheet scope, and where its documents come from.

Tapping a member's avatar on the Log tab opens their Info sheet. The prototype defines the shape; the open question is the data source.

Sheet shape (from the prototype)

  • Title 🪪 {Name} — Info; header has an Edit / Done toggle.
  • Top: document thumbnails (88px tiles) → tap opens a lightbox (dimmed overlay, rounded image, Close).
  • Fields are read-only until Edit is toggled; then the same field renderers + a Save footer appear (the fields come from the ## Info metadata table — see #1).

Doc icon as the quick-ref avatar (finding, 23 Jul 2026)

documents.info returns an icon field on every document, so the app can read each person note's icon. In practice all four notes already use a custom uploaded image as their icon (Ben 27f8e4f0…, Ari cc614e6a…, Ada a23d005f… — bare UUIDs, color: null), not an emoji. That's a ready-made per-person avatar source, better than the hardcoded avatarEmoji in the member config.

Catch: custom doc icons are not served through the public attachments.redirect?id=… endpoint (verified — that fetch fails for an icon UUID), so rendering one needs Outline's icon/file URL path, and it needs confirming a member's own API key can fetch it. Small spike required — read how document icons are stored/served in the Outline source: https://github.com/outline/outline. (Emoji icons, by contrast, render for free as the literal glyph.)

The open question: where do the "documents" (thumbnails) come from?

The most likely source is attachments on each member's canonical Outline note — Nathalie's note is already attachments-only (passport/licence/ID scans), which fits. Options:

  1. Attachments on the canonical note — enumerate the note's attachments via the Outline API, thumbnail them. Simple, one source of truth, but mixes app-managed and ad-hoc attachments.
  2. A dedicated documents area (sub-collection or separate doc per member) — cleaner separation, but more structure to maintain and set up.

This determines both the L3 (Person Info) data source and how the metadata parser (#1) locates a member's structured data vs their document scans.

What to decide

  1. Confirm the Info-sheet scope (read-only view + Edit-to-save, doc thumbnails + lightbox).
  2. Choose the document source (attachments on the canonical note vs a dedicated area).
  3. Use the note's Outline doc icon as the quick-ref avatar (pending the icon-URL spike above), or keep the hardcoded avatarEmoji?

Blocks: the Person Info sheet (L3) and its coupling to the metadata parser (#1) and attachment mechanics (#11).

Recommendation: use attachments on the canonical note as the document source — it matches how the notes are already used (esp. Nathalie's), keeps one document per person, and avoids inventing new structure. Reconsider only if mixing app scans with ad-hoc attachments proves messy in practice.

Source: Solution Design — Family App v1 §4 (doc vpBNbG4TsV); prototype design/Family App.dc.html; skills/design-system/SKILL.md (Person Info sheet).

**Decision — Person Info sheet scope, and where its documents come from.** Tapping a member's avatar on the Log tab opens their **Info sheet**. The prototype defines the *shape*; the open question is the **data source**. ### Sheet shape (from the prototype) - Title `🪪 {Name} — Info`; header has an **Edit / Done** toggle. - Top: **document thumbnails** (88px tiles) → tap opens a **lightbox** (dimmed overlay, rounded image, Close). - Fields are **read-only** until Edit is toggled; then the same field renderers + a **Save** footer appear (the fields come from the `## Info` metadata table — see #1). ### Doc icon as the quick-ref avatar (finding, 23 Jul 2026) `documents.info` returns an `icon` field on every document, so the app can read each person note's icon. In practice **all four notes already use a custom uploaded image** as their icon (Ben `27f8e4f0…`, Ari `cc614e6a…`, Ada `a23d005f…` — bare UUIDs, `color: null`), not an emoji. That's a ready-made per-person avatar source, better than the hardcoded `avatarEmoji` in the member config. Catch: custom doc icons are **not** served through the public `attachments.redirect?id=…` endpoint (verified — that fetch fails for an icon UUID), so rendering one needs Outline's icon/file URL path, and it needs confirming a member's own API key can fetch it. **Small spike required** — read how document icons are stored/served in the Outline source: https://github.com/outline/outline. (Emoji icons, by contrast, render for free as the literal glyph.) ### The open question: where do the "documents" (thumbnails) come from? The most likely source is **attachments on each member's canonical Outline note** — Nathalie's note is already attachments-only (passport/licence/ID scans), which fits. Options: 1. **Attachments on the canonical note** — enumerate the note's attachments via the Outline API, thumbnail them. Simple, one source of truth, but mixes app-managed and ad-hoc attachments. 2. **A dedicated documents area** (sub-collection or separate doc per member) — cleaner separation, but more structure to maintain and set up. This determines both the L3 (Person Info) data source and how the metadata parser (#1) locates a member's structured data vs their document scans. ### What to decide 1. Confirm the Info-sheet scope (read-only view + Edit-to-save, doc thumbnails + lightbox). 2. Choose the document source (attachments on the canonical note vs a dedicated area). 3. Use the note's Outline doc icon as the quick-ref avatar (pending the icon-URL spike above), or keep the hardcoded `avatarEmoji`? **Blocks:** the Person Info sheet (L3) and its coupling to the metadata parser (#1) and attachment mechanics (#11). **Recommendation:** use **attachments on the canonical note** as the document source — it matches how the notes are already used (esp. Nathalie's), keeps one document per person, and avoids inventing new structure. Reconsider only if mixing app scans with ad-hoc attachments proves messy in practice. **Source:** Solution Design — Family App v1 §4 ([doc vpBNbG4TsV](https://outline.marquezkeenan.family/doc/solution-design-family-app-v1-vpBNbG4TsV)); prototype `design/Family App.dc.html`; `skills/design-system/SKILL.md` (Person Info sheet).
Owner

Present all image attachments as a 3-wide grid of square thumbnails in the order they appear in the doc. Tapping on one brings the image up full-screen, fitting into the screen in the largest way possible, rotating if necessary.

For defining the source of the docs, I am inclined to create a single note in Outline that serves to present the structure of the data, e.g. we hardcode a single Outline doc, which includes a bulleted list of Person notes, and in time could be a primary source for other kinds of data.

Present all image attachments as a 3-wide grid of square thumbnails in the order they appear in the doc. Tapping on one brings the image up full-screen, fitting into the screen in the largest way possible, rotating if necessary. For defining the source of the docs, I am inclined to create a single note in Outline that serves to present the structure of the data, e.g. we hardcode a single Outline doc, which includes a bulleted list of Person notes, and in time could be a primary source for other kinds of data.
ben closed this issue 2026-07-23 17:49:08 +02:00
Sign in to join this conversation.
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#32 Person Info sheet
utilities/Logbook
Reference
utilities/Logbook#9
No description provided.