Designing an Intro to CS for Non-Majors: From Objectives to Problems

When working on my introductory computer science class for non-majors, I started with the objectives.  From there, I thought about the types of assignments and tutorials I wanted, but mostly moved on to figuring out the actual lecture content.  I like to organize my courses by specific problems in a way that is loosely related to inquiry-based learning.

With this approach, I think about the kinds of things that my audience might find useful or interesting.  The earlier problems tend to be more on the interesting side, but by the end the problems should be more relevant to the students' fields.  During lectures, I will introduce the problem by showing the completed software, then go step by step in showing how that software is built.  In the process, new concepts need to be introduced.  For example, when we start to get bored of repeating certain values all the time (and start to run into errors when changing these values), I'll introduce variables.

The best part about having my learning objectives done first is that I can use them to make sure I've hit all the main points within these problems.  As I write out my step-by-step outline, I highlight key words that are colour coded to the objective they relate to.  I imagine this will also help tremendously as I move on to writing the code and creating the lecture slides and peer instruction questions.

Here's an example of the second problem's design for this course:

Another nice feature of the problem-based organization is that I have a natural way to organize the content (such as slides, code, and other resources) in our online learning management system.  I haven't tried this before, so I don't know how well students will like it compared to, say, a week-by-week organization.  I should mention that I am also including tables of resources according to topic (e.g. variables, functions, good programming concepts, etc) as well as by problem, so hopefully this will help.

With all of this laid out, it will be much easier to fill in the details.  That's the most fun part!

Introducing the GHC13 Communities Committee

Did you know that the Grace Hopper Celebration of Women in Computing has a strong online presence? From Tweeting to blogging to note taking, we've got you covered.  Whether you're an attendee who hasn't figured out how to be in 8 places at once, or someone enjoying the conference from afar, social media can show you what you've missed.

It's the Communities Committee along with our awesome ABI representative Rosario Robinson that make this all happen.  I'd like to introduce you to the committee now!

Charna Parkey, Co-chair DSP Engineer, PhD Candidate, yogi, martial artist, potter, step mom, volunteer, entrepreneur. Passionate about life, food, friends and family.	Gail Carmichael, Co-chair Computer scientist, educator, and blogger who is taking leave from a PhD to teach undergrads for a year.  Wrangler of a toddler who thinks bedtime is the worst time.
Kate Tsoukalas Software testing ninja, blogger and tweeter passionate about promoting, encouraging, and increasing the numbers of women in tech.  Can be found chasing Frisbees and climbing walls in her spare time.	Rosario Robinson, ABI Her Systers’ Keeper. Developer, open source advocate, and passionate about making positive social global change. Working for the cause and not the applause. Changing the world through technology and community engagement.

We'd love to get to know you, too.  If you're interested in being a Communities volunteer at this year's conference, submit an application by September 7 by clicking the link on the right hand side of the Communities home page.  Be sure to read Kate's summary on why being a volunteer is awesome!

Designing an Intro to CS for Non-Majors: Starting With the Objectives

I have been working on my course design for my introductory computer science class for non-majors.  It is taught in Processing and covers all the basics of programming and computational problem solving.  I have been keeping the idea of backward course design in mind in that I am starting with my learning objectives and working from there.

via Development Phase in Instructional Design

This approach is turning out to be helpful for several reasons.  For one, I wanted to organize the content into 8 or so example programs that will hopefully be of interest to the target students.  Each program will be demonstrated first before I walk them through how it's made via live coding.  As certain concepts are needed, the coding will pause and we will discuss the concept in general and in the specific context of the program.  I also intend to have at least one peer instruction question per lecture period.  Having a detailed list of objectives is helping me ensure I hit all the main points in the planning process.

Beyond this, as I have found when teaching as a contract instructor in the summer, you can give your learning objectives up front all you want, but it doesn't mean students will remember them or see how the course material connects to them.  This year, I plan to colour code the objectives and explicitly link to them during every lecture and in every tutorial and assignment.  I am hoping that this will make the course more clearly interconnected and help students organize the content in their minds as we go.

Finally, always linking back to the objectives will help me prove to students (and know for myself) that everything we do is relevant to the desired outcomes.  Nothing should feel like busy work!

