Expanding Your Horizons

Introduction

Expanding Your Horizons is a network of conferences for girls, with a goal of increasing interest and participation in science. In 2010, the CS department led an activity at the Madison, Wisconsin EYH conference. We noticed that it was hard to find information about what other computer science groups had done, so we are documenting our experience in the hopes that it will prove helpful to other groups.

Conference Format

The format of the conference and the specifics vary between EYH conferences, so this information will be specific to the one in Madison. The conference runs from 9:30-4:30 on a Saturday in November. The students are girls in middle school (grades 6-8 / ages 11-14) and come from both the city of Madison and surrounding areas. Some of them are there because they're interested in science -- and some are there because their parents signed them up and made them go. The girls are put into groups of 10-14 students, with a pair of undergraduate student leaders who bring them between sessions and generally help out. Each group attends 3 sessions, each from a different area. They attend at least one that they indicated they wanted to attend on their registration, and at least one that they did NOT choose, in an effort to expose them to fields they might not know anything about. Each session is 50 minutes.

Presentation Goals

There are two goals to the session. The first is to expose the girls to some cool, interesting science that they might never have seen before. The second is to demonstrate that being a scientist and being a woman are not mutually exclusive. The second goal is important because the stereotypical image of a scientist is an older white man in a lab coat. By showing that women with families and hobbies can also succeed as scientists, we hope to encourage girls to believe that they, too, can become scientists. This document will include our experience with both these goals.

Considerations

There are several things to take into account when designing an effective presentation. Some of these are partially based on Tips for a Successful Career Session, provided by EYH Wisconsin.
Interactivity
Sessions that are too heavy on demonstrations and presentations may bore the students. Hands-on activities are nice because the students get to interact with the presenter(s) and one another, and actually get to "do science." On the other hand, simply turning them loose without sufficient structure might set them up to fail (or be confused about the point), and they might not make the connection about how the specific activity they're doing is related to the field as a whole. A consideration that is probably less relevent in computer science is that if parts of the activity are flashy but dangerous (think liquid nitrogen or some chemical reactions), it might need to be a demonstration to keep it safe for the students. However, the Tips for a Successful Career Session indicate that hands-on sessions are especially popular.
Teamwork
If the girls are working in groups that are too large, some of them may not be participating or getting as much of a chance to say something or discover things on their own. On the other hand, if they're working on their own, they might get stuck or intimidated and be too nervous to ask questions.
Reinforcing/Breaking Stereotypes
Besides stereotypes about what computer scientists look like, there are also stereotypes about what they do. One that seems to be prevalent is that computer scientists design video games. Another is that CS is all about robots. Or, from their computer classes at school, they might think that CS is making spreadsheets and using a word processor, and you have to be really good at typing. A particularly popular stereotype is that computer scientists are people who fix broken computers and do tech support (something that probably shouldn't surprise us, considering how often we get asked to fix relatives' computers and printers!) We want to at least consider what kind of stereotypes we are reinforcing or challenging.
Making a Difference
We noticed that many of the other areas had descriptions that included something about saving lives, helping animals, or saving the environment. Having a positive impact on the world can be important to the students, so we want to show them that computer scientists can make a difference, too.
Time Constraints
50 minutes isn't very long, especially considering that the students might be a few minutes late, and it takes time to get everyone settled in, for wrap up, to introduce the presenters and students, etc. If there are multiple activities, we also need to consider the time it takes to switch between them.
Possibility of Failure
The last thing we want to do is have an activity that the girls "fail" at in some way, and then have them decide that clearly that means that computer science is too hard for them. At the same time, we don't want to make it trivially easy, either, because they'll get bored. We want to have something that is both sufficiently challenging to keep them engaged and give them a sense of accomplishment, but also that it is hard to "fail" at, either because we give them enough support or we have an open-ended activity.
Cool Factor
Some of the sciences have lasers, liquid nitrogen, fire, cow stomachs, etc. We want them to think that CS is just as interesting and cool.
Budget
We might not have a very large one, so our resources are limited.
Info to Cover
According to the Tips for a Successful Career Session, there is some information that girls want to know about a job. They list the following:
  • how to plan my education to prepare for it
  • how much money I would make doing it
  • that it is fun
  • that I can do it and have a family
  • what people with that job do on a normal day
