Software calm: cum am ucis un toggle care pâlpâia și am învățat chat-ul să spună în ce mod e

Nu orice lansare e o poveste de război. Unele sunt doar o listă de lucruri mici, aproape invizibile, care erau greșite pe tăcute — genul de lucruri care nu strică nimic, dar fac o aplicație să pară ușor nedemnă de încredere, ușor agitată, ușor nu-a-ta. GeekBye v2.0.3 și v2.0.5 au fost două dintre acestea. Fără funcții noi. Doar calm.

„Software calm" sună a stare de spirit. E de fapt un morman de decizii specifice. Iată trei dintre ele.

Un toggle care nu se putea hotărî

Era un toggle din setări — cel care controlează recuperarea audio — care pâlpâia când îl apăsai. Îl atingeai să-l pornești și, pentru o fracțiune de secundă, arăta pornit, apoi sărea înapoi la oprit, apoi se așeza. Un mic hâțân vizual, dar ochiul ți-l prinde, și se citește ca aplicația nu e sigură ce face.

Cauza e o cursă clasică de UI numită update optimist. Când apeși un toggle, aplicația are două alegeri: să aștepte ca setarea să se salveze cu adevărat și apoi să actualizeze comutatorul (corect, dar pare lent), sau să schimbe comutatorul imediat și să salveze în fundal (pare instant). GeekBye făcea a doua variantă — schimbă imediat — dar și recitea valoarea salvată când aceasta se întorcea. Deci secvența era: apeși, comutatorul se schimbă optimist pe pornit, valoarea reală salvată sosește o clipă mai târziu, și pentru un cadru cele două erau în dezacord, iar comutatorul sărea vizibil.

Fixul e să faci ca valoarea optimistă și valoarea confirmată să fie de acord curat — comutatorul se angajează la starea pe care ai ales-o și încetează să se mai îndoiască de sine când salvarea se confirmă. Alături de asta, v2.0.3 a făcut o trecere neglamoroasă prin texte: descrierea recuperării audio a fost scurtată ca să se alinieze cu rândurile-surori, iar formulările din setări au fost umanizate. Nimic din asta nu e o funcție. Totul e diferența dintre un panou de setări care pare inginerit și unul care pare lucrat cu grijă.

Un tur care nu voia să plece

Tururile pentru utilizatori noi sunt utile exact o dată. Problema e această unicitate: după ce l-ai văzut, un overlay de onboarding pe care nu-l poți închide devine dezordine care semnalează aplicația asta încă te crede nou. v2.0.3 a reparat ambele capete ale acestui lucru — turul de produs poate fi acum ascuns, iar dacă chiar îl vrei înapoi, există un buton Reia turul. Arată-l când ajută, dă-te la o parte când nu, și lasă utilizatorul să-l invoce în termenii lui. A respecta faptul că utilizatorul nu mai e nou e propria lui mică formă de calm.

Asistentul care nu voia să spună cum gândea

Ăsta e cel care a contat cu adevărat, și se leagă de o problemă mai profundă pe care o urmăream.

Asistentul GeekBye răspunde diferit în funcție de context. Într-o ședință, „ce părere ai despre asta?" ar trebui să primească un răspuns conversațional, conștient de ședință. Într-o sesiune de programare, aceleași cuvinte ar trebui să primească unul tehnic. Așa că backend-ul trece întrebarea prin cadrul potrivit — să-l numim mod ședință sau mod programare — și acea încadrare chiar schimbă răspunsul pe care îl primești.

Necazul: aplicația nu-ți spunea niciodată care mod a răspuns. Așa că atunci când asistentul îți dădea un răspuns cu iz de programare la o întrebare conversațională — sau răspundea la o întrebare de cod ca și cum ai fi stat la taclale — părea că AI-ul e pur și simplu greșit. Nu era greșit; era în celălalt mod, iar tu nu aveai cum să vezi asta. O stare ascunsă făcea un comportament corect să pară stricat. (Logica de mod în sine e o bucată de lucru mai mare — orchestratorul care decide cum să răspundă la întrebări non-cod în timpul unei sesiuni de programare — dar nimic din asta nu-ți e de folos dacă nu poți vedea decizia pe care a luat-o.)

v2.0.5 a adăugat un chip de mod read-only în chat: o mică etichetă care arată dacă asistentul a răspuns în mod ședință sau mod programare. Read-only e tot rostul — nu e un control pe care îl setezi, e o fereastră către o decizie pe care sistemul deja a luat-o. Nu mai ghicești de ce un răspuns pare aiurea; poți vedea cadrul din care a venit.

Detaliul care face chip-ul onest

Iată alegerea de inginerie care merită transmisă, pentru că e genul de lucru care separă un indicator lipit la repezeală de unul demn de încredere.

Informația de mod vine de la backend ca parte a răspunsului transmis în flux — un mic cadru mode în fluxul de server-sent events. Dar un client mai vechi care e anterior acestei funcții n-ar ști ce e un cadru mode; în cel mai bun caz îl ignoră, în cel mai rău caz randează ceva stricat. Așa că clientul își anunță capabilitatea: trimite un antet de request care spune știu cum să afișez un chip de mod, iar backend-ul emite cadrul mode doar către clienții care l-au trimis. Clienții vechi nu primesc niciodată un semnal pe care nu-l pot gestiona; clienții noi primesc exact cadrul pe care l-au cerut.

E o strângere de mână cu un singur antet, și e diferența dintre „am adăugat o funcție" și „am adăugat o funcție fără să stricăm pe nimeni care încă nu s-a actualizat." Aceeași trecere de review a strâns și restul comportamentului: chip-ul se șterge singur la reset și când se schimbă contextul conversației (o etichetă de mod învechită e propria ei mică minciună) și apare doar în vederea de chat unde e locul lui.

Ce ne-au învățat două lansări „fără funcții"

1. Agitația e un semnal de încredere. Un toggle care pâlpâie, un comutator care sare, o etichetă care mai zăbovește un cadru — niciunul nu e un bug în sensul de crash, dar fiecare șoptește aplicația asta nu e chiar în control. Calmul e absența acelor șoapte, și îl câștigi câte o condiție de cursă pe rând.
2. Un mod ascuns face un comportament corect să pară un bug. Asistentul făcea ceea ce trebuia și era învinovățit pentru asta, pur și simplu pentru că utilizatorul nu putea vedea cadrul. Când sistemul tău ia o decizie invizibilă care schimbă rezultatul, arată decizia — un chip read-only e adesea întregul fix.
3. Funcțiile noi ar trebui să fie invizibile pentru clienții care nu le pot folosi. Strângerea de mână cu antet de capabilitate înseamnă că semnalul de mod ajunge doar la clienții care îl pot randa. Compatibilitatea înapoi nu e o verificare de versiune lipită mai târziu; e un client care spune ce înțelege și un server care respectă răspunsul.

Astea sunt lansările despre care nimeni nu scrie titluri de changelog, și sunt o mare parte din motivul pentru care GeekBye v2 se simte așa cum se simte. Pentru lansarea pe care s-a construit acest calm, vezi ce presupune cu adevărat o versiune 2 (v2.0.0). Pentru munca de fiabilitate de alături, ziua în care aplicația noastră și-a făcut singură DDoS (v2.0.1) și de ce notetaker-ul tău AI se oprește în mijlocul ședinței (v2.0.9).