Steven
Steven6 min leestijd

De loginpagina IS de demo

GeekBye v1.7.5 voegde 's ochtends een productscreenshot toe aan de loginpagina en verwijderde hem diezelfde dag — om hem opnieuw te bouwen als echte componenten. Plus: de gebruiker die sneller was dan de OCR, en hoe 25 style-commits op één dag er werkelijk uitzien.

Engineering
Design
UX
GeekBye Releases
De loginpagina IS de demo

GeekBye v1.7.5 is een release van één week met een gespleten persoonlijkheid: 37 commits, waarvan 28 een loginpagina-redesign zijn — en 25 dáárvan zijn style(login)-microtweaks, allemaal geland op één enkele dag. Het is ook de release die een van de leerzaamste races in de codebase fixte. Beide verhalen zijn het vertellen waard, en ze komen samen in hetzelfde idee: de loginpagina is het eerste wat een niet-ingelogde gebruiker ziet, dus kan hij maar beter het product zijn, geen plaatje ervan.

Een screenshot, ongeveer vijf uur lang

De redesign begon conventioneel. Herstructureren naar twee kolommen, de sign-in links, en het product rechts tonen — als afbeelding. De commits van de late ochtend doen precies dat: om 11:57 landt een echte preview-screenshot in de repo, een PNG van 114 KB, die zes minuten later nog één keer wordt bijgewerkt.

