I think that a strongly interactive system is one where the user feels involved and where there is a continuous exchange between the user and the system. Crawford describes interaction as a process where two actors “listen, think, and speak.” I found this interesting because it means that a system should not just react to an action, but should take the user’s input, process it, and then respond in a meaningful way. This makes the interaction feel more like a conversation between the user and the system. Based on the examples given by Crawford, I understood that a strongly interactive system needs all three parts working together, not just one or two of them.
For improving the degree of user interaction in my p5.js sketches, I could make the system behave according to the user’s actions. For example, I could add mouse functionalities where objects change depending on where the user moves the mouse or what they click on. I could also use keyboard inputs to let the user control different parts of the sketch. Instead of having the same response every time, I could make the sketch respond differently depending on the user’s actions. This would make the user feel like they have more control over what happens.
In the future, I would like to make these interactions more complex and meaningful. Animations or transitions could be added to make it clear how a specific user action led to a specific outcome. I could also make the system remember previous user actions and use them to affect what happens later, such as in a game where the user’s previous choices change the experience. This would make my sketches feel less like animations that the user is simply watching and more like interactive systems where the user and the program are continuously responding to each other.
For this OOP project, since I have never done this before, I just wanted to test if I understand the class, the constructor, the array, and how to push new items into an array, and so I decided to create some “atoms” that bounce around in the canvas.
They are called atoms, because my original concept that I wanted to make was atoms, that are red and are following a certain path on the screen but it got lost in translation, and started to look more like confetti, so I decided to leave it for that day.
I have astigmatism, which just means that especially in the dark light sources seem a little weird (the photo demonstrates it better) and weirdly, I got inspired by that on Saturday, when I was with a friend out at night. I think the balls in the end were just much easier to make than those lights that I usually see, but it just clicked something in my brain. So I moved on from my initial idea and started to work on something else.
The concept that I used in the end was kind of a mixture of the two: I made some ellipses that are going around but not on a predetermined route but randomly, and from my astigmatism came the idea to make them almost vibrating and very very colourful.
The Code
(click on the canvas as many times as you want)
So the code was very hard to do, and I was struggling a lot with it not working. To start with, I created the basics, I made an array to store my atoms in, and then in the draw function I made a for loop to loop that array and its elements. In the for loop, there are three other functions that I am going to explain later in the class.
let atoms = []; //setting the array
function setup() {
createCanvas(400, 400);
}
function draw() {
background('black');
//for loop goes throught the array, checks the index of each element and displays all of them
for (let i = 0; i < atoms.length; i++){
//called function from class, updates their position
atoms[i].atomMotion();
//called function from class, determining how the atoms look like
atoms[i].display();
//called function from class, recognising the borders of the screen
atoms[i].checkEdge();
}
}
After this, I made a mouseClicked function to add elements to my array. I tried to explain what it does inside of the code.
//when mouse is clicked a new atom will appear at the point of click, in the this.x and this.y the coordinates of the click get saved for that specific new atom as the mouseX and mouseY coordinated were given for the new one, and then the new atom gets pushed into the array with a new index (i)
function mouseClicked(){
atoms.push(new Atom(mouseX, mouseY));
}
And then I created the Atom class. I wanted to make it fun, so I added randomisation to quite a few attributes of the atoms, such as their diameter and how fast they will be moving around the screen. I decided to name their attributes only x and y because any other name just confused me, since these are referring to where the mouse was clicked and so where the atom formed.
class Atom{
//x and y are defined as the coordinates of center of the atom, the mouse position at the time of the click, and so each atoms gets assigned that value at the start
constructor(x, y){
this.x = x;
this.y = y;
//each atom gets assigned a random diameter
this.diameter = random(10, 80);
//each atom gets assigned a random speed
this.velocityX = random(-4, 4);
this.velocityY = random(-4, 4);
}
After this was the hardest part of the whole code, but also what I am most proud of because I wanted them to not move out of the canvas, so I had to make them bounce back from the walls. To do this I needed some videos explaining to me the “science behind it”, for example, how to change the atoms’ motion once they detect the sides of the canvas: in the end I ended up multiplied their current velocity with -1 to reverse them back once they detected the edge. I also had to understand HOW it can detect the edge, but once I saw a video about it I understood and made my own code.
Basically what I did, is I divided the (randomly) assigned diameter of each atom to get the radius of each. The this.x and this.y are the midpoints of the atoms, so I checked if their leftmost and top points (so the midpoint minus the radius) are < 0, so past the canvas’ borders. (this is the example of the left side’s code)
The second part of the if statement snaps the atoms back to the canvas in case they moved too fast and went a few pixels out of frame by putting their midpoint back at where they used to be. This was what took me a very long time, because sometimes they would just glitch into the wall. And lastly came the switching direction.
The else if statements do the exact same thing, with the only difference that they check the rightmost and the bottom parts, that is why here the radius is plus not minus.
Here is the full code of the bouncing:
checkEdge(){
let radius = this.diameter / 2;
//first it checks the LEFT side, if the leftmost edge of the ball (center minus its radius) reaches x = 0, so the left side of the screen, it snaps it back, and then reverses the direction
if (this.x - radius < 0) {
this.x = radius,
this.velocityX *= -1;
}
//first else if checks the RIGHT side the same way
else if (this.x + radius > width) {
this.x = width - radius;
this.velocityX *= -1;
console.log('this works');
}
//second if checks the TOP of the screen the same way
if (this.y - radius < 0) {
this.y = radius;
this.velocityY *= -1;
}
//second else if checks the BOTTOM of the screen the same way
else if (this.y + radius > height) {
this.y = height - radius;
this.velocityY *= -1;
console.log('this works too');
}
}
After this was relatively easy to finish the code. I am lying though a little, because I finished this earlier than I did the previous checkEdge part. But regardless, this part I was able to relatively quickly. Most of hówhat I did is explained in the code itself.
But just to add on a litte, I love playing with the random function, so I also decided to make the colours and oppacity of the atoms randomised, and so they no longer look like atoms but confetti. However, at this point I had too many functions and variables connected to and named atom that I didn’t dare change anything.
//this function updtaes the atoms' position after the click has happened, and the new atom is added to the array, its temporary position, so the one saved into the this.x and this.y parameters gets added to a randomised velocity value give above
atomMotion(){
this.x = this.x + this.velocityX;
this.y = this.y + this.velocityY;
}
//defines how the atoms actually look on the screen, and updates it every time
display(){
noStroke();
//fills in the circles, but the colours and the transparency is randomised
fill(random(0, 255), random(0, 255), random(0, 255), random(90, 200));
//actually drawing the ellipse or circle
ellipse(this.x, this.y, this.diameter, this.diameter);
}
}
And lastly here is the full code in one:
let atoms = []; //setting the array
function setup() {
createCanvas(400, 400);
}
function draw() {
background('black');
//for loop goes throught the array, checks the index of each element and displays all of them
for (let i = 0; i < atoms.length; i++){
//called function from class, updates their position
atoms[i].move();
//called function from class, determining how the atoms look like
atoms[i].show();
//called function from class, recognising the borders of the screen
atoms[i].checkEdge();
}
}
//when mouse is clicked a new atom will appear at the point of click, in the this.x and this.y the coordinates of the click get saved for that specific new atom as the mouseX and mouseY coordinated were given for the new one, and then the new atom gets pushed into the array with a new index (i)
function mouseClicked(){
atoms.push(new Atom(mouseX, mouseY));
}
class Atom{
//x and y are defined as the coordinates of center of the atom, the mouse position at the time of the click, and so each atoms gets assigned that value at the start
constructor(x, y){
this.x = x;
this.y = y;
//each atom gets assigned a random diameter
this.diameter = random(10, 80);
//each atom gets assigned a random speed
this.velocityX = random(-4, 4);
this.velocityY = random(-4, 4);
}
checkEdge(){
let radius = this.diameter / 2;
//first if checks the LEft side, if the leftmost edge if the ball (center minus its radius) reaches x = 0, so the left side of the screen, it snaps it back, and then reverses the direction
if (this.x - radius < 0) {
this.x = radius,
this.velocityX *= -1;
}
//first else if checks the RIGHT side the same way
else if (this.x + radius > width) {
this.x = width - radius;
this.velocityX *= -1;
console.log('this works');
}
//second if checks the TOP of the screen the same way
if (this.y - radius < 0) {
this.y = radius;
this.velocityY *= -1;
}
//second else if checks the BOTTOM of the screen the same way
else if (this.y + radius > height) {
this.y = height - radius;
this.velocityY *= -1;
console.log('this works too');
}
}
//this function updtaes the atoms' position after the click has happened, and the new atom is added to the array, its temporary position, so the one saved into the this.x and this.y parameters gets added to a randomised velocity value give above
move (){
this.x = this.x + this.velocityX;
this.y = this.y + this.velocityY;
}
//defines how the atoms actually look on the screen, and updates it every time
show (){
noStroke();
//fills in the circles, but the colours and the transparency is randomised
fill(random(0, 255), random(0, 255), random(0, 255), random(90, 200));
//actually drawing the ellipse or circle
ellipse(this.x, this.y, this.diameter, this.diameter);
}
}
Problems
Problems I ran into in the code was mainy with the bouncing: in the beginning it wouldn’t work, then it worked but only on two sides, then only on three and all atoms disappeared on the bottom, but in the end I did manage to make it all work. It also glitched sometimes into the wall.
I think I have already mentioned this, but the main problems I ran into were that I needed to catch up on the elements of a class, of OOP as a whole, and I didn’t realise this until AFTER I started working on the code, so I had to pause and watch some tutorials and explaining videos.
References:
I got the main idea from this video:
These two helped to understand the bouncing technique more:
Helped to understand how to push an object into array:
I think a strongly interactive system has to respond quickly and meaningfully to whatever the user does. Speed matters a lot, because if there is a noticeable delay between my action and the system’s reaction, the loop breaks and it stops feeling like a conversation. It should also accept a wide range of inputs rather than just one, and produce output that is fun and exciting to receive: sound effects, motion, color, and visuals that reward the user for engaging. Using Crawford’s framework, a strong system has to do all three steps well. It has to listen properly by capturing what the user is actually doing, think by shaping its response to that input rather than repeating itself, and speak clearly so the user can tell their action caused the result. Reliability belongs here too, since bugs and crashes break the cycle completely and a system that stops responding has stopped interacting altogether.
The other characteristic is the user’s own willingness to explore. Someone eager to poke at a system will have a far richer experience than someone who isn’t in the mood, even with identical software. A good system invites exploration by making its possibilities visible and by rewarding the first thing the user tries, which is what pulls them into trying the second.
For my own p5 sketches, my main idea is to widen the range of inputs they accept. At the moment I rely on a narrow set, so I want to make more use of the cursor; not just clicking, but position, speed, and dragging, so the sketch is continuously responding rather than waiting for one discrete event. I also want to use clicks to transform the artwork, so that each click shifts the sketch into a different look or state and gives the user a reason to keep going. Beyond that, I would like to experiment with 3D, since being able to rotate and look around a shape hands the user real control rather than just something to look at, and to play with motion that reacts to the user instead of looping on its own; if the direction or speed of movement responds to where the cursor is, the sketch is listening continuously instead of just performing.
After reading the chapter, I kind of agree with the author’s definition of interactivity, and I liked how he used conversation as an example. I also think the author put into consideration the different perspectives on what interactivity means. I understand why some definitions may seem subjective because people find it easier to relate one meaning to another word, but by doing that, the meaning can become more vague and less accurate. This can cause people to misunderstand or misuse the word in different contexts.
One of the things that grabbed my attention was the difference between reaction and interaction. A reaction is more of one action responding to another action, while there is no real ongoing exchange between the two. For instance, the branch-breaking example in the chapter, something happens, you do another action in response, and then it ends. Interactivity, on the other hand, is a give-and-take relationship where influence is an important part of the process. The user influences the computer, but the computer also influences what the user does next.
I think to build a successful interactive system, you need to have clear guidelines so both the user and the computer can understand one another. What are they communicating? How is the computer listening to the user, and how is it responding? With all of that comes the idea of influence: how is the user influencing the computer’s behavior, and how does the computer influence the user in return? You cannot just add a random interaction and call it a day. There needs to be a purpose behind it. Are you trying to get across a message? Is the program dependent on the user’s choices? For my p5 sketches, I think I could make the interaction more meaningful by letting the user’s actions actually influence how the artwork develops, and also give the user more control over what they can influence.
In his book, Crawford critiques the manifold ways we tend to ‘wrongly’ define interactivity. For him, it is more of a “conversation: a cyclic process in which two actors alternately listen, think and speak” (8). I really appreciated how he explained this idea using an analogy of two people conversing. While this helped me understand why the elements of this process are not substitutable, what really struck me was the difference he highlighted between interaction and reaction. He notes the sensation we get from reading, for instance, as describing an “intense reaction, and [that] interaction is not reaction on a higher plane of existence” (13). This can be very useful when it comes to designing for people. It allows us to take a step back and wonder whether our product is actually interactive or just a really well-dressed trigger. He cautions that, in this case, he is “not arguing that interactivity is the sole gauge of merit” (14).
However, this is where I find his language to not really match his claim. While he does mention that not everything needs to be highly interactive to be good, he introduces an interactivity spectrum, arguing that things like the refrigerator light are still technically interactive, just at a very low level. He even calls the fridge interaction “silly and beneath the intellectual dignity of almost everybody” (11). If interactivity were truly just one dimension among many, as he insists, there would be no reason for him to give low interactivity scores to certain things and dismiss them. This brings me to the question he raises in the chapter: “Does interactivity exist in the eye of the interactor?” (11). Saying something is low interactivity instead of not interactive still requires someone to decide where exactly it falls on that 0-to-10 scale, and Crawford never really explains who gets to make that call or by what standard. I think that his own examples suggest the answer is just him (his judgement), hence the name: “Crawford Scale” (15). So while I agree his framework gives us a much richer vocabulary than a strict binary, I do not think it earns the objectivity he implies it has. Nonetheless, this reading helped me ground what we mean by an interactive design, which I will use as a heuristic to evaluate my designs henceforth.
I often find myself wondering: beneath all the sleek design and high-definition media, what is the internet really made of? At its core, it’s nothing more than basic lines of text, numbers, and code.
This project is my exploration of that idea. By using basic alphanumeric characters (a-z, 0-9,@#%?&) as the fundamental “atoms” of my digital canvas, I let them generate randomly while using code to keep them organized and separated. It’s my way of turning raw, invisible data into a visual piece of art.
How this was made?
One problem I met at first is how to prevent the letters from overlap.instead of writing super long and confusing if statements to prevent letters from crashing into each other, I used a return;. If a new letter gets too close to an old one, the code just stops right away and tries again next time. It’s super simple and keeps the code clean.
for (let i = 0; i < charCount; i = i + 1) {
let c = chars[i];
let d = dist(x, y, c.x, c.y);
if (d < (size + c.size) * 0.45) {
return;
}
}
I didn’t just store the letter itself in the array. I packed its X/Y positions, size, letter type, and RGB colors together into one object. This makes it super easy later—my drawCharacter() function knows exactly how to paint it.
When I was setting up the object properties, my instinct was to write something simple like “color:rgb” or directly grab an entry from color palette I thought, “Why can’t I just store the whole color array together and hand it to fill()?” But when I tried that, p5.js didn’t handle the color array the way I expected inside fill(). I was so confused until I realized I had to unpack the array and store the RGB values as three separate properties (r, g, b) inside each object so fill(c.r, c.g, c.b) could read them smoothly.
Reflection
To be completely honest, my code went wrong a million times before it finally worked. Going into this project, I knew using an array was a strict requirement, but I didn’t actually have a deep understanding of how arrays function under the hood.
I spent a huge amount of time just trying to wrap my head around one fundamental question: Why couldn’t I just pick a random letter and a position inside AddCharacter() and paint it right onto the screen? Why did I have to save everything into an array first, and then write a completely separate for loop inside draw() just to repaint it every single frame? Wrestling with this concept and breaking down p5.js’s frame-by-frame rendering loop was easily the biggest learning curve for me.
Looking back, there are definitely things I wish I could have added: I wanted to experiment with cooler typography effects, like adding soft ghosting or motion shadows behind the characters, but it felt a bit too complex for my current skill level, so I decided to keep the visuals simple for now.And I’d love to explore adding interactivity in future versions—such as letting users click anywhere on the canvas to spawn specific words, using mouse clicks to control the generation order, or adding a click-to-clear button to reset the canvas and start over.
The main inspiration for this project came from a certain artwork in Casey Reas’ Eyeo talk on chance operations. I really liked the idea of shapes emerging from within other shapes, so I wanted to explore that idea through something more natural. What better example of something emerging than a flower blooming? I sketched a couple of different flower shapes first so I could have them as references while coding.
Progress
I started by creating a class for the flowers and defining their properties. Then I drew the flower and its petals, and used a for loop to add multiple flowers to an array. After that, I experimented with adding inner petals to each flower, which made the blooming process more visible.
But one problem I ran into was figuring out how to make the inner petals appear after the outer petals instead of growing at the same time. I wanted the flowers to feel like they were actually blooming. I solved this by making the inner petals start growing only after the outer flower reached a certain size. This created a delay between the two layers and made the blooming process feel more realistic. I then added different colors to the outer and inner petals and made sure they were not the same color.
While looking at the result, I noticed that all the flowers had the exact same angle of rotation, which made them feel too repetitive. I changed the rotation to be random for each flower, giving them more variation and a more natural feeling.
Finally, I wanted to add an interactive element. I imagined the mouse cursor as a kind of magical sensor: when it gets close to a flower, it makes the flower bloom faster. This makes the viewer feel like they are affecting the growth of the flowers just by moving through the artwork.
//INCREASE GROWTH SPEED WHEN MOUSE IS NEAR FOR OUTER PETALS//
let distance = dist(mouseX, mouseY, this.posX, this.posY);
if (distance < 80) {
this.size += 0.7;
} else {
this.size += random(0.05, 0.5);
}
//DELAY THE INNER PETAL SIZE INCREASE//
//INCREASE GROWTH SPEED WHEN MOUSE IS NEAR FOR INNER PETALS//
if (this.size > 12) {
if (distance < 80) {
this.innerSize += 0.6;
} else {
this.innerSize += random(0.2, 0.4);
}
}
Reflection
I am really proud of this project because I explored many different ideas and developed a deeper understanding of the concepts I was working with. If I were to alter anything, I would experiment with adding more variations to the flower shapes. However, I chose not to include this in the final piece because I felt that too much variation could make the artwork feel messy and take away from the blooming effect.
Based on Chris Crawford’s reading, string interaction acts like a two way conversation that needs solid listening, thinking and responding, and one weak part can break the whole experience.Beyond this idea,I also believe a good interactive system should feel approachable for regular users and give them room to experiment without breaking everything.human comfort also shaped the interaction.Even if a system completes the input-process-output loop, it stills fails as interactive work if users feel worrying they will crash the sketch etc.It should also meet users halfway:it does not demand expert knowledge to participate.New users can find satisfying results with simple actions, while people who dig deeper can still find more complex effects.there should not only be one “correct” way to interact.Multiple different user choice can all lead to interesting outcomes, rather than forcing users to follow one intended path.
For my own p5 sketch, I can make general improvements across Crawford’s three interaction stages. For better listening, I can try to out some music ,or built some interactions that allow users to record their own voice.For better thinking, I can let the system remember past user activity so responses build over time, instead of always triggering the same fixed outcome. For better speaking, I can add clear feedback so users can tell how their actions affect what they see.
I wanted to take our in-class example of making a car class/element and use the car as a pen to scribble over the canvas. The point of this type of generative art was to create an unending and random pattern, while giving the viewer an essence of cyclicalness as the cars seemed to rush towards the right end of the canvas, and then reemerge from the other side only to repaint over their own scribbles.
Moreover, I wanted to add meaningful interactivity in the form of terrain creation, where the user can drag their pointer on the canvas to create a muddy region. This muddy region slows down the cars horizontally while maintaining their constant aggressive back-n-forth vertically. This jitter zone eventually populates with ink much faster than the rest of the canvas, and, although the mud is eventually enveloped by the scribbles, the texture of that region remains visibly distinct and dense.
Adding the telemetry HUD showing real-time average speed was a fun experiment too, giving immediate visual feedback as soon as you trap cars in your mud pits.
Code that I’m particularly proud of
/**
* Steers agent away from nearby cars to maintain safe personal space.
*/
applySeparation(nearbyCars) {
let desiredSeparation = 14;
let steerX = 0;
let steerY = 0;
let neighborCount = 0;
for (let other of nearbyCars) {
if (other === this) continue;
let dx = this.posX - other.posX;
let dy = this.posY - other.posY;
let distance = sqrt(dx * dx + dy * dy);
// Apply repulsive force inversely proportional to distance
if (distance > 0 && distance < desiredSeparation) {
steerX += (dx / distance) * (desiredSeparation - distance);
steerY += (dy / distance) * (desiredSeparation - distance);
neighborCount++;
}
}
if (neighborCount > 0) {
this.posX += (steerX / neighborCount) * 0.04;
this.posY += (steerY / neighborCount) * 0.04;
}
}
}
Why: When spawning the initial cars in a grid, I noticed that often times overlaps would happen. I started with 900 cars (30×30) initially and would use per-car seperation logic, that would reduce FPS by a lot. To reduce this calculation, I decided to implement a solution called spatial grid updating. It immidiately boosted the FPS and it future proof.
Embedded sketch
How Was This Made
This project is built around an autonomous agent model combined with an off-screen persistent canvas:
Persistent Trails via createGraphics: Normally, calling background() in draw() clears every prior frame. To allow cars to act as drawing pens, I created an isolated rendering layer named trailLayer using p5’s createGraphics(). The car chassis, tires, mud, and HUD are redrawn continuously on the main canvas, while each car leaves permanent line strokes on trailLayer beneath them.
Organic Movement & Drawing: Instead of moving in rigid straight lines, each car is given a small randomized horizontal step and an erratic vertical offset (random(-4, 4)) on every frame. This converts pure vehicle physics into an energetic, hand-drawn scribble texture.
Interactive Mud Physics: The terrainPatches array records coordinates clicked or dragged by the user. On each update tick, each car performs a radius check against active terrain circles. When an intersection is detected, currentSpeed is cut to one-third of its maximum speed, concentrating the scribbles into dense clusters.
Color Scheme: The color palette was curated based on vintage Bugatti racing liveries (French Racing Blue, Rouge Garance, Deep Navy, Atalante Yellow, and Obsidian Black Carbon) rendered against an off-white, parchment-toned canvas (#E4D5B7) to evoke technical drafting or blueprint paper.
References & Inspiration:
Craig Reynolds’ Boids Algorithm: The separation logic in applySeparation() is directly adapted from Reynolds’ classic steering behavior rules for autonomous flocking agents.
Spatial Hash Grids: The SpatialGrid bucket implementation was referenced from standard 2D broadphase collision detection patterns used in real-time game engines.
In-Class Vehicle Class: The starting chassis and wheel coordinate offsets were built out from our foundational class OOP exercise.
Problems Encountered & Solutions:
The Screen-Wrap Laser Bug: When cars reached the right edge and wrapped around to x = -10, line(prevX, prevY, this.posX, this.posY) drew a jarring, full-width horizontal stroke across the screen. I fixed this by adding a conditional gate (if (this.posX >= prevX)) so trails are strictly drawn while vehicles travel forward.
Input Flooding on Mouse Drag: Dragging the cursor across the canvas pushed hundreds of identical terrain coordinates into memory every second. I added an addTerrainPatch() helper with a minSpacing threshold of 8 pixels, ensuring clean, evenly spaced patches without choking the update loop.
Future Improvements:
Currently, there’s only one type of terrain (mud), I would like to introduce a few more, such as a zero friction zone (ice patch) that boosts horizontal velocity over the zone. Additionally, the canvas currently gets too full, and the user has no way of canvas clearing. I could add a small corner button that clears the trails, or a long press that slowly clears out trails from bottom up. Another experiment would be adding sounds to each car based on spatial circumstances.
I really enjoyed reading the article, because I really like the style, and for most it really opened up my eyes. I think I mostly agree with what it is saying about the features of interactivity, that it has to “listen, think, and speak”, although it made me think of the question, whether this makes AI interactive or not. AI has all three of these features, but I personally wouldn’t put it into the same category as an interactive website, for example. I recognise, that it is a two-way communication, like one between two humans, but it feels like a midpoint between a human interaction and a website. I think, and I might be wrong because I am not entirely educated in this, but a website has more limitations than an AI in regard to their “speaking” or response to the interaction, but a human one is far more natural, AI is just statistically choosing the next best word. The article just made me think of interactivity as a scale, where I was trying to place AI according to my best knowledge.
This ended in me thinking of maybe randomness as a feature of a strong interactive system. The article/chapter mentions 3 (listening, thinking and speaking) but I think randomness, or randomisation in an interactive system makes it interesting to keep using it. For example, I could be talking to my friends every day, and we would have a different conversation each time, and so I have the urge to keep talking to them. Maybe randomness is not even the best word to use here. Responsiveness represents my point better, because randomness can become repetitive in cases of a website. For example I made my self-portrait have chnaging clothes to the click of my mouse, but the colours were chosen from a previously set array of colours. It was random yes, but after a while it just repeated the same colours and it became boring quickly. So I would say then, the fact that a system is able to store previous information and “speak” in regard to that, is another feature of a strong interactive system. I also have to agree that design should accomodate interactivity, and a strong interactive system has a design that is able to support that interactivity.
Just because of my nationality, I have to say that I really enjoyed when he mentioned Hungarian. I actually laughed when I saw it, because I really didn’t expect it, but it felt good to know that my language is being used as an example. I even had to send a picture of it to my family.
As for concrete ideas for my sketches, I can’t really say any examples, however I know that I want to move on from simple mouse clicks and try out something that might be more complicated or requires more research beforehand. I know that when last semester I was in CommLab and making my final assignment I was able to store some informations on the website with cookies. I am not sure how, if even this is possible here, but if it is I wouls love to experiment with it.
