After some grueling weeks of battling with programing it is time to see what the class has learnt and what kind of insights is produced. My final sketch was supposed to be an interaction based on 3 interactions combined from post “Some progress…!?“. Unfortunately I had no way of combining them into one running interactive sketch as the code for each interaction was creating issues when combined with the other one.

Listening to the presentations and feedback during one session I could recognize that some of my colleagues had the same struggles as (my teammate and) I had. Constraints were a recurring topic some group struggled with that is also to my project. There is simply not enough experience felt through the kinaesthetic interaction. One of the dynamic attributes that plays a crucial role in an interaction is the coupling between input and output and therefore also an expectation of nuance. It being a major factor in whether the interaction has longevity or not. This is important to get right as we are supposed to design solution not only that makes sense and are useful but also sustainable solutions that can stand the test of time.

What is the kinaesthetic experience we are exploring? That came up a few times which I also think fits my project. I think that overall not enough time (due to various reasons) was an issue. The technical skills required to make the imagined design work was a bit steep and most of the time was a bit wasted on programing instead of experiencing the interaction which was the main goal. A couple of groups brought this up too, while it was easier for some to get technical help in person at school others (including myself) had to seek technical advice elsewhere.

This show and tell was a bit hard to summarize as each group got different and unique feedback and I think that this is mainly because this module was very dynamic. Doing the “same” style and execution was not going to happen as we could see in previous modules.

In conclusion, some final thoughts and reflections of this module:

• As a team, we had a rough start, not having an agenda or deliverables was the culprit. Equal workload and effort was also an issue when I objectively assess how much we produced. Simply put we were to liberal with the time not knowing how much demanding it would be to program the interactions.

• We started off with sport as theme and circular movements. By thinking about how physics work and the human body, circular movements made sense to pursuit. It may be a loosely defined theme that we didn’t really treated with the care it required. Not choosing to specify if further until the last week was also an issue which is tied to poorly executed collaboration and deliverables not being set.

• Technical skills can sometimes lag behind, such as this case (and in this project) where more time is put into doing static/technical work rather than experiencing the material/interaction. This is a huge issue as this would crash the whole time plan and outcome if it were done in a professional context. Given that it is school work and the fact that we explore sometimes things we are not good at or need more training in, we can live with that. At least I know how much I’m capable of if a project with a programing theme would appear.

• Although it didn’t shine through completely in my final sketches but kinaesthetic interaction makes sense to use only if the interaction is well crafted and responsive enough. A lot of issues coupling issues presented themselves during different iterations and explorations. I think that a majority of them wouldn’t exist if the sensor (webcam) or software were more detailed, precise and accurate.

• This is not related to the content of the module but I felt that I have to mention something about the fact that working online with a subject that vastly is dependable on other people and peers input and comments is also an interesting insight. Given the whole situation with the pandemic, I didn’t do any user testing for this module which is limiting the possibility of a prototype that is well thought out and robust. User testing as a tool should in most cases be used to confirm or deny design solutions. Working the last week alone with this module was like working in the dark when it comes to iteration of the design.

I have been getting very technical with the sketches, the last 48 hours. A balloon model was created and connected with the wrists. From the perspective of facing the camera to the front, the only viable joints to use was the wrists. 3 different interactions were designed in order to explore the movement. Figure 1 is about slow movements to gently keep the balloon floating, a minor movement across the X-axis was added to it. As more drastic movement of the balloon didn’t match the input. However the coupling isn’t perfect but good enough to explore and get a sense of the movement.

A bit harder to program was the dynamic transition between slow to fast movement. A clear decoupling between the speed used to intentionally shoo away to the balloon felt not entirely natural. Either my hands are moving to fast for the webcam or the software is lagging behind, either way this sketch could be improved. A code snippet was added to the end so if speed is sustained at a certain level the balloon would eventually fly away. In my sketch I didn’t manage to make it fly away graciously it only disappears from the canvas. While in the gif it shows to be working but in reality the part where it disappears was could come whenever speed was created. So I’m guessing my code isn’t up to par.

The last sketch was made to experience the air moving through the hands more freely and carefully. While the balloon didn’t disappear exactly when I stopped the movement I could still sense some connection to it. The way that air move around my hands felt natural and the coupling made sense. The difference from previous sketches is that the movement is more calm and controlled. Here again we can see a shortcoming of my programing skills, the balloon is supposed to fall down when I stop my movement…

Experiencing all of these movement with the wrists as the joints being tracked, I came to the conclusion that the software actually tries its best to track points that aren’t really 100% visible all the time. I guess the backend, machine learning, comes into play and estimates where those points are. There is a paradox to these sketches and that is that the coding is done with a 2-D plane in mind. The X- and Y-axis has 4 quadrant that measure values constantly while my body is tracked in a 3-D space. Making sense of this conversion between real world, space and time to digital values is beyond my understanding but so far with the experimentations done we can identify problematic areas.

All in all there seems to be one way interaction in these sketches, mostly because the computer is looking for my movements and reacting accordingly. A nuanced dimension to the sketches could be shown where I, the user, wait for the computers move or response. Maybe we could have thrown the balloon to each other and avoid it falling down to the ground. A lot of ways of enhancing the nuance are visible but programing them is another feat I can’t accomplish on a short time or by myself.

Today was different in that sense that my teammate decided it was best if we split up and did the the project separately. Which I’m a bit surprised over because mostly, if not all of the time, I have been developing the material/code. I’m just a bit confused as to what the motivation behind the move is. These things certainly happen all the time in a professional setting too, the important part is that the knowledge gained during the time we worked together is shared.

Continuing on from where I last left off was that some kind of object has to interact with the user and so I came up with the idea of using a balloon as the object. Which technically wouldn’t be hard to program, just a colored circle with a straight cord.

In order to create meaningful and coupled interaction, the movement that the user makes has make sense and offer a dynamic interaction. While I was trying out different movements I found that my pace was as if the balloon had some imaginary weight to it. The speed and force I used in figure 1 was more of trying to push air upwards to keep the balloon floating and moving. This made sense in a way, kind of like keeping a feather floating in the air. The point of keeping the balloon floating is to keep it in your possession, if the user stops to “generate” air the balloon would fall down to the ground.

In some way the interactive component is to keep generating air to keep the balloon floating, the force of the movement isn’t as important as the nuance of speed. Doing faster circular motions should generate more air and keep the balloon floating for a longer period of time or maybe it blows away from the frame? There is a couple of different scenarios I want to try out, as usual the only thing I fear is that programing will be a hinderance to try out those things.

