# Refined Mockups — Questions > Fill in each `[Answer]:` tag. Options A-E plus X (Other). The file is the > authoritative record of your UX design decisions. ## Q1: Authoring entry point How do you want to drive the newspaper generation? A) A single command run (e.g. `newspaper generate`) that reads a config + content folder and emits `newspaper.html` — CLI-first (recommended) B) A local browser page that picks content and generates live (no shell, all in-browser) C) Both — a small CLI plus an optional browser "generate" page X) Other (please specify) [Answer]: A ## Q2: Content & metadata input shape How should you provide content and dynamic issue metadata (masthead title, couple names, date, volume)? A) A `content/` folder of markdown/txt files plus a small `config.json`/front-matter holding masthead metadata (recommended) B) One markdown "issue file" that contains everything (articles + metadata front-matter) in a single document C) Paste text into the browser page, metadata typed in a small form X) Other (please specify) [Answer]: A ## Q3: AI per-article review surface Your stories call for a whole-first-pass AI draft then per-article human review (US9). How should that review be surfaced? A) After the AI draft, emit a review page/step listing every article with approve / edit / replace controls per article before final render (recommended) B) Emit a single editable draft markdown file the couple edits directly, then re-render C) A CLI prompt loop: for each article, ask approve / edit / replace in the terminal X) Other (please specify) [Answer]: A ## Q4: Print preview Do you want a print-preview step to see how the pages break before printing? A) Yes — a browser "preview + print" page showing the whole newspaper with a Print button (recommended) B) No — generate straight to the printable HTML and print it directly C) Preview only in the same generated page; the couple opens it and prints X) Other (please specify) [Answer]: B ## Q5: Funnies input format For crosswords / find-a-word / comics: how should you supply the source so the generator can build the fun section? A) Structured data (JSON) per puzzle — grid words + clues for crossword, word list for find-a-word; comics as image files + dialogue (recommended) B) Natural-language markdown describing the fun items, AI turns it into a puzzle C) Both — structured for puzzles, markdown for describing comics X) Other (please specify) [Answer]: X - I want you to generate it from the content. the content will build the articles and the funnies and provide the context for what cartoons to search for and try to insert ## Q6: Accessibility level for the generated page What accessibility target should the generated newspaper page meet? A) WCAG 2.1 AA — semantic HTML, heading hierarchy, alt text on images, keyboard-operable where interactive (recommended) B) Practical baseline — valid semantic HTML + alt text + readable contrast, without a formal WCAG pass C) No formal accessibility requirement — this is primarily a printed keepsake X) Other (please specify) [Answer]: C ## Q7: Empty / first-run experience When the couple opens the generator with no content yet, what should they see? A) A friendly guided empty state: short message + a pointer to the content folder / config, plus a small sample issue they can generate to see the layout (recommended) B) A friendly empty state with guidance only (no auto sample) C) Just generate a stub page so they see the masthead/layout structure X) Other (please specify) [Answer]: A ## Consolidated Summary Confirmation > Summary of your seven design answers before the mockup artifacts are generated: > > - Authoring entry: **CLI-first** — a single `newspaper generate` command reads a config + content folder and emits `newspaper.html` (Q1=A) > - Content/metadata input: **`content/` folder of markdown/txt + a small `config.json`** (or front-matter) holding masthead metadata (Q2=A) > - AI per-article review: **a review page/step** listing every article with approve / edit / replace controls per article before final render (Q3=A) > - Print preview: **no separate preview step** — generate straight to the printable HTML (Q4=B) > - Funnies input: **generated from the content itself** — the content builds the articles AND the funnies, and provides the context used to search for / insert cartoons (Q5=X) > - Accessibility: **no formal WCAG requirement** — primarily a printed keepsake (Q6=C) > - First-run: **friendly guided empty state** with a pointer to content/config plus a small sample issue (Q7=A) Does this all look correct before I generate the mockup artifacts? - Looks correct - Request changes [Answer]: Looks correct