Conference PaperPDF Available

Initialization in Scratch: Seeking Knowledge Transfer

Authors:

Abstract and Figures

With the growing movement to use visual block-based languages (VBBLs) in elementary and middle school classrooms, questions arise about the learning outcomes of such activities. While some schools are content to use VBBLs to spark interest and motivation for the future pursuit of computing, others are asking, Does this early exposure produce knowledge that transfers to traditional text-based languages (TBLs)? If transfer is a goal, then a corollary is, How do we design the transition to maximize the transfer? This paper focuses on initialization of state and variables, exploring the differences between Scratch and two TBLs: C and Java. Based on observations of 9-12 year old students in a VBBL curriculum, we identify four pieces of knowledge that are critical for C and Java but are not nearly as obvious in Scratch, including whether, when, and how to perform initialization. We conclude with suggestions for instruction and development environment that may improve transfer.
Content may be subject to copyright.
Initialization in Scratch: Seeking Knowledge Transfer
Diana Franklin§, Charlotte Hill, Hilary A. Dwyer, Alexandria K. Hansen, Ashley Iveland,
Danielle B. Harlow
§Center for Elementary
Math and Science Education
University of Chicago
1100 E. 58th St
Chicago, IL 60637
dmfranklin@uchicago.edu
Gevirtz School of Education
Department of Computer Science
UC Santa Barbara
Santa Barbara, CA 93106-9490
{hdwyer, akillian, aockey, dharlow}@education.ucsb.edu
charlottehill@cs.ucsb.edu
ABSTRACT
With the growing movement to use visual block-based
languages (VBBLs) in elementary and middle school classrooms,
questions arise about the learning outcomes of such activities.
While some schools are content to use VBBLs to spark interest
and motivation for the future pursuit of computing, others are
asking, Does this early exposure produce knowledge that
transfers to traditional text-based languages (TBLs)? If transfer is
a goal, then a corollary is, How do we design the transition to
maximize the transfer? This paper focuses on initialization of
state and variables, exploring the differences between Scratch and
two TBLs: C and Java. Based on observations of 9-12 year old
students in a VBBL curriculum, we identify four pieces of
knowledge that are critical for C and Java but are not nearly as
obvious in Scratch, including whether, when, and how to perform
initialization. We conclude with suggestions for instruction and
development environment that may improve transfer.
Keywords
Initialization; Scratch; VBBLs; K-6; knowledge transfer
1. INTRODUCTION
For decades, computer scientists have been developing
activities for young students in an effort to engage them in
computer science early, leading to many educational
programming platforms[7, 14], activities[3, 13] and outreach
programs[21, 9]. Two goals of such early exposure to computer
science include recruitment[6, 15] and computational thinking
skills. It is hoped that early exposure to computer science makes
students more likely to either become computer scientists, work
with computer scientists, or program as needed. Block-based
programming languages were developed to allow students to learn
fundamentals of programming without the overhead of typing or
memorizing commands. An open question is how much of what
they learn is useful only for programming in VBBLs, and how
much helps them when moving to a TBL. In this paper, we restrict
ourselves to imperative and object-oriented languages. This
question has gained importance as the Hour of Code and other
efforts have piqued the interest of elementary schools. Recent
research has shown that some knowledge does transfer between
VBBLs and TBLs when bridging and hugging techniques to
support transfer are used[1, 8].
Here, we consider transfer to occur if a student applies
principles from one context to another, even when the learning
environment and language details differ and consider the
conditions of the two types of languages (VBBLs and TBLs) that
support and hinder transfer. In this study, we closely examine
initialization of variables and objects as accomplished in Scratch,
C, and Java, and the relationship between these. The contributions
of this paper are:
Detailed comparison of the data models in Scratch and C/Java.
Identification of key concepts that are integral to initialization
in C/Java but overlooked by students in Scratch.
Suggestions for the development environment and instruction
that may improve transfer.
The rest of the paper is organized as follows. We provide
background on visual block-based languages, prior work on
transfer, and our theoretical framework in Section 2. Section 3
describes initialization in more detail. Sections 4 and 5 present our
curriculum from a high level and the methodologies derived from
educational research used in our study. We then present our
results in Section 7. Finally, Section 8 contains our conclusions
and future work.
2. BACKGROUND
There are several visual block-based development
environments, including Alice[7], Scratch[14], and LaPlaya[12]
with common attributes like, a drag-and-drop development
environment to replace much of the typing, available commands
displayed visually, images are favored over numerical and textual
output, and sprites are created with a friendly interface hiding
variables such as position, orientation, and size.
In our work, we use a variant of Scratch, a common
programming environment for novices in a variety of
contexts[16]. Scratch differs from more traditional, text-based
languages in both control and data. First, while it has some similar
control structures (loops, conditionals), the program paradigm is
entirely event-driven, with no single thread of control in the
program. Second, the data consists mostly of sprites
represented by 2D images with attributes such as size, position,
orientation, and visibility that can be manipulated.
Block-based languages have been used at the college and
pre-college levels to provide an early introduction to computing
with a transition to a traditional language either within the same
first course (college)[8] or in a second course (pre-college)[1].
Two types of approaches have been used. Some courses present
each concept first in a block-based language, and then in the
traditional language. Other courses present a set of concepts in a
block-based language, and then transition to a traditional
language, revisiting each of those concepts in the new language.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. Copyrights for
components of this work owned by others than ACM must be honored.
Abstracting with credit is permitted. To copy otherwise, or republish, to
post on servers or to redistribute to lists, requires prior specific permission
and/or a fee. Request permissions from Permissions@acm.org.
SIGCSE ‘16, March 02-05, 2016, Memphis, TN, USA.
© 2016 ACM ISBN 978-1-4503-3685-7/16/03$15.00
DOI: http://dx.doi.org/10.1145/2839509.2844569
217
The difference between visual block-based languages and
traditional languages is debatable. In this work, we assume two
major differences between the types of languages. First, the
programming environment differs, with traditional languages
depending on typing on a blank screen, and much less scaffolding
of the available instructions and syntax. Second, the type of data
operated on differs. VBBL projects are multimedia projects,
operating mostly on graphical data (2D or 3D), and the languages
provide primitives to manipulate these attributes (changing size,
location, orientation, etc.); Traditional languages typically operate
on strings and numbers.
Perkins and Salomon[18] define two techniques, bridging
and hugging, that help students transfer knowledge from one
context to another. Bridging refers to how the concept is taught in
the first context. These principles can be applied to computer
science when teaching general concepts within a single language.
When presenting a new topic in the language, a bridging
discussion would describe how the general concept is applied to
other contexts (e.g. real-world or other languages) to prepare
students for the use in other languages. This gives students a
broader understanding of the concept, allowing them to more
easily apply it to the new language. Hugging refers to how the
concept is taught in the second language. Initial examples are
chosen to make the second context as similar to the first as
possible in order to encourage students to see the relationship
between the two languages. More examples follow that show the
different ways this concept can be applied to the second concept.
Dann et al.[8] applied bridging and hugging to a college-
level blended Alice/Java course. Student achievement increased
across the entire course - improving their final scores from 61% to
85% and 82% (with similarly large gains with every subject in the
course) compared to a Java-only course. Another pertinent result
was that in order to improve hugging, the block-based language
sometimes must fundamentally change in order to allow for
simpler correlating examples in the second language. In particular,
parallelism and inheritance are not subjects that match well
between Alice and Java at this time.
Armoni et al.[1] performed a study in two different
classrooms. First, they taught students Scratch in a middle-school
course. Then, some students enrolled in a high school CS1 course
in which they were mixed with students who had not taken the
Scratch course. They found that the students who had taken the
Scratch course did significantly better (20 percentage points) than
the other students in bounded and conditional loop execution, but
there was no difference in variables and conditionals. In addition,
teachers covered the material more quickly when students had
already taken the courses. They found that students knowledge
was very limited to the contexts in which they had been taught,
lending credence to the importance of bridging and hugging.
One line of work seeks to build learning progressions for
young VBBL learners. Seiter[19] used existing projects across
different grade levels to identify how computational thinking
concepts varied by level in their Progression of Early
Computational Thinking (PECT) Model. However, existence of a
block in a project is not evidence of learning, as Brennan et al.[4]
found out when interviewing Scratch contributors.
In order to understand how students learn a topic, learning
progressions have been proposed that illustrate a path (or choice
of paths) that students go through in understanding a particular
topic, with the final goal being some level of understanding
appropriate to the student s age. When thinking of computer
science from a learning progressions perspective, it is tempting to
consider the learning of VBBL programming at the bottom of the
Figure 1: (a) Primitive type declaration / initialization, C/Java
(b) Class constructor definition and use, Java
(c) Struct function definition and use, C
progression leading to skills and understanding for traditional
languages. However, programming in VBBLs may require
different ideas and skills than TBLs, making the learning process
more complex than the linear learning progression model depicts
and more akin to transferring knowledge between related fields of
knowledge than directly building knowledge. In fact, other
scholars have made the argument that learning progression
models, in general, are too simple to capture the learning process.
Hammer and Sikorski[11] argue that a particular level of
understanding requires different pieces of knowledge. These
pieces of knowledge may not have a particular order to them and
may be activated differently depending on the learning context.
This perspective learning is related to earlier work by
Hammer[10] in which he proposed the idea that, rather than large
concepts, learners had smaller ideas that are neither correct nor
incorrect on their own, but may be activated appropriately or
inappropriately by a context. An important perspective in this
work is to break concepts down into smaller chunks. It is not
sufficient to study whether students learned loops or could
transfer their knowledge of loops or any other single concept.
The idea of transfer (or learning) from this perspective becomes
activating appropriate combinations of smaller ideas in a new
context.
The goal of this study is to better understand initialization of
variables and objects in Scratch and TBLs. More specifically, we
seek to identify pieces of knowledge (from student work and
observation) and hypothesize what aspects make transfer
challenging without careful bridging and hugging.
3. VARIABLE INITIALIZATION
In this section, we describe initialization in Scratch compared
to C and Java. We focus on two aspects: the variable types and
mechanisms for initializing values, and the lifetime of variables.
In the interest of space, we simplify the concepts. In addition, we
do not evaluate whether it is easier or harder; we merely discuss
the differences.
In C and Java, there are two kinds of variables. Primitive
types use simple assignment operators to initialize (Figure 1a).
Variables may also be grouped. In Java, a class provides the
ability to define functions that operate on variables in an object of
that class. In addition, a constructor, contains all initialization of
variables in the class (Figure 1b). In C, the user may define an
initialization function, but the system does not explicitly support it
differently than any other function (Figure 1c).
Variables are created and destroyed throughout the program.
The longest lived variables are global variables, which are created
when a particular execution begins and destroyed when it ends.
All variables should be initialized (written to) before they are used
218
Figure 2: Blocks that modify Figure 3: Blocks that initialize
named variables sprite attributes
(read from). If the programmer forgets to initialize before use in
C, then the variable could have any value in it. For most variables,
the value will begin with whatever value was already in that
memory locationthe ending value of another variable that is no
longer present in the program. This leads to unpredictable
behavior, and it is difficult to track down such bugs. In Java,
however, uninitialized variables are detected by the compiler.
In Scratch, programming occurs in a combined development
/ runtime environment. There are also two types of variables.
Variables can be declared explicitly by the programmer, and
standard operators are provided for those (Figure 2). More
common, however, are groups of variables in sprites. These are
created with a “new sprite” button and given a first costume
(image). When a sprite is created, it starts with a default set of
values. Although the variable values may not be displayed
directly, the visual effect is clear. Figure 3 shows blocks that can
be used to initialize such attributes. There are two major
differences between these blocks and traditional variable
manipulation. First, the blocks are specific to the purpose (size,
direction, pen down or up). Second, while some of them do have
explicit variable names on which one can operate (e.g., x, y, size),
many of them have no way to read the values, only set them (pen
up or down, hide/show).
Scratch variables are created during program development
rather than program execution. When the program is run twice in
a row, the starting values are the same as the ending values from
the previous execution. When the program is stored, the current
values of all variables are also stored.
Finally, a complicating factor in initialization in Scratch is
that there exists no definite “beginning” of a Scratch program. As
stated previously, a Scratch program opens in its previously saved
state. Scratch is an event-based program, so a program could
consist entirely of events such as mouse clicks or key presses. The
convention is to begin the program on the green flag, so this is
where initialization would occur. However, because this is merely
a convention, with no system enforcement, it may not be evident
to novice Scratch programmers. In addition, there is no explicit
support for initialization like a constructor, and programmers may
not create functions.
4. CURRICULUM
Research on how children learn often depends on the curriculum
that supports that learning. This is true of our work, as well. Our
curriculum is intended to help students develop ideas about
computational thinking with two types of activities: activities
done off the computer (modeled on CS Unplugged activities[4])
and programming activities done on the computer. The computing
concepts covered are the minimum set of concepts necessary to
successfully complete a digital storytelling project in Scratch and
included two lessons on initialization. The context of the projects
were varied and selected to be interesting and accessible to our
population of 4th graders (8-9 years old). We also included bonus
projects for students who finish early and would like to explore
more creatively.
Figure 4: The Animal Sprint stage after the race has occurred.
We included an explicit lesson on initialization (see Figure
4) called Animal Sprint. This lesson animates a race between a
horse, rooster, and cat. The animals begin in the correct positions
so that students can see where each animal should begin. Then
each animal starts running when clicked. When the green flag is
clicked to reset the race, only the horse moves to back its initial
position at the starting line. The rooster and cat, in contrast, are
not properly initialized. For the rooster, both the location and
orientation need to be initialized because of its non-linear path to
the finish line. For the cat, both the location and size need to be
initialized because it stopped and ate several items, growing
bigger, on its way to the finish line. In this study, we focus only
on the initialization of the cat. Because of the difficulty students
had completing this project, we added a second project (Piñata)
that required only initializing position.
5. METHODS
We used design-based research, using both qualitative and
quantitative data to simultaneously inform curriculum
development, research, and practice[2, 4, 23], improving our
curriculum as we learned about student learning. Design-based
research is “a systematic but flexible methodology aimed to
improve educational practices through iterative analysis, design,
development, and implementation, based on collaboration among
researchers and practitioners in real-world settings, and leading to
contextually-sensitive design principles and theories[23].
This study involved ten 4th-6th grade classrooms (aged 8-12)
at five schools across California. In two of these schools (schools
B and E), we collected only student project snapshots. In the other
three schools (A, C, and D), we observed instruction and
interviewed students. Schools varied in numbers of classrooms,
grades participating, start dates, and order of projects.
Being present in three classrooms as participant
observers[22] allowed us to discover concepts the students were
struggling to learn. Researchers wrote field notes following each
school visit. In addition, in both distant and local classrooms, for
every project, we stored not only the final projects, but also
snapshots during the development process. A snapshot was taken
and stored into a zip file each time a project was run (when green
flag clicked) if at least 4 changes had been made.
Computer science researchers read the field notes and
inspected a subset of student projects to explore how the code
deviated from what was intended. They then identified the
specific features of projects that indicated a different view of
initialization than we anticipated. After identifying these features,
the entire set of student projects was automatically assessed to
count how often those features manifested themselves in projects.
219
Figure 5: Resetting just Figure 6: Resetting just
before the sprint. after the sprint.
The computer science and education researchers then met
together to discuss any conceptual issues, sources of those
conceptual issues, and changes to make to the lessons, projects,
and/or programming environment. These conversations focused
on points where students made what appeared to be errors from
the perspective of experts in computer science.
These conversations made visible understandings about
initialization held by the computer scientists that derived from
traditional languages and may not have been applicable to
Scratch. The disciplinary knowledge of experts differs
considerably from that of novices, making it difficult for experts
to anticipate where novices will struggle and, in some cases,
making them assume an unnecessary ordering of how information
is learned, a phenomenon termed expert blind spot [17].
While the students programmed in a VBBL, the experts
knowledge was developed and reified largely through TBLs. As
such, our analysis of projects, fieldnotes, and challenges, brought
to light differences between the VBBL and TBLs. In some cases,
these differences made it difficult for the students to develop the
knowledge useful for TBLs through the VBBL curriculum.
This process was repeated with each subsequent wave of
classrooms. Finally, at the end of the process, the computer
scientists and education researchers identified key pieces of
knowledge that were necessary for initialization in TBLs, how
those were expressed in Scratch, and the challenges in matching
the two languages.
6. RESULTS
Our final results are the pieces of knowledge[10] derived
from the lens of traditional languages but expressed in a way that
is applicable to Scratch. We also present the different expressions
of that knowledge observed in student projects and discuss the
implications on transfer between Scratch and other languages.
Finally, for some results (due to space limitations), we also
present data as to how often students demonstrated use of
concepts in their projects. We present this data to give a sense of
the variance and challenge involved in teaching initialization
rather than to make precise conclusions.
In this study, we focus on initialization of the cat in the
activity called Animal Race. The correct script initializes two
attributes: size and location. That is, the cat’s size is reset to
100%, and the cat is placed in the proper starting location.
Figure 7: Existence and timing of initialization for cat s
position in final snapshot of a given student s project.
Figure 8: Existence and timing of initialization for cat s
position in any snapshot of a given student s project.
For each project, we looked at two types of data - snapshots
and final projects. We looked at final projects to gauge how
students ended their programs, and we looked at all snapshots to
identify what techniques students used along the way. Many
students (47% at school B, 77% at school C, and 56% at school E)
successfully initialized the cat to the starting line by their final
submission, as seen in Figure 7. Variances in completion rates
were due to the number of sessions schools spent on initialization,
when they encountered the lesson (later schools curriculum had
been improved), and the ages of the students.
6.1.Initialization Before Use
In traditional languages, it is imperative that the variable be
initialized before it is used. In Scratch, however, this is not as
obvious, since all variable states are stored between executions,
and the expression of the variables (sprite attributes) are already
visible before program execution. Therefore, we found three
additional ideas that students needed to understand in order to
initialize in Scratch. Although perhaps not obvious, it is actually
critical in Scratch to initialize at the beginning rather than the end
execution can be stopped at any time, so only initialization at
the beginning is guaranteed to occur.
1a: Initialization cannot occur at the end of a program.
Many students initialized at the very end of the race. Figure 5
is a script that initializes at the beginning of the script, and Figure
6 is an example of initialization at the end of the script.
Figure 8 shows all the places initialization occurred during
students development. We can see that, at one time or another,
26% of the students from school C placed initialization after the
sprint. In addition, almost 10% introduced a race condition
220
Figure 9: Expected script. Figure 10: Initializing before race,
assuming end position of race.
because they used when sprite clicked rather than when green flag
clicked as the trigger event (creating a second when sprite clicked
script that ran in parallel with the given sprint script). Finally,
several students in classes B and E altered their sprint code
enough during their development that the cat no longer reached
the finish line (if sprinting from the starting line).
Figure 7 shows that only school C, which spent 3 sessions on
Animal Sprint and received very targeted help, had a majority of
students complete initialization before the sprint. About half of the
projects in the other classrooms had no initialization at all.
The frequency of students initializing after execution shows
the effect that carrying the state through alters students ideas of
initialization. It makes sense to students to initialize, or reset the
state at the end because that will be held. Therefore, unless
students are taught explicitly to initialize at the beginning,
students may attempt to initialize at the end in traditional
languages, as well.
1b: Initialization should occur on the green flag
In TBLs, the only requirement is initialization before use. In
Scratch, however, all attributes of sprites are visible, even before
the program is running. When, then, should initialization occur?
By convention, execution starts when the green flag is pressed, so
initialization should occur as the first actions in the green flag
script (Figures 9 & 10); all other events are part of the running
program. Many students, instead, initialized with the on cat
clicked script, which made initialization occur immediately before
or after the race.
1c: Initialization should be hidden from the user.
In Java and C, not only does initialization occur first, but it is
a separate, unique action. Constructors are special pieces of code
that are not explicitly called by the user or programmer: the
system calls them automatically when a new variable is created.
This challenged us to find a way to express the specialness and
separateness of initialization in an environment in which the
expression of the values are already visible before execution.
We identified this problem through iterative observation and
discussion. Initially, several students used blocks that were
unexpected to the computer scientists on the team. For students
who placed initialization code before the action (e.g., prior to the
sprint in Animal Sprint or at the start of the Piñata Project), they
chose one of two block types: go to (instantaneous) or glide (a
visible, slow movement).
Figure 11 shows what blocks students used in their final
submissions of the Animal Sprint and Piñata projects. In schools
C and D, all students used the go to block, whereas at schools B
and E, many students used the glide block. In School D, for the
Piñata projects, the presenter explicitly pointed out that it looked
silly for the candies to slowly glide up to the piñata. Therefore,
students had explicit instruction to use the go to block. At school
E, no directions were given. In discussions about this concept, we
discovered that the computer scientists expectation of
Figure 11: Instantaneous vs gradual initialization in last
submission only for projects that included initialization before
the action
instantaneous blocks was a manifestation of the belief that
initialization is special and should not be confused with normal
execution. Those who were encountering initialization only
through Scratch (education researchers and students) did not see
this distinction.
The important question is whether teaching this distinction
would help students transfer their knowledge to TBLs. More
specifically, would teaching that initialization is a special, distinct
action that occurs at the beginning of the program and should not
be viewed as part of the program, help transfer their knowledge?
While teaching that seeing the initialization looks silly may have
resulted in the students using the instantaneous blocks, it is
unlikely that students learned any generalizable concept.
6.2.Initialization does not use prior state
In traditional languages, nothing can be assumed about state
prior to initialization. In Scratch, the state is dependent entirely on
that variable s end state. This influences the instructions / blocks
used for initialization.
2a: Absolute blocks need to be used rather than relative blocks.
In traditional languages, absolute instructions (e.g., int x = 5)
must be used for initialization (as opposed to int x += 5).
Likewise, in Scratch, there are absolute blocks (set size to X%)
and relative blocks (change size by X).
In Scratch, because initial state is the same as end state, the
case for absolute blocks is not obvious. Figure 8 shows
initialization based on an absolute go to block, whereas Figure 9
shows a script that moves the cat back to the starting point
assuming it had been left at the end point. This works only in the
most expected use case: the program is running from beginning to
end each time. Unfortunately, this does not work properly if
someone accidentally presses the green flag twice without waiting
for it to complete, or if someone stops execution in the middle.
Table 1: The four pieces of knowledge identified that results in
robust implementations in both Scratch and traditional langs.
Initialization should occur at the beginning of the program
Initialization should occur in the green flag script
Initialization should be hidden from the user
Absolute blocks must be used to initialize
7. DISCUSSION
These findings can be analyzed from several levels. First, we
identified several “pieces of knowledge”, summarized in Table 1,
that signify principles about initialization derived from domain
221
experts’ expectations of Scratch projects. We found that because
Scratch saves state across executions and the state is visible as
sprite attributes, even the most basic pieces of knowledge of
initialization in traditional languages, “Initialize before Use” and
“Assume no Prior State”, are not obvious to a novice Scratch
programmer. Other attributes of Scratch, such as the lack of a
definite starting point and the variety of blocks used to alter state,
makes it much more difficult to identify exactly where to put the
code (the event) and which blocks to use (absolute vs relative).
One might be tempted to conclude that these are irrelevant,
especially when using Scratch with no desire for the knowledge to
transfer to other languages. Three out of the four principles,
however, apply to Scratch projects themselvesonly the question
of instantaneous vs. gradual initialization has no clear answer in
Scratch. Because students appear to design for the simple case
(executing the project to the end each time) they often initialize in
locations that do not work in other conditions. Once those
conditions are encountered, it is difficult to fix their program,
especially if they are not present to move everything back.
What about if transfer is one of the goals? We found that,
despite explicitly teaching initialization, these principles were not
obvious to the students. Therefore, the development environment,
language, and instruction will need to be revised to better align
these concepts. Within Scratch, students could be shown what
happens when a project is interrupted part way through in order to
develop a practice of initializing first and with absolute blocks. In
addition, bridging should occur to present more general, high-
level principles including the separate, special nature of
initialization. It should occur in the green flag script (or a special
script created just for initialization), and perhaps it should be
instantaneous. In addition, a Scratch variant could provide a
separate event for initialization that must be executed before the
green flag. Finally, hugging could occur when students encounter
traditional languages to relate what they learned in Scratch to
what they see in the new context. Students need to be explicitly
taught that variables are destroyed every time the program ends,
so they need to be initialized anew each execution.
8. CONCLUSIONS
We have discussed the details of initialization of state as they
are expressed in Scratch projects, presented several pieces of
knowledge necessary to understand initialization, and suggested
instructional strategies and Scratch modifications that could
increase the chances of successful knowledge transfer.
Initialization is just one of several important concepts for
creating digital storytelling projects. Similar analysis needs to be
undertaken for sequential execution, events, message-passing,
costumes, and scene changes, identifying how 4th graders learn
these concepts in VBBLs, and how that might affect their
understanding of traditional languages.
9. ACKNOWLEDGMENTS
This work is supported by the National Science Foundation CE21
Award CNS-1240985. We would also like to thank all of the
teachers, students, and schools involved in this project.
10. REFERENCES
1. Armoni, M., Meerbaum-Salant, O., and Ben-Ari, M. 2015.
From Scratch to “Real” Programming. Transactions on
Computing Education. 14, 4, Article 25 (February 2015)
2. Barab, S. and Squire, K. Design-based research: Putting a
stake in the ground. The Journal of the Learning Sciences,
13(1):114, 2004.
3. Bell, T., Witten, I. H. and Fellows, M. Computer Science
Unplugged. 2006.
4. Brennan, K. and Resnick, M.. New frameworks for studying
and assessing the development of computational thinking. In
AERA, 2012.
5. Brown, A. L. Design experiments: Theoretical and
methodological challenges in creating complex interventions in
classroom settings. The Journal of the Learning Sciences,
2(2):141178, 1992.
6. Lori Carter. 2006. Why students with an apparent aptitude for
computer science don t choose to major in computer science.
SIGCSE Bulletin 38, 1, 2731.
7. Dann, W., Cooper, S., and Pausch, R. Making the connection:
programming with animated small world. ITiCSE, 2000.
8. Dann, W., Cosgrove, D., Slater, D., Culyba, D., and Cooper,
S. Mediated transfer: Alice 3 to Java. In Proceedings of the 43rd
SIGCSE Symposium. ACM, New York, NY, 141146, 2012.
9. Franklin, D., et. al. Animal Tlatoque: attracting middle
school students to computing through culturally-relevant themes.
In Proceedings of the SIGCSE Symposium. 2011.
10. Hammer, D., Elby, A., Scherr, R. E., & Redish, E. F..
Resources, framing, and transfer.Transfer of learning from a
modern multidisciplinary perspective, 89-120, 2005.
11. Hammer, D., and Sikorski, T. Implications of complexity for
research on learning progressions.
Science Education, 99(3) 424-
431, 2015.
12. Hill, C., et al. Floors and Flexibility: Designing a
programming environment for 4th-6th grade classrooms'' In
SIGCSE 15. ACM Press, 2015.
13. Hood, C. S., and Hood, D. J. Teaching programming and
language concepts using LEGOs. In the Conference on Innovation
and Technology in Computer Science Education
(ITiCSE), June 2005.
14. Maloney, J., et al. The scratch programming language and
environment. Trans. Comput. Educ., 10(4):115, Nov. 2010.
15. Margolis, J., and Fisher, A. Unlocking the Clubhouse:
Women in Computing. MIT Press, Cambridge, MA, 2003.
16. Meerbaum-Salant, O., Armoni, M.,and Ben-Ari, M. Learning
Computer Science Concepts with Scratch. In the International
Workshop on Computing Education Research (ICER10), Aaarhus,
Denmark, pp. 69-76, 2010.
17. Nathan, M.J., and Petrosino, A. Expert blind spot among
preservice teachers. American educational research
journal, 40(4), 905-928, 2003.
18. Salomon, G., and Perkins, D. Teaching for transfer.
Educational Leadership, 22-32, September, 1988.
19. Seiter, L. and Forman, B. Modeling the learning progressions
of computational thinking of primary grade students. In the
International Workshop on Computing Education Research
(ICER13). ACM, 2013.
20. Spradley. J. P. Participant observation. Holt, Rinehart and
Winston, 1980.
21. The stars alliance: A southeastern partnership for diverse
participation in computing. NSF STARS Alliance Proposal.
http://www.itstars.org/.
22. Vygotsky. L. Mind in society: The development of higher
psychological processes. Harvard Uniersity Press, 1978.
23. Wang F., and Hannafin, M. Design-based research and
technology-enhanced learning environments. Educational
Technology Research and Development, 53(4):523, 2005.
222
... The last two publications, and Weintrop et al. [2018], discuss LaPlaya and Kids Engaged in Learning Programming and Computer Science (KELP-CS) curriculum that includes EDP. The former publication explores mismatches between LaPlaya and its users' abilities, continuing with the initialization theme of Franklin et al. [2016] above. The latter one presents such usage patterns of visual block-based languages that can be harmful from the viewpoint of later computer science education. ...
... Third, Fields et al. [2016] research children's learning trajectories by combining their social learning context with programming project snapshots. They especially examine EDP and parallelism as well as initialization, the latter adding to the work presented in Franklin et al. [2016] and above. The last publication [Fields et al. 2017] is a journal article based on the first publication of this stream-a conference paper of the same authors from [2014]. ...
... Scratch and LaPlaya. Franklin et al. [2016] found out that some students initialized their projects in wrong types of events. Similarly, report that some students "used unusual starting events but did not convey this to a user." ...
Article
[MANUSCRIPT: https://research.aalto.fi/en/persons/aleksi-lukkarinen] — During the past two decades, event-driven programming (EDP) has emerged as a central and almost ubiquitous concept in modern software development: Graphical user interfaces are self-evident in most mobile and web-based applications, as well as in many embedded systems, and they are most often based on reacting to events. To facilitate both teaching practice and research in programming education, this mapping review seeks to give an overview of the related knowledge that is already available in conference papers and journal articles. Starting from early works of the 1990s, we identified 105 papers that address teaching practices, present learning resources, software tools or libraries to support learning, and empirical studies related to EDP. We summarize the publications, their main content, and findings. While most studies focus on bachelor’s level education in universities, there has been substantial work in K–12 level, as well. Few courses address EDP as their main content—rather it is most often integrated with CS1, CS2, or computer graphics courses. The most common programming languages and environments addressed are Java, App Inventor, and Scratch. Moreover, very little of deliberate experimental scientific research has been carried out to explicitly address teaching and learning EDP. Consequently, while so-called experience reports, tool papers, and anecdotal evidence have been published, this theme offers a wide arena for empirical research in the future. At the end of the article, we suggest a number of directions for future research.
... Transfer between programming languages does take place, but tends to require explicit guidance and is known to be challenging for novices and even seasoned programmers (see, e.g., [8,51,57,122,125,143]). Santos et al. [122] (p. ...
... For example, Grover and Basu [62] comment on how Scratch de-emphasizes types: "[students who] don't have to deal with variables' data types ... end up with an incomplete understanding of expressions and operators (e.g. the fact that arithmetic operators make sense only with numbers [is just one] of the many issues). " Franklin et al. [57] discuss variable initialization in Scratch similarly. RPBs that deal with non-obvious aspects of the system should be constructed with particular care. ...
Preprint
Full-text available
We propose a framework for identifying, organizing, and communicating learning objectives that involve program semantics. In this framework, detailed learning objectives are written down as rules of program behavior (RPBs). RPBs are teacher-facing statements that describe what needs to be learned about the behavior of a specific sort of programs. Different programming languages, student cohorts, and contexts call for different RPBs. Instructional designers may define progressions of RPB rulesets for different stages of a programming course or curriculum; we identify evaluation criteria for RPBs and discuss tradeoffs in RPB design. As a proof-of-concept example, we present a progression of rulesets designed for teaching beginners how expressions, variables, and functions work in Python. We submit that the RPB framework is valuable to practitioners and researchers as a tool for design and communication. Within computing education research, the framework can inform, among other things, the ongoing exploration of “notional machines” and the design of assessments and visualizations. The theoretical work that we report here lays a foundation for future empirical research that compares the effectiveness of RPB rulesets as well as different methods for teaching a particular ruleset.
... Some advocate that visual languages are the best option for introducing novices to programming, while others support text-based languages as the best modality since that is what professional developers use. Thus, researchers have tried to address this topic, and they have work on evaluating the effects that the modality (block-based, text-based, and hybrid) has in the learning process [26,103,118,170,171]. Franklin et al. [53] study the differences between block-based languages (e.g., Scratch) and text-based languages (e.g., C and Java). Other researchers focus on studying how to ease the transition from a block-based language into a text-based language [81,172] and the drawbacks users face in this transition [104,105]. ...
Preprint
Full-text available
Block-based environments are visual programming environments, which are becoming more and more popular because of their ease of use. The ease of use comes thanks to their intuitive graphical representation and structural metaphors (jigsaw-like puzzles) to display valid combinations of language constructs to the users. Part of the current popularity of block-based environments is thanks to Scratch. As a result they are often associated with tools for children or young learners. However, it is unclear how these types of programming environments are developed and used in general. So we conducted a systematic literature review on block-based environments by studying 152 papers published between 2014 and 2020, and a non-systematic tool review of 32 block-based environments. In particular, we provide a helpful inventory of block-based editors for end-users on different topics and domains. Likewise, we focused on identifying the main components of block-based environments, how they are engineered, and how they are used. This survey should be equally helpful for language engineering researchers and language engineers alike.
... To minimize the overhead required on the part of the user, some end-user robot programming systems automate parts of the setup process, such as mapping of the programming workspace and detection of programmable devices and robots (e.g., [53]). On the other hand, supporting users in appropriately initializing programs, which is challenging for novice programmers [38], has been less explored in the literature, though prior work has suggested its potential usefulness in preventing program errors by end-users (e.g., [117]). ...
Preprint
Full-text available
As robots interact with a broader range of end-users, end-user robot programming has helped democratize robot programming by empowering end-users who may not have experience in robot programming to customize robots to meet their individual contextual needs. This article surveys work on end-user robot programming, with a focus on end-user program specification. It describes the primary domains, programming phases, and design choices represented by the end-user robot programming literature. The survey concludes by highlighting open directions for further investigation to enhance and widen the reach of end-user robot programming systems.
... When students program with the Bee-Bot they must think not only about the starting point but the starting orientation as well. Scratch expects the students to program the initialization on their own [15] and this is an issue even with elementary students [16]. ScratchJr has an implicit initialization and the program runs from its original state in every run. ...
... While these visual, block-based, and tangible programming approaches help to lower the barrier to entry into programming, learners need to eventually transition to textbased programming [20]. Several transition methods have been proposed [21], [22], [23]; while their methods may vary in specifics, researchers agree that explicitly linking the concrete with abstract programming benefits transfer [22], [24]. Based on this idea, we combined the idea of concreteness fading and comics to establish a tighter connection between the concrete (comic) and abstract (code), as shown in Fig. 1. ...
Chapter
Recent years have seen growing interest in utilizing digital storytelling, where students create short narratives around a topic, as a means of creating motivating problem-solving activities in K-12 education. At the same time, there is increasing awareness of the need to engage students as young as elementary school in complex topics such as physical science and computational thinking. Building on previous research investigating block-based programming activities for storytelling, we present an approach to block-based programming for interactive digital storytelling to engage upper elementary students (ages 9 to 10) in computational thinking and narrative skill development. We describe both the learning environment that combines block-based narrative programming with a rich, interactive visualization engine designed to produce animations of student generated stories, as well as an analysis of students using the system to create narratives. Student generated stories are evaluated from both a story quality perspective as well as from their ability to communicate and demonstrate computational thinking and physical science concepts and practices. We also explore student behaviors during the story creation process and discuss potential improvements for future interventions.
Conference Paper
When students in programming courses are taught event-driven programming (EDP) for the first time, they face new terminology and concepts that they should internalize. Moreover, they learn a fully new approach for reasoning about program logic and execution order. However, there is a lack of research in students’ understanding of these concepts. In this paper, we describe a study, in which we asked web development students to explain their conception of EDP: what are the main concepts involved and how they interact. Moreover, we asked them to explain the execution of a short piece of JavaScript code that focuses on basic usage of events and event listeners. The answers, which we requested as concept maps and text, were analyzed using inductive content analysis. Our results clearly demonstrate shortcomings in the students’ learning and illustrate various misunderstandings that they may have regarding EDP. Based on the findings, we give suggestions for improving the teaching of EDP.
Article
Just as end-user programming has helped make computer programming accessible for a variety of users and settings, end-user robot programming has helped empower end-users without specialized knowledge or technical skills to customize robotic assistance that meets diverse environmental constraints and task requirements. While end-user robot programming methods such as kinesthetic teaching have introduced direct approaches to task demonstration that allow users to avoid working with traditional programming constructs, our formative study revealed that everyday people still have difficulties in specifying effective robot programs using these methods due to challenges in understanding robot kinematics and programming without situated context and assistive system feedback. These findings informed our development of Demoshop, an interactive robot programming tool that includes user-centric programming aids to help end-users author and edit task demonstrations. To evaluate the effectiveness of Demoshop, we conducted a user study comparing task performance and user experience associated with using Demoshop relative to a widely used commercial baseline interface. Results of our study indicate that users have greater task efficiency while authoring robot programs and maintain stronger mental models of the system when using Demoshop compared to the baseline interface. Our system implementation and study have implications for the further development of assistance in end-user robot programming.
Article
Abstraction is one of the most fundamental ideas in computer science (CS), and as such, according to Bruner, it should be taught spirally, starting as early as possible and revisited at every level of education. However, teaching CS abstraction to novices is a very challenging task, and CS educational research has often demonstrated students’ difficulties in learning this idea, in different contexts and at different age levels. The challenge in teaching CS abstraction is even greater when dealing with young students, since according to theories on children’s cognitive development, their abstraction abilities may still be not fully developed. In 2013, Armoni [5] introduced a framework for teaching abstraction in the context of algorithmic problem solving, intended for novice students. We studied the effect of this framework in an introductory CS course for 7th graders, in which Scratch was used as the programming language for implementing algorithmic solutions. Our findings indicate that the framework was highly effective for developing CS abstraction skills as well as other related skills and aspects, such as the tendency to provide explanations for solutions, the use of initialization processes, and the perception of the nature of CS. It also significantly improved students’ general CS performance in this course
Conference Paper
Full-text available
The recent renaissance in early computer science education has provided K-12 teachers with multiple options for introducing children to computer science. However, tools for teaching programming for children with wide-scale adoption have been targeted mostly at pre-readers or middle school and higher grade-levels. This leaves a gap for 4th -- 6th grade students, who differ developmentally from older and younger students. In this paper, we investigate block-based programming languages targeted at elementary and middle school students and demonstrate a gap in existing programming languages appropriate for 4th -- 6th grade classrooms. We analyze the benefits of Scratch, ScratchJr, and Blockly for students and curriculum developers. We describe the design principles we created based on our experiences using block-based programming in 4th -- 6th grade classrooms, and introduce LaPlaya, a language and development environment designed specifically for children in the gap between grades K-3 and middle school students.
Article
Full-text available
Mitchel Resnick (mres@media.mit.edu) MIT Media Lab Brennan, K., & Resnick, M. (2012). Using artifact-based interviews to study the development of computational thinking in interactive media design. Paper presented at annual American Educational Research Association meeting, Abstract Computational thinking is a phrase that has received considerable attention over the past several years – but there is little agreement about what computational thinking encompasses, and even less agreement about strategies for assessing the development of computational thinking in young people. We are interested in the ways that design-based learning activities – in particular, programming interactive media – support the development of computational thinking in young people. Over the past several years, we have developed a computational thinking framework that emerged from our studies of the activities of interactive media designers. Our context is Scratch – a programming environment that enables young people to create their own interactive stories, games, and simulations, and then share those creations in an online community with other young programmers from around the world. The first part of the paper describes the key dimensions of our computational thinking framework: computational concepts (the concepts designers engage with as they program, such as iteration, parallelism, etc.), computational practices (the practices designers develop as they engage with the concepts, such as debugging projects or remixing others' work), and computational perspectives (the perspectives designers form about the world around them and about themselves). The second part of the paper describes our evolving approach to assessing these dimensions, including project portfolio analysis, artifact-based interviews, and design scenarios. We end with a set of suggestions for assessing the learning that takes place when young people engage in programming.
Article
Scratch is a visual programming environment that is widely used by young people. We investigated if Scratch can be used to teach concepts of computer science (CS). We developed learning materials for middle-school students that were designed according to the constructionist philosophy of Scratch and evaluated them in a few schools during two years. Tests were constructed based upon a novel combination of the revised Bloom taxonomy and the Structure of the Observed Learning Scratch is a visual programming environment that is widely used by young people. We investigated if Scratch can be used to teach concepts of computer science (CS). We developed learning materials for middle-school students that were designed according to the constructionist philosophy of Scratch and evaluated them in a few schools during two years. Tests were constructed based upon a novel combination of the revised Bloom taxonomy and the Structure of the Observed Learning Outcome taxonomy. These instruments were augmented with qualitative tools, such as observations and interviews. The results showed that students could successfully learn important concepts of CS, although there were problems with some concepts such as repeated execution, variables, and concurrency. We believe that these problems can be overcome by modifications to the teaching process that we suggest. Outcome taxonomy. These instruments were augmented with qualitative tools, such as observations and interviews. The results showed that students could successfully learn important concepts of CS, although there were problems with some concepts such as repeated execution, variables, and concurrency. We believe that these problems can be overcome by modifications to the teaching process that we suggest.
Article
Computer science (CS) activities for young students are widely used, particularly visual programming environments. We investigated the use of the Scratch environment for teaching CS concepts to middle school students. In a previous article [Meerbaum-Salant et al. 2013], we reported on the extent to which the CS concepts were successfully learned. In this article, we look at the transition from studying CS with the visual Scratch environment in middle school to studying CS with a professional textual programming language (C# or Java) in secondary school. We found that the programming knowledge and experience of students who had learned Scratch greatly facilitated learning the more advanced material in secondary school: less time was needed to learn new topics, there were fewer learning difficulties, and they achieved higher cognitive levels of understanding of most concepts (although at the end of the teaching process, there were no significant differences in achievements compared to students who had not studied Scratch). Furthermore, there was increased enrollment in CS classes, and students were observed to display higher levels of motivation and self-efficacy. This research justifies teaching CS in general and visual programming in particular in middle schools.
Conference Paper
In learning to program, students must gain an understanding of how their program works. They need to make a connection between what they have written and what the program actually does. Otherwise, students have trouble figuring out what went wrong when things do not work. One factor that contributes to making this connection is an ability to visualize a program's state and how it changes when the program is executed. In this paper, we present Alice, a 3-D interactive animation environment. Alice provides a graphic visualization of a program's state in an animated small world and thereby supports the beginning programmer in learning to construct and debug programs.
Conference Paper
We introduce the Progression of Early Computational Thinking (PECT) Model, a framework for understanding and assessing computational thinking in the primary grades (Grades 1 to 6). The model synthesizes measurable evidence from student work with broader, more abstract coding design patterns, which are then mapped onto computational thinking concepts. We present the results of a pilot-test study of the PECT Model in order to demonstrate its potential efficacy in detecting both differences in computational thinking among students of various ages as well as any clear overall progressions in increasing computational sophistication. Results of this sort are vital for establishing research-based and age-appropriate curricula for students in the primary grades, i.e., developing non-trivial, challenging but not overly daunting lesson plans that utilize the cognitive development stage of each grade level most effectively.