Peripeteia

A phenomenological perspective on interaction (like Heidegger’s or Merleau-Ponty’s) describes it as a loop, where the interaction is followed by feedback, and this one triggers refletion that supports the understanding of the interaction and thereby of the system. This new understanding iteratively shapes the following interactions with the system, leading to the formation of mental models about the systems’ inner working. Weiser described calm technology as fading in the background of users’ attention. This definition does not entail that the systems are not to be seem by their users in any way. A common trend in ubicomp has been replacing background for invisible, making systems invisible under the argument of being calm technology. Invisibility takes different shapes:

• Implicit interaction (sensors act autonomously)
• Literally invisible systems (very small sensors/interafaces, invisible means like radio waves, or totally virtual technologies like software)

The problem with this approach is that the interaction loop is broken, thus not reflection or understanding is enacted. Important to Weiser though, is that technology goes to the background but does not dissapear, thus the interaction loop is not broken. Being in the background allows also for the tecnology to come to foreground at different levels of detail.

When a technology is well adopted, our interaction with it ceases to occupy the center of attention, falling into the background. The interaction keeps generating feedback though, but this one is processed in the peryphery of our attention. The user is aware of the interaction, even though it’s not the object of his attention. A different feedback from the one expected puts the technology back in the center of attention.

A different perspective on this issue is that of technology as infrastructure (see Leigh Star in her work The Ethnography of Infrastructure). A technology adopted within our everyday activities is an infrastructure. Infrastructures are embbeded into our activities, thus transparent in our usage of them. It’s said of infrastructures that they become visible upon breakdown. By breakdown, Star mean the unexpected: complete non-working or undesirable behavoir. It implies the existance of feedback to the user, as a way to receive information of the infrastructure’s working, but also, once the infrastructure falls in the background, as a tool to match expectations between real and expected behaviour. This matching again, occurs in the background of our attention.

Technologies must embrace this basic cognitive requirement in order to be adoptable and become infrastructures. Technological infrastructures should provide feedback, an allow for this feedback to easily move between focus and periphery of the users’ attention. Focus, to enable the reasoning and further understanding of the technology that foster the formation of mental models. And periphery to be able to fade in the background, and provide information enough to enable the matching between expectations and actual behavoir of the technology, enabling the gaining of visibility upon breakdown.

A way to obtain this dual behavoir is through awareness systems used in the context of infrastructures. Infrastructure awareness systems convey information about properties of an infrastructure with special focus on the effects of the interactions with it. Infrastructure awareness systems should allow for information to be provided in the pheriphery and the center of users attention, taking into account the different possibilities in each situation. The centre of attention permits conveying detailed information, that can be read or deciphered by the user. The peryphery uses subtle perceptive cues like basic colours and shapes, sounds or movement.

PD: This post is not necessarily a continuation of the previous one. It’s rather a re-writing adding the phenomenological perspective, and introducing infrastructure awareness system (supporting both periphery and focus) as a way out.

Ubiquitous computing technologies, according to Weiser’s vision, fade in the background of user’s attention. This has been discussed as invisibility, and the discussion continues on whether this invisibility is physical, as when sensors are hidden or embedded in everyday products, or psychological, as when the engagement of the user with the technology is such that the interface “disappears” (see note 1).

Invisibility however is also a challenge from the user perspective. Invisible infrastructures subtract the spatial dimension from technologies and make it difficult for users to understand them. In some cases the benefit and the ease of using the infrastructure is so great that users adopt the infrastructure even without understanding it. However, there are cases where invisibility stands on the way adoption, as infrastructures require users to constantly engage with them. The Ubiquitous Computing field is full of examples like the automatic adjustments of settings in a smart home, the myriad of eco-feedback technologies, and pervasive CPU sharing or cyberforaging. If users do not engage with these infrastructures, they cannot deliver an acceptable service, hindering adoption again.

My idea, simple and intuitive, is to make these infrastructures available to perception. This approach addresses two objectives: first it provides for the users to explore the infrastructure before engaging with it, and to obtain feedback from their interaction with it. Second, it turns infrastructures into actors in the physical space where interaction takes place.

NOTE 1: Ubiquitous computing technologies are built on top of infrastructures, and together with them, similarly offer infrastructures through which services are delivered. Leigh Star describes infrastructures as invisible (embeddedness and transparency). Leigh’s invisibility relates to more to the fact that users obviate the infrastructures and focus on the tasks their are to accomplish. Taking the example of the gas pipe, it’s difficult to argue that the pipe is invisible (even if camouflaged), but it’s obvious that for most gas users the pipes are something we know about, but nothing to think about when we use gas.

TagCloud from my thesis proposal Latex source!

This year at CHI 2010, there was a very interesting paper+panel about infrastructures in HCI research called “The Infrastructure Problem in HCI“. The paper identifies different types of user experience difficulties caused by underlying infrastructures. The central conclusion of the paper was a call for the HCI community to become more involve in creating technical infrastructures, which implies a “substantial expansion to the methodological toolbox of HCI”.

This paper is particularly relevant for my own work, as we are trying to build a technical infrastructure called the P2P collaborative grid, and explore different aspects of HCI on top of it. As you might guess, I am working on the HCI part of the project, but I count with quite some experience in building technical systems and infrastructures. My engineering degree thesis alone focus on creating a software framework for supporting multi player games on ad-hoc networks.

