Category Archives: Teaching

Advocating for HCI in Computer Science Departments

Posted on by
1

Note: This post generated a fair bit of discussion on Facebook and I’m adding (as block quotes) a few of the comments since this was first posted.

Recently, I’ve had a number of conversations where I’ve been asked whether I feel like I belong in a traditional Computer Science department. Given that my whole academic career has been centered on Computer Science (from declaring it as my major upon entry into undergrad to my current faculty position at U of M), I can definitely say that it is my community of practice. I get my funding from NSF CISE, I publish almost exclusively in ACM conferences, I teach only Computer Science courses — where else would I belong? But, I also realize that it is a salient question for many colleagues in my field, as HCI1 researchers are more and more likely to find their home in iSchools, Design, Psychology, Cognitive Science, and Human Factors programs. In this post, I want to articulate why I am of the opinion that Computer Science department and colleges/schools of Computing should be doing more to recruit and retain Computer Scientists trained in HCI.

Meaningful Evaluations – Most Computer Scientists develop algorithms and systems with the idea of improving upon some existing baseline. While some metrics of success may be straight-forward to articulate (e.g., time to run, prediction accuracy), many evaluations may require consideration of a richer and more nuanced set of factors. In the end, the most meaningful metrics look at how a system or algorithm performs in service of people. HCI is the branch of Computer Science where researchers have the training to plan and perform evaluations that lead to more meaningful, ecologically-valid comparisons. More importantly, Computer Scientists trained in HCI also have the fundamental understanding of the development process that allows them to carry out studies that lead not only to summative comparisons, but also to specific implications for how systems and algorithms can be improved in order to perform better in real-world evaluations. For example, an HCI evaluation may reveal the relative consequences of different types of algorithm accuracy errors, leading to an understanding of the kinds of improvements to accuracy that have most significant effects.

I agree with all the above, and would add two things: 1) some HCI work is more oriented around systems building, and that is more naturally centered in a CS department. Sometimes it is very technical application of existing techniques and sometimes it is new techniques – but this kind of work readily live in multiple places. 2) I think the best traditional technical work happens when it is done with close work with stakeholders. Even theoretical work can be stronger when considering the real needs and problems of users. Developing that understanding is best done in close proximity to them – thus integrating HCI into CS can help that process.

-Prof. Ben Bederson, University of Maryland

Diversity – Computer Science has a well-documented diversity problem, which has been growing in recent years. It has also been documented that both women and minorities are more interested in applying STEM to culturally-relevant broader impact contexts. Thus, it’s not surprising that of the few women and minority Computer Scientists who do make it through grad school, many choose focus on HCI. While CS departments should be making an extra effort to recruit and retain qualified women and minority candidates, my personal experience with faculty hiring is the opposite. I frequently see that given two candidates with similar training and publication records (in terms of venues and quantity), women are more likely to end up in iSchools while men are more likely to stay in Computer Science. If this trend is real, it is bad for CS because it is a lost opportunity to increase diversity. The problem is two-fold. First, a CS department may not make an offer to a qualified candidate due to a narrow definition of what constitutes technical work or a contribution to Computer Science. Second, even when an offer is made, the candidate may perceive a department culture that is unfriendly towards HCI work and elect to accept a competing iSchool offer (despite the fact that iSchools may pay less and have a higher teaching load).2 The New York Times recently ran an article showing that as more women go into specific field, salaries in that field decrease. We don’t know the mechanism by which this happens, but my worry is that this is the pattern that is emerging here. Of course, there could be a number of alternative explanations, but I think that it can’t hurt to collectively keep an eye on this.

Learner-Centered Teaching – There are many CS courses that do not require any specific area specialization to teach, most notably introductory classes to CS, computing courses for non-majors, and freshmen seminars. There are many reasons why HCI faculty may be particularly well-suited to achieve excellent outcomes in such courses: (1) there is a clear transfer of skills between designing user-centered systems and designing learner-centered curricula, (2) HCI research can be presented in these courses as a counter-example to popular misperceptions of Computer Science as an asocial, solitary pursuit, and (3) HCI faculty may provide stereotype-threat-breaking role models, given the larger proportion of women and minority faculty in HCI. In my opinion, Computer Science departments with a strong undergraduate education mandate should be actively seeking to recruit Computer Science HCI faculty.

