Author: Asma Al Murr

For this piece, I wanted the text to be the artwork. I was drawn to generative typography and to the way Arabic calligraphy sometimes forms circles and wreaths. That felt right for motivation: words orbiting you like support. Using p5.js, I kept the idea simple: move, rotate, repeat and let those small rules create rhythm.

Before I touched the code, I mapped the whole idea on paper. I drew quick thumbnails of a circle in the center, tested where the English and Arabic lines should sit (which one tilts left/right), and marked the button at the bottom so the composition felt grounded. I sketched a few ring sizes to see how the wreath should feel, then noted font options next to each sketch (tall/condensed for English, warm/legible for Arabic). I even made a mini color chart with high-contrast pairs to keep legibility strong. That paper plan made the coding step feel like tracing: I wasn’t guessing; I was just implementing a layout I’d already tested by hand.

The code is organized so the flow is clear. In `setup()` I make the canvas, center the text, and place a button at the bottom. In `draw()` I set the background color, then call one function to draw the ring and another to draw the button. The ring function repeats the Emirati Arabic line around a circle  so it looks more like art created through text. Inside the ring, I tilt the English line one way and a slightly larger Arabic line the other way. When I click the button, the quote, colors change, so every press feels like a fresh poster.

Conceptually, I’m showing the message in two voices. English gives punch and clarity; Emirati Arabic gives warmth and a playful touch with design. The outer Arabic circle feels like community, something steady around me while the inner cross of lines pulls my eye back to the center. Bright, high-contrast colors keep it readable and energetic.

I did hit a bump halfway through when I started messing with Arabic fonts. The letters were not connecting and looked wonky, basically it was unreadable. This set me back a good two hours since I started on a new P5js file as Prof Mang suggested, with just the most simple form of the code before I realized the issue wasn’t my code; it was the font itself. Some fonts don’t include proper Arabic shaping, and p5 will fall back to whatever it can. Then I switched to a full Arabic font (like “Noto Kufi Arabic”) and Instead of downloading the font I embedded it into the HTML which fixed my problem. This was a good learning lesson as it gave me more confidence in my coding abilities. I was so sure that I had probably messed up the code, I didn’t even give myself a chance to consider that the font was the issue.

Here is an image of the issue I was facing:

I’m most proud of the code that draws the Arabic ring. It took me a while to understand not just how to do it, but how I wanted it to feel. I kept imagining the words circling like quiet encouragement, not static but not too free flowing, it was really about finding that in between. Getting there meant a lot of trial and error: turning things a bit, nudging them outward, letting each repetition change in a small way so it didn’t look stiff. When it finally worked, the text stopped feeling like code on a screen and started feeling alive. That moment when something frustrating becomes simple and meaningful is why this section is my favorite.

 // outer ring (Arabic repeated around a circle)
  textFont(AR_FONT);
  let r = min(width, height) * 0.38; // radius
  let copies = 24; // how many stamps
  let spin = frameCount * 0.005; // slow rotation

  for (let i = 0; i < copies; i++) {
    let angle = spin + (TWO_PI * i) / copies; // angle around circle
    let wobble = sin(frameCount * 0.02 + i) * 4; // tiny breathing
    let size; // Cycle the text size
if (i % 3 === 0) size = 16;
else if (i % 3 === 1) size = 18;
else size = 20;
    push();
    rotate(angle); 
    translate(0, -r + wobble); 
    textSize(size);
    text(quotes[qIdx].ar, 0, 0); 
    pop();
  }

Going forward, I want to push the typography and build patterns from text itself experimenting with new pairings (e.g., Amiri or Markazi), and exploring grids, spirals, lattices, and simple art made only from words. I’ll play with  rotation and translations to see how meaning shifts as the pattern changes. If I had more time to work on this I would focus more on the interactivity part and less on the generative art part. Although this made a cool visualization, maybe I could explore with the users typing a feeling which would then be met with a motivational quote to match/ respond to that feeling. Overall, this was a great learning experience and made me more confident in using text for generative art.

