The homepage now does two connected jobs: it explains the project and hosts the working board editor. That placement is deliberate. Someone arriving with a few photos should be able to understand the format, test the controls, and decide whether the result is useful without registering or following a second “launch app” link.
Removing an unnecessary decision
An earlier structure separated the introduction from the tool. Visitors first saw a landing page, then had to choose a route before they could find out what the editor actually did. For a focused, single-purpose tool, that step did not add safety or clarity; it only postponed the useful part.
The current sequence is more direct:
- Read a short explanation of the fan-made format.
- Use the real editor in the first section.
- Continue to instructions, privacy details, and related articles if more context is needed.
This also makes claims easier to verify. When the page says that photos can be arranged, fonts changed, or a JPG downloaded, the corresponding control is visible nearby.
Keeping photo work local
The embedded editor is a React component inside an Astro page. When a visitor selects a photo, the component reads that file through browser APIs and uses an HTML canvas for the board and export. The normal editing path does not send the selected photos to an application server or create an online gallery.
That local-first approach is especially appropriate here. Personal boards may contain family pictures that do not belong in an unnecessary upload pipeline. It also means there is no account, server-side project history, or recovery mechanism: refreshing or closing the page can discard the working board, so visitors should keep their original photos and save the downloaded JPG.
Google Analytics is handled separately from the editor. It measures site usage, but selected photos and generated boards are not included in Analytics events.
What the page explains below the editor
Putting a tool first should not mean hiding important context. The supporting sections answer four questions a new visitor is likely to have:
- What scene inspired this format?
- How do I add, arrange, and export photos?
- What can I do to improve the crop and readability?
- What happens to the images I select?
The page also repeats the independent fan-made status and links to the Privacy Policy, Terms, About page, and contact method. Those details help visitors evaluate the project rather than asking them to trust a bare upload control.
Designing around the working surface
The editor is large, interactive, and more demanding than ordinary article content. Embedding it on the homepage means the surrounding page has to stay quiet: the main action cannot be disguised as an advertisement, and unrelated promotional blocks should not crowd the upload, shuffle, clear, or download controls.
On smaller screens, the instructions remain available after the tool instead of competing with the canvas. Keyboard labels and visible button text provide alternatives to icon-only guessing. The board itself remains a visual experience, but the page explains the workflow in regular text.
How we check future changes
When a feature is added, the homepage copy should be updated only after the control exists. A useful release check includes:
- adding and replacing one photo;
- dragging photos between filled and empty frames;
- changing template, subject, typeface, and signature;
- shuffling and clearing the board;
- downloading a JPG and opening the result;
- confirming that Analytics never receives selected photos or generated boards;
- checking the flow at both phone and desktop widths.
Keeping the editor on the homepage is not just a layout choice. It is a promise that the site’s main purpose is available immediately, that the explanation matches the product, and that visitors can make a board without handing over an account or a server-side copy of their photos.