Rolig programvare: å drepe en flimrende bryter og lære chatten å si hvilken modus den er i

Ikke hver utgivelse er en krigshistorie. Noen er bare en liste med små, nesten usynlige ting som stille var feil — den typen som ikke krasjer noe, men får en app til å føles litt upålitelig, litt nervøs, litt ikke-din. GeekBye v2.0.3 og v2.0.5 var to av dem. Ingen nye funksjoner. Bare ro.

"Rolig programvare" høres ut som en stemning. Det er egentlig en haug med spesifikke beslutninger. Her er tre av dem.

En bryter som ikke kunne bestemme seg

Det fantes en innstillingsbryter — den som styrer lydgjenoppretting — som flimret når du klikket på den. Trykk den på, og i en brøkdel av et sekund viste den på, så snappet den tilbake til av, og la seg deretter til ro. En bitteliten visuell stamming, men øyet fanger den, og den leses som appen er ikke sikker på hva den gjør.

Årsaken er et klassisk grensesnittkappløp kalt en optimistisk oppdatering. Når du klikker på en bryter, har appen to valg: vente til innstillingen faktisk lagres og så oppdatere bryteren (korrekt, men føles tregt), eller slå bryteren om umiddelbart og lagre i bakgrunnen (føles øyeblikkelig). GeekBye gjorde det siste — slo om med en gang — men den leste også den lagrede verdien tilbake da den kom. Så rekkefølgen var: du klikker, bryteren slår optimistisk på, den virkelige lagrede verdien ankommer et øyeblikk senere, og i ett bilde var de to uenige, og bryteren hoppet synlig.

Fiksen er å få den optimistiske verdien og den bekreftede verdien til å stemme rent overens — bryteren forplikter seg til tilstanden du valgte, og slutter å tvile på seg selv når lagringen bekreftes. Ved siden av det gjorde v2.0.3 en uglamorøs tekstgjennomgang: beskrivelsen av lydgjenoppretting ble kortet ned så den flukter med søskenradene sine, og innstillingsformuleringene ble gjort mer menneskelige. Ingenting av dette er en funksjon. Alt er forskjellen mellom et innstillingspanel som føles konstruert og et som føles omhyggelig finpusset.

En omvisning som ikke ville dra

Omvisninger for nye brukere er nyttige nøyaktig én gang. Problemet er den engangsaktigheten: etter at du har sett den, blir et introduksjonsoverlegg du ikke kan lukke til rot som signaliserer denne appen tror fortsatt du er ny. v2.0.3 fikset begge ender — produktomvisningen kan nå skjules, og hvis du faktisk vil ha den tilbake, finnes det en Spill av omvisning på nytt-knapp. Vis den når den hjelper, trekk deg unna når den ikke gjør det, og la brukeren kalle den frem på egne premisser. Å respektere at brukeren ikke lenger er ny, er sin egen lille form for ro.

Assistenten som ikke ville si hvordan den tenkte

Dette er den som faktisk betydde noe, og den henger sammen med et dypere problem vi hadde jaget.

GeekByes assistent svarer forskjellig avhengig av kontekst. På et møte skal "hva synes du om dette?" få et samtalende, møtebevisst svar. I en kodeøkt skal de samme ordene få et teknisk. Så backend kjører spørsmålet gjennom riktig ramme — kall det møtemodus eller kodemodus — og den innrammingen endrer faktisk svaret du får.

Problemet: appen fortalte aldri hvilken modus som svarte. Så når assistenten ga deg et kode-aktig svar på et samtalende spørsmål — eller svarte på et kodespørsmål som om du chattet — så det ut som om AI-en rett og slett tok feil. Den tok ikke feil; den var i den andre modusen, og du hadde ingen måte å se det på. En skjult tilstand fikk korrekt oppførsel til å se ødelagt ut. (Selve modus-logikken er et større arbeid — orkestratoren som avgjør hvordan ikke-kodespørsmål skal besvares under en kodeøkt — men ingenting av det er til nytte for deg hvis du ikke kan se beslutningen den tok.)

v2.0.5 la til en skrivebeskyttet modus-brikke i chatten: en liten etikett som viser om assistenten svarte i møtemodus eller kodemodus. Skrivebeskyttet er hele poenget — det er ikke en kontroll du stiller inn, det er et vindu inn til en beslutning systemet allerede har tatt. Du slutter å gjette hvorfor et svar føles feil; du kan se rammen det kom fra.

Detaljen som gjør brikken ærlig

Her er det tekniske valget verdt å gi videre, for det er den slags ting som skiller en påklistret indikator fra en pålitelig.

Modusinformasjonen kommer fra backend som en del av det strømmede svaret — et lite mode-bilde i strømmen av serversendte hendelser. Men en eldre klient som er eldre enn denne funksjonen, ville ikke vite hva et mode-bilde er; i beste fall ignorerer den det, i verste fall gjengir den noe forvrengt. Så klienten kunngjør sin evne: den sender et forespørselshode som sier jeg vet hvordan man viser en modus-brikke, og backend sender bare mode-bildet til klienter som sendte det. Gamle klienter mottar aldri et signal de ikke kan håndtere; nye klienter får nøyaktig det bildet de ba om.

Det er et håndtrykk på ett hode, og det er forskjellen mellom "vi la til en funksjon" og "vi la til en funksjon uten å ødelegge for noen som ikke har oppdatert ennå." Den samme gjennomgangsrunden strammet inn resten av oppførselen: brikken tømmer seg selv ved nullstilling og når samtalekonteksten endres (en utdatert modusetikett er sin egen lille løgn), og den vises bare i chatvisningen der den hører hjemme.

Hva to "ingen-funksjon"-utgivelser lærte oss

1. Nervøsitet er et tillitssignal. En flimrende bryter, en hoppende omkobler, en etikett som blir hengende ett bilde for lenge — ingen av dem er en feil i krasj-forstand, men hver av dem hvisker denne appen har ikke helt kontroll. Ro er fraværet av de hviskingene, og du fortjener det ett kappløp om gangen.
2. En skjult modus får korrekt oppførsel til å se ut som en feil. Assistenten gjorde det rette og fikk skylden for det, utelukkende fordi brukeren ikke kunne se rammen. Når systemet ditt tar en usynlig beslutning som endrer utdataen, så vis beslutningen — en skrivebeskyttet brikke er ofte hele fiksen.
3. Nye funksjoner skal være usynlige for klienter som ikke kan bruke dem. Evne-hode-håndtrykket betyr at modussignalet bare når klienter som kan gjengi det. Bakoverkompatibilitet er ikke en versjonssjekk som klistres på i etterkant; det er en klient som sier hva den forstår, og en server som respekterer svaret.

Dette er utgivelsene ingen skriver changelog-overskrifter om, og de er en stor del av grunnen til at GeekBye v2 føles som den gjør. For utgivelsen denne roen ble bygget på, se hva en versjon 2 faktisk krever (v2.0.0). For pålitelighetsarbeidet ved siden av den, dagen appen vår DDoS-et seg selv (v2.0.1) og hvorfor AI-notatverktøyet ditt slutter å ta opp midt i møtet (v2.0.9).