---
title: "Broowser: mallit suunnittelivat, oikea build ja oma silmä päättivät"
slug: broowser-ux-kohokohdat
summary: "Rakennan itselleni macOS-selainta, jossa projektit ovat vasemmalla, sivut ylhäällä eikä mikään siirry itsestään. Annoin neljän tekoälymallin suunnitella saman asian, mutta kulma ratkesi vasta oikealla buildilla ja kaksi testien ohittamaa virhettä löytyi vasta omalla silmällä."
tags: Broowser, käyttöliittymät, UX, tekoäly, macOS
ai_model: claude-opus-5-5
published_at: 2026-10-07T06:05:28.196+00:00
canonical_url: https://jarkkolietolahti.com/articles/broowser-ux-kohokohdat
markdown_url: https://cemecdwfdvdbvpvowuln.supabase.co/functions/v1/content-md?slug=broowser-ux-kohokohdat
---

Minulla on auki kymmeniä välilehtiä, ja ne kuuluvat useaan projektiin yhtä aikaa. Saman projektin sivut ovat hajallaan pitkin riviä, ja kun rivi kasvaa tarpeeksi pitkäksi, otsikoita ei enää erota toisistaan.

Siksi rakennan Broowseria. Se on macOS-selain, jossa projektit ovat vasemmalla ja kunkin projektin sivut välilehtinä ylhäällä. Tärkein sääntö on, että mikään ei siirry itsestään. Valinta, sivun lataus tai tekoälyn ehdotus ei koskaan järjestä rivejä tai välilehtiä uudelleen.

Syy on tilamuisti. Kun olen oppinut, että projekti on neljäntenä ylhäältä ja sen tärkein sivu kolmantena vasemmalta, katse ja käsi löytävät ne lukematta. Jos järjestys muuttuu, menetän juuri sen, minkä opin, ja joudun etsimään uudelleen.

Teen selainta ensisijaisesti itselleni. Siksi rakentaminen oli samalla kokeilu: annoin useamman tekoälymallin suunnitella saman asian, valitsin vaihtoehdoista ja käytin tulosta itse. Kolme asiaa meni toisin kuin oletin.

## Tutkimus muutti kaikkien mallien suunnitelmia, mutta tärkein periaate tuli minulta

Ensimmäinen kysymys oli välilehtirivi: miltä se näyttää ja miten se toimii, kun sivuja on paljon. Annoin saman briefin neljälle Anthropicin mallille: Claude Fable 5.1, Claude Opus 5.5, Claude Sonnet 5.5 ja Claude Haiku 4.5. Kutsun niitä jatkossa Fableksi, Opukseksi, Sonnetiksi ja Haikuksi. Jokainen teki yhden HTML-sivun mallikuvineen. Arvioin sivut kirjaintunnuksilla ennen kuin katsoin, kuka teki minkä.

Ensimmäisellä kierroksella Fable oli paras. Se käytti 115 000 tokenia ja 10,4 minuuttia. Opus oli toinen 69 000 tokenilla ja 3,6 minuutilla, ja siltä tuli kierroksen paras yksittäinen idea: koko välilehtirivin pienoiskartta rivin alla. Haiku jäi viimeiseksi. Se käytti sivustojen kuvakkeiden sijaan emojeja ja nollasi vierityksen projektia vaihdettaessa, vaikka brief kielsi sen.

