Why Computer Science is Relevant No Matter What You're Teaching

I had only half an hour to put forward my case. I wanted to convince the educators who attended a special CU-WISE event last week, Discover WISE, that no matter what subject they taught, they should throw a bit of computer science into the mix.

I started with a discussion on what computer science actually is.  After all, so many people have a misconception that it was likely these science and technology teachers did, too.  It didn't take long to get down to the real answer with this group (great bunch!), but it still had to be done.  After brainstorming, I started with my usual "big fancy definition" from Wikipedia:

Computer science (or computing science) is the study of the theoretical foundations of information and computation and their implementation and application in computer systems.

("Bet that doesn't sound like something that would fit into your class!")

Then I gave my own take on what it was all about.  This is the same list I show during outreach or even my Introduction to Computers for Arts and Social Sciences course.

• It’s all about finding ways to figure stuff out.
• What can be computed automatically?
• How hard is it to compute?
• What cool applications are there? (Like video games, Facebook, and more)
• What’s the best way to set up a computer so it can do all this stuff fast?

Then I briefly showed them how computer science can connect to many different areas. In fact, I always say, give me anything you're interested in and I'll find a way to connect CS to it - after all, computers are everywhere! There's always a problem that can be solved with computing.

So why should these teachers care about teaching CS to their students? As the stats show, computer science is suffering greatly from a lack of females (and from people in general - some stats say that we won't have enough talent to fill jobs in the near future!).  One of the reasons seems to be that girls never find out what CS really is.  (I always ask the girls I do outreach with to tell me why they think there aren't more women in CS, and this is a reason they consistently offer.)

If students make it to the computer labs, it's usually to learn how to type or write reports or do research online.  Only about half the teachers present said their school even had computer science classes, and I'm willing to guess that among the courses that do exist, many of those teaching them don't have a CS background.  So even if girls were to make it into a high school "computer science" course, what impression are they likely to leave with? There's a good chance they will think CS is all about programming boring example programs that aren't relevant to them.

But if we can show how computing connects to the courses they are taking (you know, the ones they are actually passionate about), we might get a few girls interested in considering at least a minor in CS, if nothing else.