I disagree with “there is a clear transfer of skills between designing user-centered systems and designing learner-centered curricula.” There’s a potential for transfer, but I’ve met some HCI (and even Ed) researchers who are really awful teachers. And I don’t like the idea of giving all other CS teachers an excuse, e.g., “I don’t do HCI, so I don’t have the background to be a good teacher.”

-Prof. Mark Guzdial, Georgia Tech

I wanted to keep it to these three top reasons, but there are a number of other ways that Computer Science as a whole benefits from the specific skills that Computer Scientists trained in HCI bring to the table, including more interdisciplinary work, broader impact of research, and considerations of critical issues (e.g., bias) at design stage.

If you are currently in a Computer Science department and you agree with my arguments, there are a few clear steps you can take to help your department: (1) advocate for soliciting and hiring Computer Science candidates trained in HCI, (2) confront and question arguments against hiring a candidate that focus on vague concern of “not being technical enough” (especially, when candidate is trained in Computer Science and publishes in computing venues), and (3) articulate narratives of Computer Science that include rather than exclude HCI.

1. I use HCI (Human-Computer Interaction) here as the broader discipline, but this includes many related disciplines including HRI, Game Studies, Social Computing, Mobile & Ubiquitous Computing, etc.
2. I am uncomfortable calling out specific schools and contrasting specific people. I am basing this entirely from my personal experience on the job market 3 years ago. I received 3 offers from iSchools and 3 offers from CS departments. Your mileage may vary.

A Month Abroad: Tel Aviv

Posted on by
Reply

As some of you may know, I spent all of July living in Tel Aviv, Israel (location chosen because Eugene’s company has a dev office there). A month has passed since I returned, the dust has settled, and I am ready to reflect a bit on the experience from both personal and professional perspectives. Overall, there were almost no drawbacks to taking this trip and I would recommend a month abroad to anybody in a similar position. I certainly am already contemplating options for next summer!

Chatting about my work at Tel Aviv University. Photo courtesy of my wonderful host, Shuli Gilutz.

Chatting about my work at Tel Aviv University. Photo courtesy of my wonderful hostess, Shuli Gilutz.

There were some major research benefits to spending a month abroad. The obvious one, of course, is that I was able to give talks at international universities (in my case, Tel Aviv University and University of Haifa). The other benefits were more process-based. The trip was an easy way to temporarily put aside the minutia that get in the way of getting the big things done (meetings, continuing stream of email, random requests for my time, etc.). I think the 8-hour time difference was particularly helpful with managing email as I was actually able to check and answer email in one sitting instead of having it trickle in throughout the workday. Additionally, the time constraint of the month-long trip led me to plan explicitly which concrete goals I would accomplish: major revisions on a CSCW paper, re-write a journal paper, write and submit a Jacobs Foundation grant with a colleague, read Ways of Knowing in HCI, and take a course on Machine Learning to build some skills I need for a new project. To get those things done in a month, I knew that I would need a schedule that included daily writing and I would need to read one chapter and complete one course lecture set every workday. Finally, the time constraint introduced a great low-risk way for me to try out a new approach to work and really put it into practice. I was very productive in July and most of it was due to being able to change my focus by getting away for a bit.

The impact of my trip on advising was more of a mixed bag. In the summer, I was guiding two Ph.D. students and seven undergraduate students working in my lab in various capacities. Upon returning, I asked them to anonymously share about their view of my leave. While all the students thought I set clear expectations about being gone during July, four of them underestimated the impact of my trip and found themselves being less productive in their research. Students commented that my presence helped motivate them, get them through blocks, and get quicker feedback — this was harder to do while I was away. However, in terms of instrumental help, all but one students felt that they were still able to get through blocks: by getting help via email from me (5 students), by making a greater effort to solve the problem themselves (6 students), and by reaching out to lab mates for help (4 students). I see these as positives of the trip — my absence encouraged the students to be more independent and proactive in their research.

Seen across the street from a cafe where I did much of my writing. Note the napping cat on the roof.

Seen across the street from a cafe where I did much of my writing. Note the napping cat on the roof.

