Design Process Reflection
This project started with a simple but powerful idea: What if people in the future could feel the beauty of things we’ve already lost? I wanted to create a poetic experience that connected image, memory, and emotion, but something more than just a visual archive. My goal was to design an interactive system where people could discover forgotten objects and, reflect on what it means to lose something forever.
Starting Out
At first, I thought about making a system that takes an image and generates a short poem from it, kind of like a visual-to-poetry generator. The idea felt interesting, but the early versions didn’t really feel meaningful. Generating a fixed poem for each unique image was too straightforward and lacked variety and emotional weight.
That’s when I started thinking about how people interact with data and memory. I imagined a sort of digital archive from the future, where bits of information were still floating around, but their connections had become unstable, like trying to access fragments of a half-lost history.
Iteration & What I Changed
Originally, I designed a moving star system that would make images appear when the mouse is hovering over a dense formation of links. Then my professor reminded me that my design has already appeared within the demo and I have to make some more changes to make it unique. So I changes the moving star system into a network with loose connections, and the nodes would all gather to the place where my mouse is.Â
The network consists of image nodes, each one representing an object (such as old tools, broken machines, or forgotten devices) that had disappeared from human history. These nodes are connected by thin, flickering lines, which made the interface feel alive but unstable. Users could move around and select different image clusters. When they clicked one, a short paragraph would pop up, written in a style similar to a Wikipedia entry. It would describe the object’s origin, use, and how it eventually faded away.
One problem I ran into was letting users pick as many images as they wanted. It made the whole thing feel too casual. So I changed the rule: you could only select three images. After that, the system would generate a three-line poem based on your choices. After that, those three images would be corrupt and deleted permanently from the database. They’re gone for good, and no one else can see them again. It creates a delicate tension when people suddenly find they only have one chance, and become much more careful and thoughtful in how they explored.
What I Learned
I used to think that emotional impact mostly came from visuals or text. But now I realize that interaction design itself can carry meaning. It’s not just about what you show, but what you let people do, and what they have to give up in the process.
Compared to my early ideas, the final version feels much deeper. The visual design of a dark background, glowing lines, fragile nodes helps to set the mood. But more importantly, the experience feels intentional. The limit of three choices, the final poem, and the permanent deletion all work together to create something that feels almost ritual-like. It’s not just a website; it’s a small tribute to memory, and loss.
Explain the inner workings of your code in detail. In your own words, and with the help of screenshots, code snippets or possibly diagrams, break apart the logic behind your code, illustrating how different sections are functionally related.
Describe the technical challenges that you faced, solutions you found as well as compromises you had to make.
What could have been implemented better and what changes you would make if you had the chance to do it all over again. What discoveries did you make along the way?Â
Be as detailed and specific as you can.
The code was initially messy and used way too many global functions. Plus, I have to entirely reorganize the code logic from my prototype since my "star map" background went through a major change and I have to add the fade-in and fade-out transition effects for both the connections and the photo album.
In my final code, I tried to write in the clearest way possible. To begin with, I put all the core elements (dots, connections, pictures) into classes:
The Spot class.Â
The parameters: baseX/Y - the basis of the point, x/y - current position of the dot, alpha - used for transition fade-in and fade-out effects, alphaChange - the speed of which alpha changes, used within the update() function in the Spot class.
During update(), we check whether each dot is close to the mouse, if yes, then we set this.follow as true and make the dot lerp to position.
The Connection class (i.e. the lines between close spots).
Similar to the spot class, it also has an update logic that changes the alpha of these connections on demand.
To make the links look like they are only "loosely" connected, I made it more transparent the further the distance between the two dots.
The Picture class, used to store the frames of each picture (in the lost memory).
The alpha logic is similar to the Spot class.
Notice there are two different parameters called this.show and this.notCorrupt, this.show determines whether the picture is currently "face up" when the user sees the album (max. 3 pictures at once), and this.notCorrupt determines whether this memory can still be opened (for once only before it disappears forever)
The best design strategy, in my opinion, is the introduction of interface "states". After I assigned four states to numbers, I could simply say, for example "if (state == STARMAP)" and run the corresponding code. This makes the code clear and readable.
The code logic works like this: state is first "STORY" to roughly tell the audience what this project is about, and then goes to "STARMAP" to let users interact with the connections, which reveals an image at the point where they hold their cursor. The program goes between "STARMAP" and "PHOTOBOOTH", and reaches the "ENDING" state when the entire set of 12 pictures are corrupt and could never be seen again.Â
The entire state-changing logic and cycle for which poems and wiki descriptions appear is based on frameCount. It is carefully controlled so that during debugging, the length of each segment could be manually tuned and flexible. What's more, all the pictures and lines in the star map can be scaled with custom canvasHeight and canvasWidth.
showStory and showPoem functions that draws a black rectangle and puts the corresponding text for the users to see.
The most difficult part is definitely designing how the different scenes fade in and out. Ultimately, I compromised to changing the alpha of each element on screen based on frameCount, but I still think this process can be further modulized. Currently it is directly written in the state change part of the code. For instance:
By the way, another challenge I faced along the way is that the frame counts and object positions have to be carefully calculated, but the use of map() made it much easier.
Last but definitely not the least, the poems were carefully crafted so that any three sentences in any order could reveal a sort of meaning. I'm pretty proud of that design as well.
When I first started this project, my main idea was to make something that shows how memory and meaning can disappear in the digital age. I wanted people to feel a sense of loss, not just by watching something fade, but by making a choice that causes something to disappear. That’s how I came up with the idea behind After Three Lines: Oblivion.
In the beginning, my plan was mostly visual: a screen filled with floating particles that form ghost-like images as you move your mouse around. I wanted it to feel dreamy, like trying to remember something that’s slipping away. But after a few tests, I realized that the experience didn’t feel personal enough. People liked how it looked, but they didn’t feel very connected to what they were seeing.
For my initial feedback, one peer said it was “cool, but I didn’t really feel anything when I clicked,” and a guest reviewer suggested adding some emotional weight. I decided to change the way users interact with the images. Now, when you choose three images, you get a short poem based on those choices… but those images are then gone forever. That moment is quiet, but kind of heavy, and I saw people pause more before deciding to select an image.
Another thing that changed was how I handled the images themselves. Instead of random shapes, I added descriptions that pop up when you select them. These stories talk about the object’s past and how it disappeared. That made the whole project feel more connected, and helped users care more about what they were choosing.
What worked best in the final version was the mood — a mix of beauty and sadness. People told me they felt surprised by how emotional it was, even though it was all online. What didn’t work as well was the image clarity; sometimes the dots didn’t form a clear enough shape. I’d like to fix that in the future and maybe let users submit their own “lost objects” to expand the archive.
Overall, I think After Three Lines: Oblivion does what I hoped. It makes people think about memory, choice, and what we leave behind, not just in real life, but online too. I also learned that interaction doesn’t have to be loud or flashy to be powerful. Sometimes, quiet choices are the ones that stay with us the longest.
The p5.js reference book has been invaluable in my creating process as it helps me to understand many core concepts and functions, such as how to insert and modify images to my own free will. https://p5js.org/reference/
Björk’s Biophilia is a 3D interactive galaxy where artwork are show by interacting with the starmap. I originally planned somthing like this but later realized that it might be too ambitious. But it is still a great source of inspriation. https://www.snibbe.com/apps/biophilia
Finally, the idea of making each poem appear only once is heavily inspired by Poetry Vanishes: A Rainy Reverie where the poems get washed up by the rain. In some sense, the poems in my project is washed up by the passage of time. https://www.delightarchive.com/poetry-vanishes