One of our general goals to make sure that the girls realize that the presenters are real, 3-dimensional people with hobbies, friends, and families. We also want to break stereotypes and give them an idea of what a typical day at work would be like; some of the reason that so many of them are interested in being doctors and veterinarians might be that they've met doctors and vets before and know what they do, while they don't really know what some other kinds of scientists work on. It is also important to keep girls taking math and science classes in middle school and high school, so that once they get to college, they have the option of taking STEM classes (even if they ultimately decide they don't want to become scientists).

Pre-2010

A group of grad students (and possibly undergrads) from WACM did activities for EYH for several years in the past, and there used to be an officer in WACM responsible for EYH. With turnover of grad students, the momentum was lost, and there were some number of years with no representatives from the CS department. These sessions had an activity with drawing faces on pumpkins in Java (seasonally appropriate because the conference takes place in the fall). Skeleton code was provided, and then they used the coordinate system to design their own jack-o-lantern.
Pros
  • Each student got to design her own pumpkin (so they could be creative and unique).
  • It showed that programming is just telling the computer what to do.
Cons
Since none of us were around at the time, we don't know how well the activity actually went. However, one possible concern is that because of the skeleton code, there's a lot of "magic" going on that they don't understand. From the finished versions that were put up online, it looks like some students didn't get very far (probably because of the limited time). It is also hard for the students to continue working on it, because it requires the skeleton code, an IDE, etc.

2010

A group of 6 grad students and one professor ran a session using Scratch. Scratch is a programming environment with draggable instructions that control sprites (actors), the background (stage), and music. It makes it easy to create simple games and tell stories. We started our session with about 10 minutes of introductions. We had the students introduce themselves and tell us a fact (I can't remember what the question was). We then gave a short powerpoint where we talked about how computers are in many of the devices they use on a daily basis. We also talked about what kinds of jobs computer scientists have. In the presenter introductions, we also made sure to have a fun picture, to list an outside hobby, and to say what we liked about CS. We tried to ask the students what they thought at many points in the presentation.

After the introduction, we ran through a short presentation about the basics of Scratch. We tried to keep this short, but we wanted to give the girls some idea of what to do before setting them loose. Afterwards, each girl got to work on a computer for the remaining approximately 30 minutes. We provided them with a guide to a simple project (bouncing sprites that, when clicked, turn into letters and move to form the student's name), but allowed them to decide whether to follow the instructions or do something else instead. Most students chose to work on their own ideas. At the end of the session, they each got their own thumb drive to save their work on and take home. The drive also had instructions for downloading Scratch and for our activity.
Pros
  • Students could work at their own pace, and do whatever they thought was cool.
  • It showed that programming is just telling the computer what to do.
  • Some of the students came up with things we didn't even know how to do in Scratch.
  • The students could continue exploring at home, if they wanted to (and they got a cool thumb drive).
  • Because we had lots of presenters, we could work closely with students and give them a lot of encouragement.
  • The presentation gave examples of different kinds of computers, as well as different types of jobs that computer scientists can do, hopefully breaking some stereotypes even if our Scratch activity didn't.
Cons
  • Might have been reinforcing the computer science == video games stereotype.
  • Student feedback indicated that although our activity generally had a good rating, some girls were getting frustrated.
  • Students worked alone and might have gotten stuck because of it; we had enough presenters that we could ask them how they were doing every few minutes, but a partner/group activity might have been more engaging for some of them. And after all, computer scientists do talk to one another, not just sit at machines by themselves.
  • Listening to 20 minutes or so of our presentation right at the beginning might have been boring for some students.
To hopefully give others ideas, here is our presentation. We made sure to stop and ask the students what they thought the answer was before each slide. We had this set of instructions, though most students didn't use them. Feel free to use it for inspiration, but please do not modify and redistribute it without permission.

2011

Planning for 2011 is in progress.
Ideas so far: Arduino, Lego MindStorms, Wakamaru
Mindstorms Experience: The first thing I found when trying to use it was that the interae was not intuitive to me. I'm not sure how much of that is because I come with a lot of preconceptions about how things should work, and how much is because it really is confusing. Wires are DEFINITELY confusing -- I understand how they work now, but it's hard to drag them places or delete them. It also took me an embarassingly long time to figure out how to expand the tab with ports to show the rest of them.

2012

Organized, planned, and led by 3 students. I think this year was the most successful and that we've learned from our previous experiences.
Activity: We once again used Scratch. This time, we had a project in mind -- link -- which was a simple game where there is a sprite bouncing around the screen. You try to touch it with the cursor, which makes it stamp, then change costumes and reappear in a random location. Each time you touch it, you get a point, and the goal is to get the most points in a certain amount of time. We chose this project because it's a game, it's simple to explain and implement, and yet uses a variety of concepts: movement, interaction between sprites and the mouse, the timer, variables, random numbers, and if/while blocks (control flow). We close not to use clicking on the sprites, because that's a little iffy in Scratch.
We started our session with a brief presentation on what computer science is, similar to the one we used in 2010

Other Ideas/Resources

Some ideas to think about (warning, this is unedited stream-of-consciousness that I will clean up before the final verison of this document):