ungrounded

Once, when I was testing out some ideas that would eventually go into a journal paper on applying Activity Theory to peripheral displays I went into Peter Lyman's office. I figured Lyman, an expert in qualitative studies and ethnomethodology, would have a solid grounding in the area and would be able to help me navigate some of its exceptionally convoluted nuances. But when I asked him he just smiled and looked at me and said, "I don't do theory, sorry." At the time, that was shocking to me.

Lyman also said things at other times that made me think he had an appreciation for the style of work we did in the HCI branch of the CS Dept at Berkeley -- lite with theory and heavy with iteration. Reflecting back on these comments, I think that his attitude toward his work relied upon a relatively unusual metaphor, one that I'll call (forgive me) the Rauschenberg.

There are many researchers who apply a house-building metaphor to their work -- they pour a foundation (deep theory), construct the framework (hypothesis and experiment), and if it stays up they embellish the work (generalization, discussion, etc.), or strike the lot. Metaphors can only go so far, of course, and sometimes it is necessary to explain results with a different foundation than what one started with. But the end result is a solid thing that others can see, repeat, build upon, etc.

This is a great metaphor to rely on for scientific work. It is useful because the component of the work that is most generalizable is the product.

But I think that it is a poor metaphor for others, like Lyman, and as strange as it may seem, builders in general. The difference is that for others the goal is not to create a thing that itself is a generalizable contribution, but to go through a process that ends in an interesting or useful result but not one that is necessarily more or less valid than any other.

This is where we get to the Rauschenberg (Robert Rauschenberg was a Neo-Dada artist who would create sculptures ["combines"] by selecting pieces of detritus that he saw on a walk-about around an urban setting). The idea is to pick a certain frame, say discarded street signs, and collect data with that frame in mind. Since there is not necessarily any theoretical underpinning, the selection of a frame is more-or-less arbitrary. And indeed the results for any frame could lead nowhere (if so, pick a new one). Because the frame is ephemeral, you can basically discard it as you move to the next stage, interpreting what you have collected to meet some goal. For the artist this goal is a personal aesthetic (I suppose), but for designers the goal would be something more like usefulness to particular people. Now we can start down the traditional iterative cycle, getting feedback, iterating, throwing away what does not work, etc. But crucially you can throw everything away, including the materials and original frame, because there's no particular spec you are necessarily building to. At the end of this process you have a product that solves a much more specific set of problems and that in and of itself is not at all generalizable.

Clearly this second approach is not science -- it is design.

But then, can it also be research? To the extent that doing research is roughly equivalent to the generation of novel results that can potentially be built upon by others, then yes. Instead of the end result being the contribution, though, it is usually the new tools and techniques that had to be developed in the process of making the final product.*

Such contributions have actually enjoyed some respect in the HCI research community, usually as toolkits. But I think the approach taken in tool and toolkit research is problematic because researchers too often apply the house-building metaphor when the Rauschenberg would do better. That is, they treat the tool or toolkit as a first-order goal, a result in-and-of itself, presumably to appear more scientific (an ongoing concern in the academic HCI community) or futuristic (in the case of tools at least). Most useful tools and toolkits tend to emerge, I think, when the primary goal is a product or application (as is the case with so many platforms today). This type of work, to confuse metaphors again, tends to be more grounded. **

This is all too bad, really, because what is wrong with being a design researcher, making one app or explaining one set of people in one place at a particular point in time, while documenting the tools and techniques you develop along the way?

* One might argue that this would ultimately lead to focusing only on short term products. I think you can expand the types of work you develop, though, by requiring a higher level of technological savvy from your user base, trading off its potential size of course (see earlier post).

** This line of reasoning is related, I think, to the overemphasis on design method that Jon Kolko describes. While methods can play an important role, they should be connected directly to, and always in service of, the construction of a usable thing.

deep drive

The last few years has seen a surge in technologies designed to motivate people to get fit, reduce emissions, save money, etc. These tools take the form digital widgets that modify cute icons, dole out points to encourage competition, or issue tokens to be exchanged for real goods.


Digital widgets and virtual credits can address motivation about as well as a smiley face sticker can address depression.


