Vladimir's Reflection

Course content:

Week 1: It was quite interesting to hear the emphasis on complementing workers over replacing them, but it is quite tough to consider. A lot of ideas that we tend to have for robots working alongside humans can easily replace workers without that being the goal. Even just something as simple as an automatic "pill dispenser" for people with dementia may already be on the path to replace caretakers if enough of these kinds of ideas are incorporated. In order to make something that truly "complements" caretakers, it needs to add a new kind of activity that is helpful to the people with dementia, perhaps improves their mood, but does not actually disrupt the caretaker's position. But this kind of restriction is still hard to keep in mind. We want the best for both workers and their target audience at the same time, but some ideas, such as a "self-scanner", can be nice for people who are more introverted. But ideas like this are clearly making it so fewer employees are needed at stores (though I have noticed how there are stores out there that actively choose to NOT have a self-scanner). At the end, it's a battle of ethics.

Week 2 (hindsight focused): This was the week in which the main claim structure was shown, utilizing Use Cases, Functions, and Effects. Overall, I found that their incorporation in the use case structure made it very clear in a small overview what is needed to implement a specific feature. In the meantime, the claims that work alongside it make it very clear what makes your product worthwhile, assuming your tests end up agreeing with the descriptions of those claims. The IDP and TDP were quite confusing due to their very similar names yet very distinct goals and would definitely be something to look at again in another project.

Week 3: This topic was quite interesting, though I had never thought about just how many different kinds of memory impairments there could be. Up until now I primarily knew of i.e. dementia, memory loss, and blocking of memories through PTSD, but the existence of distortion-type impairments and even the inability to make both short-term or long-term memories separately is definitely new. There is so much that can go wrong in the brain, it's honestly quite a miracle that it all works so well most of the time. Unfortunately, I think everyone has experienced how memories do tend to fade over time. Perhaps the way all information is ordered could explain this. If everything is stored in some form of "graph", then certain links do need to go, as the graph would otherwise be way too complex, which is unfortunate as I thought the brain should have enough capacity for it. Perhaps there is a way to train yourself to manipulate the way this graph is formed, so you can better organize your memories? Unfortunately, it seems that having other devices doing this work for you is a lot more dystopian, though at the same time, I am not sure if I would be interested in such a device in the first place, since I do not even bother to take pictures of my activities.

Week 4: This ended up being quite a calm week, mainly because a lot of the material is stuff I had already seen prior in HCI. It seems there is quite a lot of overlap! It is quite nice to see, and know, however, that prior experience in testing one field can help a lot with testing another. The methods are essentially the same, such as A/B tests, and likert scales. The affect button was quite interesting, though I would need to know more about how well this actually works. Won't this form of gamification inherently attribute more positive results? I suppose this is why methods such as A/B tests are so important and effective, because even factors like this are taken into consideration during these tests (though that does make comparing different tests may not be very effective if these factors are so prevalant.). After having already done A/B testing in HCI however, a slightly different method could be more interesting experience for this course. (In hindsight, maybe we should have tried the Affect button instead of just doing a Likert scale).

Week 7: This lecture has shown just how everything we do is supposed to tie together in one project, and it has made it very clear just how important each aspect is. It seems that once you have everything written down and set up properly though, it is a very easy framework to modify and update in different iterations, with some incredible results given the right team. While not discussed, it may also make your process a lot easier to digest for involved stakeholders. I was not too sure for the rest of the project, but this week made it very clear just how important all of these steps were. Definitely a process to recommend using in the future for another project.

Course contribution:

In week 1, our group collaboratively discussed what direction we should take for our project. Ideas surrounding patient mood assessments, to handle panic attacks through music play or by calling the caretaker came up, as well as a pill dispenser popped up. However, with the pill dispenser going against the philosophy of complementing, it was discarded. In hindsight, it seems that we underestimated the importance of looking back at this quick start, as we treated it moreso as part of the ideation phase.

In week 2, collaborative work on the Foundation started, where we started to deviate from our earlier ideas to move towards something focused on "music" or "improving one's physical well-being", though the final idea was not obtained just yet. It was here that we started to split up some of the relevant work. My assignment was to assess what AI and ICT technologies were required, and how to use them. Having updated it based on feedback, we end up with an approach focused on LLMs, voice-text translations, and the robot. With the LLM alone, massive privacy concerns start arising on where this data goes, and what would happen if this data were somehow to get "hacked". Especially in the current day, I have seen that people are wary of having a constant spy camera in their home. As such, especially when developing this further, we should keep in mind how we can make people feel safer. With our experiments being so short, I feel like this also was not part of our experiments, and could have negatively affected one's trust if our experiments were longer. This further justifies the need for an experiment to be drawn out over an extended period of time, which should be done if this robot were to be developed further.

In week 3, work on the Specification started. After collaboratively deciding on what ended up being the final project idea, we split up our work, with me working on the Use cases and their respective Claims. This seems to be the "core" of Specification, where all ideas are brought together, and largely determines what the end product looks like. As such, any changes made to design philosophy should be reflected here. The initial format was a bit confusing due to the second part of the table, though this was resolved with the new format. We ended up with a 3-step process: The initial setup, companion mode, and the dancing session. It seems we went overboard with this process, as we only ended up needing to test the dancing session specifically. In the future, it would be useful to restrict the use case section further, and only include that which is relevant to the current/previous iteration's testing procedures. Additional ideas can then be posted externally in either a separate "ideas" section, or some other document.

In week 4, after collaboratively finishing up what was still unclear to us in specification (including the need of some specificity on my part), we split up the task distribution for the presentation, for which I presented the Foundation (including Alice and our caretaker), made by Aleks. This presentation served as a way to solidify our current ideas and start a proper transition to the testing phase. As such, it seems that the impact of holding a presentation should not be underestimated.

After this, work on our Evaluation started. My focus was on the testing procedure itself, while helping out with some of the evaluation. There are quite a few different paths to take. The initial idea was to do some form of A/B test, but it quickly turned out that this was very unpractical. Our robot is focused on a dancing session, where our focus was on evaluating whether people actually benefit from this and wanted to partake. In an A/B test, it was unclear what the B would be. I.e. we could have just gone for the companion mode, but this limits feedback on the dancing session itself, and does not allow for a proper comparison on how one feels physically. As such, a Before/After approach seemed to be more beneficial, especially with our lower sample size. Rather than force-fitting a specific type of test on your application, choosing the right test seems to be quite important.

In terms of our project, it was quite unfortunate that we did not manage to get our robot to work. It seems that robot functionality is quite inaccessible, with Miro's free functionality being quite outdated, and the main useful tool being inaccessible, at least for Miro. As a result, we had to go for a more LLM-focused prototype, though I cannot help but feel like it was a missed opportunity. It is still quite fun to interact with, though it is not as interesting as an actual robot. This has made it clear that we should pay a lot more attention to coding accessibility and time constraints next time around. Robots may sound cutting-edge, but they may not be as easy to work with. The end results were quite interesting, seeing people's proudness go down with use of the robot. I do wonder if this also has to do with robots in general. We have already seen how i.e. chatgpt can actually negatively impact the brain in the long term. The robot does essentially all the work for us, we are just there along for the ride. If we want to make sure people stay proud, then it may be important that the activity is primarily influenced by them, i.e. by making sure that starting the dance session is their idea, and that they are doing the activity with regard for their own benefit. 

Final additional contributions (excluding group work):

Feedback updates for 1c, Use cases+Requirements, Evaluation.
Creation of the text for Prototype (not the prototype itself).