Mattel’s Game Developer Barbie is fantastic, says Casey Fiesler

Casey Fiesler and Miranda Parker did a wonderful remix of the original computer engineer Barbie (see Guardian article about that).  Great to see that Mattel did a better job the next time around, and Casey loves it.  I love the point she makes below, which echoes a concern I’ve voiced about open source software.

This is particularly important is because as much as we don’t want to suggest that girls can’t code, we also don’t want to suggest that coding is the only path to working with computers or games. Sometimes other parts of computing—like design or human-computer interaction—are delegitimized, considered less rigorous or less important. Or maybe they’re delegitimized in part because they happen to be the parts of computing where there are more women present (in other words, more inclusive), which is even worse.

Source: Mattel’s Game Developer Barbie is fantastic.

June 29, 2016 at 7:47 am Leave a comment

NSF director unveils big ideas, with an eye on the next President and Congress

Interesting and relevant for this list. There’s a lot in the NSF big ideas document (see link here) about using technology for learning, but there’s also some on what we want students to know (including about computing technology), e.g., “the development and evaluation of innovative learning opportunities and educational pathways, grounded in an education-research-based understanding of the knowledge and skill demands needed by a 21st century data-capable workforce.”

The six “research” ideas are intended to stimulate cross-disciplinary activity and take on important societal challenges. Exploring the human-technology frontier, for example, reflects NSF’s desire “to weave in technology throughout the fabric of society, and study how technology affects learning,” says Joan Ferrini-Mundy, who runs NSF’s education directorate. She thinks it will also require universities to change how they educate the next generation of scientists and engineers.

Source: NSF director unveils big ideas, with an eye on the next president and Congress | Science | AAAS

June 27, 2016 at 8:03 am Leave a comment

Dr. Kamau Bobb Talks Research and Challenges in STEM Education

I’ve talked about Kamau Bobb’s work in this blog previously, when he wrote a depressing but deeply-insightful op-ed about the state of mathematics education in Atlanta public schools. He’s recently been interviewed in a three part series in Black Enterprise about his role as an NSF program officer.  The below quote is from Part II — I recommend the whole series.

The most significant challenge facing STEM education and the workforce is the capacity of the U.S. educational system to produce interested and qualified participants in the STEM enterprise. Here is where the racial and socio-economic challenges facing the nation are most glaring.

According to the National Center for Education Statistics National Report Card, there are some damning realities that significantly challenge STEM education and the STEM workforce. In 2015, only 33% of all eighth grade students in the U.S. were proficient or better in mathematics. Only 13% of black eighth graders and 19% of Hispanic eighth graders were proficient or better in mathematics, which is in contrast to 43% of white students and 61% of Asian students. For students who live in poverty and qualify for the National School Lunch Program, only 18% were proficient in eighth grade mathematics.

According to the College Board, only 16% of black students are college or career ready by the time they take the SAT in eleventh grade. For Hispanic students, 23% are ready. For Asian and white students, 61% and 53%, respectively, are ready for higher education or to take on meaningful work. This landscape is a problem.

Source: Dr. Kamau Bobb Talks Research and Challenges in STEM

June 24, 2016 at 8:03 am 3 comments

Google-Gallup Survey now Disaggregated by States: Fascinating and confusing reading

Google has now released the results of the Gallup surveys from last year of parents, teachers, and principals about attitudes on CS disaggregated by 11 populous US states — see state reports (and methodology explanation) here.  The blog announcement about the report is here. These are fascinating to read, especially for me and my colleagues since some of these states are also ECEP states (see our recent report on activity in ECEP states).  Pennsylvania, Wisconsin, and Texas are doing much better than the US average in this analysis, while Ohio and North Carolina are far behind.

These are the results of a large scale survey, not an interview, or focus groups.  The advantage is that we get a lot of answers (9, 693 elementary school principals across the US). The disadvantage is that they answered these questions, without probes, follow-ups, or any “What did you mean by that?”