So I told the teachers about CS Unplugged, and showed how the various activities could fit into other classes from art to history to biology or physics.  In fact, I even have a document I made that suggests some of these connections (though I've thought of many more since writing it).  I told them they could ask for my help if they wanted to be able to do some of the activities on their own, or said they could invite CU-WISE to come to their classes and do some activities for them.

I know at least a few in attendance were convinced of my position.  Here's hoping that we can start infiltrating non-CS classes with some good old fashioned CS fun, and that some students will get hooked in the process.

Storytelling in Education and Games

Imagine bringing the magic of storytelling into your classroom.  But not just any classroom - in your math classroom.

Storytelling @ Thurdays by kodomut

If that sounds strange to you, then you haven't been following the work of Dan Meyer.  He's the guy that told us math classrooms need a makeover in his TEDxNYED talk.  A recent blog post of his describes The Three Acts Of A Mathematical Story.

• Act One: "Introduce the central conflict of your story/task clearly, visually, viscerally, using as few words as possible."
• Act Two: "The protagonist/student overcomes obstacles, looks for resources, and develops new tools."
• Act Three: "Resolve the conflict and set up a sequel/extension."

Besides the fact that I think this would work equally as well in computer science classrooms, it got me thinking about an idea I had a while back for educational games.  There's a GRAND project called BELIEVE that's all about making it easier to tell stories in games:

Research to discover new mechanisms to allow game designers to create helpful allies and challenging opponents by generating scripts automatically can support authors in providing creative high-level direction to these agents. A multi-queue behavior architecture with prioritized interruptible and resumable independent and collaborative behaviours will be employed.  BELIEVE will provide authors a library of highlevel behaviour, plot patterns, and game story idiom scripts for adaption to the story at hand.

When I heard about BELIEVE, my immediate thought was that we need something similar for educational games.  We know narrative is important, but I don't think the standard mechanisms for storytelling in games would necessarily work.  After all, there is a hidden agenda of actually teaching something specific.  Once we figure out the secret formula for how to weave learning into a game in a way that is both fun and effective, it makes sense to create tools that help others get the same good results.

To tie it all together, I wonder if the techniques Dan uses can inform or influence how we tell stories with educational games.  Something to think about the next little while.

Smaller Class Sizes Can Matter

My Introduction to Computers for Arts and Social Sciences course usually has several hundred students when taught in the fall and winter (when I'm not teaching), but under 100 when I teach in the summer.  So far I've had about 50 show up to each class.  I'm finding this to be an ideal number when trying to engage the students in in-class discussion.

Joris holds court by Felix42 contra la censura

Even with a large group, I could definitely imagine doing a couple of the discussion exercises I've done with my students.  For example, I recently did a "mock quiz" where I made up some questions on the programming concepts we talked about in class and got students to write their answers as best they could.  Then I told them to discuss their answers with their neighbour(s) to find out where they needed to enhance their understanding.

The next step I took was to ask a few brave students to share their answers with the class.  They did, and we corrected their understanding as needed.  But then something interesting happened.  Students felt comfortable asking more questions on the same topic, getting deeper and deeper and uncovering some really good points and clearing up some misconceptions I never would have known about otherwise.  I was really impressed with the quality of the discussion that happened and know that it really helped the students as well.

I'm not convinced this would have happened in a room with 300+ students.  Even being able to hear their questions or answers in a huge lecture hall would have been a struggle, and if my own experience is anything to go on, it's pretty intimidating to speak in front of that many fellow students.  If we hadn't got past the "check with your neighbour" stage, I'm pretty sure there would have been many misconceptions still out there.

To me, this experience (among other similar ones) has really shown to me how valuable smaller class sizes can be, especially when teaching more technical topics.

What has your experience been? What kind of success have you had with questions and discussions in large lectures? Have you mostly had to stick to the lecture style and make it all one way?

Programming Concepts in Scratch

On Monday I started my lessons on Scratch for my Introduction to Computers for Arts and Social Sciences class.  My goal is for students to understand boolean values and if statements, loops, variables, and the broadcast mechanism.

These are my notes and slides.  They assume a basic knowledge of the layout of Scratch and how the scripts work.  You are welcome to use them if you would like.

Boolean Values

Anything inside a Scratch block with the angled ends is a boolean value.  It represents something that, in the end, will be TRUE or FALSE.  You can think of it as asking a question and answering either yes (TRUE) or no (FALSE).

Some examples in Scratch are the 'mouse down?' and '□ < □' blocks.

Boolean values can be combined or modified with and, or, and not blocks.

For the final boolean value of the and block to be TRUE, both the boolean values inside must be TRUE.  If either (or both) is (are) false, then the whole thing is false.

For the or block to be TRUE, at least one of the two boolean values must be TRUE, but one can be FALSE.  If both are FALSE then the whole thing is false.

The not block basically just gives the opposite value.  If the boolean inside is TRUE, the result will be FALSE with not, and vice versa.

If Statements

The if blocks have little slots that are perfectly shaped for a boolean value.

The if block will check whether this boolean value is TRUE or FALSE.  If it is TRUE, then the code tucked inside will run.  Otherwise, it will not.  In the example above, the 'meow' will play because 5 is indeed less than 6, but if we swapped the 5 and 6 then it would not play.

One type of if block also includes an else.  In these blocks, the first section of code will run when the boolean is TRUE, but the second section of code will run if it is false.

Loops

When a loop starts, its code (shown in the image below as a star) will be run over and over until some kind of stopping condition is met.

The simplest kind of loop in Scratch is the forever loop.  In this case, there actually is no stopping condition - the code inside will continue to run until the program tells the script to stop running (such as when the red stop sign is pressed on the stage).

Another kind of loop is the forever if.  This loop also goes on forever like the forever loop, but the code inside will only run when the boolean value is TRUE.  The loop will check every single time whether the boolean is TRUE, and it can be different each time.  The loop will still keep going.  In the example below, the meow will play, but only if the space bar is being held down.

A repeat loop allows you to say exactly how many times it will run.  The stopping condition occurs when the code has run that many times.

The repeat until loop continues until the boolean value is TRUE.  As soon as it is, the loop stops for good.  It is possible to have the loop start and the boolean value to be TRUE right away.  In this case, the code inside will never actually run even once.

Variables

Imagine you have a box that you label.  You can put one thing in that box at a time, and check what's inside any time you like.  That box is your variable.

In the example above, we named our variable myObject, which is like labelling our box with "myObject."  To put something in the box, we use the set block.  In this example, we're going to put the word earth into the box.  We can then hide or show the variable in the Scratch stage if we want to.

Now we can check what's inside the box at any given time by accessing the variable.  In the example below, we play a particular sound based on what's inside.  Because we still have earth in the box, the meow will play, but the note will not.

If we want to, we can change what's inside the box by setting the variable again.  When we do that, whatever used to be in the box is essentially tossed out or even destroyed - it is forgotten forever.

Broadcast

In Scratch you can broadcast a message any time you like.  It's like shouting out to the world, "hey! something happened!"  You can name your message anything you like, but it's a good idea to keep it meaningful so you remember how you intended to use it.

Other scripts, both within the same sprite that shouts the message and in other sprites altogether, can listen for that particular message and act upon it.  They do this with the 'when I receive' block, specifying which message they care about.  More than one script can receive the message; in this case, both scripts will start running at exactly the same time.

If a script doesn't really care about that particular message, that's fine - it can just ignore it.  No harm is done.

One useful way a broadcast can be used is in a game.  If the main character is keeping track of his own health, he might broadcast a message saying he's dead so the other sprites can react accordingly.  Perhaps they will stop moving and a game over message will display.

Conclusion

To get a feel for all these ideas, practice is required.  Try little code blocks and experiment by changing them and seeing what happens as a result.  Scratch is super easy to manipulate and you never have to be afraid of breaking anything.

There is a great tutorial and example game by David Malan of Harvard University.  I recommend working through it.

Teaching How to Think Computationally

One of my three main objectives for this year's "Introduction to Computers for Arts and Social Sciences" course is to teach the class how to think computationally.  It was a goal last year as well, but I did not attempt to articulate exactly what the concept of computational thinking actually meant to the students.  This year I dedicated some time to the concept during the introductory class.

Thinking RFID by @boetter

The sources I found on Mark Guzdial's blog turned out to be quite useful in distilling what computational thinking really meant.  I had started making slides based on the most recent definition put forward by Jeannette Wing, as blogged by Mark.  I started my section with this quote:

Computational thinking enables you to bend computation to your needs. It is becoming the new literacy of the 21st century. 

I was going to use the points under "Computational thinking for everyone means being able to:" but in the end the text seemed better suited to educators than to students.

Luckily, I remembered that the latest issue of CSTA Voice focused on computational thinking.  The articles within were very useful and I ended up using their list of characteristics of being able to think computationally:

• Formulating problems in a way that enables us to use a computer and other tools to help solve them;
• Logically organizing and analyzing data;
• Representing data through abstractions such as models and simulations;
• Automating solutions through algorithmic thinking (a series of ordered steps);
• Identifying, analyzing, and implementing possible solutions with the goal of achieving the most efficient and effective combination of steps and resources; and
• Generalizing and transferring this problem solving process to a wide variety of problems.

With a bit of an example for each of these, I think the students got the main idea.  I told them that learning some basic algorithms, how data is represented on the computer, and how to program in Scratch (all topics in our course) will get them thinking in this new way.

I observed in the next class how important trying to think this way would become for many of the students.  It turns out that even in Microsoft Word, they are used to entering straight text and never using anything that you might call "codes." For example, many still use the "enter-enter-enter..." method to get to a new page rather than a page break, and many didn't about the built-in cross-referencing, table of contents generator, or citation system.  Understanding how to make the computer make your life easier should be a huge benefit to them all.

Do you have any great resources for teaching students how to think computationally? How do you usually approach it? Have you found it hard to know whether you're actually succeeding?

2011 Mini-Course: Post-Course Survey Results

Each year at the end of my mini-course, I give the girls a customized survey to try and find out what their attitudes are about computer science after experiencing it first hand.  Naturally, I'm hoping that they see the subject in a new light!

Some of the most interesting results are shown below.  I'm going to refrain from analyzing them in this post to make it easier for you to skim the results, and because many speak for themselves.  You might find it interesting to compare them to last year's results.


"Was this course your first choice?"

• Yes: 10
• No: 8
• Not sure: 2

"If no, did you enjoy it more than you expected?"

• All 8 who answered no to the first question answered yes here

"Would you have signed up for this course if it wasn't just for girls?"

• Yes: 13
• No: 7

"Are you glad it was just for girls?"

• Yes: 15
• No: 1
• I'm happy as long as I'm not the only girl: 4

"I enjoyed learning about what computer science was really all about."

• Disagree: 1
• Neutral or Don't Know: 2
• Agree: 7
• Strongly Agree: 10

"It was cool to see how many different areas of study can be connected to computer science."

• Neutral or Don't Know: 2
• Agree: 10
• Strongly Agree: 8

"My confidence in my ability to use and understand computers has increased."

• Disagree: 1
• Neutral or Don't Know: 2
• Agree: 8
• Strongly Agree: 9

 "I would consider computer science as a good career for me."

• Disagree: 2
• Neutral or Don't Know: 10
• Agree: 4
• Strongly Agree: 4

(This is an overall improvement from last year!)


"I am more likely to try computer science in high school or university after taking this course, or this course has confirmed my desire to do so."

• Strongly disagree: 1
• Disagree: 1
• Neutral or Don't Know: 2
• Agree: 10
• Strongly Agree: 6

"I liked having a variety of practising female computer scientists and engineers help out in the lab."

• Agree: 8
• Strongly Agree: 12

"What topics and activities did you like the best in the mini-course?"

• I liked all the topics and activities.
• I liked working in the computer lab on games and learning how to work the software even if I did get stuck.
• The role of females in computer science and in video games.
• I really enjoyed learning about the career opportunities available in the computer science industry especially for girls.
• Learning how to make video games and how girls are important in computer science.

(This is just a selection.  Artificial intelligence came up several times as a favourite topic.)

2011 Mini-Course: Games Students Made

This year's edition of my mini-course (Computer Science and Games: Just for Girls!) wound down at the end of last week.  I made sure to get a copy of the girls' games and post them on my website, partially so they could share the executables with their friends, and partially so I could share them with you.

There's a pretty good mix here of games based on the various tutorials we looked at and original ideas. Some might be a bit buggy but I think they should all run.

• Banana Bonanza
• Bob Eye
• Eggtastic
• Energy for the Castle
• Explorer Maze
• Fun Game
• Haunted House Maze
• Indiana Jones
• Lily
• Mario
• Mario Platform
• Mario Shooter
• Maze Game
• Pacman
• Platform Plus
• Platform Plus Plus
• Purple Guy Maze
• Ringette