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 have decided to make a device that visualizes the next seven days in your menstrual cycle. We want a device that is desireable to have in your house as decoration, and it should be abstract but informative for the woman and possible partner.
We landed on a some kind of physical bar chart that shows the next week.
We toyed with the idea of making several parts to our concept. An app, a thermometer and a shape changing artefact. We scrapped this as we realize we are not making a real product anyway. If we are faking the shape changing part we can as well fake the functionality.
Storyboarding
So what story do we want to tell? We want to show three different use cases, using it as contraception, wanting to get pregnant and to know when to expect your menstruation. We want as little acting as possible as we are not actors. We will have to show a quite abstract and complex concept in a clear fashion, that will be hard. Will people be able to follow and understand? We have an idea of something slick and cool, lets see how it pans out.
I was away during this day but I have read the texts that where the base of this lecture and will reflect on them here
Space exploration
The Anatomy of Prototypes: Prototypes as filters, Prototypes as Manifestations of Design Ideas, by Lim, Stolterman and Tenenberg, discuss the use of prototypes in the design process and formulates a new framework for thinking about prototypes. They argue that the old way of thinking Lo-Fi or Hi-Fi is flawed as it does not really take into account what the prototype is for.
The authors talk about how externalizing your ideas by sketching and prototyping help you traverse your design space and find new solutions and problems in the process. In their study of prototyping they build a framework to define the anatomy of a prototype. This anatomy makes it easier to discuss and evaluate the purpose of the prototype and what meaningful knowledge it brings.
The fundamental principle
Prototyping is an activity. A prototype is not a product but a tool to explore a possible design and it should manifest the qualities you are interested in researching without distorting the concept as a whole.
Economy
You should strive to make a prototype that is simple and efficient. The simplest you can to just measure the things you want to measure.
Anatomy
The anatomy model consists of two main parts:
Filters
What do you want to explore with your prototype. If you just want to get a sense of how the artefact feel when handling you might want to focus on appearance, but if you want to get to know if the GUI interactions you may need interactivity and more functionality.
Appearance: The physical properties of the design. Colors, size, weight and more.
Data: How accurate is the data in the prototype? Do you have real or filtered data? Do labels real?
Functionality: Are all the functions implemented or just some or even any?
Interactivity: Is feedback real? Can you interact with the prototype or is it just a block of wood?
Spatial Structure: This may be app layout or relation to different parts of the prototype.
Manifestation
THe manifestation is more about the look and fell of the prototype. These qualities can impact the data you get out of prototyping, often in ways you might not know beforehand.
Materials: What materials are used? This will have an impact on the look and feel of the prototype.
Resolution: How polished is the manifestation? This is what people talk about when they discuss fidelity in prototypes.
Scope: How much is implemented in the prototype? Closely tied to filters.
Is it relevant?
I think the empirical studies this is based on are a bit low quality. 8 subjects in a study makes it hard to draw any reasonably grounded conclusion but it speaks to my gut feeling. I don't think is the best way to grade a papers contribution to the field but I don't have the experience to do a thorough analysis of merits and faults in their thinking. The researchers seem to add a lot to de vocabulary about prototypes and give us new tools to analyze and discuss prototypes.
The take away for me here is "find the manifestation that, in its most economic form, will filter the qualities in which the designer is interested, without distorting the understanding of the whole", this is in my opinion an elegant way of phrasing a quite complex problem. A key insight is that different manifestations can give different evaluations where the audience perceive different aspects. LoFi vs HiFi can give different insights and are not necessarily different quality.
The text as a whole was very interesting and gave me new insights but it was also very repetitive and complicated. It could really use some editing.
The Houde & Hill model: Role - Look & Feel - Implementation
Prototype Prototype Prototype
In what do Prototypes Prototype, Houde and Hill introduce a model for talking about what a prototype does as opposed to the more traditional discussion about what it looks like. Their stance is that every artefact a designer uses is a prototype.
They introduce the notion that prototypes can be "ready made" objects and all artefacts that answer design questions are prototypes. A brick can be a prototype if you want to test the weight and size of a product.
A balanced triangle
Houde & Hill introduce a model for planning and evaluating prototypes, a triangle that is not resting on any corner or side to show that none of the qualities discussed is the base or the point. The model has three corners: Role, Look & feel and Implementation and when you combine them you get integration.
Role: Artefacts high up in this dimension explore what role the product would have in a users life. It is about how you would use the product and could be as crude as a hand drawn story board or a highly polished video prototype.
Look & Feel: These prototypes are meant to evaluate how the artefact look and feel when used. We can disregard user value and functionality and focus on delivering a prototype that explain the aesthetic values of the design. It can be a very polished slide show or just an object trying out size and weight.
Implementation: This kind of prototype is a functional product but without the right UI. It could be a smartphone voice assistant that is not in a smartphone but otherwise work as intended or algorithms that solve a problem.
Integration: Artefact that prototype all aspects are integrated prototypes. They are more or less complete and can show problems and opportunities in the package.
A seminal piece
As a seminal paper on prototyping it feels more like a think piece than research. It raises interesting questions about the importance of a correct vocabulary to discuss prototyping. It also broadens the term prototype and shows the importance of making different artefacts to test different aspects. The thought on audience is also interesting and I feel I have made mistakes in that regard multiple times. I have not understood my audience and therefore showed the wrong prototype.
To sum it up
Both texts give me a new language for describing my prototyping. They also gave me insights into the importance of iterating and making quick prototypes. I have a tendency to overwork my prototypes as if they where products. This could also be in part attributed to a lack of opportunity to work in an iterative way during our courses. We often have to show results after just a few days and that is not enough to make many prototypes.
Brief: Make a video prototype of a shape changing object. Tell the story of how it is used and what user value can come out of it.
We have 3 weeks to do it.
Materials: Video
Team: Malin, Zakiya, Cathrine, Simon and me
We started our work with some ideation sessions. In Methods 1, we learned some techniques that we found really helpful. Just sitting and writing random ideas for five minutes helps create lot of new ideas. Some will be very bad but a few will be something you can work with. We went on with some more sessions where we riffed on each others ideas.
Organizing our chaotic minds
My favourite idea was a scarf/gps that shows the way by pointing in the right direction or the telepathic tape roll "TeleTape". These devices might not have been the most serious so they where abandoned along the way.
After a while we had some ideas we could discuss and we chose some kind of device that would visualize your menstrual cycle similarly to the app Natural Cycles.
Now we just have to decide what kind of device this should be. I just saw the Typified Weather Poster and really like the idea of the changing colors in a physical object. Like toy cars or t-shirts when I was a child. Maybe this could be implemented in some way.
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.
