Eric Nehrlich, Unrepentant Generalist

So, although it will look like this is a response to Jofish’s comment, I had actually sketched out these ideas this morning before I read his comment, and just didn’t have time to write them up until this evening.

One nuance that I glossed over in my discussion of feedback is one that Jofish rightly points out: that sometimes the designer _wants_ to make the user aware of the tool that they’re using and the assumptions they are making. I conflated the two types of feedback that I talked about in the post. There’s one type of feedback, which is consistent and reliable, which is the type necessary to have a piece of equipment achieve “ready-to-hand” status. But the type of conversational feedback I mentioned in referring to Suchman’s work is different; it is not consistent because it is constructed in response to the user’s specific action. One can not have a conversation with a hammer in hand, because the hammer has disappeared from awareness. For a conversation to happen, the equipment must resurface and be “present-at-hand”, an object in its own right.

So to address Jofish’s point, I guess my statement should be revised to something like “if you want your tool to disappear, to be able to achieve ready-to-hand status, then you need to design for it to have consistent and reliable feedback”. But there are other design goals. Being aware of this design principle regarding feedback will let one understand how one’s tool may be used in interaction. And I’m sure that he addresses some of this stuff in the paper that he refers to, but I haven’t had a chance to read it yet.

I had a couple other random followup thoughts on feedback.

While feedback should be consistent and reliable if one is designing a tool to be ready-to-hand, it does not necessarily have to be simple. One example I thought of this morning is the violin. The violin is seemingly simple, but it requires a great deal of practice and skill to get to the point where it is comfortable enough and predictable enough to disappear from one’s consciousness, to where the violinist is simply making music without awareness of the violin. I never got to that point myself, but I can imagine. Another example of complex, but consistent, interfaces is in video games. I’m horrible at video games, but I know that when I watch friends play, they aren’t thinking “Okay, now I need to hit A-B left-right-up-up”, they’re thinking “I need to punch my opponent”; the controller is invisible to them. So consistent interfaces does not necessarily mean simple interfaces.

Another case that occurred to me was trying to apply these ideas to user interface design. There’s the canonical example of bad user interface design where the geeky software engineer just puts all of the controls to the program on the screen at once. After all, if everything is available, then all the feedback necessary is there, right? Who wouldn’t want to be able to control every single detail? We can use Heidegger’s distinction to frame an answer. When every single control and indicator is on screen, the user has to stop and study the screen to figure out where the appropriate control or indicator is. This moment of study brings the user interface to “present-at-hand” status, because the user becomes aware of the interface _as_ an interface, as an object in its own right. The user interfaces that stay “ready-to-hand” instead present only the feedback necessary to let the user continue their actions.

This may seem like a contradiction, or at least it did to me just now, in that if the interface is only providing certain feedback at any given time, then the feedback is changing, and therefore isn’t consistent and reliable. But I think this can be resolved by the interface providing consistent and reliable feedback at any given step of the process, such that the feedback is not only consistent and reliable, but also appropriate. It would be like a waiter at a perfect restaurant: never obtrusive, refilling your water glass without you noticing, yet always available when you need to ask them a question.

The ideal user interface would be one that took into account what the user was trying to accomplish and made it easy for them to accomplish it. This is not a new idea, of course. Everybody from Don Norman to Alan Cooper to Jakob Nielsen recommends this. But I feel like I should be able to use some of these ideas I have been reading about and find ways to apply them in a more direct fashion to the kind of problems that face me in my professional life. Part of it is the tricky aspect of figuring out what the user is trying to do when one is unfamiliar with the task oneself. Part of it is figuring out how to organize information so that what is on the screen is considered by the user to be relevant to their goals at any given time. Unfortunately, it seems like it basically comes down to reading minds, and that’s difficult. I grew to the point where I was able to do it at my last job, after working with the same people for a few years, but it’s not something that is transferable to a new environment. The feedback loop is different.