Before I’m starting to address the actual work topic to the work I want to remind myself that things aren’t going as expected in this module. I was counting on producing roughly 5 posts a week but instead some posts contains progress and thoughts from the day before, as time is being taken up more by programing and less by experiencing. Writing how I feel about coding isn’t the main task rather reflection on the interactive experience of the module. Using and planning a weekly agenda is probably the way to solve this issue, which my teammate and I haven’t done. So this is a important note to my future self.

Some progress in experience were made, I tried out the precision and accuracy of the sketch. Amongst countless of trials and errors, these two videos were the ones with the best outcome.

As can be seen in both videos: one hand/wrist controls the color and the other one controls the size of the circle. This was an attempt to define the precision and accuracy of the material. Unfortunately the results are disappointing. Not much precision is achieved even though my movements are pretty calm and basic. Same test was attempted by placing the circle on different points and different joints were used to control the variables but the same result ensued.

With that in mind we can proceed in a different manner. As the object is continuously moving sometimes even randomly, can we incorporate it into the sketch so it acts as if it was natural? Maybe instead of circle we can have a balloon that floats upwards? The imprecise nature of the sketch might blend in with the random jittery movement of a balloon and should be less visible as balloons are normally bouncy and moving with the wind in real life.

As far as the input movement maybe we can go back and analyze which of the parts of the upper body (we are limiting ourselves to the upper body) we can use to control the object. What’s more interesting for me is also to use parts we usually don’t think about using when we want to control things. Elbows and shoulders come to mind.

Mostly I have been trying to wrap my head around the coding which is the biggest challenge for now. We got some direction with coaching but there seems to be a lack of collaborative progress on coding the sketches. For now I have taken the responsibility of programing while Kristian is exploring/investigating movements (with and without the sketches).

Making a sense of the details of the sketch is the hardest part. I feel that in order to start crafting the interaction I need to know how detailed the resolution of the camera is. At this point I don’t know what’s really happening at the backend of the sketch, if more computing power is needed or if something else is making the frames lag? I crafted some simple sketches to test out the accuracy. The point is to control the color/size of the circle with the wrists by moving in different directions on the axis.

As the window is 480×640 pixels that is the maximum of our canvas. Could be bigger but for now I feel that trying out the precision with upper body is enough.

The way the canvas works is bit different from the word of mathematics. The 0.0 (x,y) start at the top left and positive y-value moves to the bottom and the positive x-value moves as usual to the right. Now I have divided the HTML canvas into four square blocks with a color assigned to it, so depending where the wrist are position the user can control the color of circle and the size.

The reasoning for posting figure 3 is that I recall something Clint mentioned, I believe during a show and tell and that was something along the lines that we should balance the experiencing of the material with the actual practical programing. It was said that it can actually hard to keep track of that relation and I can only agree. As a programmer I’m far from the best, I get how things should work theoretically but I struggle in making it work practically. That is most to the fact that I don’t see myself being a programmer in the future. If I were to work with a specific area within coding I could take the time and specialize myself in it but being good at programming on a general level is not interesting for me as I believe everyone should specialize in something specific rather than being average at everything.

Figure 3 represent something that I have worked with for a couple of hours and as I’m doing the programming solo and my teammate doing something else, it becomes sluggish at times. An extra parentheses or comma renders an error and throwing me into troubleshooting-mode wasting even more time trying to find the answer on the web. The snippet of code isn’t long or overly advanced and it shouldn’t take a experienced programer more than a half hour to complete but that is just the truth that this type of coding isn’t my type of designer tool. As we work (in this course too) in fast iterations I’m a bit critical and surprised of the choice of material that the teachers made. Maybe more readily available examples or tools could be provided to not tax the programming part of the module.

Since we are working separately but together online, we choose a somewhat generic theme we both felt comfortable with. We choose to take a look at movements in sports and basically when we discussed it we came to the conclusion that almost all genres have movement in some kind of direction in order to do the “sport”. Focusing on what makes the human body move, we ended up on “circular movements”. If we look at the way we run, the way we throw things from a biomechanical point of view we see that some parts or multiple move in circular pattern in order to create motion and force.

The sketch above makes it a bit more clear why we came to the conclusions that circular movement can be found in approximately any human movement. If we look at the joints: ankle, knee, wrists and elbows we can see that they make a revolution in order to propel the human body forward. Also the body to the right illustrates that when we make a simple turn that the whole body is rotated around the spine which represent the spinal vertebrae. Simply put most of the movements we do can be seen as a “cricular movement”.

A more casual chore we all have done atleast one time in our life is to stir a pot. Sketch 2 is with a view from above. If we track the the elbow and wrist joint of the arm stirring the pot we can se that it makes it in a circular movement.

Going back a few post I discuss very briefly fine and gross motor skills. The way we execute a movement we apply certain speed and force, but some parts of the body have some intrinsic limitation in performing these tasks. I can for example use my hands to clap very loudly and without using much precision or accuracy and at the same time I can use my hand to hold a pencil and draw very fine lines which requires maximum accuracy. If you would apply the same thought to my feet/legs they seem to perform the best in movements which call for gross motor skills? Maybe I’m trying to say that I want to give my gross motor skill the ability to perform a more accurate skill through the help of an kinaesthetic interaction.

Figure 3 is also possibility to play with the precision by choosing a color from a color pallet. Don’t if it’s necessary as it seems pretty advanced but thought I would include it as a suggestion. The interaction would be controlled by the hand (wrist) to pick color and the other hand could choose the lightness/saturation of the color?

This lecture was interesting, not only because it was spaced away from the first introduction lecture but also because it takes on kinaesthetics in more detailed way. We have experienced some movements these days but now we got the explanation to them. The things that Jens talked about made so much sense, it’s that “aha-moment” you get. You know about something because you have experienced it practically but you haven’t really verbalized or made sense of it in your head. Jens opened up by talking about perspectives and how it can interpreted by the person moving, the observer and the machine.

The final pages on the slides mentions that the interactive experience is supposed to involve technology to take part both via an input and an output. This raises the bar a bit as we are not supposed to focus solely on a movement isolated from any context.

Some potential questions to probe during the weekend:

Speed and movement, can we craft an interaction where the user has to use different speed in order to do the interaction. What kind of body parts are suitable for speed and can physical limitation of certain parts of the body be augmented some way? E.g. it’s easier to fast hand movement with your hand than your feet, it’s easier to circular motion with your head than the shoulder…

Floating movements, How can an interaction be made were the user get a feeling of running in mud, swimming against the current or going against the wind?

Movements with tension and strength, How does for example movements in yoga translate into a digital counterpart. Muscles are contracting and under tension and the pose is paused before going over to the other one. How can a digital interaction inspire the user into those types of movements?

We are going to meet up again on monday to brainstorm around a theme and what we exactly want to do.

