Posts tagged ‘Scratch’
It’s out! Yay!
That may change, however, as it’s much easier to get started in Scratch thanks to a new release of the platform that lives entirely in the browser.
You can try the programming language here and the new version allows for webcam interaction with the on-screen sprites and you can now add vector-based graphics that will scale without losing resolution. You can also create your own programming “blocks” and add new logic to your programs or games.
Posted to the SIGCSE-Members list from Moti Ben Ari:
Michal Armoni and I have written a book: “Computer Science Concepts in Scratch”. (See the short description below.) It can be freely downloaded from http://stwww.weizmann.ac.il/g-cs/scratch/scratch_en.html under the Creative Common BY-NC-ND license.
The book is based on Scratch 1.4 … although Scratch 2.0 is due to be released in a few days. We are planning to prepare a supplement and / or revision for 2.0 in the future.
We’ve set up a separate email account for correspondence related to the book: email@example.com.
Moti and Michal
Prof. Mordechai (Moti) Ben-Ari
Department of Science Teaching
Weizmann Institute of Science
I firmly believe that a strengthening computer science education program has to be one of the most obvious and cost effective things we can do to ensure future economic prosperity. Israel has the highest rate of startup per capita anywhere and that in part stems from its strong computer science education program. Estonia, another country with both a strong tech sector and economy, recently announced a plan to expand teaching of computer science to all primary school children. Do we want to be left in the dust by these countries, or left unable to compete with the growing economies of India and China? What is it going to take to get computer science education moved up the agenda in the USA and here in the UK?
A recommended video from Mitch Resnick, who leads the Lifelong Kindergarten group at the MIT Media Lab, the home of Scratch.
Most people view computer coding as a narrow technical skill. Not Mitch Resnick. He argues that the ability to code, like the ability to read and write, is becoming essential for full participation in today’s society. And he demonstrates how Scratch programming software from the MIT Media Lab makes coding accessible and appealing to everyone — from elementary-school children to his 83-year-old mom.
As director of the Lifelong Kindergarten group at the MIT Media Lab, Mitch Resnick designs new technologies that, in the spirit of the blocks and finger paint of kindergarten, engage people of all ages in creative learning experiences.
Thanks to Guy Haas for the link to this!
While the programming languages are simpler than the ones used by professionals, they’re still teaching kids the foundations of computer science, according to Karen Brennan of Harvard Graduate School of Education, who helped develop the Scratch program at MIT’s Media Lab.
“They were learning how to test and debug, they were learning how to break down problems,” Brennan told Here & Now. “They started seeing the world in a new way, that computers weren’t something that other people did or other people think about, but computation becomes something that they can use to express themselves, that they can solve problems.”
It’s nearing the end of the semester here, and classes are wrapping up, so the pent-up travel bursts into my calendar. Here’s what I’ve got the next three weeks:
- I told my youngest daughter, “I’ve got a cool talk coming up. What’s the coolest, geekiest, most amazing techie thing you’ve heard of recently?” She immediately replied, “The Mars Rover!” And I got to say, “I’m going to NASA!” (which is even cooler in our house than saying, “I’m going to DisneyWorld!”) I’m flying tonight to Baltimore to visit NASA Goddard Space Flight Center tomorrow and give a talk about computing education for everyone. My eldest daughter wishes she could come with me — “That’s my dream job!”
- Friday, I’m going to MIT Computer Science and AI Laboratory (CSAIL) to talk about “What we know about teaching computer science (Answer: Not all that much)”. It’s going to be an exciting day. Hal Abelson and Mitchel Resnick are both on my schedule. I’ve already received a note from Richard Stallman saying that he can’t make my talk, but am I going to release any free/libre software to address problems in CS education? (Seriously!)
- Next Tuesday and Wednesday (Dec 4-5), Barbara and I are visiting Stanford again. We were just there in March and are pleased to be invited back so soon. I’m giving two talks on Tuesday (and the nervousness factor rises geometrically, not linearly). The first is a demonstration lecture, which I’m excited about and wish I got invited to do more often when I visit places — I don’t get to teach introductory CS much here, and I love doing it, so it’s a treat for me. The second is a research talk on “On-Line CS Education.”
- Then the following Monday (Dec 10), I’m at Tufts University visiting the Center for Engineering Education and Outreach. There’s a bunch of great work going on there, but I have a more personal interest in going there, too. I lived at Tufts when I was an intern for GTE Laboratories in Waltham in the Summer of 1983, and have fond memories of the campus.
If I’m slow in responding here (or via email) over the next three weeks, I hope you’ll understand. If you’re around one of these places and can come to my talk, please do and stop by to say hello!
In our summer camps, two of the most popular activities have been Scratch and Pico Crickets. Unfortunately, the company has been bought out by Lego and is being dismantled in favor of their WeDo, which isn’t anywhere close to the same thing. I’m excited about Hummingbird — I hope that it captures some of the Pico Crickets excitement.
While educational robotic kits traditionally have focused on the technology itself — the building of a robot — Hummingbird treats robotics as just one element that can be combined with craft materials and text to communicate thoughts, feelings or ideas.
“We want students to become inventors of technology rather than users of technology,” said Robotics Professor Illah Nourbakhsh, whose CREATE Lab developed Hummingbird for a project called Arts & Bots. “Hummingbird feeds a student’s natural curiosity about technology by enabling her to incorporate robotics into something she is making that is meaningful or useful.”
The results often amount to kinetic sculptures that use sensors to detect changes in their environment and respond with movement and/or light displays. A cardboard dragon that turns its head and tries to bite anyone who comes close is one example. Students in West Virginia built a working replica of Star Wars’ R2D2.
The 999th blog post feels like a good point to think about where we’re going. Here’s how I define the big question of computing education research:
Computing education research is the study of how people come to understand computing, and how we can make that better.
But that’s the big question. There are lots of research questions inside that. Here are some of the ones that I’m intrigued by. This is an overly-long blog post which I’m using as a place marker: Here’s what I’m thinking about right now at the end of the first 1000 blog posts. Skip around to the parts that you might find interesting.
What are the cognitive processes of learning to program?
Why is learning to program hard? The empirical evidence of teaching computer science suggests that it is. Failure rates worldwide of 30-50% in the first class have been reported for decades. The misconceptions and challenges that students faced in Scratch in Israel (ITICSE 2011) are quite similar to the same ones documented in Pascal at Yale in the 1980’s (Soloway et al.).
Are there cognitive challenges to learning programming that are unique among other disciplines? Perhaps so. Consider these two possibilities:
- Agency: Writing a computer program is the task of providing instructions to another agent to execute, but a non-human agent. Miller in 1981 found that humans found it hard to describe task processes to another human, and the produced instructions required human understanding to interpret them. People do not naturally produce instructions at a level detailed enough for a computer to execute.
- Time: A program uses a variety of notations to compress time, e.g., iteration and recursive constructs. These notations describe a process in brief which will execute repeatedly many times (perhaps millions of times). We know that these notations are among the most challenging for students to grasp.
Both agency and time notations are unique to the challenge of programming. Perhaps these factors (among others) help to explain why programming is so hard, and understanding these challenges will lead to new insight into how humans conceive of agency and time.
Where do problems/difficulties/misconceptions in learning programming come from?
Most students have no experience in programming computers before they enter their first computer science class. So, no prior conception of assignment, memory allocation, WHILE and FOR loops, linked lists, or recursion — yet these are way up there on the list of things that are hard about learning to program. They haven’t changed in decades, across multiple languages. Where did those problems come from? Do we teach them wrong? Exactly where so that we can fix it! Do students have some prior knowledge that is interfering? What knowledge are students bringing to bear in learning to program?
Can we teach computing without a programming language?
Can someone learn what a computer is, how it works, and what its limitations are simply through non-programming activities?
Mathematicians did. Turing defined what a computer is, without a programming language. Instead, he defined a machine and a language.
I’m increasingly coming to believe that those are outliers — Turing and mathematicians who figure out computing without a computer are unusual, and we can’t do that at-scale. Learning to understand computing is learning to understand a notional machine (duBoulay), to construct a mental model of how you expect the notional machine to work (Norman), and that mental model consists of decontextualized parts (deKleer and Brown). It’s very hard to think about those parts without having names or representations of them. It can happen, but it takes enormous cognitive effort. It’s not going to be effective and efficient to reach our learning goals without a language.
Challenges for CS10K
The CS10K effort (to have 10,000 high school teachers capable of teaching CS:Principles in 10,000 US high schools) requires answers to some significant research questions. Some of these include:
- What kind of pedagogy will fit into the lives of in-service high school teachers and other working professionals?
Computer science pedagogy today is mostly apprenticeship-based: Students get a bit of instruction (perhaps some modeling of good behavior), and then are expected to learn through doing, by programming in front of an IDE. While the apprenticeship-based model is effective, it’s inefficient if the goal is understanding about computer science, as opposed to expertise as a software engineer.
In-service high school teachers are a particularly challenging audience. Most likely, they will never be professional software engineers, and they are full-time (overworked) professions, so they have neither the motivation nor the time to engage in apprenticeship-based learning. How do we teach CS to these teachers in the small bits of time that they have available?
- How do we create sufficient, high-quality on-line materials to lead to successful CS learning at a distance?
The best distance learning programs in the world (such as the Open University UK) rely significantly on text-based materials, because we know how to control costs while creating and maintaining high-quality content. CS is not best taught with printed text, since visualizations and simulations play a key role in student learning. How do we create sufficient (e.g., at reasonable cost), high-quality materials to support CS learning at a distance?
- What will motivate high school teachers to take classes in computer science, to be engaged with the content, and to sustain their interest?
The existing CS teaching programs in the United States are woefully undersubscribed, e.g., Purdue’s CS methods course has never had more than one student enrolled each term that it is offered. What will drive more teachers into CS education?
- What do teachers need in order to develop into successful computer science teachers?
High school teachers will not need to be professional software engineers. They do need to be able to present CS ideas, to assign and assess student work, and to mentor, e.g., to help facilitate student debugging and guide development. What are the learning objectives for CS high school teachers? How do we assess that development?
- CS PCK: What is Computer Science Pedagogical Content Knowledge?
In most disciplines, there is a body of knowledge of how to teach that. How People Learn has a whole chapter on domain-specific teaching practices, and points out that those are much more powerful for effective teaching than domain-general teaching practices. For example, science educators explain how to support inquiry-based learning, and mathematics educators know how to build on innate understanding of number. We call that knowledge pedagogical content knowledge. How do we best teach computer science? How do we help future educators develop the unique skills to teach computer science?
One of the highlights of SIGCSE 2012 was meeting Mike Richards and learning about the new introductory computing course at the Open University, My Digital Life. It’s an interesting contrast to the Stanford on-line CS courses.
I met Mike at a BOF (Birds of a Feather) meeting on digital books for CS. There were three major themes that I heard at the BOF: What standards are there going to be for electronic books, what features should there be, and what should authoring look like. The answer to the first question was clearly, “Who knows?” It’s too early. There were book authors in the audience who were pretty upset with the answer, insisting, “I need to know what to write in now, and I don’t want to have to change later!” That’s not going to happen yet. The answer to the second question had a disappointing amount of posturing — lots of “Well, I think…” with no data, no evidence, no arguments. Just claims of having the superior vision. The third one was pretty intriguing, with some really important ideas. Cay Horstmann had an interesting take on the value of XML, in any form. Mike described what their authoring process was like.
Mike said that it cost $3M USD to build “My Digital Life.” It consists of a set of books, some really great videos (including one of Alan Kay that he showed in his session), and a terrific computing platform and a modified form of Scratch. The interesting thing was that the majority of that $3M budget went to “proofreaders, testers, and editors.” They hire people to try the lesson, and then they watch where it doesn’t work. Iterative development with formative evaluation — what a great idea!
On Saturday morning, Mike presented his paper with Marian Petre on the SenseBoard that they use in “My Digital Life.” The course is currently 2/3 through its first offering. They have 4,500 students with no pre-requisites. It’s 1/3 female. 2/3 have no previous background knowledge. They have a wait list of 900 people for the next offering. Historically, the Open U gets very high student satisfaction ratings, and over 50% completion rates.
They decided to emphasize that their students don’t want to just observe computation, they want to make things. They decided to focus on ubiquitous computing, because that’s the future of computing from their students’ perspectives. They created the Senseboard, an Arduino-based device with microphone, IR sensor, push buttons, sliders, servo motor connections, stepper motor connections, and sensors for temperature, motion, and light. The board is included as part of the course (for which students pay around $800 USD), but should become available separately soon for about $80 USD. They have created a version of Scratch for programming the Senseboard. They extended Scratch with primitives for string and file handling, sensor handling, networking, and improved debugging.
I loved the way that they designed the curriculum. One of their design mantras are “No blank screens.” Each project comes with parts that already work, with descriptions and background images. The clear descriptions go step-by-step (checked by testers), and “jump aheads” (“If you already know Booleans, skip to this page”). All projects are provided with full solutions, so nobody ever gets stuck or can’t play with the result because they couldn’t figure it out. What an interesting notion — that the point of the programming assignments is to give students something that they want. Grading is not based on the assignments. Grading is based on seven marked-up assessments with a tutor, and one big final.
The projects looked great: Burglar alarms, a tank game with remote other players, a “tea ready” alarm, a BBC news feed (pull off your favorite articles and stuff them in string boxes), a network seismograph (showing the amount of traffic in your part of the network), live opinion polling, and games that the students found pretty addictive. Mike had a great quote from a student saying that he wanted to learn to make a “ghost detector” by the end of the course.
Mike says that the Stanford and MIT open learning initiatives are forcing the Open U to make some of “My Digital Life” available on their open learning site. But the Open U is worried about that. Stanford and MIT are putting up material that faculty built for free, with no or little testing. The Open U. spent $3M building this course. How do you recoup your investment if you give it away for free? There’s a flip side to that question. The Open U spends the majority of its development cost on guaranteeing quality, in the sense that the assignments are do-able by students (see previous discussion on reasonable effort). What guarantees can you make about free courses? Does course quality matter?
I share Geeky Mom’s concerns about students finding Scratch (Scratch?!? Really?!?) too hard, and the notion of learning computing becoming like eating vegetables. Computing is the most expressive and powerful medium that humans have ever invented — surely, it’s not brussell sprouts!
I’ve been having conversations with various students about learning Scratch. I find it really helpful just to ask for honest answers, and I love that most 8th graders will actually be honest. The main answer I get about learning Scratch is that students find it too hard. It’s too much work, they say, to get any good results. Or it’s too tedious. I find this interesting because they’ll do math and science that’s also pretty hard.
Reports abound that CS is a great field economically. Yet, it’s not filled with women. It’s also not gaining too much traction in high schools. We keep telling people that CS is “good for you” but people aren’t engaging. Is Scratch like putting ice cream on brussell sprouts? Or worse, maybe it is brussell sprouts. If that’s true, I’m not sure how to fix that. Look at what’s going on with nutrition these days. Eat your vegetables has been a mantra for years and yet, our obesity problem increases.
How cool! I’m interested in the changes that they’re recommending for Scratch Jr and the rationale that they’re offering.
In focus groups with teachers and children, the Scratch Jr research team has also noticed that younger children struggle with the number of blocks needed to create a program. “The relationship between cause and effect needs to be clearer for this age group,” Bers said. The idea is to reorganize the program so kids can focus on only one thing at a time.
Younger children also have trouble distinguishing between the colors in Scratch, (Scratch Jr will be redone in bright, primary colors), and they struggle with how Scratch moves from top to bottom (Scratch Jr will move from side to side.)
I have had several people now send me a link to Bret Victor’s video on Inventing on Principle. It is a really impressive demo!
His system reminds me of Mike Eisenberg’s work on SchemePaint. Mike wanted the artist to be able to interleave programming and direct manipulation. In SchemePaint, you could draw something by hand, then store the result in a variable to manipulate in a loop. Or you could write some code to tesselate some graphical object, then add tweaks by hand. It was beautiful. The work that Mike did on SchemePaint led to his wonderful work on HyperGami, a CAD system for origami, which was the start of his Craft Technology group. That’s the group from which Leah Buechley graduated — she did the LilyPad.
People are sending me Bret’s video asking, “Wouldn’t this be great for learners?” I bet it could be, but we’d have to try it out. At one point in his lecture, Bret says, “Why should I have to simulate the computer in my head?” Because that’s the point of understanding computer science. Bret’s system looks like a powerful visualization system, and visualization can be used to lead to real understanding, but it isn’t easy to design the visualization and context such that learning occurs.
The problem is that visualization is about making information immediate and accessible, but learning is about changes in the mind — invisible associations and structures. Sometimes good usability makes it easier to make these associations and structures. Tools like Scratch and Alice increase usability in one direction (e.g., syntax) while still asking students to make an effort toward understanding (e.g., variables, loops, and conditionals).
My first PhD student was Noel Rappin, who explored the features of modeling environments that lead to learning. He had a CHI paper about his work on helping chemical engineers learn through modeling. Our colleagues in chemical engineering complained that their students couldn’t connect the equations to the physical details of the pumping systems that they were modeling. Noel built a system where students would lay out the physical representation of a pumping system, then “look underneath” to see the equations of the system, with the values filled in from the physical representation (e.g., height difference between tanks).
He ran a pilot study where students would lay out a system according to certain characteristics. They would then manipulate the system to achieve some goal, like a given flow rate at a particular point in the system. When Noel asked the pilot students if they gained any new insights about the equations, one student actually said, “What equations?” They literally didn’t see the equations, just the particular value they were focusing on. The system was highly usable for modeling, but not for learning.
Noel built a new system, where students could lay out a model, and values from the model were immediately available in an equation space. To get the flow rate, the student would have to lay out the equations for themselves. They would still solve the problem by manipulating the physical representation in order to get the right flow rate, and the system would still do all the calculations — but the students would have to figure out how to compute the flow rate. The system became much harder to use. But now, students actually did learn, and better than students in a comparison group.
I like the way the McGraw Prize in Education is framed, and congratulate Mitchel Resnick on receiving the award for his work on Scratch.
“Technology in education is a great catalyst for change — for creating, managing, and communicating a new conception of learning,” said Mr. McGraw. “This year’s Harold McGraw Prize winners are the embodiment of the transformative impact of technology on improving education. Their innovations are enabling students to learn at their own pace and empowering teachers to inspire and coach.”
Mr. McGraw said, “Digital learning is the opportunity of the century. For many students around the world, technology makes education more accessible, adaptable and affordable. We applaud these exceptional leaders for guiding the way and enriching the lives of so many students.”
Mark’s Trip Report on ICER 2011: Students’ experience of CS classes, and making compilers more friendly
Last week was the International Computing Education Research conference for 2011 at Rhode Island College in Providence, RI. (What a cool city! My first time, and I enjoyed getting lost on one of my runs!) It was the first time in years that I actually stayed for the whole conference, since I left after the first day last year. I enjoyed realizing again why I loved this conference so much. Several of the papers were wonderful, the discussions and hallway chit-chat were terrific, and it was great to see so many colleagues, as well as meet people whose papers I’ve been reading but hadn’t yet met.
I’m labeling this “Mark’s Trip Report” because I’m not going to attempt to be thorough or fair in what papers I mention. I’ll tell you about what struck me. I’ll do a separate post just on the keynote.
The first set of papers were ostensibly about how students choose computing, but I thought that there was a strong subtext about understanding the student experience of a computing classes.
- Colleen Lewis talked about “Deciding to Major in Computer Science: A grounded theory of students’ self-assessment of ability,” but it was really much more about that “self-assessment” part than about the “deciding” part. Colleen told us that a common theme in her interviews were the tension between growth vs. fixed mindset (drawing on Carol Dweck’s work). Many students decide early on that they’re bad at computing and they can’t get better, i.e., they don’t have the “Geek gene.” Those students won’t choose CS, of course, but for such a disappointing reason.
- Mike Hewner presented his work, which spoke to where students get their information about CS and how a good class experience can color a student’s perception of a specialization area.
- Päivi Kinnunen presented “CS Majors’ Self-Efficacy Perceptions in CS1: Results in light of social cognitive theory” which was about applying Bandura’s work (which explores how early failures at something lower students’ belief of their ability to do that something) to CS1.
Päivi’s paper got me wondering what we’re telling CS majors when we have them use Alice or Scratch in CS1. As we know from Mike’s work, CS majors know something about CS — they know something about the languages used in regular practice. When we tell them to use Alice or Scratch, are we saying to them (in light of Bandura’s work), “You aren’t capable of using the real, authentic practice” and thus lower their self-efficacy? And if we use a “real” language (even if harder) are we saying (in a Dweck growth mindset sense), “Yeah, this is hard, but you can do it. You can learn to handle the real thing.”?
Päivi’s talk was a great set-up for Sally Fincher’s “Research Design: Necessary Bricolage,” which ended up winning the people’s choice (voted) best paper award (called the “Fool’s Award” at ICER). Sally was asking how we go about gathering information about our students’ practices. She said that we rely far too much on semi-structured interviews, and we should think about combining other methods and practices to gain more insight. She showed examples of some of her research instruments, which were really wonderful (i.e., I plan to steal them as early as this semester!). Here’s a neat combination of methods: First, give students a graph of 24×7 in 30 minute increments, and ask them to mark when they work on the class.
That’s the “when.” To get the “where,” Sally (and Josh Tenenberg and Anthony Robins) gave students cheap digital cameras, and asked them to take a picture of where they were working.
That upper left hand corner is a bus seat. Would you have guessed that your students do CS homework on the bus? Notice the mixture of affordances: In the bus, in the dorm room, in the lab with peers, at a table to work with friends. Did you realize that students are working so much away from a rich computational infrastructure? There’s no bottomline result here — rather, it’s about what data we should be gathering to figure out the things that we don’t realize yet that we need to know.
I enjoyed the papers by Cynthia Bailey-Lee, Beth Simon (for her paper on PeerWise with lead author Paul Denny — Beth’s name seemed to be on every-other paper this year!), and Matt Jadud because they were all replication studies. Cynthia was taking a finding from Biology (on using peer instruction) and seeing if it worked in CS. Beth and Matt were both taking earlier CS Ed papers, and see if they still worked in new settings. It doesn’t matter what the bottomline finding was. It’s so cool that our field is starting to go deep and check the work of earlier papers, to explore where it works and where it doesn’t, and to develop more general understanding.
Kathi Fisler presented a really interesting paper, “Do values grow on trees? Expression integrity in functional programming” that was particularly interesting for the variety of interpretations of the paper. Kathi presented it as an exploration of whether function programming is “unnatural” for students. I’m not sure how to ask that question. What I found them exploring was, “How do novices and experts see the nested structure of s-expressions? Do they see the trees? Is that evident in their editing behavior, e.g., do they edit maintaining expression integrity, or do they ignore the parentheses when typing?” Since so much computing involves the Web today, I’m wondering how comparable the results would be to people typing HTML (which is also a nested, tree-based notation).
I had a nice chat with Kathi’s co-author Guillaume Marceau who, with Kathi and Shriram, won the SIGCSE 2011 best paper award on designing error messages for students (which is an issue that has come up here recently). I told Guillaume about Danny Caballero’s thesis, and he told me about why it’s so difficult to get error messages right for students. The problem is that, by the time the parser has figured out what the problem is, all the context information to help the student has been thrown away. An example is “identifier not found.” For a student, a variable and a method/function name are completely different identifiers, completely different meanings. It takes students a long time to generalize an identifier-value pairing such that the value could be an integer, an object, or a code block. For most compilers, though, why you want the identifier is lost when the compiler can’t find an identifier’s meaning. Racket contains compiler calls that help you construct the context, and thus provide good error messages. He doesn’t hold out much hope for Java — it’s so hard just to compile Java, and refactoring it for good error messages to help students may be impossible.
Two other papers that I want to say brief words about:
- Simon’s paper on “Explaining program code: giving students the answer helps — but only just” follows up on the Bracelet work where students were asked to read and explain the purpose of a piece of code. The students failed miserably. Simon wondered, “What if we gave them the answer?” Rather than have the students fill-in-a-blank about what the code did, he gave them a multiple-choice question where the answers were the top five guesses from the first study. Yes, there was improvement. But no, performance was still appalling.
- Michael Lee presented on “Personifying programming tool feedback improves novice programmers’ learning,” which is a slightly wrong title. What they did was to create a programming task (moving a little graphical character around on a board), but “personified” the parser. A mistyped command might get the little character to say sheepishly, “I’m sorry, but I really don’t know how to do that. I wish I did. I know how to do X. Is that what you would like me to do?” I don’t think that the authors really measured learning, but what they did measure was how long students stuck with it — and a personified compiler is not nearly as scary, so students stick with it longer. (See Bandura above.)
ITICSE 2011 was a fun, interesting event in Darmstadt, Germany last week. Here’s a brief report on my experience of ITICSE, completely biased and centered on the events that I attended, and only highlighting a handful of papers.
Ulrik Schroeder’s opening keynote (slides available) focused on the outreach activities from his group at Aachen University, with some high-quality evaluation. The most interesting insight for me was on their work with Lego Robotics. I raised the issue that, in our GaComputes work, we find that girls get more excited about computing and change their attitudes with other robots (like Pico Crickets or Pleo Dinosaurs) more than Lego Robotics. Ulrik agreed and said that they found the same thing. But boys still like and value being good at Lego Robotics, and that’s important for their goals. He wants to find and encourage the girls who do well at the same robots that the boys like. He wants the girls to recognize that they are good at the same CS that the boys do. It’s a different goal than ours — we’re more about changing girls’ view of CS, and they’re more about finding and encouraging girls who will succeed at the existing definition of CS.
I went to a paper session on A Tool to Support the Web Accessibility Evaluation Process for Novices. They had a checklist and rubric, including role playing (what would an older user do with this site? A sight-impaired user? Someone whose native language isn’t English?) to use in evaluating the accessibility of a website. I liked the tool and was wondering where the same model could be used elsewhere. I got to thinking during this talk: Could we do a similar tool to support the design of curriculum that encourages diversity? Could we provide checklists, rubrics, and role plays (How would a female CS student respond to this homework write-up?) to help faculty be more sensitized to diversity issues?
Probably the paper that most influenced my thinking was Orni Meerbaum-Salant’s paper on Habits of Programming in Scratch (same session). They studied a bunch of students’ work in Scratch, and identified a number of common misconceptions and errors. What was fascinating was that the bugs looked (to me) a lot like the ones that Elliot Soloway found with the Rainfall Problem, and the issues with concurrency were like the ones that Mitchel Resnick found with Multilogo and that John Pane found with HANDS. That suggests that changing the environment doesn’t change the kinds of errors students are making. And since all student programming misconceptions come from our instruction (i.e., students don’t know much about programming before we teach them programming), it means that we’ve been teaching programming in basically (from a cognitive perspective) the same way since Pascal.
The paper reporting on a multi-year professional development effort in Alice was really interesting. They had lots of great stories and lessons learned. The most amazing story for me was the school district where, not only were the CD/DVD players disabled, but the IT staff had used glue guns to fill in the USB ports on the school computers. The IT administration wanted there to be no way for teachers to load new software onto those computers. How depressing and frustrating!
All the papers in the session on Facilitating Programming Instruction were thought provoking. Paul Denny’s project measures how much thrash and confusion that students face in figuring out Java — and there’s a lot of it. Shuhaida Mohamed Shuhidan (“Dina”)’s dissertation work is yet another example of how little students understand about even programs as simple as “Hello, World!” I really liked that Matt Bower is exploring how learning a second language can influence/interfere with the first language learned, but I was disappointed that they only used self-report to measure the influence/interference. Without any kind of prompt (e.g., an example program in the first language), can you really tell what you’ve forgotten about a first language?
My keynote went well, I thought (slides available). I talked about CS for non-majors, for professionals who discover CS late in life, and for high school students and teachers. After lunch the third day, I headed off to Aachen University to visit with Ulrik’s group, so I didn’t get to see more. IITICSE was a lot of fun and gave me lots of good ideas to think about.