Conference PaperPDF Available

User-Centered Design in Block-Based Programming: Developmental & Pedagogical Considerations for Children

Conference Paper

User-Centered Design in Block-Based Programming: Developmental & Pedagogical Considerations for Children

Abstract and Figures

In this paper, we present an analysis of 123 students' (aged 9-12) digital stories created in a visual block-based programming language across three grade levels (grades 4-6). These students were all involved in the same introductory computer science curriculum. Participating students attended the same school and received computer science instruction from the same teacher within the context of the academic day. We analyzed each project for the extent of user-centered design that the student programmed. Specifically, we identified two components of user-centered design: 1) the programmed control choices students used, and 2) if/how they communicated those mechanisms of control to the user. Our work indicates that students in fifth and sixth grade (aged 10-12) used higher diversity of event blocks and coordinated action across multiple sprites at a higher rate compared to fourth grade students (aged 9-10). In contrast, fourth grade students tended to create more simplistic programs, rarely coordinating actions across multiple sprites. This work suggests that the construct of user-centered design within visual block-based programming languages is more complex than previously indicated. Additionally, explicit instruction about user-centered design is necessary, but may be more effective when a student reaches the age of 10 or 11 years old. CCS Concepts • Human-centered computing~ User centered design • Human-centered computing~ Graphical user interfaces • Social and professional topics~ Computing education • Social and professional topics~ K-12 education
Content may be subject to copyright.
User-Centered Design in Block-Based Programming:
Developmental & Pedagogical Considerations for Children
Alexandria K. Hansen§, Ashley Iveland§, Cameron Carlin§, Danielle B. Harlow§, Diana Franklin
§Gevirtz Graduate School of Education Center for Elementary
UC Santa Barbara Mathematics and Science Education
Santa Barbara, CA 93106-9490 University of Chicago
{akillian, aockey, dharlow} 1427 E. 60th St.
@education.ucsb.edu Chicago, IL 60637
ccarlin@umail.ucsb.edu dmfranklin@uchicago.edu
ABSTRACT
In this paper, we present an analysis of 123 students’ (aged 9-12)
digital stories created in a visual block-based programming
language across three grade levels (grades 4-6). These students
were all involved in the same introductory computer science
curriculum. Participating students attended the same school and
received computer science instruction from the same teacher
within the context of the academic day. We analyzed each project
for the extent of user-centered design that the student
programmed. Specifically, we identified two components of user-
centered design: 1) the programmed control choices students used,
and 2) if/how they communicated those mechanisms of control to
the user. Our work indicates that students in fifth and sixth grade
(aged 10-12) used higher diversity of event blocks and
coordinated action across multiple sprites at a higher rate
compared to fourth grade students (aged 9-10). In contrast, fourth
grade students tended to create more simplistic programs, rarely
coordinating actions across multiple sprites. This work suggests
that the construct of user-centered design within visual block-
based programming languages is more complex than previously
indicated. Additionally, explicit instruction about user-centered
design is necessary, but may be more effective when a student
reaches the age of 10 or 11 years old.
CCS Concepts
Human-centered computing~ User centered design
Human-centered computing~ Graphical user interfaces
Social and professional topics~ Computing education
Social and professional topics~ K-12 education
Keywords
User-centered design; empathy; computer science education;
graphical programming; elementary school; K-6 education;
pedagogy
1. INTRODUCTION
Every year, more U.S. schools report integrating computer science
into their instruction. In 2015, more than 49,000 high school
students took the Advanced Placement computer science exama
25% increase from the previous year [1]. Educational initiatives
such as Hour of Code, coupled with an increase in novice-
friendly, graphical programming environments (e.g., Scratch,
Blockly, Alice, etc.), have provided more developmentally-
appropriate opportunities to expose younger children to computer
science. For example, over 4.5 million upper elementary school
students (aged 9-12) participated in the 2014 Hour of Code [2].
Additionally, President Obama’s recent initiative, Computer
Science for All, seeks to expose all students to computer science,
empowering the next generation of American students with the
computing skills necessary to thrive in a digital economy [3].
This recent push to expose younger students to computer science
is a promising approach to attract more individuals to the field of
computer science. Students’ career interests by 8th grade (age 13-
14) are largely predictive of later career choices [4]. It follows that
if students are not exposed to computer science by this age, they
are far less likely to consider a career in the field of computer
science in the future.
As computer science is integrated into more classrooms and
schools, research-based findings are needed to inform curriculum
design, interface development, and best teaching practices. In this
paper, we focus on the computer science skills, practices, and
perspectives that are useful for creating digital stories, a common
early project for students following constructionist-inspired [5]
curricula. We consider a digital story to be an animation, using
sprites that are programmed to interact; see [6] for a fuller
description.
In our previous work [7], we found that when making projects to
share with others, several of our young students (fourth grade;
aged 9-10) used complex interfaces without providing the user
any instructions for how to use their program. In fact, some
students’ stories used such a complex combination of key presses
and sprite clicks, that the presence of the student who created the
program was required to run the program correctly. Furthermore,
we realized that we (as curriculum designers) failed to provide
students with lessons that explicitly focused on user-centered
design within the context of programming.
This led to the identification of user-centered design as a crucial
learning goal and the subsequent design, and implementation of
curricular activities explicitly focused on helping the students
develop user-centered designs. User-centered design has informed
the development of many graphical programming environments to
ensure the interface is developmentally appropriate for a specific
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. IDC '16, June 21-24, 2016, Manchester, United
Kingdom © 2016 ACM. ISBN 978-1-4503-4313-8/16/06…$15.00
DOI: http://dx.doi.org/10.1145/2930674.2930699
age [8, 9, 10, 11]; however, scant research exists on how young
children integrate user-centered design within their own
programming. In the context of digital storytelling, one aspect of
user-centered design that we can expect young programmers to
use is including information for the user about how to interact
with the program. In the projects we analyzed and discuss below,
this often took the form of instructions typed onto the background
of the stage, such as “Press 1, 2, 3 to see each scene of the story,”
or “Use arrow keys to move the character.”
In this paper, we explore two aspects of user-centered design
within block-based programming, both of which are related to the
idea of providing instructions to the user: 1) the programmed
control choices students used, and 2) if/how they communicated
those mechanisms of control to the user. We present an analysis of
123 students’ digital stories after the completion of 12 hours of
our programming curriculum. Our sample included 39 fourth
grade students (aged 9-10), 45 fifth grade students (aged 10-11),
and 39 sixth grade students (aged 11-12). All 123 students
attended the same school and were taught computer science by the
same teacher. Analyzing across grade levels (while keeping the
classroom, teacher, school, and curriculum consistent) allowed for
potential findings in regards to development and computer-
science readiness across ages.
Our findings suggest that fourth graders (aged 9-10) differ from
fifth and sixth graders (aged 10-12) in ways that impact their
ability to incorporate user-centered design in visual block-based
programming. While it may prove beneficial to expose students
under the age of 10 to the idea of user-centered design, our work
suggests that students over the age of 10 are more capable of
coordinating and programming actions across multiple sprites—an
important aspect of designing interactive programs in block-based
languages.
In the following sections, we first present an overview of three
areas of literature related to user-centered design: the role of
empathy, how students’ frames may affect their ability to
incorporate user-centered design, and an overview of the
programming skills required. Then, we provide an explanation of
our research context and methods, including a description of how
we taught user-centered design within our curriculum. Finally, we
conclude with our analysis and findings, ending with suggestions
to others working with young children and interactive
programming in block-based environments.
2. RELATED WORK
Along with Papert [5], we take a constructionist stance towards
learning in our work. Papert posited that individuals learn best
when they are constructing an artifact for public consumption.
Here, the created artifact is a digital story. In computer
programming, creating (or programming) something for someone
else requires thinking about the end user. That is, the person
navigating the story.
User-centered design “is a broad term to describe design
processes in which end-users influence how a design takes shape
[12]. Following this, the role of the designer (in this case,
elementary school students learning to program) is to “make sure
that the user is able to make use of the product as intended with
minimum effort to learn how to use it[12]. This assumes that the
programmer (in our context, the programmer is also a student) is
creating something for someone else to use.
To create something for someone else to use, at least three things
must be true: 1) The child must be capable of taking on the
perspective of someone else, 2) The child must see the task as
being one in which they should take on the perspective of
someone else, and 3) The child must have the programming skills
to create a program that a user can interact with. The first criterion
is one of psychology, the second of task framing, and the third of
computer science education. All are discussed below with relevant
literature.
2.1 Empathy: Taking on another perspective
One area of research that speaks to students’ use of user-centered
design is around empathy [13]. Empathy is considered a skill that
can support user-centered design [14]. Of the many types of
empathy, cognitive empathydescribed as “intellectually taking
the role or perspective of another person”best aligns with the
goals of developers in computer science [15]. Integrating
cognitive empathy as a pedagogical tool may support children’s
use of user-centered design while learning to program.
However, a young child’s use of cognitive empathy is contingent
upon the fact that the child can experience empathy. Specifically,
the child’s use of cognitive empathy depends “upon role-taking
skills and the ability to assume the perspective of another
individual” [13]. Research in psychology has investigated when
children are able to take on another’s perspective.
Piaget [16] posited that children under the age of 6 or 7 often
behave egocentrically, tending to focus on their own perspective
and ignoring those of others [17]. Following Piaget’s proposed
model of development, it is not until a child reaches 11 or 12
years of age that she or he can better take on the perspective of
another individual. However, Piaget’s model of development has
received criticisms, with many scholars seeking to test his
working theories.
While scholars have noted that empathy is different in adults
compared to children [18], studies have demonstrated that
children as young as 3 years old are able empathize with the
perspectives of others [19, 20]. Additionally, in a meta-analysis of
studies that investigated empathy training, it was found that “age
does not moderate the effect of empathy training” [21]; in other
words, young children can be supported in their development of
empathy through purposeful exposure and training.
A variety of empathy training and intervention programs have
been used with individuals of all ages [21]. Common empathy
training techniques include: 1) Situational story-telling (e.g., role-
playing, storyboards, scenarios), 2) Engaging in direct contact
with the population one is seeking to develop empathy for, and
when direct contact is not practical, 3) Using data (e.g., photos,
videos, stories) to learn about a target population [21].
2.2 Framing a computing task
Another potential factor that may limit a child’s ability to
incorporate empathy and user-centered design is their frame. A
frame refers to “a set of expectations an individual has about the
situation in which she finds herself that affects what she notices
and how she thinks to act” [22]. Framing is a reflection of an
individual’s internal state of mind: how one views a particular
situation will impact how one behaves in that situation. Often, the
term “framing” is applied to an epistemological perspective how
one views knowledge and learning. For example, a child who
believes that knowledge is something passively transmitted from
instructor to student might not actively engage with the material in
a course, failing to question and make sense of new material so
that it accurately assimilates into their pre-existing cognitive
schemes [16]. Instead, that child might sit quietly, copy down
words verbatim, and refrain from asking questions.
In the context of computer science education, children are often
(usually implicitly) asked to switch between frames: specifically
the frames of a learner, user, and developer. For example, in pre-
structured coding activities (e.g., Hour of Code), children may
think of themselves as computer users playing a game. They are
presented with characters, tasks to accomplish, and sounds and
animations that make the experience feel game-like. However,
this may cause young children to view their experience only as a
game, failing to recognize that they are actually behaving as
learners simultaneously. This approach to learning is often
referred to as “gamification,” which is defined as “the use of game
design elements in non-game contexts” [23].
While gamification may elicit increased engagement or
excitement around a task, it may also conflate students’ frames.
For example, our curriculum begins with pre-structured coding
activities, but eventually transitions students from the frame of
learner and game-player/computer-user to the frame of developer
by asking them to program an open-ended digital story. If children
are still operating under the frame of game-player or computer-
user, the more open-ended nature of programming (which we see
as being closer to the actual actions of computer scientists
working in the field) may prove difficult. In our experience, some
students do not make this transition effectively or naturally.
Transitioning from playing games to programming games for
somebody else to play is a cognitively demanding jump, and is
often not taught to students explicitly. This may impact students’
abilities to incorporate user-centered design because, if a child is
still operating under a game-player or computer-user frame,
providing accessible interactions to another user may seem
unnecessary.
2.3 Programming skills
Another component that impacts a children’s ability to engage in
user-centered design is their skill level in programming. Even if a
child can cognitively take on the perspective of another user, if
she does not have the programming skills to create interactive
experiences, she will not be able to use her empathetic abilities.
This leads to questions around the area of assessment in block-
based programming, and what skills are necessary and in what
sequential order they should be developed.
Kafai, Ching and Marshall [24] investigated the educational
benefits afforded when children were tasked with designing
interactive, multimedia projects. Specifically, they described a
multimedia project as including a “title page, navigation aids,
interactivity, and instructive aspects like a quiz,” which shares
similarities to our conceptualization of interactive media using
user-centered design. To investigate this, researchers tasked 26
fifth and sixth grade students (aged 10-12) with programming a
multimedia project to convey a scientific concept using Logo.
Students worked in groups for this activity, so a total of 7 final
projects were collected for analysis. It was found that student
understanding of both programming and science concepts
improved, as measured by pre- and post-assessments.
Additionally, projects were analyzed for science content,
animations, informational/navigational screens provided to the
user, and interactive quiz questions. Results indicated that the
students incorporated scientific content at a higher rate than
animations and navigational clues about their completed program.
Authors discussed that providing informational/navigational
screens has value in terms of technological fluency, but students
had a difficult time incorporating content and organization
cohesively within programs, despite this being an explicit
requirement. This work further supports the need to identify
pedagogical strategies for effectively teaching children how to
incorporate interactivity for users while programming.
Brennan and Resnick’s investigation [25] of assessing interactive
media within Scratch-based projects provided a useful framework
for thinking about programming skills. Their proposed framework
includes three key dimensions: 1) Computational concepts, 2)
Computational practices, and 3) Computational perspectives.
Computational concepts link to specific skills within block-based
programming (sequencing, loops, events, parallelism,
conditionals, operators, and data). Computational practices
include practices such as abstracting, debugging, and remixing
code. Of particular interest to our work is the idea of
computational perspectives, described as “perspectives designers
form about the world around them and about themselves” [24].
While the computational perspectives discussed were limited to
expressing, connecting, and questioning, we contend that taking
on another’s perspective might also qualify. Additionally, a
child’s ability to transfer between frames (game-player/computer-
user, learner, and developer) may also connect to computational
perspectives and the ability to create interactive projects.
Other work has claimed to investigate user-interaction within
Scratch-based projects [26]. When investigating 536 Scratch
projects created by youth aged 8-18 in an afterschool center,
Brennan and Resnick found that just over 40% of youth included
some level of interaction (defined by the use of keyboard or
mouse input) [25]. However, the paper did not report on if and/or
how the youth made the keyboard or mouse input known to an
outside user, and if there was a difference across participants’
ages.
2.4 Proposed Model of User-Centered Design
Combining our earlier empirical work and reading of the
literature, we suggest that the construct of user-centered design in
block-based programming is a complex idea. Figure 1 represents
our understanding of user-centered design, as it relates to smaller
sub-constructs. Black arrows indicate pathways that we
investigated in this paper, while gray arrows indicate pathways for
future research.
Figure 1. Proposed model for the construct of user-
centered design.
As shown in Figure 1, successful user-centered design by students
in block-based programming is dependent upon many factors:
specifically, the ability to empathize, computer programming
skills, and the students’ frame.
We posit that both students’ ability to empathize and their
computer programming skills are influenced by their age. As
discussed earlier, empathy is developed early in childhood, but
continues to develop, as children grow older and even into
adulthood. Unlike empathy, programming skills do not increase
merely as a result of getting older. However, children do learn to
think more logically and develop computational thinking skills as
they get older, which likely results in faster and more
sophisticated uptake of computer programming instruction. Also,
as children get older, it is more likely that they have had prior
computer experiences that contributed to what they were learning
through our instruction.
Additionally, we contend that curriculum (in our case, task design
and the programming interface) directly impact students’ framing.
For example, if the task instructions state, “Move the bear to get
the honey,” a student may interpret that under a game-playing
frame; in contrast, if the task instructions state, “Program the bear
sprite so that it moves to the honey sprite,” a student may be more
likely to interpret that under the frame of a programmer or
developer. The model shown in Figure 1 frames and guides our
research.
3. RESEARCH CONTEXT
This research was part of a larger NSF-funded project which has
two primary goals: 1) to design a curriculum to teach basic
programming and computational thinking to 4th-6th grade students
(aged 9-12), and 2) to develop and test a learning progression for
computational thinking at the upper elementary school level.
Here, we focus on the concepts necessary to program a digital
story: specifically, the concept of user-centered design.
3.1 The Programming Environment
All on-computer lessons were completed in our programming
environmentLaPlaya, a modified version of Scratch [8]. Like
Scratch, LaPlaya is a graphical programming environment that
allows novices to engage in programming without worrying about
the syntax complexity required by more traditional computing
languages, such as Java or C++. In graphical programming, users
drag and drop commands (called blocks) to form longer lines of
commands (called scripts). Scripts are created for characters or
objects (called sprites). For more information about our
modifications to Scratch, see [9].
3.2 The Curriculum
Our curriculum consists of two modules: 1) Digital storytelling,
and 2) Game design. Each module consists of three types of
activities: 1) On-computer activities with small tasks that
gradually increase in complexity, 2) Off-computer activities that
provide opportunities to connect learned computing concepts to
everyday life (modeled after CS Unplugged [27]), and 3)
Engineering design lessons that teach the engineering design
process, emphasizing the iterative nature of programming. Each
12-hour curricular module culminates in a final, open-ended
programming exercisea digital story or a game, designed and
programmed entirely by the student. Here, we only report on
findings from the digital storytelling module.
3.2.1 User-Centered Design
During the 2013-2014 school year, we piloted the digital
storytelling module in fifteen 4th-6th-grade classrooms at five
schools. However, as our initial work [7] indicated, we did not
include explicit lessons to teach students about user-centered
design. As a result, many students did not incorporate user-
centered design within their final digital stories, in retrospect an
unsurprising finding. This finding led to the creation of an explicit
lesson about user-centered design that was piloted in the 2014-
2015 school year.
The revised curriculum for the 2014-2015 school year included
lessons targeting the following concepts, in order: sequencing,
breaking down actions, event-driven programming, user-centered
design, initialization, costume changes, and scene changes. Table
1 shows the differences in targeted concepts between the 2013-14
and 2014-15 academic years.
In the user-centered design lesson, students completed three small
tasks. First, students were asked to find hidden scripts in a
completed program. In the program, there were scripts associated
with multiple sprites, some of which were visible to the user (e.g.,
initialization scripts) and some which were hidden (e.g., actions of
sprites controlled by key clicks). This task was designed to teach
students that some elements of a program can (and sometimes
should) be hidden from a user to simplify the experience. Second,
students were introduced to the term user interface. They were
presented with a poorly designed user interface for a program
created in the same programming environment (LaPlaya) and
asked to figure out how the program functioned. The program
played a digital version of the classic “tortoise and the hare” story.
Activating the sprites required the user to hit letter keys that were
not obvious. Only by trial and error could the students figure out
how to make the program run. By providing students with a
poorly designed interface, we hoped to encourage discussion
about how to create better user interfaces. In particular, we hoped
to convey to students that 1) Interfaces are not always developed
in a user-centered manner, and 2) It is the job of the developer to
design and program a user-interface that allows the user to interact
with relative ease. Classroom teachers also facilitated a discussion
around this topic, providing an opportunity for students to reflect
on the experience, alleviating possible dissonance. Finally, for the
third task, students were asked to redesign the user-interface so
that it was more accessible to a new user.
4. RESEARCH METHODS
The development of our programming environment, curriculum,
and research were informed by design-based research [28]. A
design-based research methodology is a systematic and flexible
approach that allows for collaboration between researchers and
practitioners within real-world settings with the aim of improving
educational practice [29]. In our case, this refers to the
collaboration between educational researchers, computer
scientists, and teachers who were using our curriculum and
programming environment in schools.
This collaboration often resulted in observations about what was
and was not working in classrooms with students. Due to the
flexible nature of this research methodology, changes were made
to the curriculum and/or programming environment to improve
the experiences of participating students as more was learned
about student learning. For example, as shown in Table 1, the
concept of message broadcasting was removed from the first
digital storytelling module because it proved too complex for
fourth grade students (aged 9-10). At the recommendation of
computer scientists, educational researchers, and teachers, these
concepts were moved to module 2game design (designed for
students aged 10-11 who had already completed module 1).
Additionally, the concept of breaking down actions (e.g.,
recognizing that turning and moving required two separate
commands) was added in module 1 to supplement the concept of
sequencing as we noticed that some students needed more support
in this area.
4.1 Data Collection
In the 2014-2015 school year, we tested our digital storytelling
module and programming environment with over 1,500 students
(aged 9-12) at 10 schools. The schools had varying numbers of
classrooms, grades participating, and start dates. In line with
design-based research, each implementation of the curriculum
resulted in changes, so classrooms also used varying versions of
the curriculum. Participating schools ranged from 4%-100% of
students qualifying for free or reduced lunch (a proxy for
socioeconomic status), and 2%-82% designated English language
learners. Schools generally had equal numbers of female and male
students.
In some schools, the designated computer or technology teacher
led lessons during computer lab time. In other schools, the general
education teacher led lessons; in these cases either in the school’s
computer lab or on laptops within the normal classroom. Often,
the participating general education teachers did not have any
background or experience with computer programming.
Participating schools ranged in distance from the research
university. Schools within 50 miles of the university were
considered local schools, and received more targeted support from
researchers. Schools farther than 50 miles from the university
were considered distant schools, and used the curriculum and
programming environment without active help from researchers.
In local schools, graduate student researchers (GSRs) attended
each classroom meeting and recorded detailed field notes about
student learning. GSRs sometimes assisted in teaching lessons or
reviewing content, depending upon the comfort level of the
teacher. Additionally, GSRs collected video recordings of each
class meeting, audio recordings of students asking questions, and
interviews with teachers and students. Final student projects were
also collected, as well as automated snapshots of student projects
to show the development process over time [30]. After each class
period, GSRs wrote analytical memos [31] that were shared with
the research group. Analytical memos served as the anchor for
discussion during weekly, group research meetings. In distant
schools, only student work was collected.
4.2 Data Analysis
For the purposes of this paper, only student work from one local
school was analyzed. At this school, the designated computer
teacher taught all lessons within the digital storytelling module to
each grade level (grades 4-6; ages 9-12). While module 1 is
designed for fourth grade and module 2 for fifth grade, these
students had no prior experience with our curriculum at any grade
level. Since this was the first year for the school to participate, all
grade levels completed the same introductory module, creating an
unintended but interesting data set that was useful for looking at
differences across age. Each lesson occurred within the school’s
computer lab. This school was selected because the school,
classroom, curriculum and teacher remained consistent for the
duration of the academic year. The only change from classroom to
classroom was the age, grade, and meeting time of the
participating students. Analyzing across grade levels (while
keeping the classroom, teacher, curriculum and school consistent)
allowed for potential findings in regards to development and
computer-science readiness across ages.
We analyzed 123 students’ digital stories that were designed and
programmed after completing 12 hours of the digital storytelling
module. Table 2 shows the number of students per grade level that
were included in the sample.
Similar to our previous work [7], we focused our analysis of the
digital stories on two sub-constructs to user-centered design: 1)
the programmed control choices (or event blocks) students used,
and 2) if/how they communicated those mechanisms of control to
the user. These two sub-constructs were intertwined in student
work and were sometimes difficult to tease apart. Often, the
sophistication of programming used by students impacted their
ability to create interactive digital stories that incorporated user-
centered design.
The first sub-construct identified as essential to interactive design
was the programmed control choices. After inspecting student
work, we identified three categories for type of control: user-
controlled, programmer controlled, and default control (see Table
3).
We defined user controlled to mean that the student included a
mechanism for a user to control some aspect of the digital story
(e.g., clicking on sprites or pressing keys), and they provided
appropriate instruction for doing so. Figure 2a shows an example
of a digital story that we classified as user controlled. In this
digital story, the student informed the user of how to interact with
the program (“Press the arrow to go on”). In this case, the arrow is
a sprite programmed by the student, which triggers a scene
change. As shown in Figure 2b, once the arrow is clicked, a
soccer goal appears, and the user is then directed to click the
soccer ball to shoot.
Figure 3. Programmed scripts for the soccer ball
Our goal was to categorize programs by those that used user-
centered design (providing instructions to the user) and those that
required the programmer to control events (no instructions and no
obvious interface for interaction). Programs with clear instructions
were categorized as user controlled, while projects that included
many different events without instructions and required the
presence of the student who developed the program were
classified as programmer controlled. There is a third option,
though, that does not fall into the aforementioned categories
because of conventions within Scratch programs. Scratch
programs have an implied beginning event: press the green flag. If
a project used only that event, a student may have specifically
chosen that event because the user would know to press it.
Therefore, we cannot distinguish between not informing the user
(programmer controlled) and intentionally choosing an event the
user knew (user controlled). We place these into a third category
called default control. Table 3 shows all three possible
classifications for level of control in our analysis.
The second sub-construct to user-centered design we looked at
was the diversity of event blocks and the programmed
coordination of events. After reviewing the completed digital
stories, we identified five different event blocks used by students:
1) Green flag, 2) Key pressed or Sprite clicked, 3) When other
sprite clicked, 4) Coordinated actions through the use of timing
with wait blocks, and 5) Coordinated message broadcasting.
Projects that contained fewer than three total blocks were
classified as Simple, regardless of the event blocks used. Table 4
shows the coding scheme for diversity of event blocks, with
sample blocks provided.
Returning to the soccer example shown in Figures 2a and 2b, this
student programmed user interaction using the When Sprite
Clicked block to program both the scene change and the
movement of the soccer ball. Figure 3 shows the programmed
scripts for the soccer ball. In alignment with our coding scheme,
this student’s project was categorized as user controlled for the
type of control, and When Sprite Clicked for diversity of event
blocks. Overall, we consider this project user-centered because of
the instructions provided.
In the event that a student used multiple mechanisms of control
within the programmed story, we classified the program based on
which method of control we hypothesized as more sophisticated
(see Table 4). For example, if a student coordinated actions across
multiple sprites through the use of message broadcasting and also
used When Key Pressed, we categorized the project as
Coordinated message broadcasting.
5. FINDINGS
Below we report our findings in two areas. First, we present
findings on whether the program was interactive or not and
whether someone else could control the program. Next, we
discuss the sophistication of programming commands used to
coordinate the control (events) of the program. This includes the
diversity of event blocks used and mechanisms for coordination
among sprites. In both cases, we compare the construct to grade
level (an approximation for age).
5.1 Type of Control
Our analysis suggests that students can apply user-centered design
when it is explicitly taught, and that this is influenced by a child’s
Table 4. Categories for Diversity of Event Blocks
Figure 4. Type of control across grade levels
age. Below, we first discuss the evidence that suggests that
students can apply user-centered design when it is explicitly
taught, followed by our analysis by age level.
Finding 1: 4th graders used more user-centered design with the
modified curriculum than during the previous year.
The data that was used to support the claim that students can
apply user-centered design is the data from the fourth grade
students only in our 4th-6th grade sample from 2014-2015. These
data were compared to our earlier findings (using data from 2013-
2014), which also only focused on fourth graders.
The students who participated in the 2014-2015 curriculum
completed a lesson explicitly focused on user-centered design and
34% of those fourth grade students created a program that could
be successfully controlled by a user in their final project, as shown
in Figure 4. Compare this to our previous work [7], when we
analyzed 92 digital stories completed by fourth grade students
who participated in the 2013-2014 curriculum that did not include
an explicit lesson about user-centered design. Under these earlier
conditions, only 1% of fourth grade students created a project that
informed the user of how to interact with the program and
provided a clear mechanism for doing so.
Finding 2: Take up of user-centered design differed by age.
To understand the influence of age, we returned to looking at the
full data set (all three grade levels) from the 2014-2015 school
year. While only 32% of fifth grade students incorporated user
interaction (compared to 34% of fourth grade students), the
highest percentage of user interaction was observed among the
sixth grade students, with 44% of sixth grade students
programming in this manner. While the difference between fourth
and fifth grade was small, there was a larger increase in the
amount of sixth grade students who incorporated user interaction
while programming. Recall that all of the students in our sample
engaged in the same computer science curriculum taught by the
same teacher, so we do not attribute this difference in whether
students successfully created user controlled programs to the
curriculum or teacher, but rather to age or prior experiences.
When considering projects that were programmer controlled (i.e.,
not easily accessible to an outside user), there were similar
percentages observed across grade levels (39%, 37%, and 41% for
fourth, fifth, and sixth grade, respectively).
However, we did observe a qualitative difference across grade
levels when considering the default control mechanism green
flag. Fourth (29%) and fifth (31%) grade students used the default
control at a higher rate than sixth grade students (15%). Sixth
grade students rarely used only one event in their projects,
creating programs that were more complex.
A one-way analysis of variance (ANOVA) on SPSS was
conducted to compare the differences in programmed user
interaction across grade levels (4th, 5th, and 6th). While no
statistically significant differences were found, there were
noticeable differences between the groups, as discussed above.
This analysis should be repeated using a larger sample of students
to follow-up on the qualitative differences observed between ages.
Additionally, because we were unable to determine the intentions
of students programming under the default control, the data was
limited. Follow-up interviews conducted with all student
participants might have alleviated this issue, but we were limited
in time and scope.
5.2 Sophistication of Programming
Our second analysis focused on the sophistication of
programming, and is presented in two main categories: diversity
of event blocks, and the coordination of events within programs.
Finding 3: 4th grade students significantly differed from 6th
grade students in the diversity of event blocks used.
Figure 5 shows students’ diversity of event blocks across grade
levels. The possible categories for diversity of event blocks are
shown in Table 4 through the use of example blocks. While the
diversity of event blocks is a categorical variable (and not usually
represented in a line graph), we chose to present the data in this
manner to aid in visual identification of patterns across grade
levels. There is a loose relationship between moving to the right
and increasing sophistication of the control structure, although we
cannot definitively say that it is monotonically increasing. For
example, projects classified as Simple were less complex than
those classified as Green Flag, which were less complex than
those classified as Keys pressed/Sprite clicked. However, it is not
clear whether Timing is more or less sophisticated than When
other sprite clicked. So, while we recognize that the line graph
implies more order than perhaps exists, we also find it very useful
to be able to interpret, in general, what level of sophistication
different age groups were using.
Figure 5. Diversity of event blocks across grade levels
While the markers in Figure 5 contain pertinent information (and
the connections between markers do not), the line representation
makes it easier to visually interpret the differences. Looking at the
graph, we notice that for the categories farthest to the left (Simple,
Green Flag), the marker for the fourth grade students is highest;
in the middle of the graph (Key pressed/Sprite clicked and Timing)
fifth grade students are the highest, and on the right (Other sprite
and Message broadcasting), the marker for the sixth grade
students is highest. This suggests interesting differences among
the three grade levels.
When considering the diversity of event blocks, 35% of fourth
grade students either had Simple programs (containing less than 3
total blocks), or used only the Green Flag (default mechanism) to
control the program with no additional events programmed. Fifth
and sixth grade students were different in this regard, with both
grade levels having a considerably smaller percentage of what we
identified as Simple programs, most of which used independent
events as opposed to coordinated events (see Table 5). For
example, in fifth grade, only 4% had Simple programs and 9%
used only the Green Flag; similar percentages were observed in
sixth grade students. Following this, 85% of fifth and sixth grade
students used events more sophisticated and coordinated than
Green Flag, compared to only 63% of fourth grade students.
Additionally, 15% of sixth grade student students used Message
broadcasting through broadcast and receive blocks, despite the
fact that our curriculum did not explicitly teach this concept.
A one-way analysis of variance (ANOVA) on SPSS was
conducted to compare the diversity of event blocks used by each
grade level (4th, 5th, and 6th). Estimation of histograms of the
diversity of event blocks indicated the distribution was
approximately normal for each individual grade level. The overall
F for the one-way ANOVA was statistically significant, F(2,120)
= 5.207, p < .05 (See Table 6). Thus, we conclude that there are
significant differences among diversity of event blocks used
between at least two grade levels. When conducting post-hoc tests
to identify the differences between grade levels, it was found that
sixth grade was significantly different than fourth grade (see
Table 7). However, no statistically significant differences were
found between fifth grade and either fourth or sixth grade.
Table 6. ANOVA results for Diversity of Event Blocks
Table 7. Tukey HSD Post-Hoc Test
Finding 4: 4th grade students used simpler control choices than
5th and 6th grade students, coordinating actions across multiple
sprites at a lower rate.
Another way to categorize the sophistication of programming is
the coordination of events within programs (see Table 5). The
first three categories (Simple, Green Flag, and Key pressed/Sprite
clicked) represent a model in which all sprites are programmed
independently and have no programmed relationship to one
another (see Table 5). Programs that included Timing to
coordinate sprites represent a guess-and-check model, in which
students attempted to coordinate actions across sprites, but did so
in a less sophisticated manner than actually programming
coordination; these students often would run their programs after
adding each additional block to ensure the actions of independent
sprites appeared seemingly coordinated. In contrast, the last two
categories (Other sprite, and Message broadcasting) represent a
model in which there is planned, programmed coordination across
sprites.
While this result was not statistically significant, we noticed that
nearly 80% of fourth grade students programmed their digital
story using only independent events (categorized as Simple, Green
Flag, and Key pressed/Sprite clicked). An additional 10% of
fourth grade students used Timing, indicating they recognized that
the actions of sprites should be coordinated, but did not do so
through more sophisticated programming. The final 10% of fourth
graders coordinated events across sprites through the use When
other sprite clicked, which involves an event in one sprite
triggering an event in a different sprite. This indicates that only
20% of all fourth grade students used a mechanism that involved
coordination across more than one sprite (either through Timing,
or through programming using When other sprite clicked).
The results are quite different in fifth and sixth grade student
projects. Roughly 45% of fifth grade students and 48% of sixth
grade students used mechanisms that involved coordination across
more than one sprite. While fifth grade programs were more
heavily biased towards seeming coordination through Timing
(33%), only 18% of sixth grade students programmed in this same
manner. Finally, sixth grade students showed the highest
understanding of event coordination, indicated by 15% of these
students using Message broadcasting through broadcast and
receive (compared to 0% in both fourth and fifth grade).
6. DISCUSSION
This work indicates that the construct of user-centered design,
specifically within block-based programming environments, is
complex. User-centered design is a multidimensional construct
that is dependent upon developmental psychology, framing, and
programming skills.
Our analysis suggests that students can apply the construct of
user-centered design if it is explicitly taught, but this may be
somewhat dependent upon the age of a student. In our analysis,
fourth grade students (aged 9-10) differed in their programming
skills and ability to include user-interaction, whereas fifth and
sixth grade students (aged 10-11, and 11-12, respectively) were
more successful in this regard, even though these students
participated in the same computer science curriculum and were
taught by the same teacher. While individual students may have
had prior programming experience, the students did not have prior
computer science instruction in school. While it is not surprising
that uptake and use of user-centered design after instruction is
influenced by age, this study allows us to identify a potential ideal
age range for introducing this concept. Based on these results, we
suggest that while it may be beneficial to expose younger students
to the construct of user-centered design, we recommend waiting
until fifth grade (ages 10-11) to include this concept explicitly in
computer science curriculum. However, this recommendation is
based on one population of students. Additional studies with other
demographics and increased participants should be conducted.
One potential area for future research is found in Scratch. The
current Scratch [8] programming environment includes two text
boxes for programmers titled: 1) Instructions, and 2) Notes and
Credits. Scratch advises informing the user of how to interact with
the program (through key presses, sprite clicks, etc.) in the
instructions text box, and advises informing the user of additional
information (e.g., about who the programmer is) in the notes text
box. The inclusion of a text box that prompts students to provide
instructions for an outside user may remind programmers
(children) to think about the user, and could provide a potential
publically available source of data. Investigating how students are
using these text boxes would contribute to our understanding of
how children create interactive programs. Are instructions
accessible, pertinent, and clear? Do the instructions accurately
convey to an outside user what is important to know about
interacting with the program?
Here, we focused on only one aspect of programming: considering
a user and creating a program that can be run by a user, however
our work has broader implications. It suggests that what
constitutes “introductory programming” may differ considerably
between grade levels, even grade levels that are only one year
apart. This is consistent with our earlier work that found that some
aspects of programming environments that are usable by sixth
graders are not useable by fifth graders because of the timing of
math content knowledge curriculum (e.g., coordinate plane
systems, decimals and percentages); see [9]. For example, we note
that fourth graders made fewer attempts to coordinate actions
between sprites. That is they did not use When other sprite clicked
or Timing at the same rate as fifth or sixth grade students. It is
possible that many fourth graders are not yet ready to think about
programming multiple sprites within the same program, leading to
additional areas of research.
We believe that this paper adds to the literature by identifying the
complexities involved in the practice of user-centered design and
proving an initial model of the construct that is useful for
designing appropriate curriculum and instruction for children.
7. SELECTION AND PARTICIPATION OF
CHILDREN
Children were selected based on their school’s agreement to
participate in our curriculum. After a school agreed to participate,
classroom teachers sent home consent forms to each child’s
family. The consent form informed families about the research
project, explaining that we were interested in better understanding
how young children learn computer programming by observing
students using our curriculum. The consent form allowed
parents/guardians to: 1) Opt-out of all data collection, or 2) Select
which types of data we were allowed to collect from their student;
specifically, written and drawn student work, computer work, and
video collection of classroom meetings. In the event that a child’s
family opted out of participating in the research, the child still
participated in the curriculum as the lessons were conducted
during normal school hours, as part of the school day. However,
none of these students were included in the collected video, nor
was their work analyzed for research purposes.
8. ACKNOWLEDGMENTS
Our thanks to the participating students, teachers, and schools
involved in this work. This work is supported by the National
Science Foundation CE21 Award CNS-1240985.
9. REFERENCES
[1] Le, P. (2015). Growing push to expose more students to
computer science. Accessible via The Big Story.
[2] Alvarado, C. (2014). CS Ed Week 2013: The hour of code.
ACM SIGCSE Bull, 46,1, 2-4.
[3] Smith, M. (January, 2016). Computer science for all.
Retrieved from
https://www.whitehouse.gov/blog/2016/01/30/computer-
science-all.
[4] Tai, R.H. (2006). Planning early for career choice. Life
Science, 1, 0-2.
[5] Papert, S. & Harel, I. (1991). Situating constructionsim.
Constructionism, 36, 1-11.
[6] Hansen, A.K., Iveland, A., Dwyer, H. Franklin, D. &
Harlow, D. (2015). Programming science digital stories:
Computer science and engineering design in the science
classroom. Science and Children, 53 (3), 60-64.
[7] Hansen, A.K., Dwyer, H. A., Hill, C., Iveland, A., Martinez,
T., Harlow, D., Franklin, D. (2015). Interactive design by
children: A construct map for programming. In IDC ’15.
ACM.
[8] Resnick, M., Maloney, J., Monroy-Hernandez, A., Rusk, N.,
Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E.,
Silver, J., Silverman, B., Kafai, Y. (2009). Scratch:
Programming for all. Commun ACM, 52, 11, 60-67.
[9] Hill, C., Dwyer, H. A., Martinez, T., Harlow, D., & Franklin,
D. (2015). Floors and flexibility: Designing a programming
environment for 4th 6th grade classrooms. SIGCSE ’15.
ACM. !
[10] Flannery, L. P., Silverman, B., Kazakoff, E. R., Bers, M. U.,
Bontá, P, & Resnick, M. (2013). Designing ScratchJr:
Support for early childhood learning through computer
programming. In IDC ’13. ACM.
[11] Cooper, S. (2010). The design of Alice. ACM T Computing
Education, 10, 4, 15.
[12] Abras, C., Maloney-Krichmar, D., Preece, J. (2004). User-
centered design. In Brainbridge, W. Encyclopedia of Human-
Computer Interaction. Thousand Oaks: Sage Publications.
[13] Feshbach, N.D. (1978). Studies of empathic behaviors in
children. Progress in Experimental Personality Research.
[14] Kouprie, M. & Visser, F.S. (2009). A framework for
empathy in design: Stepping into and out of the user’s life.
Journal of Engineering Design, 20, 5, 437-448.
[15] Mead, G.H. (1934). Mind, self and society. Chicago, IL:
University of Chicago Press.
[16] Piaget, J. (1976). Piaget’s theory. Springer Berlin
Heidelberg.
[17] Siegler, R. & Alibali, M.W. (2005). Children’s thinking.
Pearson Prentice Hall, New Jersey.
[18] Gladstein, G.A. (1983). Understanding empathy: Integrating
counseling, developmental, and social psychology
perspectives. Journal of Counseling Psychology, 30(4), 467.
[19] Borke, H. (1975). Piaget’s mountains revisited: Changes in
the egocentric landscape. Developmental Psychology, 11(2),
240.
[20] Wilson, B. J., & Cantor, J. (1985). Developmental
differences in empathy with a television protagonist's fear.
Journal of Experimental Child Psychology, 39(2), 284-299.
[21] Butters, R.P. (2010). A meta-analysis of empathy training
programs for client populations. Dissertation submitted to
The University of Utah.
[22] Hammer, D., Elby, A., Scherr, R.E., Redish, E.F. (2004).
Resources, framing, and transfer. In J. Mestre (Ed), Transfer
of Learning: Research and Perspectives. Greenwich, CT:
Information Age Publishing.
[23] Deterding, S., Dixon, D., Khaled, R., & Nacke, L. (2011).
From game design elements to gamefulness: Defining
gamification. In Proceedings of the 15th International
Academic MindTrek Conference: Envisioning Future Media
Environments (pp. 9-15). ACM.
[24] Kafai, Y. B., Ching, C. C., & Marshall, S. (1997). Children
as designers of educational multimedia software. Computers
& Education, 29(2), 117-126.
[25] Brennan, K., & Resnick, M. (2012). New frameworks for
studying and assessing the development of computational
thinking. In Proceedings of the 2012 annual meeting of the
American Educational Research Association, Vancouver,
Canada.
[26] Maloney, J. H., Peppler, K., Kafai, Y., Resnick, M., & Rusk,
N. (2008). Programming by choice: Urban youth learning
programming with scratch. ACM SIGCSE Bulletin, 40(1),
367-371.
[27] Bell, T., Alexander, J., Freeman, I., & Grimley, M. (2009).
Computer science unplugged: School students doing real
computing without computers. The New Zealand Journal of
Applied Computing and Information Technology, 13(1), 20-
29.
[28] Barab, S., & Squire, K. (2004). Design-based research:
Putting a stake in the ground. Journal of the Learning
Sciences, 13(1), 1-14.
[29] Wang, F., & Hannafin, M. J. (2005). Design-based research
and technology-enhanced learning environments.
Educational Tech Research and Development, 53(4), 5-23.
[30] Bryce B., Hill, C., Len, M., Dreschler, G., Franklin, D.,
Conrad, P. (2013). Hairball: Lint-inspired static analysis of
scratch projects. In SICSCE ’13. ACM.
[31] Saldaña, J. (2009). The Coding Manual for Qualitative
Researchers. Thousand Oaks, CA: Sage Publications.
... Pre-college, however, is vague -do high school students merely need to be exposed to CS, or should exposure come earlier? Research shows that students as young 13 and 14 already have predictive inclinations to which career they will have, implying the importance of exposure to computer science before then [37]; clearly, to reach students early enough to make a difference, action is needed in the entire K-12 space. ...
... One of the areas to specifically design for is age, as K-12 is a broad range of students. For example, research shows the difference of capabilities within 4th, 5th, and 6th grade computer science classes and why it is important to target different concepts at these different grade levels [37,74]. In addition, young adults have their own reasons for liking or disliking computer science, and should be taught in a way to tailor to their preferences [32]. ...
... and Bootstrap [3,6]. There are many techniques being used to try to engage and teach young students better -groups have tried block-based coding, online modules, and more [28,37,62,32,64]. Within the context of K-12 curriculum, we specifically want to look at fostering creativity through course material, as this seems like a promising way to engage young students. ...
Article
Computer Science is an increasingly important topic in K-12 education. Ever since the "computing crisis" of the early 2000s, where enrollment in CS dropped by over half in a five year span, increasing research has gone into improving and broadening enrollment in CS courses. Research shows the importance of introducing CS at a young age and the need for more exposure for younger children and young adults alike in order to work towards equity in the field. While there are many reasons for disinterest in CS courses, studies found one reason young adults do not want to study CS is a perception of it being tedious and lacking opportunities for creativity. Making more creative assignments is one way to try and engage more students who may not feel like stereotypical computer scientists. This thesis focuses in on the effects of creative choice in CS curriculum on students' self-efficacy, engagement/preferences, and performance. It aims to capture the effects of creative choice on a range of K-12 students of varying demographics in order to make CS more accessible for everyone. The first half of the thesis experimentally validates the effects of creative choice in existing 5th grade CS classes. We created two variants of worksheets for the students - creative worksheets and rigid worksheets. After distributing these worksheets, surveys, and quizzes, we found students still feel a sense of ownership with limited versions of creative choice and benefit from a blend of creative and rigid instructions. In addition, student performance was not affected by our different treatments. The second half of the thesis adapted and launched the fifth grade curriculum to a new demographic, teaching the course to Juvenile Hall students. Student surveys and reports from their teacher showed this class had a positive impact and was well received by students and staff. We found students would prefer a longer class next iteration, as this one only extended five weeks. Future work will be needed to experimentally evaluate the specific impact of creative choice in this new demographic.
... Content design is a relevant stage in the development process of mobile solutions for children, especially those focused on the management of dental anxiety. Attractive and appropriate content increases user adoption and engagement rates in an anxiety management strategy that combines a user-centered design approach with age-appropriate participatory techniques to increase levels of acceptance and satisfaction among target users [47][48][49][50]. erefore, involving children in the design of technological solutions to support the management of dental anxiety in children is a crucial factor, especially in the content design stage. ...
... We also justify our work behind this question: What is ethics for? We agree with Hansen et al. [49] that ethics in codesign with children is very important. ...
Article
Full-text available
Dental anxiety in children is a well-documented problem in the scientific literature. Tools mediated by Information Technology have been shown to positively influence children’s mood based on distraction as well as relaxing activities. We propose an empirical method of codesign with children to generate app content for reducing dental anxiety. The results are embedded in text through a thick description as an ethnographic technique. The method was applied to 163 children (6–8 years old) from a summer school and a primary school, obtaining multimedia products that were integrated into an app prototype. Finally, although this use case of the presented method is applied to the health field, it can be transferred to any other field of application of codesign to children by using material that is specific to new scenarios.
... As a result of computer science education gaining such importance, many tools that can be used in this field have emerged, and researches have started question as to how this education can be delivered in the most effective way (Fokides, 2017;Jenson & Droumeva, 2016;Hansen, Iveland, Carlin, Harlow, & Franklin, 2016). At this point, it would be beneficial to examine the opinions of the information technology (ICT) teachers about how to deliver computer science education more effectively, because they have experience both about the tools they use in coding teaching and also teaching and assessment methods. ...
... Additionally, it is seen that teaching by giving game programming tasks to students is beneficial (Fokides, 2017;Jenson & Droumeva, 2016;Nouri, Norén, & Skog, 2018). In addition, teaching methods such as digital story writing (Hansen et al., 2016) and mobile application development (John & Rani, 2015) are seen to be applied. Teachers prefer these teaching methods to enrich the learning environment and provide permanent learning. ...
... learners focus on using specific blocks [33]. Other strategies investigated include documenting how learners at different ages design for their audiences [19] and debugging strategies and the requisite knowledge to implement them [28]. Further work has documented programming strategies specific to VBBPEs, looking at how the scaffolds present in the environment support unique patterns of interaction [52]. ...
... This fact can be seen in the design of many VBBPEs directly as many include message passing and broadcasting features to achieve parallel outcomes. Previous work looking at how parallel outcomes are achieved found that students were substantially less likely to use this mechanism than the simpler wait blocks [19]. This finding is replicated by this work as only 16 students used this feature of the VBBPE. ...
Conference Paper
Visual block-based programming environments (VBBPEs) such as Scratch and Alice are increasingly being used in introductory computer science lessons across elementary school grades. These environments, and the curricula that accompany them, are designed to be developmentally-appropriate and engaging for younger learners but may introduce challenges for future computer science educators. Using the final projects of 4th, 5th, and 6th grade students who completed an introductory curriculum using a VBBPE, this paper focuses on patterns that show success within the context of VBBPEs but could pose potential challenges for teachers of follow-up computer science instruction. This paper focuses on three specific strategies observed in learners' projects: (1) wait blocks being used to manage program execution, (2) the use of event-based programming strategies to produce parallel outcomes, and (3) the coupling of taught concepts to curricular presentation. For each of these outcomes, we present data on how the course materials supported them, what learners achieved while enacting them, and the implications the strategy poses for future educators. We then discuss possible design and pedagogical responses. The contribution of this work is that it identifies early computer science learning strategies, contextualizes them within developmentally-appropriate environments, and discusses their implications with respect to future pedagogy. This paper advances our understanding of the role of VBBPEs in introductory computing and their place within the larger K-12 computer science trajectory.
... A growing number of new curricula utilizing block-based programming tools in their materials, including the CS Principles project, the Exploring Computer Science program, and the materials being developed by code.org are becoming commonplace in introductory programming contexts (Weintrop & Wilensky, 2015, p.101). Educational initiatives such as Hour of Code, coupled with an increase in novice friendly, graphical programming environments (e.g., Scratch, Blockly, Alice, etc.), have provided more developmentally appropriate opportunities to expose younger children to computer science (Hansen, Iveland, Carlin, Harlow, & Franklin, 2016). Guzdial (2004) and Kelleher & Pausch (2005) have made comprehensive reviews of Novice Programming Environments (Hundhausen et al., 2009). ...
... 1. Computational concepts, 2. Computational practices, and 3. Computational perspectives ( Figure 4). Hansen et al., 2016). ...
Article
Full-text available
Teaching programming is a complex task. The task is even more challenging for introductory modules. There is an ongoing debate in the teaching community over the best approach to teaching introductory programming. Visual block-based programming environments allow school students to create their own programs in ways that are more accessible than in textual programming environments. These environments designed for education allow students to program without the obstacle of syntax errors (errors in typing commands) found in traditional text-based languages. In this paper, the authors focus on the use of App Inventor and Scratch as blocks-based programming environments designed explicitly with novices in mind. In the authors' analysis, both Novice Programming Environments (NPEs) seemed to be attractive platforms for introducing fundamental concepts in computer programming and both look appealing for both majors and non-majors.
... Programs created in the classroom using the IDE can then be downloaded as Arduino sketches and uploaded to the iOiSphere as part of the activities included in a school visit. A user-centered approach is key to avoid typical pitfalls in this field [2]. The impact of the engagement with iOiSphere will be measured through a small questionnaire integrated into the process of uploading a program to the sphere and with consideration for the stages outlined by Resnick for creative thinking [4]. ...
Conference Paper
Full-text available
The renewed emphasis on computing at schools in the UK sheds light on challenges with programming pedagogy; for example, poor recruitment and retention. This poster introduces the physical programming education installation at the Institute of Imagination: the iOi-Sphere. It then outlines future research into a supporting development environment and curriculum for ages 5-16.
Chapter
Full-text available
Teaching programming is a complex task. The task is even more challenging for introductory modules. There is an ongoing debate in the teaching community over the best approach to teaching introductory programming. Visual block-based programming environments allow school students to create their own programs in ways that are more accessible than in textual programming environments. These environments designed for education allow students to program without the obstacle of syntax errors (errors in typing commands) found in traditional text-based languages. In this paper, the authors focus on the use of App Inventor and Scratch as blocks-based programming environments designed explicitly with novices in mind. In the authors' analysis, both Novice Programming Environments (NPEs) seemed to be attractive platforms for introducing fundamental concepts in computer programming and both look appealing for both majors and non-majors.
Conference Paper
Full-text available
In this paper, we present our analysis of 92 fourth graders' digital story projects completed in LaPlaya, a Scratch-like programming environment. Projects were analyzed for the way that students programmed the start of the story, and if the program integrated user-centered design by providing instruction to the user on how to interact with the digital story. We found that fourth grade students rarely used user-centered design while creating digital stories in our block-based programming environment. Without explicit instruction, the demands of learning programming and simultaneously programming for an abstract user may be too cognitively demanding for the average fourth grader.
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
Reviews the literature of social and developmental psychology on empathy theory and research. These 2 subdisciplines differ in their definitions and measures from each other, as well as from the counseling/psychotherapy area. At the same time, all 3 disciplines identify 2 major types of empathy: (a) affective empathy, or feeling the same way as another person, and (b) cognitive or role-taking empathy. Four proposals that result from an integration of these 3 literatures are discussed: First, empathy should be viewed as a multistage interpersonal process that can involve emotional contagion, identification, and role taking. Second, empathy in children is probably different from empathy in adolescence and adulthood. Third, empathy can but does not necessarily lead to helping behaviors. Last, empathy in counseling/psychotherapy can be helpful in certain stages, with certain clients, and for certain goals. However, at other times it can interfere with positive outcomes. (79 ref) (PsycINFO Database Record (c) 2006 APA, all rights reserved).
Article
During the past decade, design-based research has demonstrated its potential as a methodology suitable to both research and design of technology-enhanced learning environments (TELEs). In this paper, we define and identify characteristics of design-based research, describe the importance of design-based research for the development of TELEs, propose principles for implementing design-based research with TELEs, and discuss future challenges of using this methodology. (http://www.springerlink.com/content/a582109091287128/)
Chapter
The following theory of development, which is particularly concerned with the development of cognitive functions, is impossible to understand if one does not begin by analyzing in detail the biologic presuppositions from which it stems and the espistemological consequences in which it ends. Indeed, the fundamental postulate that is the basis of the ideas summarized here is that the same problems and the same types of explanations can be found in the three following processes: a. The adaptation of an organism to its environment during its growth, together with the interactions and autoregulations which characterize the development of the “epigenetic system.” (Epigenesis in its embryologic sense is always determined both internally and externally.) b. The adaptation of intelligence in the course of the construction of its own structures, which depends as much on progressive internal coordinations as on information acquired through experience. c. The establishment of cognitive or, more generally, epistemological relations, which consist neither of a simple copy of external objects nor of a mere unfolding of structures preformed inside the subject, but rather involve a set of structures progressively constructed by continuous interaction between the subject and the external world.