When I joined the project, the infrastructure was well into development, and there were clear blueprints of where the technology was going to. That means that I was facing the fact mentioned by Keith Edwards in the above mentioned article: I was doing HCI research on top of a pre-existing technology that pretty much limited anything I could do. The real consequences of this limitation became clear to me in the months to come. As a good HCI graduate student I was given a setting on which to apply ethnographic methods: a molecular biology research group. I was suppose to dig out the information about the researchers and the way they use technologies, so that we could study the way they use the P2P collaborative grid. As I went through my observations I realized the biologists would never use the P2P grid for a number of reasons. First, because the grid was attached to a software suite that even thought they all have license to, only very few use it. Second, because the grid didn’t support the kind of algorithms they did care about. And third, because there already exists plenty of other tools that could do the same as the P2P collaborative grid, with less effort for the biologists.

I was shock, the very straight forward research path I was given when I started suddenly ended in a dead end, even before I did anything. However, we decided to work around this problem and came up with the notion of Infrastructure Awareness – and that’s where I plan to do my dissertation. We will talk more about this in later posts.

However, the paper at CHI 2010 brought everything back into focus. The infrastructure not only limits the kind of user interactions that can be built, but also the kind of research questions we can ask. Keith Edwards proposes to CHI community to get dirty and build infrastructures and accept them as contributions. And I somehow agree, as long as they conform to certain standards (this is a long discussion here). My gut feeling here is that there is a lot of grease in making infrastructures, and that even though making them should be part of our focus as a community, there are other ways for the community to engage with them. For instance, I will propose to examine “infrastructure critiques” as a possibility. Going back to my own example, there are many things I could see after fieldwork were wrong about the way the technology had been designed: the fact that it run attached to an unused software, the dependence on contributors, etc. I would so much like to write a piece of paper where I take my ethnographic fieldwork and challenge the given technology with it, to finalize with a section called “Implications for Redesign”.

I began my participation in CHI2010 in Atlanta, USA, participating in the workshop “Bridging the Gap: From Contextual-Analysis to Design“.  At the session I presented our position paper on contextual analysis for infrastructure awareness, and to my satisfaction it was very well received.

Later on, we divided into groups and mine worked on the subject of bridging artifacts. Sincerely, there was a lot of very intelligent and interesting people (PJ Stappers, Pardha S. Pyla, etc), that I felt I was just draining them from their knowledge. Anyway, the takeaways for me were the following:

1. Building scenarios is a skill to be learned (by doing it), they have to be iterated over and refined over and over again, until their meaning is clear enough.
2. We wondered whether there is a difference between boundary objects and bridging artefacts. The key point here is that the design process is the key point in bridging the gap, and that design process takes place in the creation on some of the artefacts. So, for example raw data files like survey results and videos are closer to be boundary objects. Whereas scenarios, personas, and others are produced in the design process, or at least some design takes place while creating them; they are bridging artefacts.
3. A fact supporting the nature of bridging artefacts is that they contain both interpretation of the original data, and inspirational elements.
4. Bridging artefacts should give account of the fundamental objectives that the design should address, in contrast to the means objectives. For example the mean objectives could say “the users wants a mini van” whereas the fundamental objective could be “the user wants to move goods between his house and his office”. This latter one could be solve by hiring a taxi, or moving closer to the office and carry them by hand. At the same time, the bridging artefacts should hold information about the laddering in the requirements. This means that it should be possible to ask a chain of “why”s to the fundamental objectives.
5. Finally, there are, perhaps, more than one gap in the transition from contextual analysis to design. One example of this is the gap between the design idea and the actual prototype, or between the designed prototype and the market product.

This are all very interesting reflections about design artefacts. Moreover, it’s clear that whatever artefacts are the outcome of the design process, the process itself cannot be framed or operationalized.

For our work on GridOrbit we developed both software and hardware. One very simple, yet very useful, piece of hardware is the ProximityBar, which is a set of ultrasonic sensors that capture the distance of the nearest object to the public display.

We are using the ProximityBar to infer the presence of people in from of our public displays, and thus transition between interaction zones. It basically means that the kind of content displayed in the screen changes as you get closer to it. In this page you can find more details about our set-up, implementation, and some example code.

I am taking a PhD course on Interaction Design which I am finding very fun and interesting, even though I am the less qualified of the attendees and certainly the only one with, borrowing from one of the readings, a positivist background. For the next session I have to present a set of readings which in general describe interaction design in relation to HCI and explore some particular topics of interaction design.

After leafing through the papers, me and my course mates, decided to organize the papers by topic like this:

In the papers to treat, interaction design is presented as the confluence mainly of Design and HCI. However, some authors include other fields like Engineering. This confluence can be analysed in terms of the interactions that are supported/designed, the aesthetic factors, and the methods and models for research. In treating such complex topics, no one really defines interaction design. For us, it’s important to have at least an initial notion of what interaction design is, in order to be able to differenciate it from HCI and Design.

Lowgren’s critic of the interaction design book says “the book doesn’t get it, and talks only about HCI”. However, he avoids the issue and simply says that most people in the field subscribe that Interaction Design is the shaping of the use qualities of digital materials. A similar description is proposed by Kuutti. When describing the historical evolution of HCI in the 90′s, without naming it as Interaction Design, he says HCI had a turn toward design, looking for the exploration of digital technologies as a novel material for design.

So, we can say that Interaction Design is the study of digital technologies and their qualities as input material for design.

Regards,
JD