Reading Don Norman’s The Psychopathology of Everyday Things made me completely rethink how I interact with technology on a daily basis. One line that really stayed with me was Norman’s insistence that “the relevant components must be visible, and they must communicate the correct message” (pg. 3). I realized how often I silently blame myself when I struggle with a poorly designed interface, whether it’s an oven with cryptic icons, an elevator with unlabeled buttons, or even a website with a confusing layout. Norman flips that perspective and argues that it is the designer’s responsibility to make the user successful. That shift felt empowering. It reminded me that confusion is not a personal failing but often the result of flawed design.

One example that drives me crazy, which Norman doesn’t mention, is airplane in-flight entertainment systems. The touchscreens frequently misregister input, and there’s rarely any immediate feedback. Even on otherwise advanced planes like the Emirates A380, the interface feels outdated and uninspired. Sure, it plays movies and basic games, but there is so much room for innovation. Applying Norman’s principle of feedback could solve part of this problem: a simple progress indicator would reassure me that my action registered and prevent the endless cycle of frustrated tapping. Beyond that, design could take a leap forward by enabling features like screen-mirroring from passengers’ devices, turning the system into a productive and personalized workspace. As Norman argues, “discoverability” should make it obvious what is happening and how to proceed, even in a stressful environment like an airplane cabin.

I also saw direct parallels between Norman’s ideas and my own work in interactive media. His discussion of signifiers felt especially relevant. In my p5.js projects, I often rely on subtle cues like highlight effects, error messages, or color changes to guide the user’s next step without lengthy instructions. This reading made me more intentional about those choices: I now see them as part of creating a coherent conceptual model that helps users immediately understand what actions are possible. For instance, in my recent race-car animation project, I could add small speedometer icons that signal users to click the cars and make them go faster instead of just writing instructions on the screen which feels bland. This would transform the interaction from guesswork into an intuitive and engaging experience, exactly what Norman argues good design should do.

For class discussion, I keep wondering whether “invisible design” can actually go too far. Minimalism may look sleek, but as Norman points out, interfaces still need to guide users toward the right actions. I’m curious whether making an experience completely over-simplified might strip away the sense of play and discovery that makes interacting with technology satisfying in the first place.

Overall, I really enjoyed this reading because it challenged the way I usually think about design. I found myself agreeing with most of Norman’s arguments, especially his claim that bad design, not user error, is often the root of frustration. This idea resonated with me because it takes some of the pressure off the user and reframes design as a partnership between human and object. I also liked how approachable and almost conversational Norman’s writing style was, it made the large concepts and conceptual models feel accessible rather than overly academic. If I had to critique anything, it would be that at times the examples felt a bit dated (doors and washing machines don’t feel as urgent as today’s complex digital interfaces), but even so, the principles were timeless. Rather than feeling frustrated, I came away from this reading motivated to pay more attention to how things around me communicate their use, and to design my own projects with more empathy for the user.

My artwork shows three race cars speeding along a simple racetrack. I love Formula 1 racing, so I wanted to recreate that feeling of speed. I was inspired by the basic car sketch example from our course website but decided to add my own twist and take it a step further by making it interactive. The cars keep looping so it looks like they are racing, and when you click a car, the FPS increases so it look like the race speeds up. Pressing R resets everything back to normal speed. I also designed a simple racetrack with grass, yellow side lines, and dashed lane markers so the cars look like they have their own lanes.

The inspiration for this piece came from our course website, which is where I found the basic car sketch as well as our substitute lesson last week with professor Riad where we explored the ball example using arrays and classes together. I used that same logic but applied it to race cars instead of balls. I also watched a few beginner p5.js tutorials on YouTube to understand how to make objects move, wrap around, and respond to mouse clicks. It took me a lot of time because I am a beginner, but I learned so much through the process.

Before starting to code, I sketched out my track layout and car design on paper. This helped me visualize the dimensions of the canvas, where the grass and track edges should be, and how many dashed lanes I needed to divide the road evenly. I also planned the car shape very simply just a rectangle with two filled circles as wheels  because I wanted something that looked good but stayed beginner-friendly to code. On the side, I brainstormed interactions like clicking for color changes or speed boosts, eventually deciding on the speed change because it made the race feel more alive. This sketch was a key part of my process because it gave me a clear plan and made the coding step much easier and less confusing. It also reminded me that even with simple shapes, I could create something that feels playful and interactive.