Anyway. I’m going to stop here, and maybe go read that paper. Or go to sleep. Maybe I’ll take BART tomorrow, read that paper, finish the Dourish read this week’s Economist, and all sorts of good stuff like that.

As previously noted, I’m reading Paul Dourish’s book, Where the Action Is, in which he explores the branch of philosophy called phenomenology as a possible theoretical basis for embodied interaction. In particular, he mentions the work of Heidegger, about which I know nothing but a couple brief summaries I have read. But the concept which I want to address today is Heidegger’s exploration of equipment use, in which he divided equipment into “ready-to-hand” and “present-at-hand”. As Dourish explains:

These are ways, Heidegger explains, that we encounter the world and act through it. As an example, consider the mouse connected to my computer. Much of the time, I act through the mouse; the mouse is an extension of my hand as I select objects, operate menus, and so forth. The mouse is, in Heidegger’s terms, ready-to-hand. Sometimes, however, such as when I reach the edge of the mousepad and cannot move the mouse further, my orientation toward the mouse changes. Now, I become conscious of the mouse mediating my action, precisely because of the fact that it has been interrupted. The mouse becomes the object of my attention as I pick it up and move it back to the center of the mousepad. When I act on the mouse in this way, being mindful of it as an object of my activity, the mouse is present-at-hand. (p.109)

We’re all familiar with this concept. When we pick up a hammer and hit a nail, we’re not thinking about the hammer, we’re thinking about the task of hitting the nail. The hammer is invisible to our conscious thought; it has been absorbed into our extended self (Me++ explores similar ideas).

Dourish uses these philosophical concepts as a way to build a theoretical basis for designing embodied interaction. He talks about a bunch of different things, which I’ll explore more when I do a formal review, but for now I’m going to restrict the discussion to understanding how and why different forms of interaction can morph from “present-at-hand” to “ready-to-hand”, from visible to invisible, from outside my personal collective to inside.

While reading later in the book, it occurred to me that one of the keys, if not the key, to this transition is feedback. I am a tremendous believer in the power of feedback to effect changes in the world. It’s something I see everywhere, from the importance of aligning company processes with goals in Built to Last, to advocating using the feedback of others to change oneself.

How is it relevant in this particular situation? I believe that consistent and reliable feedback is necessary before an object can transition to the “ready-to-hand” state. If something is acting as an extension of oneself, it can not have an identity in its own right. It must behave exactly as one expects in response to one’s actions. If it doesn’t, if it starts behaving in an unexpected fashion, then the tenuous connection that has “coupled” it to one’s consciousness is broken, and the “ready-to-hand” status is lost. Dourish’s example of the mouse that reaches the edge of the mousepad is a good example of this transition. When the mouse is “ready-to-hand”, I move it up and the cursor goes up, so after a few moments, the mouse has disappeared from my consciousness, because when I think up, the cursor goes up. It is only when the feedback is unexpected, when I think up, and the cursor does not go up because the mouse has hit the edge, that the connection is broken.

Dourish mentions feedback in passing a few times, but I think it is central to this particular issue. Of course, I haven’t finished the book yet, so it may yet make a more prominent appearance. But that’s why I’m writing this now, so I can feel all clever if it does.

This connection of feedback with making things “ready-to-hand”, making things disappear from one’s consciousness as they are absorbed into an extension of oneself has some interesting consequences. For instance, it ties in readily with this post on cognitive trust, where I say “as we learn to trust and respect [a coworker], we can learn to call upon them with little more overhead than we do a subroutine in our own head” – our coworker has become reliable enough in our eyes that they essentially become “ready-to-hand”.