My colleague and I set out to further explore the sketches and possible movements. The sketches offers multiple body parts to be tracked which opens up the field for use to use any body part we desire to use. There is even possibility to track two bodies in one sketch but we won’t do that given the social distancing but also the fact that we work on two separate locations.

Something that lies within my core interest when it comes to designing is efficiency but I also have a great admiration towards precisions and accuracy. How can precision and accuracy be represented in a movement? That would be interesting to find out, so still on the basic sketches I coded a quick console.log command to show the value of where my wrists are (the x and y-coordinates). What we found was that it was it was a challenge to get a exact value. We tried different distance and angle to the (built-in) webcam over three different computers. Depending on the camera the value was always moving even though the wrists was resting on a table being completely still. With that in mind creating an interaction where a huge demand is on precisions and accuracy was out of the question at least for the accuracy I had in mind.

We tried if the drunk rudolph sketch was any more stable but it exhibited the same problems of inaccuracy and moving graphics even though the body part is completely still. At that point we guess it has to do with the library that tracks the motion.

A complete neglect of precise movements is not what we want to do, so we are going to ask during the coaching session if there is any workarounds to the issue or a different approach take to accuracy and precision as its too important to just neglect. If we did that we would only have gross motor skills to explore which is not necessarily the path we want to take.

We started to a bit loosely with the exploration of the code. All of me peers know by now that I try to stray away from heavy and intense coding, as it really isn’t my strong side (nor within my interest). Opening up the folder for this module came with a bit of anxiety. What if the technical limitations of my coding skills (and my teammates, which he clearly stated wasn’t good at) are going to restrict us from fully developing the prototype? I have fears just like in module 1, which was based a lot on programming skills and bad sensors. Which in my opinion gave the result that both of those areas was dragged down in the mud. The coding didn’t work because the sensor was imprecise and the sensor didn’t work because the code wasn’t good enough…

The difference this time I guess would be that I’m a bit more confident in choosing a path and just sticking with it. Ultimately this approach usually gets some heat for being a bit too careful/modest and not to explorative but I feel most confident in developing prototypes when there are clear boundaries and limitation.

So we started a bit easy with opening the test sketches and playing around with them. There is 2 sketches in the folder but with a lot of potential. They serve as as starting point for us to explore and modify. The first one being “Drunk Rudolph” which is a sketch that records you movement on the window frame the output is showing the user with a couple of elements drawn by using the canvas library. It’s a very scaled down interaction and it doesn’t really tell us what the possibilities are as there so many. We also got the instruction from Jens to casually explore the sketches then start to brainstorm about a theme and I guess, most importantly, we need to find something we are interested in before the we go any deeper.

Second sketch is called “wrist distance”, which is more of a “skeleton code” to start recording data on different body parts. Basically the same as the first sketch but this has less of the awesome canvas graphics.

My thoughts and feelings from just opening up these sketches and just grasping what they do and what they can offer is: when to many opportunities is presented people often tend to drown in them. Meaning, I’m thinking there is so much potential to do with these sketches but I fear that we may take a bigger bite than we can chew. I say this because in order to do something our technical (programming) skills have to match our imagination, which I believe will be the biggest challenge in this module.

Today is the start of a new module and quite interesting one. At a first glance it seems advanced and all over the place in regards to the exploration of the material, kinesthetic with machine learning. However the introduction by Jens seemed refreshing and comparably to the other modules a bit more liberal. While the subject is rather large it helps to do a limitation as per the countless feedback the groups has gotten on the show and tell but also that it it makes sense to focus on one aspect of the subject. Time and energy are out most valuable resources so hopefully, while this subject is rather complex and large to take on, we will manage to do enough iteration on specific are but at the same time not be to vague or shallow in our exploration.

There was a lot of talk about fine and gross motor skills within kinesthetic interaction and this is something that at least I have always thought about never really dived deeper into. It’s going to be insightful finding out the importance of theses movement we express because it’s what defines the interaction in that specific context. Movement to me is also a very complex and nuanced word, making sense and exploring it in little under 3 weeks is a not enough time.

There seems to be these 2 easily recognizable movements, gross and fine motor skills but how about those in between? What about movements that looks very grand and expressive but that requires detailed movement and precision. It is said that we can show and communicate what we do with gross motor skills as they are easily perceivable by others while fine skills don’t for the most part show that much. As it requires slow movement or maybe a part of body part to be used it can be hard to know what the person really does.

Needless to say this module is fairly complex but I think if we settle for a specific theme it would be easier to work and explore the material.

Presentation day, I feel like somehow we (students of the class) come to same type of insights or pretty similar insights at least. Maybe it’s not so unusual since we have the same base knowledge and limitations. That’s why I really take into consideration the feedback the other group gets because there is always something to learn from others. The feedback we get from the teachers are often directed towards developing our approach and critical design thinking which I like, it isn’t overly detailed or picky which has both good and bad sides but hey, that is the format of this particular show and tell. If i were to summarize the feedback from the whole session there seems to be a recurring criticisms about finding the behaviour and implementing it to the design in a meaningful and expressive way. Like in previous module the groups that put an effort into the presentation and communicating the idea got the most out of the feedback.

Something that got me thinking was a feedback Clint gave some other group about how heartbeat is represented in their project and that it might be a bit obvious to slap human-like way of acting or being into a physical object. The question is how natural occurring phenomenons can be represented as alive. When we are out in the nature and see the trees moving, the river flowing and so on, we get a notion of that we see and feel that the environment and its subparts are alive. That goes to show that each entity has it own way of being alive and expressing its state to the surrounding. In relation to my sketch it could be applied to as well. I tried my utmost to make the LED convey and mimic a human emotion without really thinking or investigating what how it “naturally” could communicate it being scared. Now maybe being scared is a bit of stretch for a LED but maybe other states like displaying that it is alive or in idle state? The possibilities could be many but I feel that they have to make sense in relation to the object.

Some final thoughts and reflections of this module is:

• Working with the bare minimum and scaled down specification was useful exercise and approach. Normally when doing projects in school we have a lot of options and resources. This limitation of only using a simple LED provided both a challenge and an ideation and thorough breakdown of the core elements of the component. Which I believe is useful since we can get spoiled sometimes without really appreciate the material or use it to its full extent.
• Constraints is tool I will take with me. As to keep growing my knowledge and efficiency I’m constantly out for tools, approaches and methods that can enhance my design work. Constraints on an already scaled down component was an interesting combination. Constraints surely will yield higher efficiency with more complex components and settings.
• The WHY’s and HOW’s are still very efficient and relevant words to carry. It makes sense to have a well crafted argument to why and how the artifact makes sense in its function and what kind of intrinsic/extrinsic value it upholds. That’s how the world spins around, things that don’t present any value get discarded.
• Programming can newer be discarded as useless skill. I was happy that we used an arduino to create the sketches as I knew there would be a lot of examples on the web and help to find. Unlike the first module this was a bit easier to do practically but also got me thinking that programming skills are more a less a mandatory skill to have when doing prototypes. As a person that strays away from coding, the arduino and other tools that make coding easier and faster is a blessing.
• Sensors and resolution are still an deciding factor to how well the project is going to work. This prototype didn’t call for specific and fine detailed movement but still there was some issues in getting the the right sensor or (should I say) resolution for the interaction.

