Posts tagged ‘block-based languages’

Summarizing findings about block-based programming in computing education

As readers of my blog know, I’m interested in alternative modalities and representations for programming. I’m an avid follower of David Weintrop’s work, especially the work comparing blocks and text for programming (e.g., as discussed in this blog post).

David wrote a piece for CACM summarizing some of his studies on block-based programming in computing education. It has just been published in the August issue.  Here’s the link to the piece — I recommend it.

To understand how learners make sense of the block-based modality and understand the scaffolds that novice programmers find useful, I conducted a series of studies in high-school computer science classrooms. As part of this work, I observed novices writing programs in block-based tools and interviewed them about the experience. Through these interviews and a series of surveys, a picture emerged of what the learners themselves identified as being useful about the block-based approach to programming. Students cited features discussed here such as the shape and visual layout of blocks, the ability to browse available commands, and the ease of the drag-and-drop composition interaction. They also cited the language of the blocks themselves, with one student saying “Java is not in English it’s in Java language, and the blocks are in English, it’s easier to understand.” I also surveyed students after working in both block-based and text-based programming environment and they overwhelmingly reported block-based tools as being easier. These findings show that students themselves see block-based tools as useful and shed light as to why this is the case.

August 19, 2019 at 7:00 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 12 comments

Blocks and Beyond Workshop at VL/HCC: Lessons and Directions for First Programming Environments

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?

Submission

We invite two kinds of submissions:

  1. A 1 to 3 page position statement describing an idea or research question related to the design, teaching, or study of blocks programming environments.
  2. 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.

Important Dates

  • 24 Jul. 2014: Submissions due.
  • 14 Aug. 2015: Author notification.
  • 4 Sep. 2015: Camera ready copies due.
  • 22 Oct. 2015: Workshop in Atlanta.

Organizers

  • Franklyn Turbak (chair), Wellesley College
  • David Bau, Google
  • Jeff Gray, University of Alabama
  • Caitlin Kelleher, Washington University, St. Louis
  • Josh Sheldon, MIT

Program Committee

  • 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

June 29, 2015 at 8:00 am Leave a comment


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

Join 9,038 other followers

Feeds

Recent Posts

Blog Stats

  • 2,014,359 hits
May 2022
M T W T F S S
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

CS Teaching Tips