Content uploaded by Edward Melcer
Author content
All content in this area was uploaded by Edward Melcer on Oct 12, 2017
Content may be subject to copyright.
Embodiment, Collaboration, and Challenge in Educational
Programming Games: Exploring Use of Tangibles and Mouse
Edward Melcer
New York University
Brooklyn, NY, 11201
eddie.melcer@nyu.edu
Katherine Isbister
University of California, Santa Cruz
Santa Cruz, CA, 95064
katherine.isbister@ucsc.edu
ABSTRACT
While there are common design decisions in existing games for
teaching Computer Science (single player puzzle based games for
the touchpad/keyboard and mouse), recent work has suggested
that alternative approaches such as collaborative play and
physically embodied designs may also provide important
benefits to learners. In order to explore how making interactions
with an educational programming game more physically
embodied could impact collaborative play, we created an
educational programming game called Bots & (Main)Frames. We
then conducted a preliminary study to examine if the level
designs achieved desired challenge and explore how two
versions of the game with different forms of physical
embodiment/input (e.g., mouse vs. tangible programming blocks)
impacted player interactions underlying collaboration. We found
that game levels seem to provide desired increasing challenge,
and that players often used the mouse and tangible
programming blocks to aid communication/collaboration in
distinctly different ways.
1
CCS CONCEPTS
• Human-centered computing→User studies;
KEYWORDS
Educational Programming Game, Physical Embodiment,
Tangibles, Embodied Interaction, Collaborative Play
ACM Reference format:
Edward Melcer and Katherine Isbister. 2017. Toward Understanding
Disciplinary Divides within Games Research. In Proceedings of FDG’17,
Hyannis, MA, USA, August 14-17, 2017, 6 pages.
https://doi.org/10.1145/3102071.3116222
1 INTRODUCTION
In a recent survey examining the designs of existing games
teaching Computer Science (CS) [9], Harteveld et al. found that
the majority of existing games feature a number of similar
design decisions such as: 1) similar playable characters (robot); 2)
Permission to make digital or hard copies of part or all 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 third-party components of this
work must be honored. For all other uses, contact the owner/author(s).
FDG’17, August 14-17, 2017, Hyannis, MA, USA
© 2017 Copyright held by the owner/author(s).
ACM 978-1-4503-5319-9/17/08…$15.00
https://doi.org/10.1145/3102071.3116222
genre (puzzle); 3) number of players (single player); and 4) form
of interaction (touchpad/mouse and keyboard).
Conversely to some of these frequent design decisions,
there is notable work advocating for the importance of learning
through collaboration [6] and physical embodiment/interactions
with the body [15, 16]. In the context of CS education, pair
programming (two programmers working collaboratively at a
shared computer on the same task [3]) has been shown to
improve self-sufficiency, performance, and overall grades for
students in an introductory CS course [18]. Similarly, more
physically embodied approaches to teaching programming—such
as the use of tangibles and manipulatives—have been found to
increase enjoyment and programming self-beliefs [17] as well as
help learners with syntax [28].
In this paper, we present the design of an educational
programming game we created called Bots & (Main)Frames. We
also provide preliminary work examining 1) incorporating
challenge into the design of its levels, and 2) how utilizing
different design decisions in educational programming games—
i.e., making interaction physically embodied—could impact
interactions underlying player collaboration. Bots &
(Main)Frames is designed to incorporate common design
characteristics (i.e., players program a virtual robot to solve
puzzles), as well as provide a comparison point to systematically
examine the impacts that different forms of physical
embodiment have on learning programming. This is achieved by
differing game design only in the form of interaction (e.g., use of
tangible programming blocks vs. mouse input), which allows us
to isolate the impact of tangible and mouse designs when all
other mechanics, aesthetics, etc. are identical.
We conducted a preliminary exploratory study with 36
novice programmers (having less than 6 months of programming
exposure) randomly assigned to play one version of the game
collaboratively in pairs. We examine how different design
principles in puzzle-based levels can present increasing
challenge to players, and how physically embodied interaction
with tangible blocks differs from use of a mouse in supporting
collaborative learning and play.
2 RELATED WORK
2.1 Tangibles and Computational Concepts
The tangible and embodied interaction (TEI) community has
done some work on the creation of tangibles to teach computing
concepts. For instance, in roBlocks [24] and Electronic Blocks
[28] learners connect tangible blocks with embedded sensors,
FDG’17, August 14-17, 2017, Hyannis, MA, USA
Edward Melcer and Katherine Isbister
actuators, and logic blocks to explore programming and physical
computing concepts. Tools such as Note Code [14] have used
music as a metaphor for learners to program and connect
buttons on “noteboxes” to play musical sequences. Thingy
Oriented Programming [7] was designed for prototyping simple
electronics applications and systems that involve networks of
sensors and actuators, where users program wirelessly
connected objects by recording sequences of actions and
reactions using tangible objects. Additionally, TanProRobot 2.0
[27] allows children to use physical blocks to program a toy car.
Notably, concepts covered by these tools focus more on physical
computing, electronics, and music than explicit use of
programming or games.
In a closer vein, Strawbies [10] utilizes wooden tiles to
program a game character to solve mazes, but has only been
evaluated through qualitative descriptions of play sessions at
local schools. Melcer et al. [17] created a similar type of
programming game that uses wooden blocks instead of tiles, and
compared the blocks to use of a mouse for impacts on
programming self-beliefs and enjoyment. However, they did not
explore complexity in the level design or impacts on player
collaboration.
2.2 Computational Thinking
Computational Thinking (CT) is a construct around the
formulation of problems and expression of solutions in a
computational way. It is thought to underlie computation related
activities such as programming, but is complicated by the
absence of a concrete definition. Consequently, many papers
have attempted to define CT independently, resulting in a wide
variety of definitions for the construct and a lack of satisfactory
operationalization or guidance for identifying real interactions as
expressions of CT [4]. However, [2, 4] have identified a core set
of CT skills commonly found in existing literature as: 1)
Conditional Logic – the use of an “if-then-else” construct; 2)
Algorithm Building – a data “recipe” or set of instructions; 3)
Simulation – modeling or testing of algorithms or logic; 4)
Debugging – the act of determining problems in order to fix rules
that are malfunctioning; 5) Abstraction – use of procedures to
identify patterns and encapsulate a set of often repeated
commands; and 6) Distributed Computation – the social aspect of
CT where different pieces of information or logic are contributed
by different players during other CT processes, e.g., simulation,
debugging, etc.
2.3 Physical Embodiment in Games
There has been a variety of different approaches, designs, and
theories around the application of physical embodiment to
learning in educational games. In a meta-review comparing and
taxonomizing embodiment strategies, Melcer and Isbister [15, 16]
identified five forms of physical embodiment commonly utilized
in educational games: Direct Embodied, Enacted, Manipulated,
Surrogate, and Augmented. In the Manipulated form of
embodiment, use of physical objects (e.g., tangibles and
manipulatives) allow for learning concepts to be embedded
Figure 1: The Bots & (Main)Frames game. The UI is
identical for all versions of the game and only differs on
physical embodiment and interaction using 1) the mouse
and 2) tangible programming blocks.
directly into the physical material and design of the object, as
well as through the embodied interactions learners have by
manipulating these objects [19, 20]. We similarly employ these
affordances in the design of the programming blocks for our
tangibles version of Bots & (Main)Frames.
3 Design of Bots & (Main)Frames
Bots & (Main)Frames is designed to incorporate common design
characteristics of existing educational programming games (i.e.,
players program a virtual robot to solve puzzles [9]), and
provides a comparison point for differing forms of physical
embodiment and interactions as input (see Fig. 1). The objective
of the game is to program a virtual robot to reach all of the red
tiles in a maze from a given starting point. Players are presented
with 10 levels and have a limited number of actions available to
solve each level. As players progress through the levels, they are
presented with a variety of programming commands to control
the robot consisting of: moving/translating forward in the
direction the robot is facing (introduced in level 1); rotating the
robot 90 degrees left or right (introduced in level 2); using a loop
to repeat one command a specified number of times (introduced
in level 4); and using a function to abstract and reuse patterns
(introduced in level 7).
3.1 Design of Mouse and Tangible Versions
For both the mouse and tangible programming block versions of
Bots & (Main)Frames, the graphics and gameplay are identical;
differing only in the way players are able to program code. In the
version of Bots & (Main)Frames, players click UI buttons to
program. As players progress, new commands become available
in the form of additional buttons that are shown when needed to
solve a level (see Fig. 2).
Embodiment, Collaboration, and Challenge in Educational
Programming Games: Exploring Use of Tangibles and Mouse
FDG’17, August 14-17, 2017, Hyannis, MA, USA
Figure 2: The Bots & (Main)Frames game. The UI is
identical for all versions of the game and only differs on
physical embodiment and interaction using 1) the mouse
and 2) tangible programming blocks.
For the tangibles version of Bots & (Main)Frames, players
instead physically connect wooden blocks to program commands
(a similar design approach to [10, 14, 27, 28]; see Fig. 3). The
design is centered on the metaphor of “following the chain of
execution”, and as a result each block has a metal hook on one
side and eye on the other that is used to physically chain them
together. The UI and gameplay are identical to the mouse
version, except that buttons are disabled and programming
commands that appear on screen are instead created by
configurations and connections of the tangible programming
blocks. Fiducial tracking from the ReacTIVision framework [12]
is utilized in order to detect which blocks are connected and
program the virtual robot in game accordingly. Additionally, the
Loop and Use Function commands are designed to further utilize
the affordances of the Manipulated form of physical embodiment
where physical form of and interactions with the blocks
represent corresponding programming concepts (see Fig. 4). E.g.,
loop blocks have an additional slot for players to slide in the
command that will be looped. This design physically illustrates
how the in-game loops only take a single non-loop command to
repeat. Furthermore, the Function/Use Function blocks are
connected by a longer chain to better illustrate how code
execution transitions from one function to another.
3.2 Level Design: Complexity and Challenge
Bots & (Main)Frames consists of 10 levels that are broken into
coverage of three conceptual topics (see Fig. 5). Levels 1 – 3
address basic algorithm building using translation/rotation of the
robot; levels 4 – 6 address the use of loops; and levels 7 – 10
address the abstraction and reuse of patterns with functions. The
first level of each grouping is designed to introduce the player to
the concept and corresponding game/programming mechanic,
Figure 3: The tangible programming blocks version of Bots
& (Main)Frames. Players must physically chain the blocks
together in order to program.
Figure 4: Left: the Loop programming block where players
insert a command that will be repeated a specified number
of times. Right: the Function and corresponding Use
Function programming blocks connected by a chain.
while the remaining levels are intended to introduce additional
challenge through harder puzzles and incorporating earlier
concepts. Therefore, the overall challenge and complexity of
each level is intended to be more difficult than the previous level
in its respective conceptual topic.
Challenge is notably important in educational games for
enhancing the enjoyment and intrinsic motivation of goal-
directed activities [1, 8], as well as generating flow for optimal
learning experiences [11, 13]. In order to design challenge in
levels appropriately, we used three guiding design principles:
breadth (the number of unique solution commands needed for
the optimal path), depth (the total number of solution commands
needed for the optimal path), and obfuscation of the optimal
solution path (presenting unique additional potential paths that
appear correct but are incorrect). For instance, level 3 should be
more challenging than level 2 to solve since both need the same
number of unique solution commands (same breadth: forward,
left, right), but level 3 also requires two more commands to
optimally solve (greater depth) and obfuscates the solution path
with two additional paths that appear correct but aren’t possible.
The notion of breadth and depth come from an existing model of
skill progression utilized for programmers in Scratch [23].
However, since Scratch is an animation programming
environment [21] rather than puzzle game, we also found it
necessary to incorporate obfuscation in the design of levels since
it is a vital aspect of challenge in puzzle design [25].
4 Methodology
4.1 Experimental Design and Procedure
For our exploratory study, we wanted to 1) determine whether
level designs achieved the desired increasing challenge for each
conceptual topic; and 2) explore how the physically embodied
design of the tangible programming blocks version and mouse
version of Bots & (Main)Frames supported interactions
underlying player collaboration. In order to address these
questions, we used a between-group study design where
participants were randomly assigned to pairs in a mouse or
tangibles condition. In the pretest survey, participants completed
a demographic questionnaire (collecting age, gender, academic
major, years of prior video game experience, and years of prior
programming experience). After submitting the pretest survey,
participants were randomized into either the mouse or tangibles
FDG’17, August 14-17, 2017, Hyannis, MA, USA
Edward Melcer and Katherine Isbister
Figure 5: The levels of Bots & (Main)Frames organized by conceptual topic covered. The challenge and complexity of each
level is expected to be more difficult than the previous level in its respective conceptual topic.
condition and played all 10 levels collaboratively in pairs. We
used video recordings of participants playing the game in order
to determine the time taken to complete each level and visually
code/analyze collaborative actions.
4.2 Participants
A total of 36 university participants (ages 17-35, median: 18)
were randomly allocated into pairs for one of two conditions.
The mouse game condition consisted of 18 (5 male) participants
and the tangibles game condition consisted of 18 (8 male)
participants. Only two pairs knew each other before the study.
All participants had 6 months or less of programming experience
and worked collaboratively in pairs to play the game. The pair
programming approach was used to examine collaborative
interaction differences between conditions.
5 Results and Discussion
5.1 Challenge of Levels
In our analysis, we operationalize the challenge of a level as the
total amount of time taken to complete it. This seems reasonable
since more conceptually and programmatically difficult levels
will take novice programmers longer to solve. The average
duration players spent on a level (in seconds) for both the mouse
and tangible block versions of Bots & (Main)Frames is shown in
Table 1. Due to small sample size as well as inability to control
for inherent differences in manipulation speed between the two
conditions (the blocks are substantially slower to
manipulate/program with), we cannot compare completion
speeds between the two conditions. However, for both
conditions, the durations for time taken to complete a level does
appear to increase substantially for each successive level in the
three different conceptual topic groupings. This matches our
design intentions to incorporate increasing challenge for each
level in its respective conceptual topic. This also suggests that
the usage of depth, breadth, and obfuscation to guide the design
for levels in puzzle-based educational programming games may
be a reasonable approach.
Level
Mouse Condition
Tangibles Condition
Mean
Duration
SD
Mean
Duration
SD
Algorithm
Building
1
19.26
6.80
24.76
16.67
2
60.52
38.12
55.43
20.15
3
121.38
107.68
132.57
65.68
Loops
4
15.70
6.70
19.96
4.40
5
45.85
26.83
35.70
6.26
6
72.99
38.08
79.10
14.91
Functions
7
59.94
44.97
55.27
32.23
8
102.95
66.82
126.67
63.62
9
171.86
107.55
130.07
32.83
10
224.36
143.01
312.44
138.06
Table 1: Frequency of Special Characters of challenge for
levels in puzzle-based educational programming games
may be a reasonable approach.
5.2 Supporting Collaboration
Prior studies have shown that collaborative programming
activities—such as pair programming—are a tightly coupled,
synchronous, and communication-intensive process [3, 5] that
requires a high level of shared understanding [26]. In order to
better understand how use of tangibles and mouse could aid in
these collaborative processes and understanding for learners, we
performed process coding [22] on the video recordings to
identify common physical instances of interaction underlying
collaboration. As a result, we found that the mouse and tangible
programming blocks versions of Bots & (Main)Frames appear to
support collaborative interaction in some distinctly similar and
different ways. For both conditions, players in every pair would
physically point to part of the level or programming commands
on screen to illustrate what they were discussing (Fig. 6).
Embodiment, Collaboration, and Challenge in Educational
Programming Games: Exploring Use of Tangibles and Mouse
FDG’17, August 14-17, 2017, Hyannis, MA, USA
Figure 6: Participants would point to a part of the level
(left) or programming commands displayed on screen
(right) in order to illustrate discussion. This was a
common interaction to aid collaboration for participants
in both conditions.
For the mouse version, all pairs of players commonly
interacted collaboratively in two specific ways. First, players
would share/pass the mouse to let the other player modify their
program (see Fig. 7). In this way, direct access to the shared code
was treated as exclusive with explicit transfers of control that
only allowed one participant to manipulate the program at a
time. Second, players would also use the mouse to virtually point
to and circle parts of the level or programming commands they
were discussing. This provided participants with a visual aid
when conversing around more abstract concepts such as the
structure of their algorithm and execution of their code.
On the other hand, players appear to have used the
tangible programming blocks to help externalize cognition and
algorithm building in ways that allowed them to interact more
dynamically. One interaction approach to aid collaboration with
tangibles was externalization of the algorithm and player
knowledge to physical space using the blocks (see Fig. 8). Players
would habitually point to blocks on the table in order to
physically aid them in simulation, debugging, and discussion of
their algorithm and its execution. This also assisted participants
in physically illustrating how certain programming
blocks/concepts worked, and they would often use the physical
properties of the blocks (i.e., pointing to the additional slot on
the loop block or tracing the chains on the function blocks) to
help convey their points.
Figure 7: In the mouse version, one participant would
often share/pass the mouse to let the other modify their
code. Here, participant M3A passes the mouse to
participant M3B to give her access to the program once she
figures out a potential solution.
Figure 8: In the tangible blocks version, participants would
use physical aspects of the blocks to aid in their discussion
of the algorithm and convey how different programming
concepts worked. Here, participant T1A is explaining how
loops work to T1B using the extra slot in the loop block to
demonstrate how a single command is looped.
Another frequently used collaborative interaction
approach that almost all pairs utilized often was the
modularization of algorithm construction, where both players
would simultaneously assemble parts of the solution to a level
(see Fig. 9). These allowed players to more fluidly discuss and
manipulate their program, with both participants often
anticipating and articulating the next command(s) that their
partner would need/use when constructing a solution.
Overall, our results suggest that while both tangibles and
mouse allow learners to cooperatively code and solve
programming puzzles in distinctly different but helpful ways, the
tangibles can provide deeper and more nuanced forms of
interaction and communication. Particularly, by providing
players with a physical means to externalize their cognition and
discuss understanding as well as allowing them to concurrently
create a program solution, tangibles may better address the
synchronous, communication-intensive, and high level shared
understanding needed in collaborative programming activities
[3, 5, 26].
Figure 9: In the tangible blocks version, participants would
also consistently modularize the building of their
algorithm by working on the same or separate chunks of
code simultaneously. Here, participant T6A attaches a
command to the algorithm while T6B prepares to attach
the next one.
FDG’17, August 14-17, 2017, Hyannis, MA, USA
Edward Melcer and Katherine Isbister
6 Conclusion, Limitations, and Future Work
This paper presents the design of an educational programming
game called Bots & (Main)Frames. We also report preliminary
work examining the use of breadth, depth, and obfuscation as
principles for designing challenge in levels, as well as analyzing
how the use of physical embodiment in the form of tangibles can
impact interactions underlying player collaboration when
compared to the mouse. Our results found that there were
substantial increases in time taken to complete successive levels
for a conceptual topic, suggesting that usage of depth, breadth,
and obfuscation as design principles for challenge in puzzle-
based educational programming games may be a reasonable
approach. Additionally, we found that while both tangibles and
mouse allow learners to cooperatively code in distinctly different
but helpful ways, tangibles can provide deeper forms of
interaction and communication that may better address the
needs of collaborative programming activities.
However, there are also some notable limitations to
this work. Due to the exploratory nature and small sample size
of our preliminary study and analysis, we cannot make definitive
claims about the effectiveness of challenge in our level designs
or the impact of different interaction methods on aiding
collaboration. We instead provide descriptive overviews of
apparent collaborative interaction methods used by players for
this paper, and plan to conduct a larger study in the future that
more systematically analyzes embodiment, collaboration, and
challenge.
ACKNOWLEDGMENTS
We thank Connor Harada for his help running studies.
REFERENCES
[1]
Sami Abuhamdeh and Mihaly Csikszentmihalyi. 2012. The importance of
challenge for the enjoyment of intrinsically motivated, goal-directed activities.
Personality and Social Psychology Bulletin. 38, 3 (2012), 317–330.
[2]
Valerie Barr and Chris Stephenson. 2011. Bringing computational thinking to
K-12: what is Involved and what is the role of the computer science education
community? ACM Inroads.
[3]
Andrew Begel and Nachiappan Nagappan. 2008. Pair programming: what’s in
it for me? In Proceedings of the Second ACM-IEEE international symposium on
Empirical software engineering and measurement (2008), 120–128.
[4]
Matthew Berland and Victor R. Lee. 2011. Collaborative Strategic Board
Games as a Site for Distributed Computational Thinking. In International
Journal of Game-Based Learning. 1, 2 (2011), 65–81.
[5]
Sarah D’Angelo and Andrew Begel. 2017. Improving Communication Between
Pair Programmers Using Shared Gaze Awareness. In Proceedings of the 2017
CHI Conference on Human Factors in Computing Systems (2017), 6245–6290.
[6]
Pierre Dillenbourg. 1999. What do you mean by collaborative learning. In
Collaborative-learning: Cognitive and computational approaches. 1–15.
[7]
Florian Güldenpfennig, Daniel Dudo, and Peter Purgathofer. 2016. Toward
Thingy Oriented Programming: Recording Marcos With Tangibles. In
Proceedings of the Tenth International Conference on Tangible, Embedded, and
Embodied Interaction (2016), 455–461.
[8]
M.P. Jacob Habgood and Shaaron E. Ainsworth. 2011. Motivating children to
learn effectively: Exploring the value of intrinsic integration in educational
games. In The Journal of the Learning Sciences. 20, 2 (2011), 169–206.
[9]
Casper Harteveld, Gillian Smith, Gail Carmichael, Elisabeth Gee, and Carolee
Stewart-Gardiner. 2014. A Design-Focused Analysis of Games Teaching
Computer Science. In Proceedings of Games+ Learning+ Society 10 (2014).
[10]
Felix Hu, Ariel Zekelman, Michael Horn, and Frances Judd. 2015. Strawbies:
Explorations in Tangible Programming. In Proceedings of the 14th
International Conference on Interaction Design and Children (2015), 410–413.
[11]
Yavuz Inal and Kursat Cagiltay. 2007. Flow experiences of children in an
interactive social game environment. British Journal of Educational
Technology. 38, 3 (2007), 455–464.
[12]
Martin Kaltenbrunner and Ross Bencina. 2007. reacTIVision: a computer-
vision framework for table-based tangible interaction. In Proceedings of the 1st
international conference on Tangible, Embedded, and Embodied interaction
(2007), 69–74.
[13]
Kristian Kiili. 2005. Digital game-based learning: Towards an experiential
gaming model. In The Internet and higher education. 8, 1 (2005), 13–24.
[14]
Vishesh Kumar, Tuhina Dargan, Utkarsh Dwivedi, and Poorvi Vijay. 2015.
Note Code – A Tangible Music Programming Puzzle Tool. In Proceedings of
the 10th International Conference on Tangible, Embedded, and Embodied
Interaction (2015), 625–629.
[15]
Edward F. Melcer and Katherine Isbister. 2016. Bridging the Physical Divide: A
Design Framework for Embodied Learning Games and Simulations. In
Proceedings of the CHI’16 Extended Abstracts (2016), 2225–2233.
[16]
Edward F. Melcer and Katherine Isbister. 2016. Bridging the Physical Learning
Divides: A Design Framework for Embodied Learning Games and Simulations.
In Proceedings of the 1st International Joint Conference of DiGRA and FDG
(2016).
[17]
Edward F. Melcer, Victoria Hollis, and Katherine Isbister. 2017. Tangibles vs .
Mouse in Educational Programming Games: Influences on Enjoyment and
Self-Beliefs. In Proceedings of the CHI’17 Extended Abstracts (2017).
[18]
Nachiappan Nagappan, Laurie Williams, Miriam Ferzli, Eric Wiebe, Kai Yang,
Carol Miller, Suzanne Balik. Improving the CS1 experience with pair
programming. In ACM SIGCSE Bulletin. 35, 1 (2003), 359–362.
[19]
Wim T. J. L. Pouw, Tamara van Gog, and Fred Paas. 2014. An Embedded and
Embodied Cognition Review of Instructional Manipulatives. In Educational
Psychology Review. 26, 1 (2014), 51–72.
[20]
Sara Price, Jennifer G. Sheridan, Taciana Pontual Falcao, and George Roussos.
2008. Towards a framework for investigating tangible environments for
learning. In International Journal of Arts and Technology. 1, 3/4 (2008), 351–
368.
[21]
Mitchel Resnick, John Maloney, Andrés Monroy-Hernández, Natalie Rusk,
Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, J. a Y.
Silver, Brian Silverman, Yasmin Kafai. 2009. Scratch: Programming for All. In
Communications of the ACM. 52, (2009), 60–67.
[22]
Johnny Saldaña, J. 2015. The coding manual for qualitative researchers. Sage.
[23]
Christopher Scaffidi and Christopher Chambers. 2012. Skill progression
demonstrated by users in the Scratch animation environment. In International
Journal of Human-Computer Interaction. 28, 6 (2012), 383–398.
[24]
Eric Schweikardt and Mark D. Gross. 2008. The robot is the program:
interacting with roBlocks. In Proceedings of the second international conference
on Tangible, Embedded, and Embodied interaction (2008), 167–168.
[25]
Mike Selinker and Thomas Snyder. 2013. Puzzlecraft: the ultimate guide on
how to construct every kind of puzzle. Sterling.
[26]
Josh Tenenberg, Wolff-Michael Roth, and David Socha. 2016. From I-
awareness to we-awareness in CSCW. In Computer Supported Cooperative
Work (CSCW). 25, 4–5 (2016), 235–278.
[27]
Danli Wang, Lan Zhang, Chao Xu, Haichen Hu, and Yunfeng Qi. 2016. A
Tangible Embedded Programming System to Convey Event-Handling
Concept. In Proceedings of the Tenth International Conference on Tangible,
Embedded, and Embodied Interaction (2016), 133–140.
[28]
Peta Wyeth. 2008. How Young Children Learn to Program With Sensor,
Action, and Logic Blocks. In Journal of the Learning Sciences. 17, 4 (2008), 517–
550.