The end is closing in for this module, it is time to do some final tweaks and get impressions from other users whos hasn’t seen nor tried the interaction earlier in the process. The key from an observing standpoint is to interfere as little as possible and give the user the bare minimum of information as to what is about to happen and hopefully some valuable insights and feedback can be generated. I couldn’t conduct the test with other students from the course so I referred to a couple of friends.

Here is what they had to say about the interaction with the prototype:

• The LED

Was hard at times to keep focus on it as it is so small. Maybe if the brightness can be increased to easier see it from a far. The same goes with the blinking that it was hard to see behaviour from a distance. The user felt like they had to make an effort to really look at it. Possible solution to this feedback is try up the current or maybe add some kind of physical aid to the LED that could reflect it making it appear to be bigger or easier to see.

• The input action (Users did 3 tests, one sensor each and the final test with both sensors active simultaneously)

Out of the 3 different combinations of sensors, the users felt that the piezo worked the best as it allowed them to do the most natural motion. The LDR felt a bit weird at some times as it didn’t really register the fast movement or the energy the users put in. Other times it would perform just fine. The last test with both sensors combined didn’t provide any more benefit over than just using the piezo element.

• The coupling

Users felt that they could control the interaction in a sense. The output of the LED blinking felt a bit static as the small changes in behaviour wasn’t really showing clear enough. Some users wanted the LED to have a bigger physical appearance or that the light should be more visible so the behaviour could be made out more easily. Almost all of the users felt that the interaction corresponded to the effort they made. From an outside observation I could detect some discrepancy between the coupling. It seemed that the feeling that the LED conveyed (that it is scared) didn’t have the strongest impact on the users. From my perspective it felt more of the arduino/LED worked for the user rather than having a balanced relation.

• Finalization of the prototype

The user testing provided some insightful feedback. I would agree with the general opinion of using only the piezo as the input sensor. It makes more sense to use one sensor that is reliable in its behaviour rather than using two (piezo + LDR) that is a bit unreliable and “confusing” to use.

The physical appearance of the LED have not been an issue for me as I have worked closely with the component for some week now but I felt that it was a issue at the beginning when I started to use it. The appearance of the 3mm LED could surely be augmented by a reflector or something that could reflect the light being emitted, giving the illusion of a larger physical output.

Being efficient with resources is one of the core objectives in sustainable design. I often feel like this is a overlooked part of the design process. Doing the most with the bare minimum should be one of the default approaches when specifying the requirements.

Regarding the feedback, it seems to be inline of what can be expected for these kinds of prototype. The prototype in itself is scaled down and demands attention from the users in order to be correctly experienced. It seemed a bit hard for a non-technical person to really see the benefit or value in the sketch other than school/research purpose. I think its therefore important to discuss the material thoroughly before starting to make clear that the users understand the interaction.

The piezo element showed the most potential but can the interaction be more nuanced from the input side? I’m curious to investigate if using both the input from the LDR and piezo will result in more dynamic interaction. I found that the sensor placement has to make sense, but using both hands at the same time will be necessary to interact with the sensors. The last video however shows a way to use one hand to make the motion of generating the vibration as well as limiting the light to the LDR.

I had to become a bit creative as I need to do one action that could fulfill to trigger both of the sensors. Now the way that the code is running is that the sensor that picks up first on the trigger will run its code. So the interaction is a bit misleading as the user never really fully know which sensor is triggered.

As far as the nuance goes I’m not really convinced that the LDR in combination with piezo gives a heightened experience than just using the piezo alone. Making sense of the code and when every trigger is being hit is the hard part. Maybe using the LDR to set the recovery time after the LED can provide a more interactive experience? But then again it’s highly dependable of when the user removes the hand from it which feels like a unnatural motion as longer sustain of shadow over LDR equals to a longer recovery time. The following days we’ll finalize the personality and try to test the interaction with colleagues the get some feedback. It’s so easy to miss something trivial when diving deep into theme.

Just like in previous module the quality of the sensors plays a role in this interaction. These are the cheapest sensors there is but it’s the only ones I could think of using in this module, even though it could always be discussed on how intrinsic performance of the sensors affect the whole system of interaction.

The thought of using a piezo element came naturally as it’s a sensor that can detect vibrations. This comes very in handy as scare can be a loud sound, a slam on the table, some object randomly falling down on the table an making a noise. The piezo works most accurately by being taped to the surface that is being used for vibrations, in this case the table.

Unlike the photoresistor we (the user) can measure the “scare”. So a more dynamic interaction can be crafted. As we can hear the sound produced we can certainly assess or at least get a feeling of how intense the scare is for us but also for the LED. The more higher value the piezo can sense (the louder we slam the table) the more frightened and longer recovery the LED will need.

Below are some videos of different scares. The sensor definitely displays a more dynamic behaviour than the photoresistor for both parties in the interaction. The LDR had an issue and that was that the user didn’t know how much limitation of the light was needed in order to make the LED frightened.

In the video demonstration the piezo is set go of at different triggers. Meaning a light knock will run a code where the LED is not that much scared while a loud knock will yield the maximum amount expression of being scared. The recovery period should also follow in proportion to how much scared the LED got. The behaviour of the LED is designed as close as I can think of human behaviour. A big scare moment for us would take more time to recover from than a smaller scare would.

The comparison between simple sensors got me thinking about how unique every interactive setting is and that a lot more can be felt if the right coupling is made between the input and output. A natural comparison to the real life also transmits a more genuine feeling into something that is not real or organic. Emotions and feelings have this multi-dimension of realism that is hard to infuse and make objects mimic. Maybe it is the fact that we know the physical boundaries of the object, in this case, the LED. I’m going off from my theme a bit here but what if the user scares the LED too much/intense that the LED would break or in other word, die? It certainly would change the users behaviour towards the LED if there was a possibility of it “dying”.

The first revision of the interaction with the LED is with a photoresistor. The component is simple in its functionality it has variable resistance depending on the light it receives on its surface. The resistance is either increasing or decreasing depending on the luminosity. The way I thought of using it is easier explained with the sketch below.

