Category Archives: Conference Reviews

Reflecting on Grace Hopper 2014: the Good, the Bad, and the Ugly

Posted on by
1

Earlier this October, I had the wonderful opportunity be one of the eight thousand women attending the Grace Hopper Conference and Celebration of Women in Computing. I came back home to a lot of questions about some of the press coverage of what happened there. So, here is my take on the good, the bad, and the ugly.

The Good. I always come back from Grace Hopper feeling inspired and energized. Four reasons for it this time… (1) I’m getting to have more opportunities to give back and share advice instead of just asking for it. After a long conversation, an undergraduate woman told me “I’m seriously thinking about grad school now and you’re about 90% of the reason.” Wow! (2) Through the CRA-W, I got to give a talk about “How to Get Your Dream Job” with Jaeyeon Jung. It was probably the largest and definitely the most enthusiastic audience I’ve ever had! (3) It was so inspirational to attend talks by women like Shafi Goldwasser and Megan Smith and Maria Klawe! It’s hard not to go fangirl over this! (4) Last but not least, the dancing. The dancing at Grace Hopper is always amazing! It is totally an experience that every woman in computing should have!

Dancing at GHC is always amazing!

Dancing at GHC is always amazing!

The Bad. Certainly, this year’s Grace Hopper came with quite a bit of controversy: a male allies panel went awry; Microsoft’s CEO said that women shouldn’t ask for raises. And yet, even these issues give me hope for the future. First, yes, the male allies panel had problems: the format shut down discussion (e.g., no Q&A) and the panelists made some very naive statements (see: “how to be a bad ally“). However, many overlook that these men took the feedback to heart and organized an ad-hoc panel the following day where women spoke while the men listened. Second, yes, Nadella did not handle the question about raises well on stage. But, he was there, he apologized right afterwards, and he launched a campaign to address the issues involved. I really believe that the net effect from both of these “bads” is positive. It both draws attention to issues of women in the workplace and makes me optimistic about male allies’ abilities to learn from their own mistakes and make positive changes.

The Ugly. However, one topic that was not well addressed at this year’s conference was the ugliness surrounding GamerGate. It was mostly discussed in the hallways over coffee rather than in any sort of formal way. We need to address this head on. We need to stand with Zoe Quinn and Anita Sarkeesian and Brianna Wu and any other women who face threats and harassment online. I am committing to doing what I can to bring a panel on GamerGate (hopefully with all of these women above) to Grace Hopper next year. Honestly, I have no idea what I am doing on the logistics side (I’ll basically be cold emailing them) [Update: all three women have tentatively agreed]. Also, I am a bit scared to become a target, but if these women can live it, I can brave the small risk. This panel needs to happen. If you have any advice, let me know.

Designing Technology for Major Life Events Workshop

Posted on by
Reply
High emotional impact and the value of the journey are two big aspects of designing tech for major life events.

High emotional impact and the value of the journey are two big aspects of designing tech for major life events.

While at CHI, I got the wonderful opportunity to help organize the workshop on Designing Technology for Major Life Events along with Mike Massimi, Madeline Smith, and Jofish Kaye. We had a great group of HCI researchers with a diverse range of topics: gender transition, becoming a parent, dealing with a major diagnosis, bereavement, and more. My own interest in the topic grew from my experience designing technology for divorce and technology for recovery from addiction. In one of the breakout groups, we discussed the challenges of designing technology in this space and some of the ways we’ve dealt with these challenges in our work. In this post, I want to highlight a few of these:

Building Tech is Risky. Building a system requires the designer to commit to specific choices and it’s easy to find something that wasn’t adequately considered after the fact. In tech for major life events, this challenge can be exacerbated because the consequences of a failed design might have big emotional repercussions (e.g., tech messing up some aspect of a wedding). Sometimes, it is a big question of whether we even should try to bring tech into a given context.

Ethics of Limited Access. Building technology to support a major life event may mean excluding those without the financial means, skills, motivation, language, etc. to use the provided intervention. Additionally, we frequently stop supporting a prototype technology at the end of the study which can be really problematic if it was providing ongoing benefits to the participants. Again, because of the high stakes involved, issues of ethics of access to technology may be exacerbated when designing for major life events.

Tension Between Building Your Own and Leveraging Existing. Many systems we build require some critical mass of adoption before they are really useful. This is particularly important with tech for major life events because there may be relatively few people facing a particular relevant context at any point in time. One of the ways to deal with this is to piggyback on existing systems (e.g., building a Facebook app instead of a new SNS), but this may cause problems when the underlying technology makes changes outside of the researcher’s control (e.g., privacy policies change, APIs stop being supported, etc.).

Asking the Right Questions about the System You Built. The final challenge is understanding what kinds of questions to ask during the system evaluation. On one hand, it is important to go into the evaluation with some understanding of what it would mean for the system to be successful and the claims you hope to make about its use. On the other hand, it is valuable to be open to seeing and measuring unintended side effects and appropriations of the technology.

I think my two major take-aways from this discussion were a greater appreciation of how difficult it is to actually build something helpful in this space and the insight that many of these problems can be partially addressed by getting away for the type of study that focuses on evaluating a single system design using a small number of metrics. The risks of committing to a specific design solution can be mitigated by providing multiple versions of the intervention, either to be tested side-by-side or to let participants play around until they decide which solution is a better option for them. The ethics of access can be ameliorated by providing low-tech and no-tech means of achieving the same goals that your high-tech approach may support (e.g., Robin Brewer built a system to let the elderly check email using their landline phones). Planning for multiple solutions when building using others’ APIs can lead to a much more stable final system (e.g., the ShareTable we could easily switch from the Skype API to the TokBox API for the face-to-face video). And lastly, the problem of figuring out what to ask during and after a system deployment can be addressed by combining quantitative methods that measure specific predicted changes with qualitative methods of interviewing and observation that are more open to on-the-fly redirection during the course of the study. Overall, diversity of offered solutions, flexibility under the hood of your systems, and diversity of methods used in the evaluation lead to a stronger study and understanding of the target space.

What’s In a Word

Posted on by
Reply
9409141159_66fbabd750_z

There were a lot of sticky notes involved in figuring out my next research agenda. Luckily, I got great help at DSST!

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).

In small groups, we mapped out the research space of DSST, focusing on how we fit into the picture of a research area that encompasses so many different communities and venues. Interdisciplinarity is not for the weak!

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.