"Skipper's Dreamhouse"

"Skipper's Dreamhouse" is a scary house that first reacts to movement at a far distance, then waits for the viewer to come closer. Once the viewer is at a certain close distance, a random timer is triggered and the deconstructed Barbie doll, Skipper, pops up to scare the viewer. Throughout making the project, various decisions were made often having to compromise aesthetic over practicality; however, on the whole the house fits the spooky, homemade, childish vibe. If we were to further this project, we'd love to add sound, either with sound effects or music that reacts to the viewer, etc. As for the title, we slowly created this narrative that Barbie's little sister, Skipper, wanted her own dream house and it is terribly spooky. We joked that it could represent somewhat of a critique on Barbie and the stigma surrounding her, as we have deconstructed the doll to just her flailing limbs, showing how her appeal consists only of mindless, emotionless body -- an ultimately ~spooky~ idea to be teaching little girls. We contributed equally to the concept of the project and problem solving, where Cassie contributed more to the Arduino software and Olivia to the outer appearance. Overall, although we hit a lot of speed bumps, it was fun and the problem solving resulted in a satisfyingly spooky project.


Working on this project was an immensely informative experience for me. My partner Huw had a lot of prior experience with arduino and working with physical computation in general, while I was relatively new to working in that way. We went through many different ideas before we came up with the idea of a marionette drummer made of trash, playing in a whacky, improbable manner in a room also made up of disposable "trashy" material. We were inspired by the materials we were working with, such as the dirty-looking carpet fuzz sheets, carpet crumb, pieces of a broken nerf toy and colored felt.

It was the use of these unconventional materials that led to a source of conflict for me and my partner (chewie) as we were trying to figure out to what extent we should try to use our materials to emulate a representation of a real space, or stick purely to our materials and not try to hide what we were working with. At one point our automaton sported a costume, a paint job and went through a few different caricaturized heads. It was after a great deal of discussion that we concluded that this attempt to aestheticize our materials was actually just clashing with the rest of the project. We removed the costume and the paint and added in the tennis ball bobbing on a spring instead, to both of our satisfaction. On the other hand, using the playing cards to make a poster, dowels and scrap metal for the drums and carpet, cardboard and foam for the bed turned out to be pretty effective as a story-telling device. We took to calling our automaton Wilson (for obvious reasons).


As far as the division of labor went, I had been learning about puppetry in my video class and was able to apply those skills to making a simple marionette puppet. I then used code from the servo sweep example as well as the motor party example to get Wilson to play. I used the spare parts I had to put together a simple drumset. My partner (chewie) was instrumental in creating the room set, and without him our project wouldn't be nearly as sturdy, nor would our wiring work. He came up with the look for the interior too, for things like the poster and the unmade bed. The most valuable contribution chewie made however, was his unwavering perfectionism. I tend to let things slide and be ok with parts of my work not being effective. chewie made us iterate multiple times through elements of the piece that just weren't working. In addition to changing the costume and color, the initial armature for Wilson was rolled cardstock, the furniture was fully cardboard and the head was a sketched-in face of John Bonham with tacked-on hair. These were all either details that were lacking in thought, or they impaired the wild and free motion of Wilson, which was clearly the focus of the piece. I was surprised by just how much one can roll back and revert changes when working with physical objects. Although we had no CTRL-Z or Github to fix our mistakes, working with actual physical layers of materials felt like there was a concrete sense of version control after all.



Perry and I let this project grow organically. We didn't create any sort of pre-formed idea or plan, but instead let our explorations at The Center for Creative Reuse and the other available resources guide our process.  We returned from the shopping trip with a bag of intriguing junk that we knew had potential to become some sort of disturbing creation, and got to work putting it all together in a way that would be both unsettling and aesthetically pleasing.

We collaborated on coming up with weird ways to use the materials we had on hand, and as Perry is more familiar with what the Arduino can do, he set up most of the physical computing and code. My role was in design, aesthetic input, and documentation.

An interesting note about this project is that because we didn't start with a concept, it was almost ludicrous how it all came together in the end.  One of the random objects we got from The Center of Creative Reuse was a stack of old religious booklets and fliers. When flipping through them near the project's completion, we found out one of the booklets was about a girl named Margaret who had a backstory that had uncanny resemblance to the situation we had put our doll in. And so, accidentally but fittingly, a our project happened upon a narrative.





This project came naturally to me since I'm interested in dance and videography. From the beginning, I was curious about how I could convey movement, choreography, and group dynamics with the motion capture resources provided.  I wanted to study how choreography that relied on more than one dancer created compositions with bodies and movements on screen.