As can be seen in the sketch the point it to do a hasty movement (scare the LED!) above the photoresistor. That movement in turn creates a shadow above the LDR and the resistance will increase. The resistance will be taken as an input by the arduino. Although the LDR is quite dynamic and versatile it think it is hard to be precise with it, at least that is what the early tests with it has shown. Figure 2 shows a graph of how a LDR works. As can be seen it’s not a straight line rather a curve.

As I only can partially cover the LDR, never completely, I can never reach the highest resistance. I have therefore divided the code to run the LED scared when the resistance reaches half or less than half of its total resistance. The LED will return to a calm state once the resistance is above half or when I remove my hand above LDR. Below are some experiments of with the LDR.

In the video the loop of a calm LED is running and when I come in to scare it with my hand the LED reacts to it. This interaction is done 2 times to show the LED being scared and then realizing there’s no danger and finlay back to what it was doing before the scare. I guess the input interaction doesn’t take into account how fast you come in to scare it, as long as a shadow is made over the LDR. This makes the interaction less nuanced than I had imagined. The LDR is at a point where it triggers if a value is reached, maybe if multiple values can be triggered we can get a more nuanced interaction? What if we can do a quicker hand movement to only cover 20% or something alike?

The idle state of the LED should be a constant wave that I believe could represent heartbeat or general activity. I’m thinking of when I usually sit and work my heartrate would find a steady pace and my (brain?) activity would be calm and focused on whatever I’m doing. If someone or something would scare me all of sudden I bet that in most cases, my heart rate would jump in that moment as well as brain activity. Transferring these properties to a LED shouldn’t be hard at least the default/steady-state. That state would represent a “calm” state. Just like most times I have been scared all of a sudden, the time to recover from the scare is equally important in the sketch.

We can ignore the dynamic context that we are dealing with since the LED can’t really fear for something because it is simply reacting according the code. The point is simply that when it’s not (being) scared it should convey that it is calm. As a part of an interaction between a user and the object, conveying the correct state is an important part in the exchange. Below is a graph of the intended interaction.

The aim is to mimic something that we (humans) would express. In the specific context we can establish a level of calmness as a base. When we are being frightened/scared we are immediately put into a reactionary expression. Some do scream other “jump up” and some do both. It’s very hard to pinpoint exactly how people react to being scared as it such a raw reaction which is rooted within our survival instinct. Some people even don’t react to a scare, so this is a highly and tricky reaction to fabricate in a digital way.

Regarding the code, the arduino should listen after the “trigger” (when being scared) and run the code that exhibits the LED being scared. Would reacting randomly to the scare be a more nuanced reaction or will it be a confusing interaction? Also should the recovery time when the LED “realizes there is no danger” correspond to the length of the reaction, as in a big scare results in longer recovery time? It’s going to be interesting finding out the answers and insights.

We have two different articles to aid us in this journey. On is about decisive constraints and is written by Michael Mose Biskjaera & Kim Halskova and the other one is written by Marco Spadafora, Victor Chahuneau, Nikolas Martelaro, David Sirkin and Wendy Ju. The article they wrote is about designing behaviour of interactive objects. I feel it is due time to mention something about them and chisel out the core insights to take into account now that a bit more serious design crafting is going to take place.

Starting of with Spadfora et al. The article got me thinking about aesthetics and how it can challenge efficiency. It is stated that many variables have to be thought through when designing an interaction between a user and and a object. The traditional way of driving the design process has been “efficiency” but just recently aesthetics has gotten more attention within the field of HCI. The focus is on how experiential behaviour and attributes are showing in the artifact.

As a way to actively and consistently designing behaviour the authors suggest to add an additional tool to the framework by integrating “a human stereotype of personality to the interactive object in order to design its behavior”. This is quiet an interesting approach, giving object a persona in some way that mimic human behaviour in order to enhance the interaction. I get the point of the examples but when I’m trying to apply the approach to our LED it becomes a bit challenging. It’s certainly desirable to make objects highly interactive and nuanced but it’s often easier said than done.

An interaction between a user and the artifact should be coupled in order for it to make sense. We can draw the conclusion that the input is equal to the output otherwise it wouldn’t make sense. If X amount of nuanced effort is inserted on the input one should expect the to get the same amount on the output. In this project the input is the user through the sensors and the output is the LED. While the photoresistor and piezo element can provide many ways of nuanced input, I’m not sure if the LED can match that level of nuance. As I posted earlier I want to give the LED some human-like emotions, the ability to be calm or scared.

The previous week was all about exploring different patterns without any special inputs. This week’s work is a bit more dynamic. A constraint and an input has to be incorporated. Here I’m thinking of experimenting with a piezo speaker and a photoresistor. Both sensors can provide a dynamic input but I will start with trying out one at a time and figure out what they offer in the interaction. The goal is to make the LED express emotion as we humans can do. The issue is that the LED only communicates to us in a rather simplistic visual way. It can’t communicate with sound which is the main way that we us to communicate with each other. Only when something is too advanced to explain or when there is some kind of language barrier is when visual communication becomes efficient to use. What I’m flagging for is that there might be a discrepancy in the coupling between the input and output of the LED interaction. Crafting a LED to express human emotion can be an enthusiastic goal to reach but we’ll let the experimentation and prototyping lead the way.

A couple of posts ago I was focused on creating this expression of a data file being uploaded and received. While it is interesting to create and experience the sketch I felt like it was time to move on according to the schedule. Below is an graph from where I left the experiment. I imagine a file transfer being somewhat linear with some minor interruptions along the transfer. The graph would show a gradual build up of intensity until it reaches 100% meaning the file is transferred. What I learnt is that sketching out these graphs of the LED behaviour is really useful to save some some time and to easier envision how the end result is going to be like. Really useful tool in other words.

So far the sketch that we have worked with so far is bit plain and it’s missing a meaningful input. The result of the input should correspond to a LED reacting in a reasonable manner. After some coaching and discussion we should come up with a input that makes sense, but first we got the decide the overall theme.

During one of the lectures Roels showed some video clips of how the light can express nuanced output to its audience. In that particular videoclip the light conveyed a scary feeling. This got me thinking about human emotions and feelings. What if we give the led some human attributes like the ability to be scared or calm? How can the LED communicate with us that it is scared or calm? The arduino sketches from previous week should be usable as a foundation for this exploration. Normally when when people (including myself) become scared is when something happens all of a sudden. It can be something unexpected but also a loud sound or a hasty interaction can trigger the feeling of being scared. So I’m going to try that one out. The figure below illustrates a simplified diagram of blocks required to make the sketch work.

The “nuanced” part of the input is not yet discovered. I feel like there will be some opportunity for a exploration of the input once the physical sketch is up and running and actual experiments can be made. As for sensors, there is a couple I’m thinking of. Piezo element for sound and vibrations, proximity sensors for distance and body movement.

