Week #10

Playtest + progress update

Last week we ran a playtest at ITP where I got to show a first somewhat working version of The Red Line. My project is not exactly self explanatory even in its final ideal form, so I'm glad I got to practice on presentation too. I learned a lot from that.

The following are some of the things that came up a lot during the playtest:

  1. Some of the people didn't seem to fully understand what the scale means, or rather which side of it is the positive one and which one is the negative. For some of them it was quite intuitive, but as enough of them had trouble "reading" the work I realized I should make it clearer. Most people did seem to understand that this is about the tension that builds up between the two ticks, and that one is driven by an inner mechanism while the other isn't. Someone defined it as "Reality vs. Boundary".
  2. Another thing that came up a lot was "what happens when the red line is crossed?". As this was visibly a prototype this is an understandable question. I think part of the feeling I want to bring forth is about this — I want people to wonder what happens, and then at that moment perhaps realize that nothing happens — it's as up to you as it ever was — you can take that information in and act upon what you said you were going to do, or you can keep moving the line, or even ignore it and maybe hope it gets better (it goes both ways after all).
  3. Presenting it at ITP posed a unique problem — people thought it was interactive and wanted to touch move both ticks. They were almost disappointed when they realized it's really not very interactive. But I think my final design addresses that, as there's a transparent plastic layer covering the motorized tick, leaving only the red line exposed.
  4. People were interested in finding out how the calculation worked, and what kind of news goes into it. This might be a very ITP-people question, but I think it'll probably be interesting to others as well (I've shown it to friends outside of ITP that also asked the same questions, and while they are not technologists, they are artists / designers). If I can manage it, maybe for the Winter Show, I hope to put up a webpage that has all of that in-depth information that people would be able to look through.
  5. Some particularly interesting feedback I got was about making it more personal — they wanted it to be less abstract, and to get a clearer sense of what crossing the red line means to me. I've thought about this a lot, and entertained these ideas for a couple of days — I thought about adding some text on the scale itself, or icons on the ticks, and tried to come up with increasingly drastic list of things to write along it. But that started feeling like a different project — an interesting one(!), but not this one I'm currently working on. I did come up with a compromise though. More on this below.

I really learned a lot from the playtest, both from the feedback I got but also in terms of how I talk about the project, and the storytelling that goes with it. I decided to instead of presenting (and calculating the score) on a scale of negative to positive, I would instead do it on a scale of what I consider to be an acceptable living situation in Israel. So the scale would be from "full of potential" to extremely inhospitable. This works better with the concept too — this way the red line being crossed means the current situation is past my threshold for what I consider a livable or bearable living situation and therefore should leave (or not come back, in my case); it's how much I'm willing to risk or compromise.

I added some icons on the scale that represent this idea. I've showed it to people around the floor (first just the icons, then in the context of the device), and while it wasn't immediately clear to some of them, when seen in the context of the device it was much clearer. The "X" being the last position also proved very helpful to people in decrypting what's happening.

I spent most of the last week working out the final version of the enclosure right — making sure all the holes and dimensions fit all my parts correctly. I then finally sent the files to SendCutSend on Friday night, but received an email the next day saying there's an issue with the bending — they cannot do a "U" shape bend where the ratio between the faces is less than 1:2. I then had to change the design, remeasure the faces' length (the bend affects it just enough so if it's not correct the entire structure is skewed) and redo the chipboard prototype to ensure all everything lines up correctly with the new design (I divided the U shape into two sections, leaving only the front-facing face and the top one connected).

At some point I tried OshCut to see if I might be able to get the parts sooner and they had a nice simulation of the bending process that really illustrated what the issue with the U shape was...

Unfortunately I had to cancel the second playtest I scheduled with non-ITP friends, otherwise I wouldn't have been able to send the files in time (they will arrive on Nov 29th which realistically only leaves me 3 days to assemble everything). I also received all the additional parts I needed (hall sensors, DC buck converter, Power jack socket, and command strips). The next things I need to do are (in no particular order):

  1. Make the final circuit with the buck converter, hall sensors and a single neopixel that should light up whenever the score is updated.
  2. Arduino code: Implement a homing mechanism using the hall sensors. I also want to try to make the motor move a little bit back and forth every time it gets an updated position so it's more visible and looks like it's adjusting itself. Need to test how this feels. I also need to implement the neopixel part, and some optimization (like sleeping in between readings).
  3. General code: I need to make the request automatic (it's currently manual), and I need to implement pagination because the API request's results come in pages. I haven't done it so far because each page is a single API call and I have a limited amount. I also need to see why the MQTT kept disconnecting during playtest and address that. Might have to make it so the connection isn't continuous but turning on and off every once in a while.
  4. Provide more training examples for the model (scoring articles myself is a great mental load but I want to add at least ~50 more examples).
  5. Close in on the final design of the icons and redo the acrylic part.
  6. Model, 3D print and paint the final ticks and holders.
  7. Get washers / bushings to use with the device's handle. Also get spray paint for it as its dimensions weren't suitable for powder coating for some reason.

There are probably a few other things to take care of that'll pop up along the way. Hopefully everything works in time!

X button icon

Jasmine Nackash is a multidisciplinary designer and developer intereseted in creating unique and innovative experiences.