Het CMS voor sites gebouwd met Claude of Codex

CMS[this] richt zich op een website die je al hebt (een URL, een zip, of de map die Claude of Codex voor je heeft uitgespuugd) en bouwt daar automatisch een contentsysteem omheen. Het ontwerp blijft onaangeraakt. De doelgroep zijn mensen die met een taalmodel iets moois hebben gebouwd en vastzitten zodra er één woord moet veranderen, freelancers met één klant, en bureaus met tientallen klantsites.

In het merkdocument stond één zin waar alles op terugsloeg, en die is scherper dan hij klinkt. Hij verbiedt niet alleen dat de tool het ontwerp van de klant aanraakt. Hij verbiedt ook dat de tool zelf zich gedraagt als eigenaar. Bijna elke beslissing in dit traject is een variant op de vraag die daaruit volgt: bepaalt de gebruiker hier wát er staat, of begint hij aan hóe het eruitziet?

Wij kwamen erbij als design partner, voor vier werkdagen. Wat er aan het begin lag was een prototype rond versie twaalf: een zwevende bovenbalk, een dock, een commandopalet, overlays. Een editor met zeven mogelijkheden, van tekst bewerken tot het hele menu beheren. En een syncmodel van twee lagen dat te simpel bleek zodra er een derde bij kwam.

De vraag was niet hoe we het mooier maakten, maar welke van twee heel verschillende beloftes bij dit product hoort. Naast de bestaande richting kwamen er twee: een warme, lichte met één zacht kleurveld, en een die het tegenovergestelde moest bewijzen: dat een interface eruit kan zien als gereedschap in plaats van als sfeer.

De lichte richting werd gedragen door één ontdekking die het uitgangspunt omdraaide: het product waar iedereen naar wees als “modern en donker” is helemaal niet donker. Zijn themakleur is #fcfbf8. De moderne indruk komt van het kleurveld en de beweging, niet van een donker canvas. Na vier volledige revisies werd de merkkleur helemaal losgelaten en verschoof de hele stelling: het meubilair is grijs, kleur is informatie, en het enige verzadigde in beeld is het model. Het verloop werd letterlijk een noorderlicht (groen, cyaan, blauw, violet, magenta), gebonden aan één betekenis: hier werkt de machine. Nooit decoratie.

De gereedschapsrichting was in de eerste build, in de woorden van de opdrachtgever, “gewoon een dark mode versie” van wat er al stond. De correctie daarop is de ingrijpendste visuele iteratie van het hele project, en hij kwam uit een telling: negentien schermen van een Hasselblad-camera geanalyseerd op kleur, en over de hele reeks zijn er maar twee dominante kleuren, samen zestig tot tachtig procent van elk beeld. Geen enkele grijstrap in de top vijf van welk scherm dan ook.

Daaruit volgde de vondst die de richting kantelde: een apparaat maakt secundaire informatie kleiner, niet grijzer. De grijsladder van wit naar 55 naar 34 procent is een webconventie; camera-interfaces kennen die gradatie niet. Tekst is puur wit, of hij is er niet. En daaruit volgde weer een reeks omkeringen die met elkaar consistent moest blijven: hoeken naar nul op alles behalve avatars, typografie die nooit boven twaalf pixels komt behalve één groot getal per scherm, en het accent van actiekleur naar toestandskleur: nooit meer een gevuld vlak groter dan een markering.

Drie richtingen naast elkaar zijn onmogelijk eerlijk te vergelijken op een codebase zonder één bron per waarde. Dus voordat er over kleur gesproken kon worden, is er geteld.

De eerste meting op de bestaande build: 1.369 hardgecodeerde hexwaarden, waarvan 137 uniek, verspreid over de markup en over strings die in het script aan elkaar werden geplakt. Eén kleur kwam 189 keer voor. De hoek-tokens wáren gedefinieerd, maar werden nul keer gebruikt: er stonden twaalf verschillende letterlijke waarden door de code heen. Daarnaast 175 losse rgba-waarden die nooit met een thema meebewogen, en dertig z-index-getallen zonder ladder.

