Component pages: the Files section is a wall of generated pipeline artifacts drowning the actual CAD files

by adom

How the Adom Wiki (wiki.adom.inc) works and how to drive it with the adom-wiki CLI: the two storage layers (git page repo vs package registry), hosting source by pushing files (not a tarball), making packages, cutting per-platform releases, and the three-tier skill layout (user skills ship, dev-skills/ and publish-skills/ stay source-only). adom-wiki is the current tool; adompkg is deprecated. Read this first before publishing or installing.

Overview Files Skills Discover Packages Releases Dependencies Issues8 Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 2mo ago ·closed by Colby Knox

Second component-page presentation ask from Colby, companion to the hero issue (adom/wiki#271-global).

On a typical molecule page (example: the IN-S42ATR component), the Files grid renders every repo file as an equal-weight card. The files a visitor actually came for are about five: the GLB(s), STEP, .kicad_mod, .kicad_sym. Below them sit thirty-plus generated artifacts of the render pipeline, all styled identically:

3D iso renders in six orientations, each in full and -icon variants (*-3d-iso*.png, ~14 cards)
outline SVGs in bold/dark/blueprint, each in named/named90/plain variants (*-outline-*.svg, ~12 cards)
viewer plumbing: adom-3d-viewer.min.js, *-thumbs.json, *-tooltips.json
hero variants (hero.png, hero-1920x1200.png)

Nothing is wrong with the files existing; the pipeline needs them. The problem is presentation: the signal-to-noise of the section is roughly 5:30, and the one thing every card shares is looking equally important.

Suggestions, composable:

Type-aware primary section for components: CAD artifacts first (GLB/STEP/footprint/symbol -- the current type detection already labels them correctly, so the grouping info exists), then README/docs, then everything else collapsed.
Collapse generated families into one card each: "3D renders (14)", "Outline SVGs (12)", expandable. The naming is regular enough to group by pattern (*-3d-iso*, *-outline-*), or the render pipeline could emit a manifest naming its outputs so the grouping is declared rather than inferred.
Viewer plumbing should probably not be listed as user files at all (adom-3d-viewer.min.js, thumbs/tooltips JSON) -- they are implementation detail of the 3D viewer, not content anyone downloads.
If a display manifest route is chosen, page.json could carry a files_display block (pin/hide/group) so any page type can curate, with the component defaults above applied when absent.

Suggestion 2 or the 1+3 combination alone would take the section from a wall to a shelf. Ties into #271: between the hero never rendering and the Files wall, component pages currently bury exactly the media that makes a part page legible at a glance.

1 Reply

Colby Knox · 2mo ago

Shipped to prod, the composed 1+2+3 version:

Design files first: GLB, STEP, footprint, symbol, datasheet render as full cards, nothing else competes with them.
Generated families collapse to one expandable row each: "3D renders (N)", "Outline SVGs (N)", "Hero images (N)", "Viewer plumbing (N)", pattern-grouped on the pipeline's regular naming. Expanding a row shows the same cards as before, so nothing is hidden, just shelved.
Viewer plumbing stays listed but lives in its own collapsed row rather than posing as content.
Image, PDF, SVG, and HTML cards now open in the browser instead of forcing a download (SVG and HTML stay CSP-sandboxed).

On your IN-S42ATR example the section goes from ~34 equal cards to 4 cards plus 4 collapsed rows. The files_display manifest idea (your suggestion 4) I left out for now: the pattern grouping covered the real pages without new schema, and a declared block can layer on later if a page needs curation the conventions cannot express. Closing.