In terms of how I organized my code, I used a setup() function to create the canvas and make three cars with different colors and speeds. These cars are stored in an array so I can easily loop through them. The draw() function runs every frame and draws the track, moves the cars, and displays them. I made a Car class with three main functions: move() to update the car’s position, show() to draw the car’s body and wheels, and clicked(Mx, My) to check if the mouse is inside the car. I also made separate functions called drawTrack() and drawDashedLine() to handle the background design so that my code stays neat and organized.

One of the parts I’m most proud of is this snippet of code:

// make cars faster when mouse is pressed (click on any car)
function mousePressed() {
  for (let i = 0; i < cars.length; i++) {
    if (cars[i].clicked(mouseX, mouseY)) {
      fps = min(fps + 10, 120); // increase frame rate
    }
  }
}

// reset when R is pressed
function keyPressed() {
  if (key === "r" || key === "R") {
    fps = 60; // reset fps
  }

This code is what makes the program interactive and fun. When the mouse is pressed, the for loop goes through every car in the array and checks if we clicked on it using the clicked() function. If we did, the frame rate (fps) goes up by 10, but never past 120 because I used the min() function to cap it. This makes the cars look like they are racing faster. The keyPressed() function resets the speed when I press R. It took me some time to this figure out how to change the FPS, but once I got it working, it felt very satisfying and made the project feel like a real race.

This was my first time using classes and arrays together in JavaScript, so it took me a long time to get it right. I had to watch many videos, look at examples, and experiment with my code to get the movement, wrapping, and interactions working correctly. The biggest challenge was figuring out how to make the cars speed up when clicked I first tried changing only one car’s speed, but it looked strange. Eventually, I made the whole race go faster when you click, which feels much more exciting and gives the sense of a real race picking up speed. Even though it was challenging, I am proud of how it turned out and I learned a lot in the process.

Reading Chris Crawford’s The Art of Interactive Design reshaped the way I think about interactivity. Crawford defines interactivity not as a simple feature or function but as a conversation, a cyclical process of listening, thinking, and speaking. What really drew me into this reading the most was his insistence that many things we casually call “interactive” are not interactive at all, because they lack a genuine back-and-forth exchange. Clicking a button or watching an animation play is not enough if the system does not “listen” and respond with meaningful output that takes the user’s input into account. This shifted my perspective away from thinking of interactivity as a checklist item and toward understanding it as a measure of quality and how deeply the system engages with its user.

One passage that stood out to me was Crawford’s description of the conversation between Gomer and Freedgund, where both must listen, think, and respond to create a true dialogue. It made me question: How do we measure good listening in a digital system? Algorithms process data, but does that count as “thinking” or “understanding”? This question feels even more relevant today, with AI systems claiming to “converse” with users. Crawford’s argument suggests that the test of interactivity lies in whether the user feels heard and whether the system’s response prompts further exploration or reflection.

Reflecting on my own work with p5.js sketches, I realize I have often stopped at surface-level interactivity: a mouse click might trigger a color change, or the position of the mouse might move a shape. But these interactions rarely invite deeper engagement. A strongly interactive system, in my view, should encourage curiosity, creating an open-ended dialogue where the user feels like a co-creator. Moving forward, I want to implement more engaging interactivity for example, using the speed of the mouse movement to alter the size or complexity of generative patterns, or incorporating audio could be an interesting way of engagement. Adding unpredictability by using randomness is also a key factor that could make the experience feel more alive. Ultimately, I want my sketches to feel less like static art pieces and more like evolving systems that “listen” to the user and respond in a way that makes them want to keep interacting.

For this week’s task, I wanted to bring together two ideas: my love for the Arabic language and our class discussion about randomness. I decided to focus on the Arabic letter Alef because it’s such a fundamental and visually striking character (also its the letter my name starts with). I thought it would be interesting to combine something very structured and cultural, like the Alef, with something unpredictable, like random color and rotation. The result is a sketch where one large white Alef sits in the center of the screen, steady and grounded, while smaller Alefs surround it, each taking on different colors and rotations whenever I click the mouse. I like the contrast this creates, the main Alef is constant, but the surrounding ones are always changing, almost like a conversation between structure and randomness

Before I even touched the code, I started by sketching my idea out on paper. I drew a large Alef in the center of the page with smaller ones scattered around it, which helped me figure out the overall composition I wanted. Seeing it on paper gave me a clearer sense of how the final sketch should feel. Having this rough plan in front of me made the coding process much smoother, since I wasn’t starting from scratch on the screen, I already had a visual map to follow.

A highlight in my code that I’m proud of is definitely the drawAlef() function. At first, it took me a long time to figure out how to break down the shape of the Alef into basic rectangles. It was a process of trial and error to get the base, and the hamza shape (figure above the base), and the over Arabic letter to look right and accurate together. Once I finally got it to look like an Alef, I was proud because it felt like I had “translated” something cultural into the language of code. It also makes the rest of the sketch easier to manage, since I can just call drawAlef() whenever I want another Alef, no matter the position, size, rotation, or color.

// draws one Alef at (x,y) with scale s, rotation rot, and color col
function drawAlef(x, y, s, rot, col) {
  push();
  translate(x, y);
  rotate(rot);
  scale(s);
  fill(col);

  // alef base
  rect(0, 0, 20, 120);
  
//drawing the hamza (همزه)
  // hamza base
  rect(0, -70, 75, 10);

  // hamza vertical
  rect(0, -90, 10, 40);

  // hamza horizontal
  rect(25, -105, 40, 10);

I really appreciate how P5js allows me to write comments in arabic without messing up the structure left to right, notice how it let me put the word (همزه) in the correct position!

This project was definitely a challenge for me, and I had to look online for a lot of help to figure it out. I came across new ideas like lists (arrays), which let me store lots of values at once, such as the positions, rotations, and colors for my mini Alefs. I also learned about the commands push() and pop(), push adds new values into a list, while pop helps reset drawing settings so my transformations don’t mess up everything else. Another big step for me was understanding how i works in a loop, and how i++ increases it each time the loop repeats. At first, these concepts were confusing, but using them in my own code made them click (no pun intended). Now I feel like I have a better grasp of how loops and arrays work together, even though it took a lot of trial and error to get here.

Looking back, I think the project works well in showing how randomness can bring life to something as simple as repeating a letterform. At the same time, I see room for future improvement. One idea I’d like to try next is adding motion, for example, making the mini Alefs slowly rotate or drift across the canvas, instead of staying frozen until I click. This would create a more dynamic sketch, almost like the Alefs are floating around the central figure. Another idea could be experimenting with gradients or fading effects so that the Alefs don’t just appear instantly in new colors but shift more gradually. Overall, this project gave me confidence in writing loops and using functions creatively.

In his talk on chance operations, Casey Reas, an artist, professor, and co-creator of the Processing programming language explores how randomness can be both a force and a generative tool in the making of art.

What drew me in most in Reas’ talk was the tension between control and surrender. His practice shows that randomness in art isn’t just chaos, but a tool for opening up creative possibilities. I found myself agreeing with his point that randomness can act as a “starting point”, like a door cracked open to reveal paths the artist might not have consciously chosen. For me, this resonates with John Cage’s example of random chance operations for musical symbols showed in the video, where unpredictability forces both creator and audience to reconsider what structure even means. At the same time, I can’t help but notice that Reas often reins randomness back into systems of symmetry and geometry, which makes me question whether he is truly embracing chance or ultimately seeking to discipline it. That tension raises a larger question: do artists ever fully give up control, or are they simply redefining the boundaries of authorship?

What challenged me most was his framing of post-WWI art as shifting toward more ‘automatic’ processes in response to destruction. While I see the logic in his argument, it seemed to privilege systematization, order and process as the most meaningful artistic response. This made me wonder if such a view unintentionally downplays the equally powerful role of intuitive or emotional art that also emerged from the same crisis. Personally, I’ve always seen randomness as something threatening, a loss of clarity, but Reas’ examples of layering it into fashion, architecture, or even modeling cancer cells made me reconsider. His work makes me ask: if randomness is unavoidable in life, is the role of the artist to harness it, or to expose its rawness without containment? That question lingers with me, and I think it pushes me to rethink my own preference for order as the only path to meaning in art.

At the same time, Reas’ talk made me consider how much my own creative process relies on hidden forms of randomness. Even when I plan a project down to the details, chance still slips in, through accidents, glitches, or unexpected associations, and often those “mistakes” end up carrying the most meaning. I think I’d like to incorporate random elements into my work as a way to break habits and push past predictable choices. Even something small, like letting code generate unexpected colors or positions, could spark ideas I wouldn’t have considered. For me, the ideal balance is somewhere in the middle: too much randomness feels empty, like the work loses its voice, but too much control risks suffocating the piece. I view randomness as something that works alongside intention, not something that overrides it, a way to keep the process alive and surprising. Reas similarly argues that randomness is not the opposite of intention but a collaborator, and that idea really shifted my perspective. Instead of resisting unpredictability, maybe it’s more useful to design spaces where it can push me outside my comfort zone. This raises a final question I’m left with: in a world increasingly defined by algorithms and precision, is cultivating randomness a way of keeping art (and ourselves) human?

I was so intrigued after the talk that I even explored his personal website, and I loved its throwback, almost nostalgic HTML aesthetic, it felt like a deliberate extension of his philosophy of simplicity and structure. I appreciated how it didn’t feel so commercial. It looked like it was made raw, and for the people who searched for his work. This was a refreshing take compared to the cookie-cutter portfolio websites we see artists use today.

I will link it here: https://reas.com/

The moment a friend joked that I’m “basically a flower,” while I was brainstorming ideas for this task, I knew exactly what I wanted to draw! A happy, cartoon daisy standing in for my portrait. Instead of wrestling with a realistic self-portrait, I leaned into something more playful and honest, something that resembled me in being bright, a little goofy, and imperfect in the best way. That choice took the pressure off and made the assignment fun, I wasn’t proving I could render a realistic portrait, but rather show a bit of personality.

Color was deliberate in this portrait. I picked a soft pink background (`#fae`) because it feels light and friendly, like a page from a sketchbook. The petals are white with a clean black outline because daisies are my favorite and that crisp edge gives a bold, sticker-like cartoon look. The center is a warm yellow (classic daisy!), and the stem is a saturated green so it reads immediately even at a glance. Together, the palette stays simple, cheerful, and high-contrast, perfect for for clarity on screen.

There were two small decisions that made a big difference. First, was the draw order: I coded the petals before the center so the yellow circle sits neatly on top. p5.js applies fill and stroke at the exact moment you draw, so layering matters, getting that step right eliminated messy overlaps without extra code. Second, the smiley face: two tiny circle calls for eyes and a single arc for the smile gave the flower a personality however this was probably the hardest part. I watched a few YouTube videos about coordinates which is how I learned to use “cx” and “cy” so I wasn’t typing magic numbers everywhere (much easier to tweak).

The smiley face was the specific piece of code that I was proud of. I know it looks very simple but it definitely took me the longest time to get right without looking completely wonky!

// Smiley
 const cx = 300, cy = 200;
 fill(0); noStroke();
 circle(cx - 20, cy - 15, 12); // left eye
 circle(cx + 20, cy - 15, 12); // right eye
 noFill(); stroke(0); strokeWeight(4);
 arc(cx, cy + 15, 60, 40, 0,PI);

What went well: I kept the geometry minimal (lines, ellipses, and circles). The result feels cohesive: the color palette, the outlines, and the proportions all read “cartoon daisy” immediately. What I could have done better: the petals aren’t perfectly placed since I originally wanted to do 5, and they look kind of odd, some spacing could be cleaner. I wish I had more time to work on this so I could adjust the shapes to my liking.

Looking ahead,  I’d also like to add motion, a subtle stem sway maybe or a smile that reacts on hover/click. Or perhaps, adding clouds or a sun in the background. For now, I’m happy that it isn’t perfect, neither am I, and that’s kind of the point. I’m still getting into the rhythm of JavaScript, and this little daisy felt like the right way to bloom.