For example, one of the benchmark items is “CS offered > 5 years.”  My first thought was that this meant that there was CS offered in the curriculum for five grades, e.g., middle school and high school.  The actual question answered by principals was “How long has your school offered opportunities to learn computer science? (% greater than 5 years)”  So this item is about the longevity of CS ed at these particular schools that were sampled.  That’s interesting, but I’m not sure what it says about the state compared to the particular schools sampled — especially in local control states (e.g., California, Massachusetts, Nebraska) where individual districts can do anything they want.

We’re told that parents want more CS, but principals and parents mostly think that CS is computer literacy (e.g., how to use a computer).  We’re told that 64% of Michigan principals say “just as/more important” to “Do you think offering opportunities to learn CS is more important, just as important, or less important to a student’s future success than required courses like math, science, history and English?”  What does that mean, if they think that CS is keyboarding skills?  When 11% of the principals in Illinois say that demand for CS education among parents is high, does that mean that the principals think the parents think it’s keyboarding? or real CS? Is one more valuable than the other to parents, in the opinion of principals?  Maybe the principals are right, and only 11% of the parents would want CS if they knew what CS was.

Overall, recommended reading, but sometimes, it feels like reading tea leaves.

June 22, 2016 at 7:26 am 2 comments

How to choose programming languages for learners: Reviewing JavaScript and Ready

My Blog@CACM post for June is Five Principles for Programming Languages for Learners. The five principles I identify are:

  1. Connect to what learners know
  2. Keep cognitive load low
  3. Be honest
  4. Be generative and productive
  5. Test, don’t trust

I wrote the essay in response to Idit Harel’s influential essay American schools are teaching our kids how to code all wrong. There were many responses to Idit’s essay, on social media and in other blogs. Much of the discussion focused on text programming languages vs. drag-and-drop, blocks-based languages, which I don’t think is the most critical distinction.

In this post, I respond to two of the suggestions that came up in some of these discussions. I use the five principles to review the suggestions in a kind of heuristic evaluation.

JavaScript

If we were going to teach a professional language to students, JavaScript is attractive. It’s free and ubiquitous, available in every Web browser. There are many jobs for JavaScript programmers. Because so much is built on top of it, it’s likely to remain around for many years in a compatible form. I argue in the Blog@CACM post that there are many dimensions to “real” when it comes to programming languages. “Use by professionals” is not the most important one when we talk about learners.

I recommend considering each of these five principles before choosing a programming language like JavaScript for learners.

  1. Connect to what learners know – You could teach JavaScript as a connection to what children already know. The notation of JavaScript doesn’t look like anything that children are likely to have seen before, in contrast to Logo’s emphasis on words and sentences, Squeak eToys’ “Drive the Car,” Boxer’s simple UI boxes (what diSessa calls naive realism), and Racket/Bootstrap’s connections between algebra and S-expressions.  However, JavaScript is the language of the Web today, so one could probably relate the programming activities to Web pages. Most learners are familiar with parts of a Web page, animations in a Web page, and other Web features that JavaScript can control. That might serve as a connection point for children.
  2. Keep cognitive load low – JavaScript has a high cognitive load. I’m a JavaScript learner and am just meeting some of its weirder features. I was shocked when I first read that = is assignment, == is type-insensitive equality, and === is type sensitive equality/equivalence. So, "5"==5 is true, but "5"===5 is false. Counting the number of = and remembering what 1 vs 2 vs. 3 means is an excellent example of extraneous cognitive load. My bet is that JavaScript overwhelms children and is probably inefficient for adult learners. This means that learners are spending so much time making sense of the syntax, it takes them longer and more effort to get to the concepts (and they may lose interest before they get to the good stuff).
  3. Be honest – JavaScript is authentic, it’s real for most senses of the term.
  4. Be generative and productive – I don’t know if JavaScript would be generative and productive for students. I don’t know anyone teaching JavaScript as a way to teach significant ideas in CS or other STEM disciplines. My worry is that the cognitive load would be so overwhelming that you couldn’t get to the interdisciplinary or complex ideas. Students would spend too much effort counting = and fighting for loops.
  5. Test, don’t trustThe only study that I know comparing JavaScript to a blocks-based language had JavaScript losing. JavaScript conditionals and loop structures were far harder for students than the equivalent block-based structures.