From a personal perspective, the trip was refreshing and restful despite being productive. It was great to be living with Eugene again, instead of being long distance (as we have been for the past year and will be until May). It was great to be able to work in coffee shops, go to the beach in afternoons, explore the country together on weekends. I find that living somewhere for a month is a different (and better, I think) way of traveling than visiting for a few days. It is more relaxed and more immersive and helped me really get a sense of what everyday life is like in Tel Aviv. I came back feeling as if I had been on vacation, even though I was working full time while there.

That being said, I know that the trip was a luxury that not everybody can afford. I don’t teach in the summer. I chose to only take two months of summer salary so that nobody could really object to me being away. For Eugene and me, the logistics were fairly uncomplicated — we don’t have kids (and I was able to talk a friend into watching my cat). My bottom line is that this was incredibly useful for me and I would love to do something like this again next summer. Maybe this is something that others would consider valuable as well — some sort of a more formal junior faculty exchange program would be really cool!

Reflecting on “Advice for New Faculty Members”

Posted on by
1

boiceI recently finished reading the book “Advice for New Faculty Members” by Robert Boice. It was recommended to me by Jeff Hancock during his visit to University of Minnesota and it was so helpful that I would be remiss if I didn’t pass along the advice to others. Some of you will be starting your faculty positions in the Fall (I wish I had read this book when I started), but I certainly found it helpful even though I’ve already been at this for a year.

This book is different from other sources of advice in that the insight comes not from Robert Boice’s own experiences, but rather from a series of empirical investigations of “quick starter” new faculty members. While there are several places you can find reviews of the book and summaries of some of its lessons, I wanted to focus on three pieces of advice in this book that I’ve found most surprising and most helpful (so far) in integrating into my own work practices:

  • The power of 15-minutes daily. As a new faculty member, many people gave me the advice to make time for writing. I did my best, trying to squirrel away entire afternoons or days for writing. However, I always found that other things came up, eating away at that time. When planning for a whole afternoon but ending up with only thirty minutes, I felt dejected and that it wasn’t worth attempting to get any serious writing done in that period of time. Instead, this book recommends planning to spend 15-30 minutes on pre-writing (e.g., outlining, brainstorming) and writing practices daily. This also mirrors great advice on making use of workable “bits” that I had previously read from Nick Feamster’s research practices blog. I was dubious as to whether this would work for me (“Isn’t there a cost in switching contexts in writing?” I thought), but trying it for a month, I found myself producing more consistently (in July: co-writing a 12-page grant, rewriting a journal paper that needed major revisions, and co-writing significant revisions for a CSCW paper) and less painfully.
  • Asking for feedback early and often. Boice recommends this practice for teaching, research, and service. I had already heard this advice for teaching during my orientation at U of M. Indeed, asking students and visiting faculty for feedback early and often led me to change my class to be more useful to students. Coincidentally, the advice counseled me to limit the amount of material covered each class, which also meant less time that I spent preparing for each session (which is a practice this book encourages for new faculty). However, in research, I have had a harder time asking for early feedback on in-progress papers and research ideas. This coming year, I am committed to finding at least two people to serve as a sounding board on each of my major projects. I suppose this piece of advice is not actually that surprising, but for some reason I never thought about extending the value that I got from getting frequent teaching feedback to the potential value I could get from getting frequent research feedback.
  • Stopping or pausing as a way of increasing productivity. This seemed really counterintuitive to me — how could stopping when I’m “on a roll” lead to more productivity? Previously, when I wrote and I got going, I’d try to really get as much as I could, squeezing every last word out of the moment. However, I failed to realize that this would inevitably lead to not wanting to write the next day and having a hard time starting next time I write. Of course, I didn’t want to start again: I was rewarding each start with a grueling 12-hour workday and I was ending when I was completely out of momentum! This lesson also mirrors Al Franken‘s advice to writers to “Park on the down-slope,” to make it easy to start again. During the past month, I’ve made an effort of stopping each writing session after 30 minutes, even if I am in the middle of a sentence, this has really helped me maintain the practice of daily writing and led to overall increases in the amount of writing I have done.

I’m sure others may find the bits I pulled out obvious but find value in other aspects of the book. Regardless, I definitely recommend this book to others (if you’re at U of M, I have a copy to borrow) and would love it if you could share the bits that you found to be most surprising, interesting, or useful to your work practices.