Ethnomethodology in Practice
From CS260SP09
Contents |
Readings
On “Technomethodology”: Foundational Relationships between Ethnomethodology and System Design Paul Dourish and Graham Button, Human Computer Interaction, 13(4), 1998.
Implications for Design Paul Dourish, ACM CHI 2006.
Recommended
Technomethodology Andy Crabtree, 6th International Conference on Social Science Methodology, 2004
Discussions
Please post your critiques/commments on the required readings below. To do that, first login by using your user name and password, then click the "edit" tab on the top part of this page (between the "discussion" page and the "history" page), New to wikis? Read the Wiki editing guide. . Hint - Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Seth Horrigan 11:34, 27 April 2009 (PDT)
Since we are discussing topics around ethnographic methods and discussing recording events from an "objective" perspective, Miner's Nacirema example is very instructive: https://www.msu.edu/~jdowell/miner.html
Seth Horrigan 17:27, 28 April 2009 (PDT)
Dourish's comments in "Implications for Design" got me thinking about the applications for ethnographic methods. Although Dourish did not discuss this, I see non-overlapping spheres of usefulness for the two types of methods he discussed. In the first place, "full" ethnographic methods are useful for a designer to understand his audience (aka his "users"). Ethnographic methods allow the designer to learn about who they are, how they behave, how they interact with their environment, and likely more esoteric measures like how they perceive the world. "Discount" ethnographic methods, which are not really ethnographic methods at all, but rather needs-finding methods drawing from the ideology and principles of ethnography, are useful to understand his audience's needs. This distinction is important because discount ethnographic methods do not give the designer a picture of the user; they give the designer a picture of the user's needs. In point of fact, to design a tool, be it software or otherwise, this is mainly what the designer needs; however, to identify the general needs in the first place, and to understand how and why the tool will affect the life of the user (or even if the tool will be adopted) full ethnographic methods are the proper avenue.
Simon Tan 21:30, 28 April 2009 (PDT)
Ah, CHI papers. Since the CHI conference pretty much defines the HCI community, papers like Dourish's tend to attract a lot of attention because they are making a push for why the community as a whole should trend towards one direction or another. Sometimes these attempts can be quite controversial - this year at CHI, there was a paper entitled "Ethnography Considered Harmful":
http://portal2.acm.org/citation.cfm?id=1518835&jmp=cit&coll=portal&dl=ACM
It seems like whenever ethnography undergoes attack in the HCI community, it's because it's not used in the "traditional" sense of ethnography (i.e. with roots in archaeology, long and extended periods of study, etc.). Some say HCI is warping the definition of ethnography for it's own use, and that it then shouldn't call it ethnography anymore. Dourish seems to not wish to reject ethnography, but rather wants to find better ways to make use of it without limiting the community to just creating "implications for design" with it. I understand that Dourish is saying "discount ethnography" techniques such as Contextual Inquiry are not really ethnographic at all, but I believe they are effective.
I suppose accomodating true ethnography in HCI is still a holy grail of sorts, but at least design methods have been inspired, if not truly derived from, ethnography.
Brian Tran 22:30, 28 April 2009 (PDT)
I liked reading about abstraction's relation to ethnomethodology. Many UIs rely on abstractions to make the interface easy for users. The reason that users know what to do with these abstractions is because the correct rational action has already been socially defined by accounts in the real world. Users can make the relation with enough similar features and do the appropriate practical action to get their expected results just like in the real world. This has made practical uses for ethnomethodology so much more concrete in my mind.
David (Tavi) Nathanson 03:36, 30 April 2009 (PDT)
I was fascinated by the "Implications for Design" paper at a broad level, as Dourish essentially stated that the current practices of the community are harmful. I was surprised that anyone would have the guts to submit a paper like that, but it seems (after reading Simon's response) that this type of paper is not alone in the category of papers that push the community one way or another. I have not encountered papers like this in my research thus far, so it was certainly eye-opening.
Regarding the content of "Implications for Design," one point I found odd was the idea that because "implications for design" places design as the natural end-point of research, ethnography is placed outside the design process, and those who ethnographers study are placed outside the design process. It seems that both ethnography and ethnographers belong outside the design process, and that they are simply part of a broader process, but I may be simply confused by Dourish's point.
Priyanka Reddy 22:13, 5 May 2009 (PDT)
I really liked the example given to demonstrate Technomethodology - applying concepts of accounts and accountability to redesign abstraction in computer systems. I found it interesting because when most people talk about making computers more usable, they talk about abstracting more and more away from the user so he/she has no idea what's going on behind the scenes. Generally, it's believed that the less the user knows (and has to know) about the system, the better. The example about redesigning abstraction took a completely different approach - the idea of revealing more behind-the-scenes information in order to make the user feel like he/she knows what's happening and feels like he/she is in control of the system and that it's not just some black box.
I think that if we could use more concepts from Technomethodology to see how other fundamental concepts in CS could change, I think we'd come up with a completely different user experience, and that would be fascinating to see.
