fredag 6 december 2013

Theme #5 - Pre-reflections

Comics, Robots, Fashion and Programming: outlining the concept of actDresses
One of the main point that is being carried throughout this paper is the tendency for electronic gadgets in general to be somewhat ”customized” to the individual user of that product. For example stickers is put on our laptops, we buy cases for our iPhones in various colors. We don’t want the technology to feel like ”technology”, more like an extension of ones personality. It enhances us in someway. That is, at least, my interpretation. Further on, Fernaeus et al. argues that [”…it is relevant to explore new and user-friendly ways for these to be controlled by physical means.”]. ”These” being the our products/gadgets.

With this being said, we are introduced to the concept of ”Physical programming” which is not really that much about programming in the classical sense that you actually write code, but rather how you can go about interacting with technology. And to be more specific: Robots. So it is more about controlling/programming the way we are able to interact with this Robot. For example the play set with ”Lego Mindstorm” consist of modular skeleton with which you can build you own robot. The user is then able to modify the interaction based on a quite simple schema. Heck, how else are you supposed to appeal to the low target group that are ”sub” 10yr olds?

Inspiration today, according to Fernaeus et al, partly comes from good ol’ comics and fashion where fashion today can be seen as a mix of both textile and digital gadgetry embedded (envision: Cardigan-based christmastree with blinking lights). The idea, in my opinion isn’t that far fetched since wearable electronics (smart watches etc) is all the rage today.

What I will remember from this paper is that electronic gadgets in general, and robots in particular is heading towards change. A change from being tradition electronics, with no end-user in mind, to rather something special. Something you can really play with, interact with and communicate with (in some sense). My question is: Since the authors clearly don’t see the traditional programming part as the main focus with these robots, what are the drawbacks to that? Is there a limit to how advanced a robot can be if it based on a more ”semantic” way of programming?

Paper by H. Li et al
After reading Haibos paper I felt that it was perfectly fitting to answer the following two questions.

Why could it be necessary to develop a proof of concept prototype?
Not all research in the domain of HCI requires some prototype to be developed, even fewer probably need a proof of concept prototype. In this case though I can really vouch for the necessity if a more high-level prototype to be developed since the whole paper is based on the quite trivial question (although not specifically stated): Is this kind of concept something that is of value for an end user? I mean, the whole paper is based on the assumption that this would be kind of neat feature to have on your phone. Therefore, it is relevant to develop this proof of concept prototype to actually be able to evaluate and answer the underlying thesis.

Without a prototype that actually implement these vibrations it will be really hard to know how it actually feels. If someone would explain the concepts of the idea, I might get interested and think that it would be an nice addition. But the real deal, could have the opposite effect, I might not like to have my phone constantly vibrating. There is a fine line to it. This is also stated by H. Li et al: "The vibration on the hand should be carefully dealt with and long durations might make users irritated".

What are characteristics and limitations of prototypes?
The characteristics of a prototype depends highly on what type of prototype you develop of course. If you want to design a phone with the main focus being a product that fits perfect in your hand, it needs to have it's main focus on the form factor, naturally. If we have the case with the vibrating phone to give feedback on an ongoing football game, design is of low priority. So the characteristics of a prototype, generally speaking would be that it should try to communicate the main concept to the end user. Be it functionality, design or other features. In some cases a low-level prototype is suitable, in some, it might not suffice.

The limitations of a prototype is that "it's just a prototype". Very often the prototype is far from the finished product in many aspects. Therefore, one of the limitations is that it can be hard to evaluate since the "whole package" isn't there yet. One aspect of the prototype might be appealing to the end user, but it could as well fall short on the features that the prototype lack.


References:
Fernaeus, Y. & Jacobsson, M. (2009). Comics, Robots, Fashion and Programming: outlining the concept of actDresses. In Proceedings of the 3rd International Conference on Tangible and Embedded Interaction. New York: ACM. 

Réhman, S., Sun, J., Liu, L., & Li, H. (2008). Turn Your Mobile Into the Ball: Rendering Live Football Game Using Vibration. IEEE Transactions on Multimedia, 10(6), 1022-1033.

4 kommentarer:

  1. Hej Mårten!

    I think that Fernaeus et al would like to offer another way of "programming" the robots, something for non-technology nerds. I would enjoy having mood-stickers on my vacuum cleaning robot (if I had one) and watch it tackle my dust-bunnies with different character. Then maybe I could match my own mood at the moment and we could be angry or happy together. That could make cleaning fun, for a change. :-)

    SvaraRadera
    Svar
    1. I get your point. I just don't see that it could be that "programatical" if you only can modify it to a minimum =)

      Radera
  2. I agree with your comment about limitations of prototypes "Very often the prototype is far from the finished product in many aspects." I think that this might give misleading feedback from test-users if the prototype lack complete features, in some cases. Maybe not very misleading but may differ a lot from a later high fidelity prototype. But I still believe that prototype testing is of strong value even though if you only got a low fidelity prototype. A small picture or a hunch of the prototype use, I believe give a better foundation for development and error findings compared to other evaluation methods excluding test-users. Do you agree?

    SvaraRadera
    Svar
    1. I agree. I do believe it do some kind of catch 22 since your prototype can be low fidelity, but not "too low" in the sense that it turns the end user away from believing in the final product. It is a fine balance indeed!

      Radera