Recently, I had an amazing opportunity to attend the DSST (Digital Societies and Social Technologies) Summer Institute in College Park, MD. DSST brings together junior (e.g., postdoc, pre-tenure faculty) and established researchers from fields like Computer Science, HCI, Social Informatics, Information Science, Sociology, Anthropology, STS, and more. While there, I participated in workshops, got more familiar with methods used in other fields, and got a lot of great tips on articulating my research agenda (this is frequently a struggle for me because I have such broad research interests).
There is so much I could write about this event, but there is one particular issue that resonated in multiple presentations, workshops, and offline discussions — the issue of vocabulary. It seems to me, that the biggest problems in interdisciplinary work arise not when we don’t know the words the other person is using but when we use the same words in different way. Here are a few examples:
- Problem: In Computer Science, this term often means “research challenge,” as in “I’m working on the problem of how to connect parents and children who live apart.” However, in some Social Science domains the word “problem” may be reserved for situations that are broken or non-normative. In other words, “connecting parents and children” is not a problem to solve — I might be supporting families in facing the challenge of separation, but I’m not fixing something that is broken. In some ways, using the word “problem” takes agency away from the people we am trying to support, instead positioning the designer as “the fixer.” Usually, this is not what people who build systems actually mean. This is a loaded term and might be better avoided or replaced with “challenge.”
- Theory: In Computer Science, this term often refers to the study of abstract constructs like Algorithms and Data Structures and frequently developed through mathematical proofs. In the Social Sciences, there are many types of theories serving different functions (my favorite reading on this is Halverston’s “What Does CSCW Need to DO with Theories?”). Theories are frequently heuristics used to understand and discuss empirical data and may or may not need to have strong predictive power. My personal observation is that theorists of both sorts have keen minds and a love for an elegant explanation and can become great friends once the vocabulary issues can be resolved.
- System: In Computer Science, “system” usually refers to a set of software and hardware that performs a specific function. At DSST, it was more frequently expanded and used to refer not just to the software and hardware but also to the people, practices, and ecosystems around the use of that particular tool.
- Ethnography: I’ve heard builders use this terms to refer to any sort of formative work that involves observing and talking to users. Not surprisingly, people who are trained as ethnographers might see this as an over-simplification. It’s hard to put the same label on a single week of observation versus two years of being embedded in a particular setting. Perhaps, rather than using the loaded term, it might make more sense to refer to specific methods used such as “two weeks of participatory observation” and “contextualized interviews.”
- Social Computing: This is a slippery terms, because we are all still trying to figure out what it means. This area is at the intersection of social science and computational systems, but what is included or excluded? As I spoke to people at the workshop, many equated Social Computing with either large-scale social network analysis (e.g., “we looked at 3 mill Tweets”) or Crowdsourcing (e.g., “we leveraged the crowd to do citizen science”). I was happy to provide a third possibility that I believe should be included in the definition: mediated communication for supporting one-to-one and small-group relationships. I hope that we continue to include things like videochat, ShareTable, haptic connectedness devices, small online support groups, etc. in our definitions and investigations of Social Computing.
In industry, most of our work happens in interdisciplinary groups. This kind of reflection has helped me understand why at times I have had trouble explaining my work or outlook to somebody from a different background, like formal methods or software engineering. DSST reminded me the importance of establishing a common ground and a common vocabulary in any work that brings together diverse disciplines.