This website remembers you!
This website is actually an another project!
How to code a Website?
Visual Studio Code
JavaScript
Git - Github
01
The Idea
Websites are usually designed to be looked at. You enter, scroll, click, and leave.
But what if visiting a website could leave something behind?
This project treats interaction as material. Every movement, click, pause, and decision becomes part of a temporary digital trace! A record of how someone moved through the website.
The website observes each session as something unique. These traces are collected, translated and eventually turned into an artifact.
The visitor is no longer only viewing the website.
They are contributing to its archive. And that is what makes every trace valuable.
You make the archive different simply by being yourself.
No one moves, pauses, clicks, or explores in exactly the same way you do. Your presence changes the archive, even if all you do is be yourself.
02
Cool, but how to make it work?
The system did not appear fully formed. It was built through a series of experiments, failed attempts, small discoveries and many revisions.
The first challenge was simple: how can a website remember the way someone moves through it?
02a
Capturing The Movement
THE GOAL
The first step was to understand how a visitor moves through the website.
The mouse normally disappears without leaving any evidence behind. I wanted to turn that temporary movement into something the website could remember.
x → horizontal position
y → vertical position
t → time
[x, y, t] → [x, y, t] → [x, y, t] → ...
SUCCESS01 - movement could become data.
02b
But Whose Data Is This?
THE PROBLEM
Recording coordinates was not enough.
If ten people visited the website, I needed to know which coordinates belonged to which person.
The solution was to create a unique session ID for every visit.
Conceptually, the data now looked like:
{ sessionId: "unique-session-id", points: [...] }
The session ID acts like a temporary label.
I do not need to know who the visitor is.
I only need the system to understand:
These points are belong to this visit.
This why now system can also see how many visits happened and can say x many visits happened and this is the archive of x many visits.
This was important to the concept of the project as well.
The archive is not about identifying people.
It is about distinguishing one interaction from another.
SUCCESS 02 - Each visit could become its own trace.
02c
Sending The Data
THE PROBLEM
Mouse movement happens constantly.
That means the website can generate a very large number of coordinates in a short amount of time.
Sending every point individually would mean repeatedly communicating with the backend.
Instead, I grouped the points into batches.
Instead of:
POINT → SERVER POINT → SERVER POINT → SERVER POINT → SERVER POINT → SERVER
the system can work more like:
POINT POINT POINT → BATCH 01 → SERVER POINT
POINT POINT POINT → BATCH 02 → SERVER POINT
batchNo gives each group its position in the session.
The backend therefore knows that Batch 02 comes after Batch 01.
SUCCESS 03 - Large amounts of movement data could be transferred in manageable pieces.
02d
Frontend to Backend
The browser is responsible for observing the interaction.
But I did not want all of the processing to happen directly in the visitor's browser.
The data therefore needed to travel from the frontend to the backend.
When a batch arrives, the backend opens the request and separates its contents into:
sessionId
batchNo
points
isFinal
meta
Each one answers a different question.
sessionId → Which visit?
batchNo → Which part of the visit?
points → What happened?
isFinal → Is the visit finished?
meta → What additional information came with it?
The backend also checks whether the information it receives makes sense.
For example:
if (sessionId.length < 5 || sessionId.length > 100) { return badRequest(...); }
This prevents an invalid session ID from continuing through the system.
SUCCESS 04 - The website could send structured interaction data to its backend.
02d
Knowing When It's Over
One of the more difficult questions was surprisingly simple:
When is a visit finished?
The website could collect information while someone was there, but it also needed to recognize the final batch of information.
This introduced an isFinal state.
isFinal = false
the session is still happening.
isFinal = true
the visit has ended.
At first, the final session was not immediately appearing where it was expected. The data existed, but the system was waiting before completing the next step.
For a while, this created a strange situation:
the interaction worked, but the artifact did not appear immediately.
The solution was to make the final batch trigger the creation of the session directly instead of relying on a delayed process.
That small change connected the live interaction to the archive.
02e
From Data To Artifact!
At this point the system could identify a visitor, record their movement, group the data and understand when their visit had finished.
But raw coordinates were never meant to be the final result.
The next step was translation.
The collected session data is passed to the backend, where it is transformed into a PDF.
The PDF becomes a visual record of that particular visit.
02f
Building The Archive
Generating the document was not enough.
It also needed somewhere to live.
Each completed session is connected to its generated PDF and stored so that individual visits can become part of a larger collection.
The structure finally became:
VISITOR → INTERACTION → DATA → SESSION → PDF → ARCHIVE
The archive therefore does not contain documents I designed individually.
It contains documents generated by the people who visited the website.