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.
Micro blogg 