I also found out that I got to “modify” my arduino to block out the visuals of the built in leds, because they are constantly shining and interfering with the red led which makes the experience a bit confusing. There are 3 leds that indicate that the arduino is on and processing, so I’m going to simply put something over them. I think by doing so the entire focus from a user perspective will be shifted to the red led and it’s behaviour.

Today’s lecture were about constraining the design space in order to further provoke the thinking of the object which can be useful, especially if the design process is “stuck”. Roel discussed different types of constraints, decisive and environmental. In reality we can think that all designs possess some kind of constraints, be it intrinsic attributes, design space or self-imposed constraints.

Roel focused a bit on decisive constraints. This is an artificial limit that should act as a resource for provoking the process. The desired result is that the the designer will acquire new insights but it is not a given. There was someone in the class asking Roel something inline with: “What will happen if a constraint is applied and nothing happens and it just becomes a waste of time?”. Roel explained that we have the privilege of working with a project that has no budget. Normally when a real project is made with real clients and time frame to respect, a more careful approach to constraint is reasonable in order to not blow the budget and timeline. Since we are students working with ample time and no budget, Roel iterated that, we don’t have to consider that caveat.

From a design perspective as designer that likes methods and tools, I think that the constraints as an approach is interesting. I have to figure out how to apply it to the LED and arduino as they seem like already scaled down, minimalistic objects. The LED has brightness/intensity and the on/off state. Constraining one of those parameters might not necessarily lead to a “creative turning point” but definitely valuable insights.

Upon reflecting on the related papers on constraints and the approach, it may have higher probability to generate result in areas were the design space is a bit larger and more complex than a red led with an arduino? I have to verify the following days when I try to the approach.

As for this week I have learned a lot about the LED and how to manipulate it. I’m still working on the sketch on how to accurately display a progress of a file being transferred.

My initial thought after the first lecture was to make the led communicate some abstract value to the user. So I thought about things most people have in their home and landed on a router. The router process the traffic between computer and the internet so all data goes through it. Most of us don’t think or pay attention to the router and the data that’s being transferred is even more irrelevant for most of us. I’d like to probe that area and see if I can make the arduino and led represent a small file being transferred or a big file being transferred.

Just like the the transfer can be represented in the software and a progress bar it surely can be represented on a led light. In the figure above the user can estimate that there is more than 50% left to transfer. The question I’m trying to answer is: How can we make the led represent the amount of data that is being transmitted given the small physical size of the led? On the end of this post are some gifs on possible behaviours of that represent the progress of data transfer.

Moreover I have got to think ahead a little bit so I don’t get stuck. The thing to remember is that a more active way of interacting with the arduino is required on the input side but I got the tip from Roel to continue to probe, test different light patterns and behaviours and focus on the input the second week.

One thing that was interesting and mentioned on the kick-off lecture was behaviours of the light and what it can communicate to its surroundings. As lights are everywhere around us, it’s hard to not notice them but they can be crafted to represent the context more accurately. It is argued that the role that the lights/LEDs have are trivial and hardly used to their full potential.

This got me thinking of the 2 LEDs on the arduino and when a sketch is uploaded one of them are rapidly blinking. That state seem like a classic thinking or processing state to me as I have seen it on CD-rom drive when loading a disc and most recently on USB flash drives to indicate transfer of files. I guess it makes sense that they have put those leds on the arduino. As I upload a sketch to it it just says “uploading…” in the software window, if no leds were indicating I might have thought the software had freezed up or that some lags were happening. There’s a difference with the CD-rom drive and the USB flash drive as they are coupled with either some visual progress bar or sound in combination with visual progress (the mechanical noise when reading a disc in the CD-rom drive).

This experiences above tells me that the context plays a big role and where the LED is placed. Also different outputs in conjunction with the blinking can enhance the understanding and make it more obvious but for this module we can’t use any other outputs than one single red led. Nuance is the challenging part although I believe we can find a context after a couple of iterations, I think we will run into to problem with the nuance. How can the behaviour of the LED be nuanced? We are strictly constrained with brightness and duration of it. From a design perspective it seems to be harder to craft something when the design space is heavily scaled down or restricted.

It is going to be interesting to see how we will provoke and further probe the design given its restrictive and scaled down nature. Methods and approaches do always interested me and will be an appreciative addition of valuable learnings in this module.

We have started to tinker with the arduino, it was a time ago since we last used it and comes in handy to repeat the knowledge. I’m not to keen on coding so I started from the beginning with the built in blink example in the arduino library and slowly enhanced the LED to represent an elevator as mentioned in my previous post.

The sketch loops all the time but in this video it can be seen how it should work. There is no input so we have to imagine that some one is pressing an elevator button and the LED reacts to it.

So these 2 sketches should represent the informative light when the elevator is being called upon and when the elevator is going up to the desired floor. I see the blinking of the led as way to to represent the urgency and motion of the elevator. The rapid blinking seems natural as a way to convey that something is about to happen real soon. Like the elevator doing it’s action.

I’m definitely interested in exploring led as source to communicate information, but I haven’t really thought about the what kind of input to apply. Maybe when I figure out the context it will be easier to figure out the input?

Have to mention how effortless the arduino IDE feels, this is the type of tool that designers need. Easy to understand, a lot of examples, and good documentation. This makes for a tool that’s efficient and versatile to use.

New module, new assignment. This time we are tinkering with a single (red?) led and an arduino to craft an “expressive hardware interface”. Later on creative constraints will be applied in week 2. First week is as usual, get to know the hardware/material, try and tinker with the led source. A tip is to try and express particular context or emotions. I was thinking of how in my building the elevator seems to be missing an indicator when moving up or down. I will try to explore and design the output (LED light) to mimic up/down movement. There are 2 different patterns for the light and it depends wheatear you are going with elevator (inside) or waiting for it to arrive (outside). Experiments will show if there is any difference in how the light is perceived and if there is a difference between going up/down with the elevator or waiting for it.

It’s the first day tinkering but this seems like a interesting module. I like the approach of using a minimalistic yet ubiquitous part like the LED diode and trying to blow up it’s usability, appearance and behavior. More recently the display is more prominent in hardware since it can act as a complex interface for the input and output. Very often the manufacturer/designer takes the cheap and fast route of just slamming a display on the device. What’s possibly missing is opportunity for interaction and a more “beautiful” design, both in feel and use. I guess those values translates into a product with a longevity and usefulness over longer period of time. I believe that sustainability is an important value and we should always try to have that in mind when designing.

