syntaxbullet/image-studio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: refine candidate handling in generation commands and update UI interactions

Browse Source
This commit is contained in:
syntaxbullet
2026-07-09 22:00:23 +02:00
parent 317a7bbf5f
commit 41bbd1e16b
5 changed files with 73 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/audits/2026-07-09-product-ux-architecture-audit.md
View File

@@ -107,22 +107,28 @@ These surfaces do not form a legible sequence. “Generate” is closer to a wor
Redesign implication: generation should open an operation workspace with a clear input stage and a result stage. The active canvas interaction inside that workspace can still be select, pan, paint-mask, or transform.
### P1 — accepting one candidate destroys the entire candidate session
### P1 — accepting one candidate destroys the entire candidate session — resolved 2026-07-09
Both “accept as layer” and “replace pixels” call `clearCommittedGenerationPreview`, which clears all candidates, not only the accepted candidate. This conflicts with the core use case of combining multiple model outputs. A user who generates several alternatives and accepts one loses the remaining comparison set.
Redesign implication: accepting a candidate should mark or remove only that candidate by default. The result tray should support keeping, pinning, multi-selecting, and clearing the session explicitly.
### P1 — up to twelve candidates are stored but only six are selectable
Resolution: both layer acceptance and masked-pixel replacement now remove only the committed candidate, select the nearest remaining candidate, and preserve the active comparison mode while results remain.
### P1 — up to twelve candidates are stored but only six are selectable — resolved 2026-07-09
Generation state retains twelve candidates, while `CandidatePicker` renders only `candidates.slice(0, 6)`. Candidates seven through twelve have no visible selection path. This is a concrete interaction bug, not merely a styling concern.
### P1 — “variant” is only a renamed ordinary layer
Resolution: the picker now renders the complete bounded candidate set in a horizontally scrollable group.
### P1 — “variant” is only a renamed ordinary layer — resolved 2026-07-09
“Accept variant” creates a standard top-level layer and records `variant-layer` provenance. There is no document-level variant set, linked source, stack semantics, exclusive visibility, or comparison group. The label promises more structure than the product provides.
Redesign implication: either call this “Add as another layer” or introduce a real variant/result-set concept. A result tray can provide variant semantics without forcing them into the document tree prematurely.
Resolution: the duplicate variant action and `variant-layer` provenance value were removed. The UI now describes the real operation as “Add as layer”; refinement layers use the same honest layer acceptance semantics.
### P1 — generation preconditions are not represented clearly
The Generate button only requires a non-empty prompt. Image-to-image can proceed without a selected source image. Inpaint configuration is available without explaining or enforcing the required source layer and mask. Outpaint and mode-specific settings coexist regardless of current mode.