CHI 2010: panel: the infrastructure problem in hci

| | Comments (0) | TrackBacks (0)

the room is packed -- much more so than for international research

liebhold's matrix

Paula Bach: how would we talk to each other?

Steve Jackson (?) 5 questions for a really good paper:
How do we grant users and usability experts legal standing? Because that plays an enormous role in changing telecommuncations policy
Is infrastructure a thing or a relation? This paper pulls back from the STS relational conception, which would say that the infrastructural qualities are not embedded in the quality of the thing but are produced in the relationship between the thing and the user. Ie, stairs. For someone in a wheelchair,
Do we want to privilege or prioritize the concerns of some users over others? Leigh Star: the problem of infrastructural orphans
When is a tool? Infrasturcture opens itself to engagement in different ways at different times. History of technology and economic history. At certain moments of making, infrastructure may be amenable to certain kinds of intervention, which raises the stakes
What does this look like in practical, organizational terms? First steps towards that in terms of metrics. But there's a lot more to be said. Does this mean systems people come to our conferences?

Mark Ackerman:
great to bring in discussions of time and technology
caveats
1) STS literature brings lots of depth!
2) IEAs only will be filled out at gunpoint by request of someone with a seat at the table - need to ground in organizational and institutional format
3) reflects a standard American fascination with progress and improvement and the closing of the frontier (Turner)
where they could push
- HCI has an obligation to cover what code does as a design need Norman Meyerwiss's 1985
-- invisible technologies -- like grading, which was invented in 1792. what does that mean for recommender systems?
-- pushing on what code does in respect to design
- software as infrastructure - what it abstracts, with respect to whom
-- how can we do research on technology that increasingly becomes *other people's technology*
--- like, for example, very large systems. like facebook. you could build an online community, but his grad students are not going to do that in their spare time [

Gregory Abowd
- what do you mean by infrastructure? what you want infrastructure to be is that what you don't have to worry about.
- what people at CHI are upset about is that the systems people don't play attention to THEM
- systems people like infrastructure when some of it is exposed so they can use it
- most of you spend your time solving the wrong problem - trying to patch those problems is a waste of time when you should be trying to fix the infrastructure
- if you want to reach out and hear what the systems people have to say, maybe you should get speakers here who speak from that community -- there are more systems conferences that invite HCI people than vice versa

Dan Olsen: we have infrastructure problems bc HCI abdicated the issues -- we walked away -- somebody else invented the web, and how cell phones work -- "we abdicated because we assumed that the infrastructure was done and we just had to put a pretty face on it." also done bc we think infrastructure is too hard. "these things are not too big unless we have an ignorance barrier." "we have calculus phobia." "If you put an algorithm into a CHI paper it's like the kiss of death" "the user study drug" "not because it's a bad thing but because it's so easy to evaluate" "we don't get these papers in here, skip to the user study, oh there isn't one, NEXT!" "I think we have to partly fix our education and partially fix how we think about it."

Q: wants to echo what Gregory said. when she presents what she does, practitioners are thrilled because they don't have to do that work. she has been continuously asked to give tutorials at the conference, but has given up on trying to get papers in after. So what makes it different today that we can have a panel of researchers talking about this, when 8 years ago everyone said it was too boring and should go to the software engineers?

Mark Ackerman: within CSCW, people are asking what the role of technical research should be. so this was a timely papaper.
Newman: the systems that we're building are more infrastructure-dependent than they were in the past -- cloud computing, etc. Multiple layers of infrastrcuture. The software industry is able to move faster than research is. Not as many UI toolkits now at CHI because they're already being built by manufacturers.
Q: but the timeline of product line architecture is 10-15 years!
Dan Olsen: Don't see anything on the iPhone we couldn't have prototyped.

Q: Why now? Also, crisis informatics. Disaster is interesting from an infrastructure perspective. ICT4D. Narratives of different kinds of infrastructure and infrastructural arrangements. Any bearing on why infrastructure is a problem, a challenge, and an opportunity?

GA: Doesn't think that infrastructure is just surfacing now as a topic.
Dan Olsen: we just exhausted what we can do with one pointer and a keyboard.
Scott Klemmer: couldn't figure out the takeaway of this paper. paraphrases what he thinks they are. we're not in dialogue enough with the systems folks. social computing folks -- they all hang out and make progress on all fronts. a seachange in systems similar to that in chi -- classics systems work is performance oriented. but work people are submitting now has a metric other than speed. Eddie Coler's make your own router system. He argues it's more user-friendly. Also similar stuff happening in theory.
Newman: their goal: build a framework for an ongoing discussion. the takeaway is a framework for the discussion. an exposition of the shortcomings we currently have. he agrees we're short on solutions right now.
Q: disagrees about building infrastrastructure. would rather have spent 10 years of energy building the best interfaces I could for zoomable interfaces, I would have been more successful and the s the field would have been more successful. Build infrastructure because I didn't have the killer app! But no one came up with that killer app because of the infrastructure I built. Just build the kludged version you need in order to create the interaction you want in order to get people to understand why it's important. But if you don't built that app, you may well be wasting your time.
Abowd: tells story of student who couldn't come up with killer app. build the "context toolkit" -- 13 years later there are lots of killer apps relating to context, and people point to that piece of work as an inspiration.
Mark Ackerman: one problems is that we don't give people a lot of incentives for building the infrastructures for us. ie, physics: you get credit for building the satellite that other people use.

Edwards: lots of problems right now bc no input into infrastructure, like in security, which wasn't build to be usable.
Newman: what we need is not more toolkits. "things that we build that are playgrounds for us but they don't necessarily have the impact." what we need to do is engage in the process of building.
Ackerman: push back on it -- context project which wasn't published here bc we weren't interested in it "what are the next infrastructures we need" "are we going to give credit to the people who build them?"
Q: physics. I look at other disciplines. Why don't we have these larger projects that we work on together. Why is it that toolkits are just the property of one person?
Abowd: the physics community is self-contained. they work on similar problems. the problems that we work on are not self-contained. the big projects are people working on twitter and facebook, and they're relying on the people who create those phenomena. So the projects . Don't think it would be desirable for all the HCI folks to be working on the same project -- it wouldn't be all that meaningful.
Q: something missing: the constraints upon engineers. building on infrastructures now means building on the infrastructures which we have now. the thing that we love that has not been built cannot be used by anyone. so building something makes some constraints. building something that supports the use cases we know about eventually trumps what we don't know about. the same things come up in the built environment.
Ackerman: wants to take apart infrastructure and research infrastructure
Jackson: argument for thinking with care about the infrastructural moment we live in. very few infrastructures are built from scratch. so when can we have more of an effect?
Q: from someone from the Social Security Administration! working on user experience framework for SSA. problems with designers who don't take into account implementability, and engineers who don't take user experience into account.
Edwards: experience on research side, not so much on developer side. cultural differences, terminology differences, value differences. in collaborations with systems people, it seems like they often design for the things that are easiest to measure. the human stuff gets left by the wayside.
Q: a third choice. "the world is going to be real and you run into the wall" build into the infrastructure the capacity for the users of it to respond to unanticipated situations. is there in the infrastructures we're building the capacity to be growable for humans. to deal with the fact that we won't anticipate everything.
Newman: infrastructure as object, infrastructure as relation -- this is infrastructure as process.
Erika: incentives matter


0 TrackBacks

Listed below are links to blogs that reference this entry: CHI 2010: panel: the infrastructure problem in hci.

TrackBack URL for this entry: http://www.confectious.net/mt/mt-tb.cgi/898

Leave a comment

About this Entry

This page contains a single entry by Liz published on April 20, 2010 5:36 PM.

links for 2010-04-10 was the previous entry in this blog.

CHI 2010: Lucy Suchman Lifetime Achievement award talk is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Pages

  • /thinking
  • projects
Creative Commons License
This weblog is licensed under a Creative Commons License.