After some more optimization of the code we have refined the interaction were it needed to be. Values of responsiveness, accuracy and consistency are the ones we experienced needed have positive impact on the user. We felt that it was working at half the capacity. Trying out different microphones and computers didn’t solve the issue rather it confirmed that the code needed to be individually tweaked for that specific computer.

We got the interface to work to our liking but had to sacrifice the function where the user would imagine a color, try producing a sound and that color would be generated. The way we thought to solve this was to assign a value to the color after some global average of what people think of color e.g. white would correspond to a low value and the most intense color would be a high value. As it was confusing and with our limited coding skills we dropped this function and chose to focus on functions for saturation and lightness in relation to frequency and loudness thresholds.

The video showcases the work and how it reacts to different sounds at different loudness.

The function is written that it randomly shows a color every time when one of the triggers are hit. So frequencies under 300Hz generates a color with low saturation and lightness, 500-2000Hz a color with medium saturation and lightness and 5000-10000Hz high values.

As we tried out this interaction a bunch of times and trying out some different values. We came to the insights that it was a bit limiting, frequency triggers and loudness thresholds alone couldn’t provide a rich quality interaction. By experiencing it we could draw the conclusion that the balance between a fluid interaction and a minimalistic output didn’t open up the design space considerably much. We needed more nuance at the input as well on the output but essentially accepted it as time was running out. More accuracy, precision and fluency in the input/output required us to focus solely on reading up on coding (as well as buying new microphone).

I believe that responsiveness, fluency and accuracy is direct relation with the practical use of the interface, possibly interfering a whole lot with nuance on both ends than anticipated.

Presentation feedback – Overall most groups got almost the same feedback with some minor individual remarks. One important feedback was to work after a set theme. That way the progress can be tracked and credibility can be strengthened. Most groups including us have just explored sound and skill without any theme. This can lead to different paths were positive insights can be found with every new experiment and found only because the aspect or point of view is constantly changing.

“What about it?”, Identify the gap and what is missing in the project is also some valid feedback given to us. Which I strongly believe is in relation with a clear theme. Overall this module has proven to be a bit challenging for us as a group as it demanded attention on coding more than focus on interaction-crafting at some periods, which felt a bit choppy as a learning experience but overall this was module was ok.

After some coaching and further discussion we started to tinker with the input interaction. It seemed a bit crude and not really reacting well to delicate and fine sounds. From my end, I developed the code with a external mic which worked average at best which is strange because it is supposed to be a “quality mic for online communication” according to the manufacturer.

As we started to add some more interactive gist to the output we were thinking of the actual point of it. What it is supposed to do and if it can inspire the user to use skill in a more interesting way. Trying out the triggers as it looks like now is a bit strange. I experience that it’s really hard to repeat triggers with e.g. sound made by the body. Unless great concentration is put into replicating the same sound, I can’t get the triggers to behave consistently, which adds some frustration in the interaction.

So far attributes like responsiveness, accuracy and consistency is areas of exploration. The output right now is tuned to be window which will display a color with a specific lightness and saturation. We thought about coupling the values of lightness and saturation with frequency and loudness. Point is to craft an experience with the interface where the user can imagine a color and try to do a sound which they think would correspond to that “imagined” color.

Moving on with the progress, we started to think about what we could achieve with frequency threshold, peak and sustain. We haven’t set on the output yet but feel that showing something visual as an output would be something we could manage to do with our coding skills. We touched on the subject on using sound as an output. How could it be meaningful? Usually a conversation works in asynchronous way, meaning: X is inputted and A is the result. This action is followed by a time difference between the two. We tried this by talking to each other at the same time. Trying to speak and comprehend what the other person is saying at the same time was difficult and not something that is considered meaningful in an interaction. Rather it would be annoying and uninviting.

Sound as an output was sloped as we believe that the effort required to dwell deeper into different sound libraries, would take more time from actually experiencing the interactivity. Although we have 3 functions there is a potential to craft a dynamic output and so far we have learned that those triggers work quite alright.

When triggering them they show a rectangular element being highlighted.

This picture above illustrate a quick sketch we did. When trying to set of the triggers I found that I used my voice to trigger them. My microphone didn’t really pick up the sound I did with my hands or when I was using other materials. I could make it trigger but then I found my self banging real hard on table, wall etc. Which is not a pleasant input interaction.

This quick little video illustrates a crude form of a visual interaction. The visual representation is a bit misleading here. The colors are not coupled with input interaction so more or less useless other than highlight that the element is triggered.

We got to play around more practically with the interface. The goal was to experience the visual output. In our team, we think of skill as basic human movement patterns and also as something that can be learnt in various proficiency. That is a highly dependent on the persons ability and background and other factors. But as we are continuing forward with our project we try to imagine us how the activity possibly can be used. We do not believe that cultural specific skills will play a part.

Continuing on with the color window, we got hit with some classic coding issues where the code would break or not properly show data so we quickly revamped and used the frequency visualizer for this test.

Here we tried to modify code to display sound through meaningful colors. We tried to make an connection between the input and output in a “universal way”. Meaning that a sound between 0-300Hz would require a deep and dark sound and higher Hz, brighter color. So we wanted to relate the sound characteristic to a color. Why? Well it was evident when we started the course that most of us didn’t know much about Hertz or sound and so we would think that the average user don’t really now what the frequency scale is or what it represent. What does e.g. 2500Hz mean? How can it be produced and what does it sound like? How can it be reproduced with high accuracy? We moved carefully with our approach and was basically relying on experiencing the design in order to answer the questions. We found that the quick display of the result was smooth and contributing to better understand what color a certain sound does. The color choice for the different frequency columns seems to be decoupled with what people think of when comparing/thinking of sound with color.

But what about it, what is the point with the interaction? The inspiration for this work is that we wanted to investigate an interaction where different skills could be represented with a color. To investigate if the user can develop their knowledge around the frequency (scale) but also experience a nuanced form of producing the sound. I got the feedback that people were more inclined to use their voice than bodily skills to produce the sound. Also a need to better understand the sound in numbers or text were needed some suggested.

A bit of further development in the module 1 group work. As for input we are quite confident with using the Audio threshold functions to craft a nuanced input. User need to produce the desired sound within the frequency range in order to interact with the interface. Peak and sustained threshold is also supposed to be used. So not only has the user to hit the frequency but also a peak and sustain it x amount of time to succeed in the interaction. Now the functions combined can be used in different ways. We were in on the track that the user create the sound with anything in the near surrounding. Be it clapping, snapping fingers or stomping feet against the floor. Anything should be possible.

When experiencing this ourselves we find it interesting that different actions can hit the same frequency. It might be an microphone issue since we are using the built-in one in a macbook. It simply might be to bad quality-wise to differentiate frequencies. The tolerance can is unknown but we feel it’s good enough for this module.