We should experiment more with JavaScript, but I suspect that students would do better (struggle less with syntax, learn more, connect to other disciplines more) with a different syntax. If I were trying to get the advantages of JavaScript without the syntax cost, I’d try something like ClojureScript — freely available, as fast as JavaScript, as ubiquitous as JavaScript, used professionally, can be used to control Web pages like JavaScript (so connectable for learners), and with the syntactic similarities to mathematics that Racket enjoys.

Ready

Baker Franke of Code.org is promoting the essay Coding snobs are not helping our children prepare for the future as a response to Idit’s essay. The essay is about the application-building tool, Ready. Media theorist Dough Rushkoff has also been promoting Ready, What happens when anyone can code? We’re about to find out.

I disagree with Rushkoff’s description of Ready, even in the title. As the first essay by David Bennahum (a “Ready Maker and Venture Partner) points out, it’s explicitly not about using a programming language.

Our efforts at Ready, a platform that enables kids to make games, apps, whatever they want, without knowing a computer language, are designed to offer a new approach to broadening access to code literacy.

Bennahum’s essay means to be provocative — and even insulting, especially to all the teachers, developers, and researchers who have been creating successful contextualized computing education:

In this new world, learning coding is about moving away from computer languages, syntax, and academic exercises towards real world connections: game design and building projects that tie into other subjects like science and social studies… This is the inverse of how computer science has been taught, as an impersonal, disconnected, abstracted, mathematical exercise.

I can see how Rushkoff could be confused. These two quotes from the Ready team seem contradictory. It’s not clear how Ready can be both about “learning coding” and “code literacy” while also allowing kids to make “without knowing a computer language.” There is no programming language in Ready.  What is coding then? Is it just making stuff?  I agree with Rushkoff’s concerns about Ready.

True, if people don’t have to code, they may never find out how this stuff really works. They will be limited to the programming possibilities offered by the makers of the platforms, through which they assemble ready-made components into applications and other digital experiences.

Let’s consider Ready against the five principles I propose.

  1. Connect to what learners know – the components of Ready are the icons and sliders and text areas of any app or game. That part is probably recognizable to children.
  2. Keep cognitive load low – Ready is all about dragging and dropping pieces to put them together. My guess is that the cognitive load is low.
  3. Be honest – Ready is not “real” in most sense of authenticity. Yes, students build things that look like apps or games, but that’s not what motivates all students. More of Betsy DiSalvo’s “Glitch” students preferred Python over Alice (see blog post). Alice looked better (which appealed to students interested in media), but students knew that Python was closer to how professional programmers worked. Authenticity in terms of practice matters to students. No professional programmer solely drags and drops components. Programmers use programming languages.
  4. Be generative and productive – Ready completely fails this goal. There is no language, no notation. There is no tool to think with. It’s an app/game builder without any affordances for thinking about mathematics, science, economics, ecology, or any other STEM discipline. There’s a physics engine, but it’s a black box (see Hmelo and Guzdial on black box vs glass box scaffolding) — you can’t see inside it, you can’t learn from it. They build “models” with Ready (see this neurobiology example), but I have a hard time seeing the science and mathematics in what they’re building.
  5. Test, don’t trust – Ready offers us promises and quotes from experts, but no data, no results from use with students.

Ready is likely successful at helping students to make apps and games. It’s likely a bad choice for learners. I don’t see affordances in Ready for computational literacy.

June 20, 2016 at 7:46 am 19 comments

Getting closer to “all” in #CSforAll: Instructional supports for students with disabilities in K-5 computing

I’ve been arguing for a while that we don’t know how to get to CS for All, because we don’t know how to teach “all” yet.  This is what the Bootstrap group has been arguing from a STEM discipline and economics perspective (see blog post). I’ve also been concerned that we’re biased by the Inverse Lake Wobegone Effect and are assuming that the high-ability learners we’ve been teaching represent everyone.