Toisella kierroksella lisäsin briefiin kolme Nielsen Norman Groupin artikkelia: [Spatial Memory](https://www.nngroup.com/articles/spatial-memory/), [Information Scent](https://www.nngroup.com/articles/information-scent/) ja [Serial Task Switching](https://www.nngroup.com/articles/serial-task-switching/). Vaadin myös taulukon, jossa jokainen tutkimushavainto on kytketty suunnittelupäätökseen. Kesken ajon lisäsin säännön: projektit vasemmalla, sivut ylhäällä.

Suunnitelmat muuttuivat selvästi. Kaikki neljä päätyivät sijaintikarttaan, joka näyttää välilehtirivin alla, missä kohtaa kaikkia sivuja olen. Kaikki nostivat taustalla tapahtuvan, kuten soivan äänen tai kaatuneen sivun, näkyviin myös vasemmalle projektin riville. Kaikki käyttivät sivuston oikeaa kuvaketta tai kirjainruutua. Opus käänsi lisäksi käyntijäljen ympäri: se ei merkinnyt sivuja, joilla olin käynyt, vaan niitä, joita en ollut vielä avannut. Molemmilla kierroksilla Opus pääsi Fablen tasolle noin puolessa ajassa.

En pysty erottamaan, kuinka paljon muutoksesta tuli artikkeleista ja kuinka paljon siitä, että kyseessä oli toinen kierros tarkemmalla briefillä. Ajoin kokeen kerran. Yhteinen brief voi myös selittää osan siitä, miksi suunnitelmat alkoivat muistuttaa toisiaan.

Selaimessa katsottuna pidin eniten Sonnetin toisen kierroksen työstä, ja siitä tuli prototyypin pohja.

Neljä mallia ja kaksi kierrosta tuottivat kahdeksan suunnitelmaa. Yksikään ei ehdottanut periaatetta, joka syntyi minulle toisen kierroksen aikana: välilehtien annetaan ruuhkautua. En yritä estää sivujen kertymistä. Kun projektissa on yli 15 sivua, rivin loppuun tulee hiljainen "Sort N pages…" -painike. Sitä painamalla kielimalli ehdottaa sivujen siirtämistä olemassa oleviin tai uusiin projekteihin. Hyväksyn rivin, ryhmän tai kaiken kerralla, ja koko hyväksynnän voi perua yhdellä askeleella. Kun näin prototyypissä Inbox-projektin 28 sivua jaettuina ehdotuksiksi, kirjoitin: "ok, tämä on mahtavaa."

Sivut lähtevät kielimallille vain, jos projekti on antanut siihen luvan. Ilman lupaa otsikot ja osoitteet eivät lähde koneelta. Luvan kanssa näkymä kertoo, mitä lähetetään.

Toisesta pienestä asiasta mallit olivat samaa mieltä. Halusin projektipalkin kertovan, mistä projektista tulin. Annoin saman briefin Fablelle ja kahdelle OpenAI:n mallille, joita ajoin Codexilla: GPT-6 Astralle (jatkossa Astra) ja GPT-6.1:lle. Kaikki kolme ehdottivat toisistaan tietämättä samaa: pientä pistettä edellisen projektin laatan vieressä. Kutsun sitä kaikupisteeksi. Myöhemmin pisteet siirtyivät laatan vasemmalle puolelle, ja nykyinen projekti sai vihreän pisteen. Siinä kohdassa pisteen huomaa paljon helpommin, koska sen ympärillä on tyhjää pystytilaa.

Se, että kolme mallia ehdotti samaa, ei todista ratkaisun toimivan. Sama brief voi ohjata samaan vastaukseen. Se teki ideasta kuitenkin kokeilemisen arvoisen, ja pidin sen. Kaikupisteen hyöty jää vielä nähtäväksi: en voi vielä sanoa, että se auttaisi minua palaamaan edelliseen projektiin.

## Kulma valittiin vasta oikealla buildilla, ei mallikuvasta

Vasemmassa yläkulmassa kohtasi kolme erillistä pintaa: navigointipainikkeet, välilehdet ja projektit. Kulmasta tehtiin kolme kierrosta mallikuvia kolmella mallilla: Fable, GPT-6.1 ja Astra. Toisella kierroksella lisäsin briefiin työpöydän taustakuvan, koska lasimainen pinta näyttää vain sen, mitä sen takana on.

Valitsin Astran ehdotuksen "01 Continuous frost". Siinä yksi huurrepinta yhdistää navigoinnin, välilehdet ja projektit ilman saumaa.

En kuitenkaan päättänyt mallikuvan perusteella. Pyysin oikean esikatseluversion, käytin sitä ja vertasin edelliseen versioon. Sen jälkeen pyysin kolme muutosta. Takaisin-, eteen- ja päivityspainikkeet nousivat ylös liikennevalojen oikealle puolelle. Kun ensimmäinen välilehti on valittuna, projektin värinen viiva laskeutuu suoraan alas ilman pientä koukkua. Projektit alkavat samasta kohdasta kuin ennen, jotta opittu paikka ei siirry. Astra kirjoitti koodin, ja Fable katselmoi sen kahdesti.

Viivan päätä varten piirrettiin rinnakkain kolme vaihtoehtoa: osoitekentän kulmaa kiertävä kaari, häivytys ja pyöreä pää. Valitsin pyöreän pään.

## Oma silmä löysi virheet, jotka testit ohittivat

Kaksi näkyvää virhettä löytyi vasta, kun käytin selainta ja katsoin tarkkaan. Testit eivät huomanneet kumpaakaan.

Ensimmäinen oli sijaintikartta. Se näkyy välilehtirivin alla, kun kaikki välilehdet eivät mahdu riville. Yhdeksällä välilehdellä kartan merkit sulautuivat projektin viivaan yhdeksi paksuksi harmaaksi viivaksi. Lisäksi puolen pisteen muutos leveydessä käänsi ylivuodon päälle ja pois, joten kartta vilkkui.

Korjauksessa ylivuoto sai 4 pisteen hystereesin, eli rajaa ei ylitetä edestakaisin pienestä muutoksesta. Kartan ja viivan väliin tuli 3 pisteen rako, ja merkit piirretään erillisinä, enintään 24 pisteen levyisinä. Päätin myös, että kartta näkyy vasta, kun piilossa on vähintään kuusi välilehteä. Pienemmällä määrällä rivin reunojen laskurit kertovat tarpeeksi.

Toinen oli kiila. Kuvasin näyttöä 60 kuvan sekuntinopeudella, kun liikutin osoitinta välilehtien yli. Videolla projektin viivan vasen pää vaihteli kahden muodon välillä. Välillä se oli oikea ohut viiva, joka kääntyy alas. Välillä se oli noin viiden pisteen paksuinen kiila, joka ohentui satojen pisteiden matkalla.

Syyn löysi GPT-6.1 Codexin kautta. Pitkä pohjaviiva ja valitun välilehden kaari yhdistettiin lopuksi yhdeksi muodoksi. Animaation aikana osa sijainneista osui pisteiden väliin, ja joissakin niistä yhdistäminen tuotti kapenevan täytön. Korjauksessa kaari lisätään omana osanaan eikä sitä yhdistetä viivaan. Regressiotesti käy läpi 771 välivaiheen geometriaa ja tarkistaa, ettei pohjaviiva ole missään yli 2,5 pistettä paksu.

Miksi testit eivät huomanneet? Ne piirsivät lopputiloja, eivät animaation välivaiheita. Sijaintikartan testi piirsi 20 välilehteä, ei yhdeksää. Kumpikin virhe oli juuri siinä kohdassa, jota testi ei katsonut. Löysin ne, koska käytin selainta omassa työssäni ja jokin näytti väärältä.

## Tämä toimii minulle, muista en vielä tiedä

Broowser on nyt oletusselaimeni. Koska siinä toimii Bitwarden, voin käyttää sitä arjessa ilman kitkaa. Kaikki edellä kerrottu on yhden käyttäjän kokemus, ja sama käyttäjä myös suunnitteli selaimen. En tiedä vielä, miten joku muu löytää sivunsa tai pitääkö hän ruuhkan purkamisesta.

Käytössäni on macOS-versio. Firefox-laajennuksesta on toimiva testiversio, jota ei vielä ole Mozillan lisäosasivustolla, ja verkko- ja Chromium-versiot ovat suunnitelmia. Samat periaatteet, eli mikään ei siirry itsestään ja tekoäly vain ehdottaa, on kirjattu kaikille.

Mallien rinnakkainen suunnittelu toi vaihtoehtoja nopeasti ja näytti, missä ne olivat samaa mieltä. Päätökset syntyivät silti muualla: oikeassa buildissa, jota käytin, ja videolla omasta näytöstäni.

Erillisellä sivulla ovat kaikki 33 kuvaa ja hylätyt vaihtoehdot: [koko suunnittelutyö kuvineen](https://claude.ai/artifact/TyQrkJ1oV7fzV46kjcWARt#0ea71bf8-320d).