Some ideas around the output were discussed and currently we are trying out. It will heavily depend on our coding skills since we know what we want, but have some issues with achieving it practically. One is to have window which will display a color. That color will be represented by a frequency at a specific loudness and it has to be sustained as well. So the idea was to use a range of colors where low pitched bass voice would show black or a dark color and high pitched voice would display red/yellow or some other intense color. The middle of frequency would display some mix of colors I would surmise.

Reflecting on our requirements for the input, we believe that the user would have some kind of knowledge and prior expertise while approaching the task of generating a sound through body movement. If absolutely no knowledge of sound (and the technical aspect of frequency) the user can quickly experience the output. That is why we also need to couple the input with the output so that no lag is experienced by the user. The user should know when an action is registered and performed. Otherwise there is no actual way for the user to memorize the interaction and frustration will prevail.

Me and my college discussed a bit where we wanted to go with this module. Thoughts and ideas came up to maybe use the body and movement to shake a sensor which generates sound or something else. For this we thought about using an Arduino to create some kind of a wearable device. Essentially we dropped the idea as we didn’t fulfill the requirement of using sound, vibrations or other bodily skills to generate the input. We could go that way but it would require us to get a bit more technical with the coding in arduino which we didn’t really feel super comfortable with.

After some coaching we got back on a somewhat clear path. We discussed the abilities of the basic microphone as well as using a piezo-element. We came up with 2 ways of interacting and creating input. One was to use a microphone and the functions around threshold (Frequency, Peak and sustained). By using the body to generate a sustained frequency we can craft a nuanced interaction with the interface. We haven’t decided clearly on a output but an interaction where the user is required to be within a range and sound level is a loose idea. Some attributes were also discussed to further deepen the feeling of a meaningful interaction.

The other path was to use a piezo element to pick up the bodily generated sounds/vibrations. The main benefit with the piezo element is that it can be very sensitive to inputs. A lot of ways can be experienced in the field of coupling the input-interaction to output. Here again we haven’t decided on any attributes or how to display output. But we see a lot of potential in the (input) device. Maybe as an output, colors on a screen can be displayed. If the user wants a bright color then a bright (high pitch) sound has to be the input? How does the user generate a bright sound is the question and there is multiple ways of doing it with a microphone/piezo.

Attaching the piezo to different material can also cause it to pick up different vibrations. The material it is attached to becomes therefore a medium for the user to explore.

Reading through the reference papers from Djajadiningrat et al. was a interesting read. The authors argues that the trend of today is sadly neglecting the natural and essential importance of movement. Technology therefor is designed around heavily taxing our cognitive load which in turn limits the possible expressions as well as interactions with it.

The paper gives a historic background to how products have changed from being very mechanical in their expression and feedback requiring often the person to use the motor skill of the whole or part of the body. The relation between form. action and function is quite obvious up to the period of the 1940-50. With technological breakthroughs so does products change, purely mechanical switches and mechanisms are replaced by electrical powered ones. Movement is no longer required to be done by the whole body or arm instead the hand is sufficient to use thanks to the use of analogue rotary controls and sliders. Feedback is mainly displayed on scales and dials. Fast forwarding to the eighties the IC-chip has done a (commercial) breakthrough, now the movement is very precise at the users finger tip. Push buttons becomes an increasingly used control as it can fulfill many functions effectively cutting down the usage of many. The function of one control to have multi function role is prevalent. Here the feedback is commonly on displays in form of a text or other visual graphic.

The author reiterates that this development is moving towards a heavy emphasis on cognition and a loss of appreciation for perceptual-motor skill. Different functions are triggered by the same actions resulting in similar looking output. The burden of remembering everything is an issue, the proposed fix would be to look at design opportunities for bodily interaction. The move towards the “knowledge in the world” rather than “knowledge in the head”.

The paper is filled with interesting information a lot more then I can capture in a single post. Reading through it got me thinking about why the situation is like the authors describe. Why the products look like they do and why they aren’t like they purpose it should be. I’m not quite sure why it is like that but is it really necessary to be so engaged with a product when in fact the only thing you want to do is “simple” action e.g. heat up the food in the microwave. The microwave has it cognitive burden on the person. Settings are pushed in via buttons or dialed in with a knob do we really want this experience to be more beautiful aesthetically? The situational context is certainly not, I’m very hungry and I’m eating micro-ed food there is no need to do this action more interactively pleasant as it’s just at this point, for most people, a built in rudimentary move.

The efficiency of operating a product (once you know how it works) is quite high. Module 1 is going to be challenging for me as it will put demand on thinking in a way I’m not quite used to.

With the introduction of Module 1 comes also a toolbox to capture input and show output in various ways. The toolbox is aimed at audio capture and most of the output data is in frequency curve or a number value like peak loudness, dB and so on. This leaves a lot of wiggle room for us to explore and modify the code in any which direction we want. So far we have followed the instructions of playing around in the toolbox and trying out different inputs. Some experiments were also made with materials. We tried out the trigger function to snapping of a finger. We found out that in the frequency range of 3000-4000Hz the trigger would set in any position and distance in the room. Regardless of hindrance in the room in form of objects or angle to the computer. Other states that trigger a on/off state can be the peak-function. When a certain sound level is hit a trigger would occur.

I guess the interest lies within experimenting with how sound(vibrations) travel and becomes affected by the surrounding environment. What kind of obstacles is there and what affect does it do. Also how should we display the result. The coupling between input and output is directly correlated to the interaction and it can be made very unique depending on what we are out after. We also got the tip to think about how it can be made nuanced, sort of having a wide field of interaction. Dynamic might be a more suitable word.

Till next experiment I want to try out more of using the body to emit input data and I want to examine what kind of potential there is to it. The reference literature mentions ways of moving away from what we know (cognitive load) to the knowledge/skills we have universally in our bodies. That is a interesting viewpoint and it’s going to be challenging (in a good way) to to work with as most objects around us interact with us when we apply our knowledge of how they work. So how can we create a rich interaction without a (pre-thought) knowledge of a product? That will be the overall theme question to answer during this module and hopefully we can discover some insights when we experiment.

So a new semester has started which means a new course. This year the courses are a bit longer and there are no more 7.5 credit courses which means that more time and knowledge will be put into the subject and in a sense more meaningful skills are developed. This course is called interactivity.

So the overall purpose is “To better understand & craft the interaction of interaction design”. It’s a large statement and boundaries are not specifically defined but there is detailed learning outcomes that can steer the path into the right direction. I treat part of interaction as something that is between the user and the product. Interaction can be seen as a very dynamic and complex medium which can and should invite people to have some form of a usability out of something. The level of invitation can vary greatly depending on the design of the product.