I got stuck in the workshop trying to make the animations work as the rest of the group was starting filming the opening sequence and some shots of the device when it was not transforming.
My problems where that the friction between the bars was very high and they got struck when I tried to push them with a couple of different stuff. I made a roller thingy to get a wave-like motion and fork to push some bars half ways and some the whole way. The fork worked ok, but the roller was worse.
The Animation Fork - A fork to push the bars to make them move magically
Another group was on sound. They made an intro to express the anxiety that could ensue if you don't use our product. It's cool to see how just a couple of samples and an eerie background can do.
I wish I was a bit more involved in this as it is something I have very little experience with. The way we divided the work was more based on what skills we have and not on what we don't have. We jokingly focus on making the best video, but in reality I think we do sacrifice learning for a higher finish.
Our first day in the workshop starts with some sketching and we start designing our first artefact.
I was mostly in charge of manufacturing as I had the most experience in the workshop. There was some minor arguments about color but in the end we went with gold. I proved a somewhat bad choice as that spray paint took a lot longer to dry and we had some problems with the bars sticking when we tried to move them to fake the shape shifting.
Math gone wrong - Only 6.25 days fit. Back to the drawing board
Another group was on sound. They made an intro to express the anxiety that could ensue if you don't use our product. It's cool to see how just a couple of samples and an eerie background can do.
I wish I was a bit more involved in this as it is something I have very little experience with. The way we divided the work was more based on what skills we have and not on what we don't have. We jokingly focus on making the best video, but in reality I think we do sacrifice learning for a higher finish.
We started our video prototyping with a lecture about narrative and how to get your story through to the viewer. We discussed how the correct framing and cutting can make a scene more interesting and what the story arc does to engage the audience.
I have not had much experience making "movies", especially since I left art. Storytelling has not been a big part of my work so it was great to get more insight int that. I will think more about it in my work in the future.
Movies as prototypes
The concept of video prototyping was new to me. Not that I have not seen any but I have not identified them as prototypes. Now it makes perfect sense to me, communicating a design that may be impossible to implement right now may very well only be possible in a movie.
I can also see how I can use it in my work. Communicating an application flow or device use can be very useful when the real experience is hard to reproduce or when you present it to stake holders that aren't users.
Workshop: Netflix gesture UI
Brief: Explore free space gestures for controlling the following Netflix functions: play/pause, skip episode, volume up/down/mute.
We have one and a half hour to capture a design proposal on video.
Materials: video
Team: Zakiya, Simon and me
We made a video of me in a couch controlling the screen by waving my hands. It's a rough prototype with bad acting and timing but we learned quite a lot from making it. Just getting our hand dirty was very useful.
Brief: Make a menial task with a library theme more fun or competetive with a timer. Time 3h.
Materials: Arduino and what we find in the workshop.
Team: Kornelia, Josephine, Max (from PD) and me
Great expectations
Our initial idea was to make some kind of essay writing simulator, but we quickly scrapped that idea as it seemed like a game that would be hard to implement in any meaningful way. We moved on to some sort of book sorting challenge. The idea was to have a book shelf that could sense if all books where where in the right order and if not would collapse to spill all the books on the floor.
The idea was our first problem, it was too complex for such a short project and on top of that we set a very high bar on the finish. I think we could feel a bit of a different culture between the Product Design program and our own. I think we at IxD see our prototypes as more of a tool to test an idea and the PD students, I think, see it more as a finished product.
I think I often fall into this "trap", to make a polished prototype to impress others instead of really prototyping my questions and it was easy to get drawn into this thinking when a team member pulls this way.
Books
To speed up the making of the books we tried to cut cardboard in the laser cutter, this worked really good and we where able to create 16 books in a short time. Start up was a bit slow, mostly because we have not had any introduction to the machine and that the students in charge of helping did not know about some quirks with dotted lines. It took some time to sort out why the cutter wouldn't accept the files and it was frustrating to have to work through another person and to try to convince them that they should try my solution.
In the end I think we saved some time using the laser cutter and got a very clean result. Cutting everything by hand would be very time consuming.
Building the case
Max was the one working more on the book case. We designed it broadly together, establishing requirements and talking about solutions.
Sad Max - We are starting to realize we won't make it
Connecting it together
The books where cut from cardboard and glued together. Josephine found great book covers to use where the users could "easily" find the authors name to sort them in the right order.
Pattern of copper tape connects the books
The tape connecting the front and back of the books
In the end we struggled to get the connection between more than about four books. This is something we easily could have found if we just started with a simpler prototype.
The take away
We set our aim to high. We should have started making a small prototype and iterate to make it more complex and polished. But it was a good experience figuring this out and we found that failing is fun
We first got a historic recap of how Processing came to be, a history of IDEs and a glance of what generative art could be.
Intro to Arduino
The MAU Arduino kit
We went on with an intro to Arduino and buttons and such. We had a nice little library called EduIntro. That helped a lot as we didn't have to debounce the presses and would get stateful switch buttons for free. We where then set free to make a small project together with a student from Product Design.
As I had a bit more experience than most with arduino I could start playing with it a bit and showing my team mates how to do more stuff. I made a small Morse code LED blinker. It can at the moment just say "SOS", but do you really need more.
During the Processing part of the seminar I made some different small programs like an "analog" watch face and some other small things.
Workshop: Multiplayering a Singleplayer game
Brief: Take a singleplayer game and make a multiplayer input device for it. You got 4 hours (this became maybe 6 hours in the end).
Materials: cardboard, Arduino, copper tape, tape, glue and wire.
Team: Katten, Lottie and me
We started by deciding on a game. Katten likes the game Snake and we started brainstorming on how we could make that a multiplayer experience. We had some idea about letting the players crawl on the floor to connect point to steer left and right. The idea seemed more fun for a single player and was abandoned.
After that we started thinking of a music game instead. We decided to go with a Guitar Hero clone called Bemuse. It's not the nicest game but we just needed something to control.
Lottie shows some serious cardboard skills. It's quite clear the Product Designers have us beat when it comes to building physical stuff.
We found some plastic tubes and insulation lying around. It fit perfectly as we could route the cables through the tube and with Katten's soldering skills we could make them really robust.
We went a bit overboard with the copper tape. As it was a fast project we didn't stop and think of more effective ways of doing it. One thing we noticed was that players would not always get that they had to connect the vertical copper strips to the horizontal ground strip using the hand held pad. This would probably have been easier if we skipped the ground strip and just would have grounded the pads.
Drum and keyboard getting done.
Connecting the whole thing to the code.
Starting to connect the whole thing together I realized I had not thought about this so much during the design of the instrument. This is very unusual for me as I often think in code very early in the process. It felt like a new and fun process to first build everything and then connect it together. The program ended up being a very simple thing using the EduIntro and Keyboard libraries.
#include<EduIntro.h> #include<Keyboard.h>
// reconfigure these pins to be the ones where // you plug your wires byte tonePins[]={D8, D7, D6, D5, D4, D3, D2}; byte drumPin = D10; byte crashPin = D11;
// which are the keys you will be using ... ? byte key[]={'s','d','f',32,'j','k','l'}; int toneCount =7;
voidsetup() { // initialize the keyboard controller Keyboard.begin();
}
voidloop() { if(drum.pressed()){ for(int i =0; i < toneCount; i ++){ if(tones[i].pressed()|| tones[i].held()){ Keyboard.press(key[i]); } } } if(drum.released()){ for(int i =0; i < toneCount; i ++){ Keyboard.release(key[i]); } } if(crash.pressed()){ Keyboard.press(KEY_RETURN); } if(crash.released()){ Keyboard.release(KEY_RETURN); } }
The final version fully assembled.
The take away
We where very pleased with our results but there are a lot to improve. People had some problems connecting the copper pads with the handles. This could be improved by making them into keys instead. This would also let the players press more buttons at once and would probably help with the spacial orientation of the hands.