I noticed this recently in my own life, actually. In my previous jobs, I was always in direct contact with my “customers”, because I was writing prototype software for my coworkers’ use. I didn’t worry too much about specification requirements or software process, because if I started coding and I ran into an ambiguity about what they wanted, I’d turn around in my chair and go “Hey, how do you want this to work?”. At my current job, however, I am at least two steps removed from the customer. The customer talks to the president of the company, and the president talks to us. The feedback loop is much longer because if there are any questions, it has to be relayed to the president, who then has to take it to the customer when she gets a chance, etc. So I’m starting to learn that I need to be much more proactive about clarifying requirements and specifications as early as possible in the software design process. At my old job, I hadn’t even been aware of how much I relied on the instantly accessible nature of my coworkers; they had been “ready-to-hand”, used without thinking. Now that the feedback has become much more distant, my link to the customer has been broken and I am aware of the customer’s existence as being “present-at-hand”, an entity in their own right.

I think this mutual dependency between tight feedback loops and the “ready-to-hand” status of something (or someone) is something to be aware of in design. Certainly one of the things that makes software so hated is that feedback is often inconsistent and reliable. One definition of insanity is doing the same thing over and over and expecting a different result. And yet with our computers, we often repeat the same action over and over… and get different results. We don’t know what makes the software work. We develop elaborate incantations to invoke the blessings of the software gods (“Oh, I know that if I press this button, then call this from this menu, and then press F3, the report works, but if you do it the other way, it crashes”).

This actually ties into Lucy Suchman’s book as well, where she talks about patterns of conversation. One thing she mentions is that when we are talking to somebody, we assume that they are offering appropriate feedback to us. She cites a particularly thought-provoking study where they had students talking to a “psychiatrist” through a computer screen, but were only allowed to ask the “psychiatrist” yes or no questions. Of course, the “psychiatrist” was a program that randomly answered yes or no without any understanding of the questions. And yet the students were able to extract useful information from the conversation, hypothesizing mental models for the “psychiatrist” that resolved even seemingly contradictory answers. Suchman uses this understanding to illustrate how important it is for software to present appropriate feedback in response to a user’s actions; if the software doesn’t, the user will construct an incorrect mental model which will be detrimental to future interactions with the software.

An ideal tool is one that is “ready-to-hand”, that disappears from consciousness. We should aspire to create and design such tools, whether we work in software or any other form of design. And that means being ever aware of the importance of consistent and useful feedback.

Last week, I went to BayFF, an EFF-sponsored roundtable discussion on bloggers’ rights. It wasn’t as interesting as I’d hoped it would be, given the caliber of discussion participants, but that was partially due to uninteresting questions being asked (since I didn’t come up with an interesting question myself, I can’t really censure the rest of the audience though).

There was one part of the discussion that intrigued me. One of the panelists (I think it was Mary Hodder) commented that “information doesn’t age very well online”, referring to the problem that everything we put on the net stays there forever. Somebody else (Dan Gillmor?) made the comment that it’ll be interesting when we get to the point in 20 years when people who wrote blogs when they were teenagers are running for public office – we will have to learn to forgive youthful indiscretions (or at least bad grammar). Apparently, Esther Dyson had spoken the previous weekend and commented that we need to have a statute of limitations for things online, such that after a certain number of years, online information would start to decay, so that people can let the past go.

I’m of mixed feelings about this. I think it’s good to let the past go. But, on the other hand, it’s nice to have a full record of what I did – I certainly want a copy of it, even if nobody else does. I mean, yes, if you go look online, you’ll find the hundred-plus posts of mine to alt.tv.buffy-v-slayer. But that’s part of who I am. It doesn’t embarrass me. Well, okay, maybe it would a little in a work context. But that doesn’t mean I want it erased from the net. I like being able to go back and page through those old discussions. I suppose if an information decay were instituted, I could save such things before they went away, but I don’t mind having it public.

I think what we really need is for people to learn forgiveness, and to understand that everybody says regrettable things. Because so much of our lives are matters of public record now, from everything we’ve ever posted online, to meetings we’ve attended, it’s too easy to find contradictions in the things that people say. Just looking around my web page, you can find all sorts of stupid things I’ve said, because the web page has been accreting detritus for over ten years now. I keep on adding stuff to it, but never deleting anything, so you can read some of my poorly written, uninformed ramblings from long ago, or check out things related to cyberspace that I thought were neat from that time.