Every weekend I run a up a mountain somewhere in the Bay Area.

Why?

When I was young I would take trips out to Colorado in the summer to visit my Grandmother. We would drive into the Rocky Mountains and she and I would take long hikes, sometimes in the forests, but also on the high tundra. I would race ahead and double back and she would point out wildflowers she had found during my absence.

When I got older there was no longer anyone there to double back to. So I just kept running.

And since then I have run with foxes, hawks, dolphins, and owls. I've nearly run into wolves and wild hogs and turkeys. I've navigated around horses, cows, and tarantulas on the trail and hunted down old growth redwoods off the trail. I've lept over snakes (always still as stone), helped lost and weary hikers find their way back to their cars (I hope). I've watched storms move across the ocean while running across high ridges. I've put my daughter in a stroller and run her through poppy fields and up foggy mountain slopes. I've dodged falling trees (definitely they make noise -- lots of logs in the woods, not so many flattened squirrels). I've run in valleys filled with the eerie, booming echoes of rounds fired from nearby shooting ranges.

“The mockingbird took a single step into the air and dropped. His wings were still folded against his sides as though he were singing from a limb and not falling, accelerating thirty-two feet per second per second, through empty air. Just a breath before he would have been dashed to the ground, he unfurled his wings with exact, deliberate care, revealing the broad bars of white, spread his elegant, white-banded tail, and so floated onto the grass. I had just rounded a corner when his incouciant step caught my eye; there was no one else in sight. The fact of his free fall was like the old philosophical conundrum about the tree that falls in the forest. The answer must be, I think, that beauty and grace are performed whether or not we will or sense them. The least we can do is try to be there.”
Annie Dillard, Pilgrim at Tinker Creek

This is why. I want to get out there and take in as much as I can, to relive those sublime summer days in the high woods with my Grandma*. So that I am able to do those 10-25** km runs up one or two thousand feet (or more) I of course have to crosstrain the rest of the week. But with that reward in mind, training is easy.

I think there are parallels. When I was young I drove long distances to school across Atlanta and witnessed gruesome accidents; hideous, rageful screaming matches between drivers that sometimes came to blows; and at best I not-so-patiently suffered through seemingly endless, boring traffic. So now I live close to work and often bike or walk.

And I don't know how you can have a child and not be fiscally responsible.

Motivations run deep. The best an app can do is to lead you to the edge of the mine.


* I do occassionally run in races, though I am not sure why -- perhaps just for the sake of variety. I never stay for the award ceremony.

** I am no ultramarathoner. For me the negatives of running overwhelm the positives at about 25km (on mountain trails anyway).

average margin launch

I've finally rolled out average margin. For now, all men's college basketball game scores and average margins will be posted to a Twitter account (I may change the way scores are published at some point). The basic idea is that by adding just one more number to a score bug you can get a lot more information about how the game went.

A good example is tonight's game between second-ranked Ohio State and lowly IUPUI. The Jaguars lost to the Buckeyes by 11, so just seeing the final score scroll across the bottom of your TV — 75-64 — you might not give the game a second thought. But average margin reveals a surprisingly tight contest. Here's the tweet for that game:

*ohio state 75* iupui 64 | avg margin: ohio state +0.8 #closerthanthat http://goo.gl/LIzV4

Ohio State in fact only took control late and so won average margin by less than 1 point.

That tweet also includes a tag "#closerthanthat" which is applied to games in which average margin reveals a much closer game than the final score would indicate. The reverse case, in which a close final score fails to reflect a game that one team actually had control of, I tag with "#notthatclose". Here's an example:

*unlv 75* boise state 72 | avg margin: unlv +12.5 #notthatclose http://goo.gl/wIB8L

UNLV was in control of this game most of the way — Boise State only made a push late to close the gap.

Finally, tweets can include another tag, "#veryclose", that indicates that a game's final score was close *and* the average margin was close, which probably means a great game to watch. Another example:

*missouri 85* vanderbilt 82 | avg margin: missouri +0.6 #veryclose http://goo.gl/zwLge

As you can see from following the link, the game was within a bucket or two almost the entire way.