If you're interested, the current version of my objectives for this course are below.

By the end of the course, you should be able to...

• Understand what computer science is, and how it can help you solve problems in your field.
• Learn how to use Processing to create visual programs of varying types.
• Explain these basic concepts of programming to somebody who has never programmed before:
• data types (numbers, Strings, etc)
• variables
• functions
• Booleans and if statements
• loops
• arrays
• objects
• Solve basic programming problems by working with:
• searching and sorting algorithms
• using simple data structures
• dynamic memory
• recursion
• Develop good programming practices in the areas of:
• breaking a problem down into smaller pieces
• testing
• debugging
• code reuse
• Learn to approach programming problems with the following values:
• a desire to experiment
• the confidence to make mistakes and try again
• the instinct to consult documentation and seek solutions yourself before asking for help

The Latest on the App Formerly Known as Carleton Quest

I've been making good progress on the app formerly known as Carleton Quest.  I've rewritten the story to include more faculty-specific info and general school spirit, made fewer locations mandatory, and updated the UI.  I submitted an ethics application for the survey we hope users will complete at the end of the app for a chance to win great prizes.  I've also been looking for a new name (so far, the winner is CU There; let me know if you like it).

  

I'm still working out a few bugs with that fancy centre button with the camera, and Andrew Heaton kindly offered via Twitter to help me style the HTML story text (thanks Andrew!).

With luck, I'll get this version submitted to the app store soon, and our posters with QR codes will be up in the next couple of weeks.

Making the Most of Your Messaging in 'Women in Computer Science' Outreach

If you've ever done outreach with girls to try to get them into computer science, you may have wondered what the best way to do it is.  After all, we've been at this a while, and yet we haven't seen the level of progress we had hoped for.  What is going wrong?

 Confused Owl / ~Phee

I have a formula that I've used in my outreach for the last 6 or 7 years now.  It goes something like this:

• I introduce myself with fun pictures of my family and hobbies.  I also include a photo of me at the Golden Gate Bridge so I can talk about how companies like Google support women in CS through scholarships and gatherings.
• I ask the girls what computer science is, then explain that it's really all about problem solving.  I go through several domains to show how computing is connected, and if there's time, I ask them for their hobbies and give some possible connections there.  I also show a video from University of Washington on various pathways in computer science to drive home the point that CS is really diverse.
• Our discussion then turns to the issue of women in CS.  I show some graphs that illustrate the problem, then ask the girls to discuss three questions in small groups before we bring it up with everyone: (1) Why don't girls go into computer science? (2) Why is this a bad thing? (3) What would make you interested in trying computer science in high school or college? This is followed by the great little video on women in CS from Google.
• Finally, I do a hands-on activity to showcase a real computer science problem (typically, a CS Unplugged activity).

This formula has served me well.  In my mini-course, I have this discussion on the first morning of five full days of learning about computer science and videogames.  I do pre-course and post-course surveys to see how the girls' attitudes change, and generally the trend is positive.  Even when they aren't sure about CS being a good career for them, they are interested in pursuing some courses in the future.  (You can see some results here, here, and here.)

But is my approach the best it can be? Will it encourage the girls to stick with CS even if they do decide to pursue it somewhere they are likely to be the minority?

My section on the 'women in CS' issue has been questioned a couple of times.  In the first, Barbara Ericson mentioned that when they tried to counter stereotypes, they actually ended up reinforcing them, causing a decrease on the number of girls who thought they could succeed at computing.  More recently, Jim Davies pointed me to research about normative behaviour, explaining that by pointing out the problem, people are more likely to focus on that and behave the same way.

Obviously, these two things had me a bit concerned, and got me wondering if I should be dropping that portion of my outreach altogether.

But I knew I had a purpose for talking about the problem.  It would feel disingenuous to ignore it altogether because I think most people realize it's an issue; however, if doing so improves our results then it may be worth it.  Another reason I do it, though, is based on the fact that I am not only trying to change a current opinion about the field.  I want to make sure that if I can convince them to further pursue computer science, they will not leave again as soon as they run into the issues that might have kept them away now.  In other words, I want to prepare them for what may come next.