Om 17:04 was hij weg. De pivot-commit vervangt de statische afbeelding door 344 regels echte componenten — een LoginDemo-paneel opgebouwd uit acht kleine stukjes die de echte overlay-UI nabouwen: de opname-navpill met zijn pulserende EQ-balken en stopknop, het chatpaneel met Chat/Transcript-tabs, een gerenderd assistent-antwoord (dat toepasselijk React's useEffect uitlegt), de "Tell me more / Simplify / Show example"-snelacties, de live-prompt-rij en het ⌘⏎ Assist-invoerveld.

Laten we precies zijn over het woord "demo", want overclaimen is makkelijk: de knoppen hebben echte hover states — glows, shimmers, transities — maar niets is aangesloten op klikken, en het invoerveld is read-only. Het is geen sandbox. Wat het wél is: het echte UI-vocabulaire van het product, live gerenderd — dezelfde logo-asset, dezelfde gradient-border- en backdrop-blur-behandeling, dezelfde productName-import die het white-label-systeem gebruikt — zodat de demo zichzelf automatisch rebrandt voor elk product dat uit deze codebase wordt gebouwd. Een screenshot kan dat allemaal niet. Een screenshot is verouderd op de dag dat je hem maakt, wazig op het verkeerde scherm en permanent gebrandmerkt als het product dat je toevallig vastlegde. Componenten zijn scherp op elke DPI, altijd actueel en correct voor elk merk — omdat ze geen foto van het design system zijn, maar het design system zelf.

De verwijderde PNG staat overigens nog steeds in de repo op de releasetag — verweesd, door niets meer gerefereerd. Elke codebase draagt een paar fossielen mee van de aanpak die verloor.

Hoe 25 style-commits op één dag eruitzien

De commitlog van die ene dag is het schetsboek van een designer, met ongebruikelijke eerlijkheid bewaard. De kolomverhouding ging naar 40/60, toen 45/55. Een "Works with"-label boven de platformlogo's werd rond het middaguur toegevoegd, verplaatst en verwijderd — het leefde ongeveer een halve dag. De platformlogo-rij zelf (Google Meet, Teams, Zoom, Slack, Webex), om 10:59 's ochtends toegevoegd, werd om 22:08 die avond volledig verwijderd. En de footer had een saga van vier aanpakken nodig om uitgelijnd te raken: één wrapper-container, toen het verwijderen van de centreerklassen, toen flexbox-centrering, toen hem gewoon iets dichter naar de onderkant duwen.

Het zou makkelijk zijn om dat als churn te lezen. Wij lezen het als de werkelijke vorm van designwerk: je convergeert door te renderen, te kijken en bij te stellen — en dat in 25 kleine commits doen in plaats van één gesquashte "redesign login page" betekent dat de zoektocht zelf is vastgelegd. Als iemand vraagt "hebben we niet ooit een logorij geprobeerd?", staat het antwoord in de history, met timestamps.

De gebruiker die sneller was dan de OCR

Het engineeringverhaal van deze release speelde zich vijf dagen eerder af, in een fixketen van drie commits. Sinds v1.5.12 zet Cmd+H een screenshot in de wachtrij met directe feedback: de thumbnail verschijnt onmiddellijk in de queue, en de tekstextractie — lokale Apple Vision OCR, grofweg één à twee seconden — draait op de achtergrond. Het queue-event wordt letterlijk verstuurd met ocrText: '' en een comment die belooft dat het later wordt ingevuld.

Dat is een goede optimalisatie, en hij muntte een race. Een snelle gebruiker drukt Cmd+H en submit onmiddellijk zijn vraag. Het tekstveld van de screenshot is nog leeg. Het request gaat de deur uit zonder schermcontent, en het model antwoordt — waarheidsgetrouw, om gek van te worden — "I cannot see images." Het naïeve pad faalde niet met een error; het faalde met een correct antwoord op de verkeerde vraag, en dat is de meest verwarrende manier waarop software kan falen.

De fix gate het submit-pad op het async werk dat de optimalisatie had uitgesteld: als een screenshot in de queue nog lege OCR-tekst heeft, parkeert het request en toont de UI een "Reading screen..."-indicator; een useEffect vuurt op het moment dat de tekst binnenkomt en verstuurt het request met de volledig geëxtraheerde content. Twee React-specifieke details in de diff zijn het stelen waard: de screenshotqueue wordt gespiegeld naar een ref die tijdens de render wordt gesynchroniseerd, omdat de closureketen van de event handlers stale state aan het vangen was; en het geparkeerde request wordt direct verstuurd in plaats van via de generieke queued-request-hook, om dezelfde stale-closure-reden.

En er zit een eerlijke plooi vastgelegd in de commit message zelf: de tracing-logs die werden toegevoegd om deze race op te jagen, onthulden een tweede bug op de backend — de prompt assembly liet de screenshottekst in één codepad volledig vallen. Eén symptoom, twee bugs, gevonden door de hele keten te instrumenteren en te kijken waar de tekst verdween. De keten eindigde met een productbeslissing, negen minuten na de race-fix: Cmd+H zet screenshots in de wachtrij voor batchanalyse, terwijl Cmd+Enter altijd een verse capture van het huidige scherm neemt — twee onderscheiden workflows in plaats van één ambigue. (Wat Cmd+Enter's Assist eigenlijk doet is een eigen post: directe AI-hulp bij alles waar je naar kijkt.)

Nog een kleine coda uit dezelfde week, voor lezers van het white-label-hoofdstuk: de Product/version (platform) User-Agent kreeg een dev-mode-fix, omdat app.getVersion() in ongepackagede Electron Electron's versie teruggeeft, niet die van het product. Identiteitsstrings lekken, zoals altijd, in het loodgieterswerk.

Drie dingen die deze release ons leerde

  1. Render het product, fotografeer het niet. Een loginpagina-demo gebouwd uit echte componenten rebrandt automatisch, overleeft elke schermdichtheid en kan niet verouderen. De screenshotaanpak werd geprobeerd en binnen één werkdag verwijderd — goedkoop experiment, helder oordeel.
  2. Elke async optimalisatie heeft een gate nodig op het punt van gebruik. "Directe feedback met lege OCR-tekst" was de juiste UX-keuze, maar het submit-pad moest leren wachten op wat de optimalisatie had uitgesteld. Als je werk uitstelt, zoek dan elke consument van het resultaat op en leer hem het verschil tussen "leeg" en "nog niet klaar".
  3. Instrumenteer de keten, niet de verdachte. De tracing-logs volgden de screenshottekst van begin tot eind — shortcuthandler naar IPC naar API-client — en dáárom sloot één onderzoek twee bugs, waarvan één aan de andere kant van het netwerk.

Voor het vorige hoofdstuk in het v1-verhaal, meetings die je écht terugvindt (v1.7.3); en voor de hele boog, de anatomie van software tot in de perfectie uitbrengen.