Een scherm herontwerpen

Een scherm werkt, maar gebruikers vinden het onduidelijk, of het ziet er te braaf uit. Je wil eerst een nieuw ontwerp, en pas daarna bouwen. Spexso brengt de feedback en schermafbeeldingen van vandaag samen in een redesign-issue. Daarna bouw je het ontwerp met echte UI5 in een prototype, en dat prototype laad je in de spec. Vanaf dan bouwen /spexso-start of de factory het zoals elke andere issue.

/spexso-redesign 59  →  redesign-issue  →  /spexso-prototype 74  →  /spexso-brainstorm 74 --design docs/design/issue-74  →  bouwen
                        (label redesign)    (echte UI5, PNG's)       (spec + UI-contract, map op main, label weg)           (start / factory)

1. Het redesign aanvragen

/spexso-redesign 59

• Spexso leest de spec en de discussie van #59 (npx spexso issue comments 59): de opmerkingen van testers na de checklist, en review-notes.
• Het vraagt één keer welke feedback van gebruikers het redesign moet beantwoorden. Plak opmerkingen, of zeg wie je het moet vragen.
• Het start de app (spexso demo-env, zoals /spexso-demo), doorloopt het demoscenario met Playwright en maakt van elk scherm een screenshot.
• Het maakt de issue redesign: <scherm> aan, met type::enhancement, stage::opportunity, het label redesign en dezelfde milestone als #59. Die issue bevat:
  • wat het scherm moet doen: doel per scherm, welke data in welke vorm, welke acties. Bewust zonder de layout van vandaag, zodat het nieuwe ontwerp er niet op blijft hangen;
  • de feedback van gebruikers, in hun eigen woorden;
  • de huidige schermen als screenshots;
  • de randvoorwaarden: Fiori en Horizon, Fiori Elements of freestyle, een control per vorm van data (ux.md §5b);
  • een prototype brief: per scherm het doel, de vorm van de data en uit welke entiteiten ze komt, de toestanden en dialogen die je wil zien, en de voorgestelde UI5-control per vlak.

Het label redesign is de poort. De marathon, de factory en auto-pick slaan zo'n issue over. Bovendien staat het in stage::opportunity, dus geen enkele picker neemt het al mee.

2. Het prototype bouwen

/spexso-prototype 74

Een getekende mock-up verbergt hoe de controls zich echt gedragen: een TreeTable zet de inspringing in zijn eerste kolom, een ColumnLayout-formulier aanvaardt geen HBox, een StepInput toont 1825 als 1.825. Het canvas van Claude Design kan UI5 zelfs niet laden. Daarom bouwt Spexso het ontwerp met echte UI5, in docs/design/issue-74/. De route volgt uit de manifest.json van de app:

• Freestyle: een mock-app met XML-views en fragments, Horizon, en een momentopname van je seed-data (db/data/*.csv → data.json). Elk scherm en elke dialoog is een URL (?screen=2&open=edit), dus de screenshots zijn reproduceerbaar en er is geen backend nodig.
• Fiori Elements: een spike op de echte app, in een wegwerp-worktree met een eigen npm ci. Alleen de annotaties en de manifest-instellingen veranderen; de app draait met cds serve --with-mocks --in-memory. Wat Fiori Elements niet kan zoals de brief vraagt (een icoon kiezen uit een preview, een telling als header-kengetal, …, zie ux.md §3b), wordt een bevinding met een beslissing: een building block, een custom section, of het dichtstbijzijnde floorplan-patroon. De map bewaart spike.diff en de README.

Spexso maakt van elk scherm een screenshot op 1440×900 (in .spexso/demo-artifacts/issue-74/design/, niet gecommit), bekijkt ze zelf, en toont ze je met de bevindingen. Je keurt goed of vraagt wijzigingen; dat herhaalt zich tot het ontwerp goedgekeurd is. De valkuilen die het onderweg vermijdt (headless-budget, verse browserprofielen, dummy-auth, geen deeplink naar een draft) staan in het rulebook prototype.md.

3. Het ontwerp in de spec laden

/spexso-brainstorm 74 --design docs/design/issue-74

• Brainstorm neemt de exacte controlnamen uit de views en fragments (freestyle) of de annotaties uit spike.diff (Fiori Elements). Wat je tijdens de prototyperondes al besliste, vraagt het niet opnieuw.
• Die koppeling wordt de UI-tabel van de spec, en dus het UI:-contract: de planner neemt het over, de builder bouwt het en de reviewer controleert het. Ontbreekt een afgesproken control of is hij vervangen, dan is dat een HIGH.
• De PNG's komen in een ## Design-sectie, met een verwijzing naar het prototype. De feedback en de oude screenshots blijven bewaard onder ## Redesign input.
• Het label redesign verdwijnt en de issue gaat naar stage::spec.
• Als laatste commit brainstorm alleen docs/design/issue-74/ op main, met [skip ci]: een docs-wijziging hoeft geen test- of deploy-pipeline. Andere wijzigingen in je working tree blijven erbuiten. Sta je niet op main, of weigert GitLab de push, dan zegt het dat en blijft de commit lokaal.

4. Bouwen

Vanaf nu is het een gewone issue: /spexso-start 74, of de factory neemt hem mee in de milestone. Bij Fiori Elements past de builder de spike.diff toe onder TDD.

Variant: een prototype voor een nieuwe issue

Je hebt net een issue gebrainstormd en wil, vóór het bouwen, eerst het scherm zien:

/spexso-brainstorm 80                                 # spec met UI-tabel (stage::spec)
/spexso-prototype 80                                  # zet het label redesign, bouwt het prototype
/spexso-brainstorm 80 --design docs/design/issue-80   # werkt de spec bij, haalt het label weg

De issue staat al op stage::spec, dus zonder poort kan de factory of de marathon hem oppikken terwijl je nog prototypet. Daarom zet /spexso-prototype het label redesign zelf; de tweede brainstorm vervangt alleen wat onder # Spec staat en haalt het label weer weg. Laat je het prototype vallen, verwijder het label dan met de hand (npx spexso issue update 80 --unlabel redesign). Een issue die al in stage::build of stage::review zit, weigert /spexso-prototype.

Kan het ook met Claude Design?

Ja. Een export van Claude Design (zip, of HTML met één PNG per artboard) aanvaardt --design nog steeds, maar die artboards zijn nagetekende HTML, geen UI5: brainstorm moet elk vlak dan zelf aan een control koppelen. Gebruik het canvas om vrij te verkennen, en het prototype voor wat je bouwt.