Like a number of other institutions, my institution offers outreach-y type programs over the summer, aimed at high school students. In the case of my institution, we offer a number of 3-week programs in different disciplines that generally follow the same format: class in the morning, and what we call “guided research” in the afternoon. The purpose is to introduce students to various fields through early research experiences, to give them a taste of college life, and, of course, to convince them to apply to my institution.

Last year, following the model of the existing science programs here, we started a program in computer science. I taught in the program the inaugural year, and I’m teaching in it again this year. Basically, I teach a week-long course on Human-Computer Interaction to a different group of students each week, in the mornings, for 3 hours each day. In the afternoons, I work with a cohort of students (12 this year) all 3 weeks on a “guided research” project of my choosing, also in the area of Human-Computer Interaction. (“Guided research” means that students work on independent projects within a particular research area, with some direction from me and my undergraduate research assistant. More on how I interpret this in a bit.)

The morning class is an interesting challenge in and of itself—how do you essentially teach an upper-level CS elective in 12-15 hours of class time, when students don’t have any prereqs?—but I want to focus here on the challenges of introducing high school students to research in computer science.

While I have a lot of experience working with undergraduates of various ability levels on research, I previously had zero experience with the high school crowd. I wasn’t sure at first how much I could expect them to pick up or retain, or whether they would be able to read and understand a journal or conference paper, or even how much mental stamina they’d have, particularly after a full 3 hours of classtime in the mornings. Further complicating matters is that the background of the students varies widely—some students in my research cohort have taken multiple CS classes already, while others have yet to take their first CS class. (This was true last year as well.)

I decided last year, and again this year, that it was important to me that my research cohort have an authentic research experience. “Authentic”, in this case, meaning “something directly pertaining to my own research work”. I also decided that, since I didn’t know better, I’d assume that the experience level of my cohort would be similar to that of an eager, smart, but less experienced undergraduate.

There are some interesting and mostly unresolved data visualization/interface issues in the home networks space, so that’s the research problem my students worked on last year and are working on again this year. This topic choice poses an additional challenge, in that the students have to also understand a bit about how computer networks work in general, but I tell them that this just means they learn a bonus field during the program—2 CS fields for the price of 1!

It turns out that “eager but inexperienced undergrad” is about the right level, but I should have also added “who learns really fast”. I overestimated last year how long things would take and underestimated what they were capable of—I figured they would get to the prototyping and usability testing phase, but they could have actually implemented their prototypes in code instead of just in wireframes. So this year, I compressed the timeline, to leave them time to implement their interfaces in HTML/CSS/Processing. The other big thing I did differently this year from last year was that I spent the entire first research afternoon talking not about HCI, but instead about computer networks, so that they’d have the right level of technical understanding to approach the problem and so that they’d better understand the barriers that home network users face when setting up, maintaining, and troubleshooting their own networks. After all, you can’t design an interface to solve a problem if you don’t understand the problem or the audience in the first place!

I’ve found that some of my project groups are quite comfortable reading (ok, skimming) research articles, and one group even asked if they could search for articles on their own. (They knew about Google Scholar, and I pointed them towards the ACM Digital Library database too.) I haven’t quizzed them, so I don’t know how much they got out of the articles, but some of them seem to be incorporating ideas from some of the papers into their design, and one group asked me last week about citation formats for their posters. Others, I think, are content to just go off the ideas in the paper I required them to read, and that’s fine too. (There is little correlation in this cohort between previous CS experience and willingness to read/skim additional articles, for what it’s worth.)

One challenge from last year that’s easier this year (but still not fully easy) is anticipating their questions and trouble spots. I need to anticipate their questions because they largely don’t understand what they don’t understand, if that makes sense. (And for some, I think they are still a bit uncomfortable asking questions of a college professor.) Often they will ask one question, and in the course of probing further I figure out that they are actually asking a completely different question. This certainly keeps me on my toes.

I’m not sure if they fully appreciate the “authentic research experience” part of their research experience in this program. Part of this, I think, is the short nature of the program—3 weeks is not a lot of time to get into the key challenges of the research problem, much less the nuances, so they don’t get the entire picture. Part of it is that they end up developing a specific interface to address the problem, so the whole thing feels more like “applying CS” than research to them. I don’t even know if ultimately it matters if they appreciate it or not—perhaps in the end it’s just important that they are able to produce something in an area of computer science that they might not have previously considered.

Taking time out of my precious summer research time to participate in this program was not a decision I made lightly—and I do lose some research time as a result. But it’s been an enjoyable and enlightening experience overall, and definitely worth the time investment. In the end, my students challenge me to think about my research in new ways and through new eyes, and that’s never a bad thing!