Posts tagged ‘Scratch’
In January, Barbara Ericson and I were invited to visit the new ExcITED Center at NTNU in Trondheim, Norway. ExcITED is the Centre for Excellent IT Education. It was a whirlwind trip, fitting it in after the start of our semester at Georgia Tech, but really wonderful. We got there just as NTNU was celebrating their new Department of Computer Science with an “IDIovation” celebration which included some great research talks and (a highlight for me) a live coding computer music performance. The whole event was recorded and is available here.
Our host for the visit was Michail Giannakos, who is a learning scientist interested in a variety of educational technologies. We got a chance to meet with several of the faculty and many of the students working in ExcITED. Like I said, it was a whirlwind trip, so please excuse me if I only mention a few of the projects we saw — the ones that particularly stuck with me, despite the jet-lag.
One team at ExcITED is logging student interactions with the IDE that they use in their classes at the University, like the BlueJ Blackbox effort. What makes what they’re doing remarkable is that they’re immediately turning the data around, to present a process mirror to the students. They show students a visualization of what they have been doing. The goal is to encourage reflection, to get students to realize when they’re spending too much time on one phase of their work, or maybe not enough (e.g., in testing). The challenge is mapping from the low-level user interactions to higher-level visualizations that might inform students.
There are several projects that are working with children who are programming in Scratch (which can be localized to Norwegian). The one that most captured my attention was where students were programming these beautiful robotic sculptures, created by professional artists. The team is exploring how this influences student motivation. How does motivation change when the robots under the students’ control are neither student-generated nor stereotypically “robotic”?
The Tiles project by Simone Mora, Francesco Gianni, and Monica Divitini aims to engage designers in ubiquitous computing. They have these cool cards that they use in an activity with designers to get them thinking about the kinds of everyday items in which computation might be embedded. They want designers to think about how sensors and actuators might be used to support user activity.
On the weekend after our visit, the chair of the department, Letizia Jaccheri, took Barb and I off to ski in Sweden in Åre. We arrived on a Thursday, spoke at IDIovation that night, met with ExcITED researchers on Friday, traveled to Sweden to ski on Saturday, back on Sunday, and flew home on Monday. An absolutely amazing trip for which we were both grateful to have had the opportunity!
Aman Yadav and Steve Cooper have the CACM Viewpoints Education column this month. They raise the questions of how learning computing can lead to greater creativity, and how we can design computing education experiences to draw students in to greater depth.
Computing has the potential to provide users opportunities to extend their creative expression to solve problems, create computational artifacts, and develop new knowledge. The pervasive nature of computing and accessibility of digital tools is also transforming K-12 education as students move from being mere consumers of content to engaging in the subject matter by creating computational artifacts. Take Scratch, for example, which is one of the many tools designed to teach kids to code, and comes with varying levels of support for educators implementing them in both formal and informal learning settings. Scratch provides students with an opportunity to express their creativity through stories, games, and animations. While Scratch has the potential to be a powerful tool, it is often used as little more than a presentation tool in the classroom. Studies of Scratch users show that few projects use variables or control flow data structures. While the Scratch environment provides a ‘low floor, high ceiling’ that allows beginners to dive into the environment without frustration, many students do not advance to a higher level. Tools like Scratch can empower students to showcase their creativity like never before; however, the way these tools are taught by teachers and used by students significantly influences whether students move along the creativity continuum. While Scratch is widely used, we know little about how it influences students’ creative thinking.
GP is a new blocks-based programming language being developed by John Maloney (most well-known for developing Scratch), Jens Mönig (developer of Snap!), and Yoshiki Ohshima (one of the developers of Squeak EToys) in Alan Kay’s group. They are all part of the new partnership between Alan Kay and Y-Combinator Research: HARC (Human Advancement Research Community). GP started in the SAP-funded CDG (Communications Design Group).
GP is not yet released, and there’s not much publicly available on it yet. The GP Team published a paper and poster in the Blocks and Beyond Workshop at last year’s VL/HCC on GP. The best introductory article on GP so-far is on the Scratch Wiki at MIT based on John’s presentation at the Scratch conference last year.
GP is an exploration of the question, “How far can we go with a blocks-based programming language? Do we have to move students to a textual programming language to let them develop everything from data analyses to real applications?”
GP users can do a lot with GP’s built-in blocks. However, as they grow in mastery, some users may wish to add new blocks to GP (e.g. to manipulate images), or even to extend the GP programming environment itself (e.g. by adding an image editor). GP is designed to be extended in itself using the same blocks language that users already know. However, unlike Smalltalk or Snap!, the GP language itself cannot be extended (e.g. to add a new control structure) without modifying the virtual machine. Keeping the GP language simple and fixed is intended to ease the learning path for beginners.
A brief tour of Smalltalk-like features of GP
When you first start up GP, it looks like Scratch. The blocks palette is different, because it’s covering a larger space of blocks. GP includes blocks for dealing with data (e.g., JSON, comma-separated values), media generation and manipulation, connections to the network and external devices, and the ability to create and coordinate multiple objects.
There are even blocks in there for manipulating pixels in an image and samples in a sound. GP is the first blocks-based language in which I’ve been able to do both sound and pixel Media Computation examples. I built the first version of MediaComp blocks for GP, then John figured out which ones were actually useful and then re-implemented them in GP much more efficiently than what I did.
I’m introducing GP here with the GP Team’s permission in order to show you a prototype ebook I’ve been building the last few months. You can play with GP at http://home.cc.gatech.edu/GPBlocks. This is the browser-based version which is offered with no guarantees — the browser version will likely change dramatically as GP is still being developed, and even the examples in the ebook may break over time. (Note: These browser-based examples are best viewed in Firefox on a desktop or laptop computer; they do not yet work on iOS or Android tablets.)
Here’s a brief series of snapshots to give you a sense of what makes GP so interesting and powerful compared to most other blocks-based languages. In the stage area (upper right-hand corner) right-click (control-click on a Mac) to bring up the stage menu.
The menu options for a workspace and to browse will elicit warm feelings of recognition for Smalltalk and Self programmers. Go ahead and click on the browse menu item.
Scanning the classes along the left hand side you realize that this is a full Smalltalk-like language. All the pieces are there and inspectable. The middle panes show the instance variables in the class (top) and the methods for the class (bottom). The rightmost pane shows the code for the method — in blocks!
One of the big goals of GP is that all of GP is written in GP. Even the lowest levels of GP (e.g., how bitmaps and blocks are constructed) can be manipulated in GP, all in blocks. Those methods are real code and “live.” Change them and you change how GP is working immediately. Right now, that’s super dangerous — there is no “editing” mode. Move a block out of place, and the method is changed at that moment. Beware of re-defining how Integers work! The GP team is currently working to complete this part of GP, allowing the GP programming system to be used to modify itself, like Smalltalk.
The GP team is also exploring the stages between blocks and text. At the top right hand corner of GP is a slider between blocks and text. Switch it to text, and all of GP is presented and usable in a textual form. (There’s even an interesting middle stage between blocks and text.)
I’ve been using GP for about nine months. During the Spring semester, I’ve been using GP with an undergraduate research assistant, David Tran, to build a prototype of a new kind of ebook structure. Play around (muck/MOHQ around) in the GPBlocks MOHQ, and in the next blog post, I’ll explain what it is and what we’re exploring in it.
My thanks to the GP team for review and comments on drafts of this post.
Code.org has just released an interesting survey about their Hour of Code initiative. They’ve been criticized for providing only an hour and overly focusing on puzzles (see Mitchel Resnick’s article here). The results suggest that they’re reaching a diverse audience, and having an effect beyond an hour — students keep going, and teachers start teaching CS.
Programming is a literacy, and no one develops any kind of literacy in just an hour of practice. Games are not the most interesting and powerful kinds of programming activities.
But they’re a start. Particularly when we get past the Inverse Lake Wobegon Effect of thinking about students as being like us. We know from many studies that students are afraid of computer programming. I’m teaching Media Computation again this semester, and at least a third of the students who have come talk to me after class have started their conversation with, “I’m one of those people who just don’t do computers.” And that’s just those self-reporting without prompting! Students associate CS with being a geek and wouldn’t want to let their friends know they like computer science, even if they do. Few students get any kind of computer science education outside of Hour of Code.
When we think about most people, sustained activity in programming for one hour can go a long way to reducing fear, increasing self-efficacy, and nurturing interest. (Consider an Hour of Code compared to less than <5 minutes typically spent at a museum exhibit.) Games are a useful place to start because they’re well-structured. Aptitude-treatment interaction tells us that more structure is better with students who have less background in a subject. Open-ended, constructionist activities like those that Mitchel is promoting are more successful with more privileged students, those who have more experience which results in higher-ability students. The Hour of Code can help inspire students to get that additional experience needed to develop more ability.) An Hour of Code is a good first step for the remedial state of computing education in the United States today.
Hooray for Hour of Code, and thanks to Code.org for promoting it and for sharing these data.
The onus is on us to turn the Hour of Code into a Lifetime of Computational Literacy.
After the Hour of Code, we asked participating organizers how it went and got some fantastic news for our field.
- 98% had a good or great experience.
- 85% of those new to computer science said the Hour of Code increased their interest in teaching computer science.
- 49% said they plan to continue teaching computer science beyond one hour.
- 18% said they began teaching computer science after a previous Hour of Code campaign!
- 87% said their students did more than just one hour of coding.
ICER 2015 at the University of Nebraska, Omaha was fantastic. Brian Dorn did a terrific job hosting all of us.
The Doctoral Consortium went really well. We had 20 students from US, Chile, Germany, and UK. Below is a picture from the “Up against the wall bubble sort” where experienced students went to one side, and newer students went to the other, and the former gave advice to the latter.
Georgia Tech had even more going on at ICER and RESPECT than I mentioned in my earlier blog posts (like here and here). The GVU Center did a nice write up about all of us here. The biggest thrill at ICER for the GT crowd was Briana Morrison receiving the Chairs Award (one of two best paper awards at ICER) for the paper that I blogged about here. Below is the whole GT contingent at ICER (including chair Brian Dorn, GT alum).
The other best paper award, the peoples’ choice John Henry Award, went to Kristin Searle and Yasmin Kafai (see paper here) about the e-textiles work with American Indians that I blogged about here. Kristin had so many interesting insights, like the boys in her project telling her that “I don’t own” the projects they made because they felt no ownership over the programming environment they were using.
The quality of the papers was very good (you can see the list of all of them here). My favorite paper from my review packet was presented Monday morning, Spatial Skills in Introductory Computer Programming. Steve Cooper and Sheryl Sorby with two undergraduates at Stanford did the study that I’ve been wanting to see for ages (see blog post where I talk about it). Training an experimental group in spatial skills improved performance over a control group. Surprisingly, SES and race differences disappeared in the experimental group! This is an important result.
But one session blew me away — it changed how I think about blocks programming.
- The first paper was from Thomas Price and Tiffany Barnes showing that students using blocks were able to achieve programming tasks faster than those using text, but with no difference in learning or attitudes afterwards (paper here). This was an interesting result, but it was a limited study (short intervention, no pre-test) so it mostly supported a finding from Chris Hundhausen from years previous that graphical, direct-manipulation languages lead to faster start-up than text languages (see paper here).
- David Weintrop presented his remarkable paper with Uri Wilensky (see paper here). Below is the graph that changed my thinking about blocks. David carefully developed an isomorphic test in blocks and text, and gave it to the same population. Students did much better on the blocks-based test. MODALITY MATTERS! Blocks and text are not equivalent. He did careful analyses at each level of the test. For example, David replicated the result that else clauses in text are really hard for novices (which I talked about here), but students perform much better in blocks-based if-else.
- Diana Franklin presented their paper describing fourth graders reading Scratch programs (see paper here). I was expecting a paper on program comprehension — it wasn’t. Instead, it was a paper about user interfaces, and how the user interface interfered or supported students exploring and coming to understand the program.
I came away from that three papers realizing that blocks programming is likely the best modality to use in elementary school programming, and perhaps even when starting to program in high school, and maybe even for end-user programmers. But even more important, I realized that Andy Ko’s comments about programming languages as being a powerful and unusable user interface (see his blog post here) is the critical insight about programming today. David showed us that blocks can dramatically increase readability of programs. Diana showed us that the user interface dramatically influences the readability of the blocks. At the novice programming level, blocks-based languages are the most promising direction today, and designing good blocks languages is as much a user interface design problem as it is a programming language design problem.
Interesting perspective from a blogger in the Scratch community, liked below. I do frequently hear the pattern described in the post quoted below. “I’ve started by daughter/niece/local-school on Scratch, and now I want to know how to move them into something ‘real’ (e.g., text).” I typically point them to amazing things that can be done in Scratch (like Alex Ruthmann’s beautiful livecoding of music in Scratch).
I recently got a chance to play with GP, a new programming language from John Maloney (of Scratch fame), where all blocks and texts are isomorphic. There’s a slider that lets you switch from one to the other. Even the debugger and class browser show up with tiles. Where does that play out in this debate? GP is the first blocks-based language I’ve used with the right primitives to do MediaComp, so I built one of my examples in it. Took me about three times as much time to write and four times as much space (in screen real estate) as in Python (even with John looking over my shoulder guiding me). Maybe that’s not a bad thing — maybe that encourages a different style of use. Next time I try something like that, I’m far more likely to think about building my own blocks and using more abstraction to save on dragging-and-fitting effort.
I’ve been a part of the Scratch community for about 8 years now (yes, really). During this time, I’ve noticed a pattern that seems to apply to a lot of people:
join Scratch => create projects => discover text-based programming => quit Scratch because of “real programming”
Note the scare quotes around “real programming”. Generally, a “real” programming language is text-based (C, Python, etc.) and apparently qualifies as real because it’s used by well-known developers for something.
Obviously I disagree with disqualifying Scratch as a real programming language.
Thursday, October 22, 2015, Atlanta, GA
A satellite workshop of the 2015 IEEE Symposium Visual Languages and Human-Centric Computing (VL/HCC) https://sites.google.com/site/vlhcc2015
Scope and Goals
Blocks programming environments represent program syntax trees as compositions of visual blocks. This family of tools includes Scratch, Code.org’s Blockly lessons, App Inventor, Snap!, Pencil Code, Looking Glass, etc. They have introduced programming and computational thinking to tens of millions, reaching people of all ages and backgrounds.
Despite their popularity, there has been remarkably little research on the usability, effectiveness, and generalizability of affordances of these environments. The goal of this workshop is to begin to distill testable hypotheses from the existing folk knowledge of blocks environments and identify research questions and partnerships that can legitimize, or discount, pieces of this knowledge. It will bring together educators and researchers who work with blocks languages and members of the broader VL/HCC community interested in this area. We seek participants with diverse expertise, including, but not limited to: design of programming environments, instruction with these environments, the learning sciences, data analytics, usability, and more.
The workshop will be a generative discussion that sets the stage for future work and collaboration. It will include participant presentations and demonstrations that frame the discussion, followed by reflection on the state of the field and smaller working-group discussion and brainstorming sessions.
Suggested Topics for Discussion
- Who uses blocks programming environments and why?
- Which features of blocks environments help or hinder users? How do we know? Which of these features are worth incorporating into more traditional IDEs? What helpful features are missing?
- How can blocks environments and associated curricular materials be made more accessible to everyone, especially those with disabilities?
- Can blocks programming appeal to a wider range of interests (e.g., by allowing connections to different types of devices, web services, data sources, etc.)?
- What are the best ways to introduce programming to novices and to support their progression towards mastery? Do these approaches differ for for learners of computing basics and for makers?
- What are the conceptual and practical hurdles encountered by novice users of blocks languages when they face the transition to text languages and traditional programming communities? What can be done to reduce these hurdles?
- How can we best harness online communities to support growth through teaching, motivating, and providing inspiration and feedback?
- What roles should collaboration play in blocks programming? How can environments support that collaboration?
- In these environments, what data can be collected, and how can that data be analyzed to determine answers to questions like those above? How can we use data to answer larger scale questions about early experiences with programming?
- What are the lessons learned (both positive and negative) from creating first programming environments that can be shared with future environment designers?
We invite two kinds of submissions:
- A 1 to 3 page position statement describing an idea or research question related to the design, teaching, or study of blocks programming environments.
- A paper (up to 6 pages) describing previously unpublished results involving the design, study, or pedagogy of blocks programming environments.
All submissions must be made as PDF files to the Easy Chair Blocks and Beyond workshop submission site (https://easychair.org/conferences/?conf=blocksbeyond2015). Because this workshop will be discussion-based, rather than a mini-conference, the number of presentation/demonstration slots are limited. Authors for whom presentation or demonstration is essential should indicate this in their submission.
- 24 Jul. 2014: Submissions due.
- 14 Aug. 2015: Author notification.
- 4 Sep. 2015: Camera ready copies due.
- 22 Oct. 2015: Workshop in Atlanta.
- Franklyn Turbak (chair), Wellesley College
- David Bau, Google
- Jeff Gray, University of Alabama
- Caitlin Kelleher, Washington University, St. Louis
- Josh Sheldon, MIT
- Neil Brown, University of Kent
- Dave Culyba, Carnegie Mellon University
- Sayamindu Dasgupta, MIT
- Deborah Fields, Utah State University
- Neil Fraser, Google
- Mark Friedman, Google
- Dan Garcia, University of California, Berkeley
- Benjamin Mako Hill, University of Washington
- Fred Martin, University of Massachusetts Lowell
- Paul Medlock-Walton, MIT
- Yoshiaki Matsuzawa, Aoyama Gakuin University
- Amon Millner, Olin College
- Ralph Morelli, Trinity College
- Brook Osborne, Code.org
- Jonathan Protzenko, Microsoft Research
- Ben Shapiro, Tufts University
- Wolfgang Slany, Graz University of Technology
- Daniel Wendel, MIT