Based on this, I knew I had to dig deeper so I could try to modify my approach instead of dropping that section altogether.  I found the research that Jim was talking about: a paper called Managing social norms for persuasive impact.  It describes a study on what type of messaging is most effective when trying to convince people to behave a certain way (in this case, to stop people from stealing wood from a petrified forest).

There are two main ways of illustrating the type of behaviour you want from people.  You can use descriptive norms, which make use of what people are currently doing.  Public health campaigns use this often: "more than 3 million youths in the US smoke and ... 3,000 become regular smokers each day."  Alternatively, you can use injunctive norms, which focus on what people ought to do.  For example, "don't leave your campfire."

Previous theories as well as this particular study have shown that the most effective type of messaging is not descriptive, but injunctive, for the reason Jim mentioned above.  Further, it is much more effective to use negative wording rather than positive (e.g. "don't leave your campfire" vs. "stay with your campfire").  This is interesting given how many campaigns meant to persuade people ignore this advice.

In my case, it seems clear that focusing on the actual number of women who don't go into computer science is a mistake, given the descriptive nature.  The girls in my audience may focus on that and think, "well if no other women go into computer science, why should I?" The follow-up discussion may counteract that, but why risk it?

If I still want to address the issue in some way, I need to find an injunctive way to do it.  I think it may be possible to do this by focusing on what we want the girls to do: try computer science.  A negatively worded question I came up with is this:

What would stop you from trying and enjoying computer science?

I think this avoids the issue of focusing on women who don't go into CS, yet allows us to explore the issues they might face later on.

What do you think? Is there a better way to approach this problem that fits with the research? Where can you switch your own messaging from descriptive to injunctive?

Female Friendly Narrative Modding in Games

Why is it that there are still so few video games stories with awesome female protagonists that don't play into the usual gender stereotypes? What's a gamer to do if he or she wants to experience more of them today? Narrative modding might be one minor possibility...

Zelda Cosplay :D / CLOUD1414

I started my journey into female friendly narrative by randomly looking up a link I've had saved up for a while: Ada: Journal of Gender, New Media, and Technology.  I found an interesting article called Self-Saving Princess: Feminism and Post-Play Narrative Modding.  It discusses the idea of modding not the game itself with editors or code, but the modding of the narrative outside the technology, that is, "modding that takes place through player and critic participation after the game has been created through discourse."

For example, Anita Sarkeesian of Feminist Frequency is discussed as someone who has modded the narrative of games with respect to how women are portrayed in them. 

Her call for funding for a series of videos on this topic was met with outrage, disgust, threats, anger, and resentment from some sectors of the gaming community online. ... But anger wasn’t the only response to Sarkeesian, and in fact, it seems that the anger and threats of violence incited more support for her project than had existed previously (and may have existed at all).

And now, with three videos published from the Tropes vs Women series on video games, Sarkeesian is calling on players to look at female characters in games in a whole new light.  This is narrative modding because "it fundamentally changes the way that players are able to engage with the game because of their knowledge of her critique and the community’s response to it.  Once these tropes are exposed and brought into mainstream discourse, the player’s experience of the game is modded."

The latest Women vs. Tropes video, Damsel in Distress: Part 3, embedded above, mentions explicit narrative modding, albeit briefly.  One well-known projects that changed Link into a girl through a Wind Waker mod came from a fellow Carleton University alumnus, Mike Hoye.

Initiatives like these are very cool, but the fact that any sort of narrative modding is even necessary has to make you wonder when video games are going to grow up and offer more female-friendly stories.  I'm hoping it'll be in time for my daughter to enjoy them when she's old enough to play.  (She's almost 2 now, so get on it, industry!)

A Picture of Me Dancing With Graphs

On Wednesday, I did my annual mentoring with Girls @ Virtual Ventures, the all-female section of the popular science and engineering camp held at Carleton.  As usual, the girls made a wonderful audience as I told them what computer science was, had them discuss why there aren't more women in CS (and why it mattered; things got intense!), and ran the CS Unplugged searching activity.

This photo was posted on the Virtual Ventures Twitter account.  I like it; it looks like I'm dancing with graphs. :)

In other news, my post about how improving CS education improves it for everyone was featured on the blog of the Ontario NSERC Chair for Women in Science and Engineering.  Stay tuned for an original, more personal post to appear there later this month.