53 lines
8.3 KiB
Markdown
53 lines
8.3 KiB
Markdown
# Page mockups and visual materials
|
|
|
|
Reuse the user's settled template, theme, route and page workflow. Receive the current page's title/message, evidence, content groups and notes through [content handoff](content-handoff.md), then define its layout, asset roles and required native objects before generating its mockup. Establish a minimal page brief if none is supplied. Follow the confirmed [execution choices](execution-and-review.md), including ImageGen scope/budget and selected alternatives. Review only consequential decisions that remain open; do not restart settled outline, style or tool choices. A request to review one page does not authorize a full-deck generation run.
|
|
|
|
When extracting style from an existing presentation or PDF, render representative pages and inspect the actual images. XML/object counts alone cannot establish density, hierarchy, ornament or spacing. Keep style references separate from strict source assets. Use existing accepted references; a rejected mockup does not remain a design baseline.
|
|
|
|
## Rough layouts and confirmed preferences
|
|
|
|
For page-by-page work with ImageGen enabled, use an actual visual or actual render from the selected template and theme as the reference. Inspect it before generation. Make a rough layout with the main content elements approximately in their intended regions, retaining the fixed page UI as a reference; focus on grouping, hierarchy, reading order and the contribution-to-evidence relationship. Do not spend the layout-draft budget on fine detail or claim pixel correspondence with the final PPT.
|
|
|
|
Let the user review the current layout at the agreed granularity, incorporate feedback, then implement the authorized page. Later authorized pages reuse the confirmed ImageGen choice and budget; seeing each new layout is page review, not a repeated permission question. If ImageGen is declined or unavailable, use only the user's selected alternative or resolve that pending choice before dependent work. Do not silently switch to another generator, Agent arrangement or text-only plan.
|
|
|
|
Record confirmed feedback in existing project/page notes or review material: the preference, user confirmation, applicable page/report scope and reference image/source revision. Reuse it within that scope on subsequent authorized pages. A local change does not become a global rule; an ongoing preference needs explicit support. Do not create another preference database or write global memory. Keep rejected drafts distinguishable from accepted references.
|
|
|
|
The template/shared recipe owns final geometry, typography, fixed spacing and UI. Rough positions in the draft cannot override those contracts. Rebuild the actual page with supported native objects and check its reading order, capacity and visual evidence associations. Draft feedback does not establish final native rendering, editing or projection acceptance. Follow [review after revision](execution-and-review.md#review-after-revision) for the agreed independent check of substantive changes.
|
|
|
|
## Page composition and HTML boundary
|
|
|
|
Every title, text, formula, label, visualization and meaningful decorative group must serve the page task and, through it, the section and report goals. Choose their arrangement from the current information relationship. Pure text can serve a short question, quotation or conclusion; a picture or icon needs a useful role. Do not mechanically reuse website hero sections, selling cards or dashboards as report layouts. The page's main meaning must be readable without scrolling, hovering or clicking.
|
|
|
|
Make conclusions and their supporting evidence visibly correspond through proximity, a shared heading, matching labels, annotations, highlighting or a necessary connector. Use only connections that express real relationships. Preserve exact premises and key reasoning/derivation steps where the audience needs them; check progression and information burden in the actual composition. Internal item counts, maintenance IDs and authoring decisions stay in process material unless the audience needs them for the report itself.
|
|
|
|
Do not use HTML/DOM/CSS to lay out report pages, including layouts later captured as screenshots, printed or converted to another format. HTML may contain a JavaScript visualization itself and its necessary runtime container. This exception does not cover surrounding titles, prose, columns or page UI; produce those through the permitted native/SVG route. A direct SVG diagram is allowed. Keep the selected route's editability claims accurate for any visualization asset.
|
|
|
|
## Mockup prompt inputs
|
|
|
|
For a requested raster page sample within the confirmed ImageGen scope, use the host image-generation tool directly. Supply:
|
|
|
|
- The selected canvas/aspect ratio, template palette, typography intent, grid and fixed content regions.
|
|
- The exact current-page text and moderate content density, with a declared hierarchy and clear content division.
|
|
- The intended page progression, necessary premises or key steps, and the association between conclusions and evidence.
|
|
- Approved representative images as style references, with the current layout allowed to differ.
|
|
- Supplied logos, figures and screenshots as strict identity/evidence assets. Preserve values, axes, labels, proportions and scientific meaning; do not synthesize substitute evidence.
|
|
- The editable reconstruction plan: decorative pictures may remain assets, while title/body, controls, separators and diagrams must later become independent native objects as required.
|
|
|
|
Inspect local reference images using the available image-viewing tool before editing or conditioning on them. Label each input's role in the prompt. Save prompt, tool result, source attribution and review status under the project. Show the current sample for the user's requested review and incorporate concrete corrections before native reconstruction.
|
|
|
|
Use generated text only as visual guidance. Native source text comes from verified content, with the template's declared fonts and sizes; do not copy misspellings or typography defects from the raster sample. Preserve original evidence/identity assets independently so the final native page can use those files exactly.
|
|
|
|
Native paragraph lines must satisfy [punctuation and singleton rules](text-and-containers.md#paragraph-line-breaking-rules). Do not preserve a mockup's forbidden line-head/tail punctuation or a row containing only one character with optional punctuation; reflow the complete paragraph within the declared layout.
|
|
|
|
## Material generation and transparent assets
|
|
|
|
For new bitmap illustrations, photos, textures or image edits, use the selected host image-generation capability. Request a transparent background when the final asset needs transparency. Preserve transparency on edits unless the user asks to change it. Use reference-image paths when all targets have paths, otherwise the smallest supported recent-image set that includes every target; do not silently omit a required target.
|
|
|
|
Ask for complete separated objects with consistent perspective, stroke and illumination. A material sheet can contain several non-overlapping assets with clear outer padding, but verify identity/count and edges after separation. Keep logos and strict evidence originals; generated approximations need explicit permission for that role. Repair small occlusions locally rather than redesigning an entire source background.
|
|
|
|
Check transparent edges against both light and dark backgrounds for halos, missing thin strokes and unintended holes. Avoid arbitrary color-key removal that erases matching subject colors. If an approved layered source or role mask exists, retain it with a clear mask-to-material contract; otherwise regenerate an unsuitable cutout through the image tool.
|
|
|
|
For an existing SVG icon system, use its vector source and declared paint contract rather than generating a new bitmap. Multiple independent color roles need stable element IDs and per-channel rules. Palette binding, fixed details, structural `none` and unlisted paint remain distinct. See [icon handoff](authoring-handoff.md#icon-material-handoff).
|
|
|
|
For all new icon sources use [icon production](icon-production.md): reuse, simple authored vectors, complex generated materials, then external supplements. Every route finishes with compliant adjustable parts; raw generated or downloaded rasters are production inputs. Apply the source and evidence requirements in [production rules](production-rules.md).
|