Maya Israel is one of the few researchers who’s asking, “How do we teach computing to students with cognitive or learning disabilities in K-12?”  Below is a link to her most recent study.  Here, she’s looking at how we teach, what helps the students to engage in the computing activity.  I talked with her about this paper — we still don’t know what the students are learning.

As computer programming and computational thinking (CT) become more integrated into K-12 instruction, content teachers and special educators need to understand how to provide instructional supports to a wide range of learners, including students with disabilities. This cross-case analysis study examined the supports that two students with disabilities, who were initially disengaged during computing activities, received during computing instruction. Data revealed that students’ support needs during computing activities were not CT-specific. Rather, supports specific to these students’ needs that were successful in other educational areas were also successful and sufficient in CT. Although additional studies would need to be conducted to ascertain the transferability of these findings to other contexts and students, our results contribute evidence that students with disabilities can and should participate in CT and be provided with the supports they need, just as in all other areas of the curriculum. We present a framework for evaluating student engagement to identify student-specific supports and, when needed, refine the emerging K-12 CT pedagogy to facilitate full participation of all students. We then offer a list of four implications for practice based on the findings.

Source: Instructional supports for students with disabilities in K-5 computing: Findings from a cross-case analysis

June 17, 2016 at 7:51 am Leave a comment

An Ebook Integrating Minimal Manuals with Constructionism, Worked Examples, and Inquiry: MOHQ

Our computing education research group at Georgia Tech has been developing and evaluating ebooks for several years (see this post with discussion of some of them). We publish on them frequently, with a new paper just accepted to ICER 2016 in Melbourne. We use the Runestone Interactive platform which allows us to create ebooks with a lot of different kinds of learning activities — not just editing and running code (which I’ve been arguing for awhile is really important to support a range of abilities and motivations), but including editing and running code.

It’s a heavyweight platform. I have been thinking about alternative models of ebooks — maybe closer to e-pamphlets. Since I was working with GP (see previous post) and undergraduate David Tran was interested in working with me on a GP project, we built a prototype of a minimalist medium for learning CS. I call it a MOHQ: Minimal manual Organized around Hypertext Questions: http://home.cc.gatech.edu/gpblocks. (Suggestion: Use Firefox if you can for playing with browser GP. WAY faster for the JavaScript execution than either Chrome or Safari on my Mac.)

Minimal Manuals

John Carroll came up with the idea of minimal manuals back in the 1980’s (see the earliest paper I found on the idea). The goal is to help people to use complicated computing devices with the minimum of overhead. Each page of the manual starts with a task — something that a user would want to do. The goal is to put the instruction for how to achieve that task all on that one page.

The idea of minimalist instruction is described here: http://www.instructionaldesign.org/theories/minimalism.html.

The four principles of minimal instruction design are:

  1. Allow learners to start immediately on meaningful tasks.
  2. Minimize the amount of reading and other passive forms of training by allowing users to fill in the gaps themselves
  3. Include error recognition and recovery activities in the instruction
  4. Make all learning activities self-contained and independent of sequence.

