Jak ożywiłem Dziennik Toma Riddle'a w przeglądarce
Wziąłem pierwotny eksperyment sprzętowy dla reMarkable Paper Pro i przeniosłem go do webowego MVP dla telefonów i tabletów: atrament wsiąka w pergamin, AI czyta pismo ręczne, a odpowiedź pisze się z powrotem na stronie.
Wyobraźcie sobie, że zapisujecie pytanie na pustym, starym pergaminie. Przez chwilę nic się nie dzieje. Potem atrament zaczyna powoli wsiąkać w papier, aż znika całkowicie. Strona cichnie, a po kilku sekundach z głębi pergaminu zaczyna wyłaniać się odpowiedź, kreska po kresce, eleganckim pismem odręcznym.
Bez klawiatury. Bez dymków czatu. Tylko wy, papier i dziennik, który wydaje się odrobinę zbyt cierpliwy.
Tak działa moje webowe MVP Dziennika Toma Riddle'a. Wziąłem pierwotny pomysł sprzętowy zbudowany dla e-inkowego tabletu reMarkable Paper Pro i przebudowałem go jako mobilne doświadczenie webowe, działające w zwykłej przeglądarce.
Od czego to się zaczęło
Inspiracją był open-source'owy projekt Maxime'a Rivesta: MaximeRivest/Riddle.
Oryginalny Riddle to aplikacja dla reMarkable Paper Pro, napisana głównie w Ruście, C i C++. Czyta ruchy stylusa bezpośrednio z niskopoziomowego wejścia, pracuje z ekranem w trybie takeover i renderuje odpowiedź z powrotem na powierzchni e-ink tak, aby wyglądała jak tekst pisany ręcznie.
To pięknie fizyczny projekt: pióro, papier, e-ink i prawie żadnego interfejsu. Zadaliśmy sobie proste pytanie: czy podobne wrażenie może działać bez specjalnego sprzętu, po prostu na telefonie albo tablecie?
Z reMarkable do przeglądarki
Wersja sprzętowa może polegać na stylusie, zdarzeniach Linuksa i bezpośrednim sterowaniu wyświetlaczem. Wersja webowa żyje w zupełnie innym świecie: ekrany dotykowe, mobilne Safari, Android Chrome, różne proporcje, wyświetlacze o wysokiej gęstości pikseli i gesty przeglądarki, które bardzo chętnie przeszkadzają w rysowaniu.
Dlatego adaptację webową zbudowałem od nowa na prostym stacku: Node.js, Express, HTML5, CSS i vanilla JavaScript. Celem nie był zwykły chatbot przebrany za dziennik. Chciałem zachować główną iluzję: człowiek pisze bezpośrednio na stronie, a strona odpowiada.
Canvas zamiast pióra, Gemini zamiast oczu
Fizyczne pióro zastąpiliśmy HTML5 Canvasem z obsługą Pointer Events. Dzięki temu ta sama powierzchnia działa myszą, palcem albo stylusem, zależnie od urządzenia.
Gdy użytkownik przestaje pisać na około 2,8 sekundy, aplikacja traktuje stronę jako ukończoną:
- canvas jest eksportowany jako PNG,
- serwer wysyła obraz do Gemini Vision,
- model odczytuje pismo ręczne,
- i od razu generuje odpowiedź w roli tajemniczego Toma Riddle'a.
Zaletą jest to, że użytkownik nie musi celować w pole tekstowe. Pisze tak, jak pisałby w zeszycie. OCR i model językowy pozostają ukryte za sceną.
Atrament, który wsiąka w papier
Najważniejsza część doświadczenia nie jest technicznie najbardziej skomplikowana, ale emocjonalnie decyduje o wszystkim: atrament nie może po prostu zniknąć. Musi wsiąknąć.
Po zakończeniu pisania kreski powoli bledną dzięki przejściom CSS, przezroczystości i delikatnemu rozmyciu. Pismo nie znika naraz, tylko rozpuszcza się w fakturze papieru. Powstaje krótka pauza, w której strona zaczyna sprawiać wrażenie żywej.
Odpowiedź Toma wraca potem przez font Dancing Script i prostą pętlę animacji. Tekst nie pojawia się od razu. Przybywa znak po znaku, z drobnymi losowymi opóźnieniami, bardziej jak pióro niż drukarka.
Tryb mobilny: jedna strona zamiast dwóch
Na desktopie dziennik może wyglądać jak otwarta księga. Na telefonie układ dwustronicowy szybko stałby się nieczytelny. Dlatego na urządzeniach mobilnych aplikacja przełącza się w tryb jednej strony.
Odpowiedź pojawia się bezpośrednio nad powierzchnią do pisania jako przezroczysta warstwa. Użytkownik pozostaje w jednym miejscu: pisze na stronie, atrament znika, a odpowiedź pojawia się tam samym.
Problem precyzji: scale drift
Na wyświetlaczach o wysokiej rozdzielczości pojawił się nieprzyjemny błąd. Im dalej palec znajdował się od lewego górnego rogu, tym bardziej atrament odpływał od rzeczywistego punktu dotyku. Na pierwszy rzut oka drobiazg. Przy pisaniu ręcznym rzecz krytyczna.
Przyczyną była różnica między fizycznymi pikselami canvasu a jego wizualnym rozmiarem w CSS. Naprawiłem to przez jawne przeliczenie współrzędnych:
const rect = canvas.getBoundingClientRect()
const scaleX = canvas.width / rect.width
const scaleY = canvas.height / rect.height
const x = (event.clientX - rect.left) * scaleX
const y = (event.clientY - rect.top) * scaleY
Po tej zmianie atrament trafia dokładnie pod końcówkę pióra także na wyświetlaczach Retina.
Demo wideo
Krótkie demo można zobaczyć także w social media:
Co dalej
To MVP jest niewielkie, ale otwiera ciekawe pytanie: czy LLM zawsze musi siedzieć w oknie czatu?
W AI Studio taki dziennik mógłby pomagać pisarzom. Autor nie rozmawiałby z anonimowym asystentem, lecz z konkretną postacią, którą właśnie tworzy. Postać mogłaby odpowiadać własnym stylem, rytmem, głosem i formą wizualną. Brainstorming przesunąłby się ze zwykłego promptowania w stronę dialogu, który brzmi prawie literacko.
W Hyperprostorze taki pergamin mógłby stać się osobnym widgetem UI. Zamiast wypełniać formularz, użytkownik mógłby rysować mapę myśli, pisać ręcznie, wydawać polecenia albo rozmawiać z cyfrową istotą przez interfejs dopasowany do jej roli.
Kolejna warstwa to głos. Szept zamieniany przez speech-to-text mógłby sprawiać, że słowa same pojawiają się na pergaminie. Text-to-speech pozwoliłby Tomowi Riddle'owi naprawdę przemówić ze strony na końcu odpowiedzi.
Dziennik Toma Riddle'a w przeglądarce pokazuje, że sztuczna inteligencja nie musi mieszkać wyłącznie w chłodnych dymkach nowoczesnych czatów. Kiedy pismo ręczne, rozumienie obrazu, animacja i dobrze dobrana rola modelu spotykają się w jednym miejscu, powstaje coś nie tylko użytecznego. Powstaje coś trochę magicznego.