Dat cijfer is de reden dat elke visuele wijziging vanaf dat punt als tweetrapsprompt geschreven werd. Eerst de tokenlaag invoeren zonder één pixel te veranderen (“het scherm moet er na afloop pixel-identiek uitzien; als er iets zichtbaar verandert, is er een fout gemaakt”), en pas daarna de waarden wisselen. Een latere sweep bracht ook schaduwen, transities, z-index en witruimte onder tokens: negen losse, apart controleerbare passes, met de instructie ze één voor één te draaien. Gaat er iets stuk in een run van zes wijzigingen, dan weet je niet welke het deed.

Dat is ook wat dit proces onderscheidt van “vraag om mooiere schermen”: elke visuele beslissing werd getoetst aan de code en niet alleen aan het oog. Een grep-telling van hexwaarden, lettergroottes en z-index bepaalde of een wijziging één prompt kon zijn of een gefaseerde operatie moest worden.

Midden in het traject viel een beslissing die alle voorgaande visuele iteraties in perspectief zette: de editor mocht geen structuur meer wijzigen. Een tabel uit de eigen bureaupraktijk beantwoordde zeven veelgestelde klantwensen met ja of nee. Nieuwe pagina's, herordenen, verbergen, dupliceren, menubeheer: die kregen allemaal nee.

Het gevolg was groter dan één geschrapte functie. Het syncmodel had drie lagen (ontwerp, structuur, inhoud) en die middelste laag bestond alleen omdat de klant structuur mocht wijzigen. Met dat ene nee klapte het model terug naar twee lagen, en verdween in één klap het moeilijkste onderdeel van het hele product: de botsingsvraag per pagina, de merktekens voor wat jij verplaatst had, het volledige scherm voor structuuroverschrijvingen. Ontwerp en structuur komen uit de bron. Inhoud leeft in het systeem. Geen middenlaag meer.

Maar een grens die alleen zegt dat iets niet kan, leert je niets en voelt als een muur. Daar kwam het patroon uit dat we het vaakst hebben hergebruikt: één zin over waar die mogelijkheid wél leeft, een kopieerbare en al ingevulde prompt voor Claude of Codex, en de weg terug via een nieuwe synchronisatie. Zes verschillende grenzen, één component. Met één uitzondering: publicaties inplannen kreeg het patroon niet, want die functie leeft niet in de bron maar bestaat simpelweg nog niet, en hetzelfde component daarvoor gebruiken zou aanleren dat de bron dingen kan die hij niet kan.

De scherpste vraag van het hele traject, met een antwoord dat in één zin past. Stel: de bouwer schrijft een tekst in Claude. Een redacteur past hem hier aan. De bouwer wijzigt diezelfde tekst opnieuw in zijn bron en synchroniseert. Wie wint?

Laat de bron altijd winnen, en een synchronisatie kan een middag redactiewerk stilletjes wissen, en dan is de belofte van het product stuk. Laat het systeem altijd winnen, en de bouwer kan zijn eigen typefout nooit meer corrigeren: hij past aan, hij synchroniseert, er gebeurt niets. Dus geen van beide. Onaangeraakte velden volgen de bron; zodra iemand een veld hier bewerkt is het van het systeem, tot iemand het expliciet terugzet.

Dat principe vertakte zich meteen naar regels die niet vanzelfsprekend waren. Collecties zijn gesplitst: het schema (welke velden er zijn, dat het een lijst is) komt uit de bron, de items zelf zijn inhoud. Bedrijfsgegevens verhuizen in hun geheel, want je wilt nooit een situatie waarin het telefoonnummer op de contactpagina van de klant is en in de voettekst nog van de bron. En het overschrijvingsscherm dat we net begraven hadden kwam terug, maar kleiner: alleen inhoud, met per regel een knop om naar de bron terug te zetten.