Proposal: card layout presets and "save as preset" #422

Activity

1. rowkav09

   added

   enhancementNew feature or requestNew feature or request

   area:cards

   on Sep 24, 2026
2. github-project-automation

   added this to nowplayingon Sep 24, 2026
3. github-project-automation

   moved this to Backlog in nowplayingon Sep 24, 2026
4. github-actions

   added

   area:artwork

   area:server

   on Sep 24, 2026
5. rowkav09

   added

   questionFurther information is requestedFurther information is requested

   and removed

   area:artwork

   on Sep 24, 2026
6. rowkav09 commented on Sep 27, 2026

   

   rowkav09

   on Sep 27, 2026

   MemberAuthor

   More actions

   Design response (proposal only; no build or product decision recorded):

   The current Card editor already has a live preview and saves a validated card object to config.json (src/settings-page-handler.js, src/app-settings.js, src/setup-config.js). The hosted link already derives its appearance query from the saved card, except artwork-specific fields. Existing test/card-visual.test.js entries are renderer test cases, not selectable named presets; naming them as though they were a product feature would be misleading.

   Suggested first slice: a small immutable list of built-in presets in the Card editor, with distinct names and deliberate complete card values (theme, width, progress and layout) that normalizeCard validates. Picking one fills the controls and immediately refreshes the preview; it does not persist until the existing Save button is pressed. If the user edits a control afterward, show "Custom" rather than claiming the named preset still matches. Reset retains its existing meaning. Preserve accessibility and the renderer's narrow-width/artwork clamping, not hardcoded preview images. Add one visual regression fixture per shipped built-in using the actual renderer plus a UI test for select -> preview -> Save and edit -> Custom. Keep the first built-in set small; "Default" and "Centred" are grounded in existing renderer states, while "Minimal" and "Wide with big artwork" need actual pixel review at narrow widths before their exact settings/names are chosen.

   User-saved presets need an explicit product call. If Rowan wants them, store a bounded map/list of {id, name, card} data alongside card in the versioned config, not as a string reference that changes what a saved card means when a preset is renamed/deleted. Validate the stored card with the same normalizeCard rules as active card settings, with a name length/count cap, unique case-insensitive names, reserved built-in IDs, and no arbitrary URL/script fields. A preset snapshot is local-only; editing or deleting one must not silently change the active card. Config currently rejects unknown top-level fields and is version 2, so add an explicit migration with backup and failure handling, not an unvalidated extra key or a write that drops server/Spotify/hosted settings. Decide whether user presets can be renamed/deleted and how name conflicts are shown before implementation.

   Hosted link choice: my recommendation is that Save continues to update the generated hosted link from the same saved card values (as it does today), filtering artwork-specific fields; merely previewing a preset does not change the link. Do not add a preset= URL query or send local preset names to the hosted service. Existing copied links are snapshots of their query values and will not magically update after a later local Save; tell the user to copy the new link. If Rowan instead wants presets local-only, that is a behavior change worth deciding explicitly.

   The three owner choices to settle before build are: (1) built-ins only or built-ins plus user-saved presets; (2) whether saved presets follow today's hosted-link behavior as recommended; (3) the exact built-in set and names after visual review. The existing issue marks these as open; this comment does not choose for Rowan. No code changed.