There are a few other things I might add at some point, including the difference between the average margin and the spread, but this is a start.

PS To calculate average margin I use game flow data from StatSheet.

the problem with paper

A writer for the TC blog, Erick Schonfeld, recently posted a description of an encounter he had with a Stanford student at a drug store trying to recruit users to experiment with a paper prototype. The prototype and study were being carried out as a requirement for an HCI course the student is taking. The TC writer, in short, found the whole experience ridiculous, especially with respect to all of the whiz-bang, interactive demos he is used to seeing. While, as many point out, paper prototyping is a standard technique in HCI, that does not mean that it always works or is always appropriate. In fact, in my experience with early stage prototypes I was overall underwhelmed with paper prototyping. But I realized over time that experience did not reflect a problem with the prototyping tool per se, but rather a lack of understanding of the context of the user.

I conducted countless paper prototypes during my graduate school career, and time-and-time again I encountered users similar to Schonfeld. I saw a lot of strange looks and cocked heads. Because I was in a more constrained setting (a lab as opposed to a drug store) I was usually able to take the time to explain what it was we were doing and why it was important. But users were rarely as invested as they were in later stage testing. This eventually led me to the conclusion that HCI tends to treat users far too monolithically.

In testing a paper prototype it is important for the user to set aside some concerns while focusing on others, and some users are able to do this more readily than others. In particular, I think there are at least four groups (hastily sketched in the diagram below): your design team, your liminal colleagues or (using Rogers' term) innovators, early adopters, and the early majority. Just as you choose the right experimental technique to fit the current stage of your prototype, you also must choose the right group to test your ideas (this critique is similar to Greenberg's and Buxton's). At the earliest stage, when you are just beginning ideation, it is likely that only your design team has the context necessary to understand what it is you are really getting at (that is, only they have the necessary grounding). The next step is to make those paper prototypes, but at that point you can only target other colleagues or people comfortable with taking large leaps of understanding with prototypes. Early stage interactive prototypes can be tested with early adopters. Finally, only when you have something pretty close to a traditional beta release should you approach the early majority (the people you might expect to see at a drug store in Silicon Valley). But doing so beforehand is usually a waste of time.



The other thing to keep in mind is that "innovator", "early adopter", etc. are just hats that people put on and they're not wearing them all the time. Someone who is usually an innovator may be much more conservative if they've just stepped off a red eye flight. This means that any quantitative questionnaire to determine which group people are in is nearly useless. It is probably best to catch people when they are likely to be in a certain frame-of-mind (innovators might be more likely to think like innovators at a trade show, for example).

bigotry should never get a pass

I lose patience with the argument that because of someone's time, his limitations are therefore excusable or even praiseworthy. It is not true that it was impossible in that time and place to look any higher. Think of Wendell Phillips, who commenting on Abraham Lincoln's proposal to colonize Black people out of the country was sarcastic. He said, "Colonize the Blacks? A man might as well colonize his own hands, or when the robbers are in his house, he might as well colonize his revolver."


Barbara Fields

Open-access publishing

Laurent and I recently published an article (SeeReader: An (Almost) Eyes-Free Mobile Rich Document Viewer) in the special issue on Pervasive Computing in the International Journal of Computer Science Issues (IJCSI). The IJCSI is open-access, meaning that the content is not hidden behind a paywall. Open-access journals are still seen as dubious by many, and perhaps rightly so. These journals are universally new and tend to enjoy less prestige and quality than mainstream journals. In return, though, they offer fast turn-around times and wide indexing.

Mike Taylor provides a good overview of the tradeoffs between publishing in traditional journals versus open-access journals, albeit in a different domain. In it, he writes:

There are (at least) two reasons to favour open-access journals: the pragmatic one is that it's the best way to make sure that anyone, anywhere in the world who's interested in your work can get it -- whether professor, curator, student, interested amateur or vaguely interested high-school kid. The other reason is that it's just right. We're talking here about the world's accumulated knowledge, in many cases acquired by publicly funded research programs. It is simply and plainly wrong that this work should be shut up behind paywalls where the people who paid for it can't see it.

One issue that seems to make detractors queasy is registration fees. But of course publishing, even primarily online, has some cost, and if the papers are being given away for free then the publisher must be recouped in some other way. As this article points out, paper fees are a common approach.

Another argument against open-access is that, if you're interested primarily in dissemination, why not simply post the paper to a blog? My take is that there are really two bars that a paper needs to cross to be published in a traditional journal or conference. The first bar is simply whether or not the work seems reasonable. That is, does it appear to make some type of contribution, is it well argued, and does it spark at least some interest? The second bar is whether the work is framed correctly for a particular conference or journal and whether it builds significantly on other work in the particular sub-fields important to the publication. My sense is that in most cases roughly half of the submitted papers pass the first test and about a quarter pass both. But now that sharing, annotation, and commentary are ubiquitous on the Internet, it is not clear to me how important that second bar is. Why not, after a sanity check (the first bar), release your publication to social review? This might even encourage cross-polination of sub-fields that are all too often sequestered.

That said, I would not advise anyone to move (yet) to an all-open access approach. I think it is important to show that you are capable of publishing in any type of venue, and that open-access is a choice, not an act of desperation. I think they are especially useful for fields that are moving fast. There is usually less than two months from submit to publish for open access journals, which includes 2 reviews, feedback, and one revision, often with immediate publishing to the web and follow-up in print. This beats the pants off of most journals and even conferences. For a field (like, currently, mobile technologies) near the inflection point of the S-curve, I believe it makes sense to push some ideas to open-access journals, especially, if as was the case in our paper, they are specific applications and not general models.

It is also important to note that there are hybrid models supported by many traditional publishers (including Elsevier and Springer). In those cases, authors can choose to pay to have their paper made available publicly. However, this only solves one part of the problem -- access -- and does not address speed.

Other projects go further, cutting out the paper altogether and exposing instead raw scientific workflows (it will be particularly interesting to follow the impact this has on the social construction of knowledge). In general, like other publishing industries, as more people gain confidence in the Web as a publishing medium, academic publishing will have to change.

Ada Lovelace Day

Today is Ada Lovelace Day. Given that I've named my child after Ms. Lovelace, I feel obligated and honored to take part in the pledge to "highlight [a] women in technology" that I look up to.

While I've many present and past fabulous female colleagues, if I'm to chose one to write about it's a no-brainer.

Jennifer Mankoff is an associate processor at the Human Computer Interaction Institute (HCII) at Carnegie Mellon University. Jen was my graduate advisor at Berkeley, seeing me through a master's and PhD. Perhaps "nurse" is a better word, as she not only worked tirelessly with me to improve my abilities but at times literally cared for me when I was ill.

Jen is a whirling dervish. A good Samaritan. A force of nature.

Jen's genius is her ability not only to handle adversity but to turn it on its head. When Jen was a senior graduate student at Georgia Tech, she suffered a severe injury to her hand that made it difficult for her to type more than about half-an-hour a day. For any student trying to write her PhD thesis, this would be a huge obstacle, but for a student studying computer science having such a limited ability to type could be devastating. Jen instead used this as an opportunity to teach herself how to break down tasks into small, well-defined chunks, map out a detailed course of action, and then relentlessly focus for the half-an-hour a day she had to work. She was able to complete her thesis on time using this approach, and she extrapolated from that success a methodology for working that has allowed her to pursue a mind-boggling array of world-class research projects while raising two children and fighting through a difficult, debilitating illness.

And this: Jen is honestly trying to change the world for the Good. She has pursued breakthrough research on improving access to digital technology for people who are disabled, and she started an ambitious sustainability project well before the Obama administration took such work mainstream. I am afraid that my disposition is too cynical to believe completely in such utopist technological innovation, but bless her for trying.

When my daughter, Ada, is older I will tell her stories about Jen, about how she fought for gender equality in faculty hiring practices at Berkeley, how she would conduct research meetings while nursing her newborn, how she worked with students at Berkeley to create an information service in the wake of 9/11, and many other stories. Ada will learn from Jen's example how women can succeed in technology, obliterate misogyny, and still fulfill their familial desires.