Review: five possible next improvements
· Australia/Sydney
Run: 2026-10-16-five-proposals · observation · proposed · pending
Owner decision and scope
The owner explicitly requested up to five proposals per review; at most one improvement may still be implemented per run. Recorded this human intervention in AGENTS.md and the manual runbook. Publication permissions are unchanged. This entry offers alternatives, not a five-feature implementation plan. No source pages changed, server started, screenshot captured or deployment made in this review.
Direct evidence: inspected the current homepage, journal templates, collection schema, recent entries and Git history. There are no visitor observations or analytics. The original brief continues to govern; this owner decision updates only proposal breadth.
1. Remove the stale Day 0 label from the browser title — recommended
- Problem/evidence: the current homepage still has the title “The Evolving Website — Day 0” after two implemented experiments. The original baseline is already preserved in Git. W3C H25, accessed 16 October 2026, explains the orientation value of a descriptive document title. It does not establish a WCAG failure here.
- Proposal/hypothesis: change only the current homepage title to “The Evolving Website”, with the matching smoke expectation. Category: technical/editorial accuracy correction, pending verification. Expected benefit: a stable browser-tab title that does not label the evolving page as its starting version.
- Acceptance: one correct title, build and smoke checks pass, homepage screenshots remain identical to the journal-link candidate. No body text changes.
- Trade-off: removes the historical cue from the current tab; it remains in the baseline journal and Git tags.
- Reversal: restore the previous title and test expectation if the owner deliberately prefers that label or a regression appears.
- Outcome: pending; no implementation checks performed.
2. Give same-day journal entries a reliable sequence
- Problem/evidence: the journal sorts same-date entries alphabetically by ID, placing the journal-link experiment before the main-landmark experiment although Git records the reverse implementation order.
- Proposal/hypothesis: add an explicit within-day sequence field and sort consistently, using documented Git history for existing entries rather than inventing times. Category: technical history correction. Expected benefit: the displayed sequence matches the recorded evolution.
- Acceptance: baseline, landmark, link and later reviews appear in documented order; duplicate sequence values for a date are rejected; build and a focused ordering check pass. State the chosen oldest-first order visibly. Scope is order only, not a timeline redesign.
- Trade-off: one additional metadata field to maintain. Actual dates must remain unchanged. Do not infer exact creation timestamps from this sequence.
- Reversal: revert ordering/schema changes if they misrepresent the history; retain the proposal and explain the uncertainty.
- Outcome: pending; direct repository evidence only, no visitor result claimed.
3. Explain journal statuses in one sentence
- Problem/evidence: the index shows “implemented” without explaining that implementation is local and publication is separate. None of the candidates has been deployed.
- Proposal/hypothesis: add a concise plain-text status explanation to the journal index: proposed means planned, implemented means changed locally, and released means published. Category: experiential comprehension hypothesis. Expected benefit: less chance of confusing a local experiment with a public release.
- Acceptance: definitions match the recorded workflow and actual state, existing links work, desktop/mobile journal captures remain readable without overflow. Do not claim a release exists.
- Trade-off: another explanatory sentence on a minimal page, without evidence that visitors are confused.
- Reversal: remove if review finds it redundant or misleading.
- Outcome: pending; comprehension requires qualitative review, not just a passing build.
4. Put Day 0 screenshot links on the journal index
- Problem/evidence: baseline screenshot links are inside the long baseline entry. The owner has found screenshot review useful in chat, but that is one owner’s observation, not general visitor evidence.
- Proposal/hypothesis: add two plain descriptive links, “Day 0 desktop screenshot” and “Day 0 mobile screenshot”, on the index. Category: experiential discoverability hypothesis. Expected benefit: a shorter path to seeing the starting appearance. W3C G91, accessed 16 October 2026, supports descriptive link labels, not measured demand for these links.
- Acceptance: both actual PNGs open successfully via keyboard and mouse; labels distinguish viewport and baseline; journal screenshots show ordinary document flow without overflow. No thumbnail gallery or image downloads are added.
- Trade-off: two more links and possible duplication of the baseline entry.
- Reversal: remove index links if the extra clutter outweighs the shortcut; preserve the original files and entry links.
- Outcome: pending; no visitor discovery measurement exists.
5. Show the outcome verdict beside each journal entry
- Problem/evidence: frontmatter and entry pages distinguish “verified”, “inconclusive” and “pending”, but the index shows only implementation status. The journal-link experiment is implemented yet its visitor-benefit hypothesis remains inconclusive.
- Proposal/hypothesis: display the existing verdict beside each index status as plain labelled text, with a short explanation that local verification does not prove visitor benefit. Category: transparency/comprehension hypothesis. Expected benefit: readers can distinguish a completed change from evidence of benefit before opening the entry.
- Acceptance: values exactly match frontmatter; verified technical outcomes and unmeasured experiential results are not conflated; no invented confidence score, new assessment or dashboard; desktop/mobile rendering and links pass.
- Trade-off: more metadata per row; may be redundant with status definitions. Evaluate independently rather than automatically combining with proposal 3.
- Reversal: remove the added display if review finds it confusing; keep the underlying verdicts.
- Outcome: pending; interpretation needs human review.
Recommendation and next step
Select proposal 1 for the next implementation run because it repairs a concrete stale label with the smallest scope. Proposal 2 is the next strongest repository-supported issue. The remaining three are experiential options, with no measured visitor benefit. Record the selected hypothesis before implementation; do not implement all five together. No change remains valid.
No candidate screenshots or deployment references exist for these proposals. The parent source is the journal-link implementation on the preceding branch; this review’s exact commit is available through Git after committing. Preserve earlier entries and their uncertainty.