I went through several iterations of how I could convey what I wanted to, so after figuring out how Posenet worked, I ended up making a lot of visual representations of bodies in movement using some of my favorite dance videos. A lot of these I trashed because they looked too clunky and didn't feel right. It felt eh getting rid of several hundred lines of usable material, but in the end, I decided that visual simplicity and readability was more important than the technical work behind it.

I was not aiming for accuracy with this project, and I was okay with an end result that was not so minutely tied to the body in particular since I wanted to visualize several bodies in relation to each other. I wanted some sort of big picture, wholistic experience rather than something dependent on accuracy. Early on, I found that Posenet would never be able to capture the bodies as well as I wanted to, so I decided to use that messiness as an advantage. I kind of like how it sometimes mistakes body parts for each other, or sees a phantom body part in the wall somewhere.

The first, second, and fourth video in the compilation are all choreographies/videographies that I love a lot. The third video is one that I filmed for KPDC, a dance club on campus. I was interested to see how a video that I produced compared to those that I admired.

Still Images:


// Copyright (c) 2018 ml5
// Copyright (c) 2018 ml5
// This software is released under the MIT License.
/* ===
ml5 Example
PoseNet example using p5.js
=== */
// PoseNet with a pre-recorded video, modified from:
let poseNet;
let poses = [];
let poseArray = [];
let noseArray = [];
let leftWristArray = [];
let rightWristArray = [];
let rightAnkleArray = [];
let video;
var videoIsPlaying;
function setup() {
  videoIsPlaying = false;
  createCanvas(833, 480);
  video = createVideo('yabbay.mp4', vidLoad);
  video.size(width, height);
  poseNet = ml5.poseNet(video, modelReady);
  poseNet.on('pose', function(results) {
    poses = results;
    if(poses.length > 0){
function modelReady() {
    console.log('Model Loaded');
function mousePressed(){
function draw() {
  image(video, 0, 0, width, height);
function drawKeypoints()  {
//   for (let i = 0; i < poses.length; i++) {
//     let pose = poses[i].pose;
//     for (let j = 2; j < pose.keypoints.length; j=j+10) {
//       for (let k = 3; k < pose.keypoints.length; k=k+10){
//         for (let l = 4; l < pose.keypoints.length; l=l+10){
//           for (let m = 5; m < pose.keypoints.length; m=m+10){ // let keypoint = pose.keypoints[j]; // let keypoint2 = pose.keypoints[k]; // let keypoint3 = pose.keypoints[l]; // let keypoint4 = pose.keypoints[m]; // // if (keypoint.score > 0.2) {
//         strokeWeight(1);
//         stroke(255,0,0);
//         beginShape();
//         curveVertex(keypoint.position.x, keypoint.position.y);
//         curveVertex(keypoint2.position.x, keypoint2.position.y);
//         curveVertex(keypoint3.position.x, keypoint3.position.y);
//         curveVertex(keypoint4.position.x, keypoint4.position.y);
//         endShape();
//       }
//     }
//   }
//   }
// }
// }
  for (var i = 0; i < poses.length; i++){
    let pose = poses[i].pose;
    for (var j = 0; j < pose.keypoints.length; j++){ noFill(); strokeWeight(1); makeVectors("nose", pose, j, noseArray); makeVectors("leftWrist", pose, j, leftWristArray); makeVectors("rightAnkle", pose, j, rightAnkleArray); stroke(255); makeConnections(leftWristArray); makeConnections(noseArray); makeConnections(rightAnkleArray); } } } function makeVectors(part, pose, j, partArray){ if(pose.keypoints[j].part == part){ stroke(0, 0, 255); ellipse(pose.keypoints[j].position.x,pose.keypoints[j].position.y, 10); partArray.push(createVector(pose.keypoints[j].position.x,pose.keypoints[j].position.y)); if (partArray.length > 4){
function makeConnections(partArray){
  for (let k = 0; k < partArray.length; k++){
    curveVertex(partArray[k].x, partArray[k].y);
function vidLoad() {
  videoIsPlaying = true;
function keyPressed(){
  if (videoIsPlaying) {
    videoIsPlaying = false;
  } else {
    videoIsPlaying = true;


Spectacle: I see "spectacle" as work that pushes the limits of our notion of what we can do with the tools and knowledge we have at our disposal as a community of artists. An entirely-spectacle driven work would likely give the audience a new way of generating content, but lack in self-awareness or meaning that transcends its time and medium.
Speculation: I see "speculation" as an experiment of some immutable artistic concept in a novel way. An entirely-speculation driven work would probably cause the audience to question the way they think about a certain concept, but lack real world applicability as a product.

A few weeks ago I came with an idea for an idle-clicker genre of game called Penis Simulator. This was during a period in Concept Studio: Systems and Processes where we were to create work in response to a system within the body, and I was working with the reproductive system. I think my project erred on the side of Speculation while modestly dabbling in Spectacle. Penis Simulator gives the player a virtual abstracted representation of a penis and testes, and by rapid mouse clicks and dragging vertically the player can control temperature and testosterone levels to achieve the open-ended goal of raising over-all sperm count. The result was one of the rare few times I have seen that something as sexualized and perverted as a human penis perceived as a totally non-sexual, sterile object with simple inputs, outputs and controlling variables. My professor expressed her discomfort and called the project problematic on a few occasions but overall the game had a positive response both amongst testers required by the class to play my game as well as people interested in trying it out of their own volition. I see my work so far as a proof-of-product and want to use what I have learnt from Warburton's argument to integrate a more substantial element of spectacle into the speculation piece I have created.

Recorded Version of two people talking and exploring some visual feedbacks

Click To enter full-screen mode

This is a dynamic chat room. The idea is that user can see the visual response of the content and words they are putting into the conversation. The font, color, position of the text, and typography all change corresponding to the content of the conversation. For example, when typing "right", the text will go towards the right edge of the chatroom. Similarly, when typing "left", the text will go toward the left edge of the chatroom. When typing "larger", the text size will increase, and when typing "smaller", the text size will decrease. Moreover, the similar idea applies to the color function in which when users type keywords of different shades of color, the color of the text will change. Other more reactions can be found when typing "bold", "child", "design", "Halloween", "scare", "scary", "fear", "essay", "report", "homework", "study", "important", "highlight", "tension", "note","technology", "computer", "coding", "computing", "round","circle", "hand", "poe", "literature", "letter", "dot", "tight", "squee", "italic", "Italic".
I always feel like text in conversation can be more fun and interesting than what it looks like now in messaging apps (all in default gray color and same size). Except for using emoji, how can text itself express anything interesting? If the text can do more, maybe we can get rid off emoji. The original idea of this project was to incorporate the basic emotions ("joy", "angry", "fear", "surprise", "disgust", and "sad") to execute the changes of type. However, this idea generalizes people's current state of feeling and have many issues with the user experience, therefore, I changed and developed the current version of the project, hoping the idea will come across with more interesting user interactions.


This is a chatroom where the more words you try to use in a single message, the more deteriorated and confusing the message becomes. If you send short messages of few words, the room will usually send the message as is. If the user tries to use too many words or letters, the message starts to disappear.

My original concept for this chatroom was a platform where the user has to collect the materials needed to construct their sentence. I planned on including some sort of pixel pile that you would have to collect from to get enough material to type out and send your message.  In the working app above, each message is given a certain amount of length tolerance- the longer a message is, the more likely characters are to be missing. The result is a tool that forces the user to use as few words as possible at the risk of having their message made unreadable.

The design aspect that this project addresses most clearly is its criticality and self-awareness. Ordinarily, chatrooms like this have no limit to the length of messages you can send. With most things we do in life, however, there is a trade off between pleasure or action and the resources spent to make that happen. By using this chatroom, where there is an implied limit to the length of your message it makes the user consider the "luxury" of digital tools their limitless theoretical resources.


Trucker Chat:

Chatroom for Incoherent CB Radio Communication Between "Truckers"



In the beginning phases of working on this project my ambitions were much higher, possibly wanting to work with Spotify/music APIs and drum machines. However, I quickly decided that I just wanted to make something simple and fun to allow me to spend time learning and experimenting with new techniques, features etc. A constant concept through my process, has been the idea of equal roles between all users. When text is manipulated and messed with to a point of incoherence, it really puts all users on the same level of not understanding what's going on and having a good laugh. Experimenting with Rita and regex really shaped most of this project because I was mainly text focused and had also never used either one of those ever before. Although there are a lot of bugs and the project could be a lot more, I had a lot of fun and I learned a lot. (Also all of the trucker slang is real, here is a breakdown of what most of it means)

Trucker Slang Meanings 


Strata #3 - Excerpt from Quayola on Vimeo.

"Strata #3" is a film and installation project commissioned by Evento and Lumin for the 2009 Bordeaux Art & Architecture Biennale. Directed by Quayola, the project utilizes the aesthetics of classical architecture and Renaissance art combined with generative patterns and technological analysis of the original artwork in order to create a psychedelic and fragmented artistic experience.

One thing that inspired me is the creative use of "old" art and new technologies in one project. I love how the project feels familiar and yet completely new at the same time. The music in the video also pairs very well with the artistic direction of the film. The visuals are stunning and the concept itself is brilliant. I'm not sure how this would have looked in real-life as it was mentioned that this is an installation as well, but from the video, it is amazing to look at.