I think it would also do good things for our society as a whole to learn forgiveness, especially in the realm of politics. People do stupid things occasionally. If we only want to elect candidates who have never contradicted themselves and never said anything stupid, we get what we deserve. I think we would do better to prefer a candidate that can change their mind and learn from their mistakes, or a candidate who may occasionally say stupid things because they’re actually interested in a discussion of different possibilities.

I think that as we move into the world where more and more of our behavior is able to be tracked online, through blogs and other mechanisms, more people will learn the art of forgiveness as they are confronted with evidence of their own inconsistency and poorly thought out comments. And I think our society would benefit from that process. So I guess I’m against the idea of information decay, and for the idea of personality growth instead, utopian as that may be. Basically, technical hacks to circumvent human nature have never worked for me as a programmer, so I don’t see why they’d work in this case.

Anyway. Nothing else discussed at BayFF really caught my attention except for a reference to ChillingEffects.org, a site which tracks cease-and-desist orders issued to websites. In particular, Google apparently forwards their cease-and-desist orders to the site, so if your site suddenly disappears off of Google one day, you can check to see if this is why (it came up because some woman in the audience had that happen to her and had felt like her freedom of speech was infringed because nobody could see her site after it had disappeared from Google, which gets into an interesting legal area – does the right of free speech include the right to force a private company to carry notice of one’s speech?).

My dad commented to me that the Google Maps Pedometer tool was a good example of a technical mash-up, a phenomenon he’d read about in BusinessWeek (subscription required or use BugMeNot) last week. Much like the musical version, technical mash-ups are mixing and matching tools from different sources that were not intended to be used together. Things like the pedometer, or the google maps visualization for craigslist ads, which is the example used in the BusinessWeek article. The article also mentions GreaseMonkey, a tool I’ve heard a lot about for doing user-side modification of web pages.

What’s interesting to me is this vision of where the future is going. That we’re moving away from the monolithic days of operating systems that do everything, or enterprise server applications like Lotus Notes, and back towards the Unix model of having a toolbox full of simple tools that each do one thing simply, but well. And it’s up to users to put those tools together for themselves in appropriate ways to do what they need. Don Norman proposed a similar future in The Invisible Computer, but he was talking about hardware “information appliances”, and I was skeptical about designing the interface between them. But on the web (or “Web 2.0″, a term for which I still have no definition), the interfaces are already mostly established, from TCP/IP, to HTTP, to XML, to SOAP, to all that other stuff.

I think Google has the right idea in publishing the interfaces to their tools, as can be seen by the way in which their tools are being incorporated in every technical mash-up being built. From their search capability to the maps, they design good stuff and then tell people how to use it. The only problem with this model is I’m not sure how you make money at it. If Google’s tools are being used everywhere underneath the surface, how do they make money off it? Do they charge a micro-fee every time they’re accessed? Do they insist that if you use their tools, you slap a “Google Inside” logo on your tool, the way Intel forced PC manufacturers? It will be interesting to see how the economic model develops in parallel with the technical model.

One other random connection that occurred to me while I was thinking about this post: I think this ties into some of the ideas of Stuart Kauffman. In particular, he mentions how combinatorics enables simple building blocks to achieve unimaginably complex behavior; e.g. if you have one hundred tools, you can combine two of those tools in ten thousand ways, three of those tools in a million ways, etc. The future belongs to letting users and developers mix and match tools for their own uses, because they will find good tool combinations far faster than any manufacturer can. Furthermore, they can create tool combinations that serve very small niche markets, in effect serving the long tail of the market. As noted, the economic model remains to be worked out, but it’s pretty clear this is where things are heading.

In an amusing coincidence, I was in the process of writing this post up this morning when I read Dav’s post that is going in a similar direction. Of course, he’s actually doing something about it besides philosophizing. But that’s another story.