There’s good evidence that minimal manuals really do work (see http://doc.utwente.nl/26430/1/Lazonder93minimal.pdf). Learners become more productive more quickly with minimal manuals, with surprisingly high scores on transfer and retention. A nice attribute of minimal manuals is that they’re geared toward success. They likely increase self-efficacy, a significant problem in CS education.

The goal of most minimal instruction is to be able to do something. What about learning conceptual knowledge?

Adding Learning Theory: Inquiry, Worked Examples, and Constructionism

I started exploring minimal manuals as a model for designing CS educational media after a challenge from Alan Kay. Alan asked me to think about how we would teach people to be autodidacts. One of the approaches used to encourage autodidactism is inquiry-based learning. Could we structure a minimal manual around questions that they might have or that we want students to ask themselves?

We structure our Runestone ebooks around an Examples+Practice framework. We provide a worked example (typically executable code, but sometimes a program visualization), and then ask (practice) questions about that example. We provide one or two practice exercises for every example. Based on Lauren Margeliux’s work, the point of the practice is to get students to think about the example, to engage with it, and to explain it to themselves. It’s less important that they do the questions — I want the students to read the questions and think about them, and Lauren’s work suggests that even the feedback may not be all that important.

Finally, one of the aspects that I like about Runestone is that every example in an active code area is a complete Python interpreter. Modify the code anyway you want. Erase all of it and build something new if you want. It’s constructionist. We want students to construct with the examples and go beyond them.

MOHQ: Minimal Manual Organized around Hypertext Questions

The prototype MOHQ that David Tran and I built (http://home.cc.gatech.edu/gpblocks) is an implementation of this integration of minimal manuals with constructionism, inquiry, and worked examples. Each page in the MOHQ:

  • Starts with a question that a student might be wondering about.
  • Offers a worked example in a video.
  • Offer the opportunity to construct with the example project.
  • Asks one or two practice questions, to prompt thinking about the project.

Using the minimal design principles to structure the explanation:

  1. Allow learners to start immediately on meaningful tasks.

The top page offers several questions that I hope are interesting to a student. Every page offers a project that aims to answer that question. GP is a good choice here because it’s blocks-based (low cognitive load) and I can do MediaComp in it (which is what I wanted to teach in this prototype).

#1: Minimize the amount of reading and other passive forms of training by allowing users to fill in the gaps themselves.

Each page has a video of David or me solving the problem in GP. Immediately afterward is a link to jump directly into the GP project exactly where the video ended. Undo something, redo something, start over and build something else. The point is to watch a video (where we try to explain what we’re doing, but we’re certainly not filling in all the gaps), then figure out how it works on your own.

Then we offer a couple of practice questions to challenge the learner: Did you really understand what was going on here?

#2: Include error recognition and recovery activities in the instruction.

Error recovery is easy when everything is in the browser — just hit the back button. You can’t save. You can’t damage anything. (We tell people this explicitly on every page.)

#3: Make all learning activities self-contained and independent of sequence.

This is the tough one. I want people to actually learn something in a MOHQ, that pixels have red, green, and blue components, and chromakey is about replacing one color with a background image, and that removing every other sample increases the frequency of a sound — and more general ideas, e.g., that elements in a collection can be referenced by index number.

So, all the driving questions from the home page start with, “Okay, you can just dive in here, but you might want to first go check out these other pages.” You don’t have to, but if you want to understand better what’s going on here, you might want to start with simpler questions.

We also want students to go on — to ask themselves new questions, to go try other projects. After each project, we offer some new questions that we hope that students might ask themselves. The links are explicitly prompts. “You might be thinking about these questions. Even if you weren’t, you might want to. Let’s see where we can explore next.”

Current Prototype and What Comes Next

Here’s the map of pages that we have out there right now. We built it in a Wiki which facilitated creating the network of pages that we want. This isn’t a linear book.

Full-MOHQ-Map

There’s maybe a dozen pages out there, but even with that relatively small size, it took most of a semester to pull these together. Producing the videos and building these pages by hand (even in a Wiki) was a lot of work. The tough part was every time we changed our minds about something — and had to go back through all of the previously built pages and update them. Since this is a prototype (i.e., we didn’t know what we wanted when we started), that happened quite often. If we were going to add more to the GP MOHQ, I’d want to use a tool for generating pages from a database as we did with STABLE, the Smalltalk Apprenticeship-Based Learning Environment.

I would appreciate your thoughts about MOHQ. Call this an expert review of the idea.

  • Thumbs-up or down? Worth developing further, or a bad direction?
  • What do you think is promising about this idea?
  • What would we need to change to make it more effective for student learning?

June 15, 2016 at 7:35 am 4 comments

Older Posts


Recent Posts

June 2016
M T W T F S S
« May    
 12345
6789101112
13141516171819
20212223242526
27282930  

Feeds

Blog Stats

  • 1,238,508 hits

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 4,219 other followers

CS Teaching Tips


Follow

Get every new post delivered to your Inbox.

Join 4,219 other followers