Content area
Purpose
The purpose of this paper is to present the design and evolution of the Dancing Computer project. Dancing Computer is an ongoing research project at the Michigan State University, which is developing a system that aims to increase computer literacy in elementary-aged children by teaching them first to read code before they write it. The main objective is to educate children on basic concepts of computer science.
Design/methodology/approachChildren are given tablet computers that present a simple program line-by-line that they execute as they pretend to be a computer. The programs are acted out on a portable dance floor consisting of colored tiles, and the program statements instruct the child to move, turn and act out dance poses and terminology.
FindingsThe Dancing Computer prototype was tested in six different locations in 2016, reaching approximately 250 students. Learning was demonstrated by significant improvements in both task duration and error performance as students performed the activities. The most common errors were movement errors, where participants failed to move the correct number of squares.
Social implicationsThis project has the potential to increase the level of computer literacy for thousands of children. This project’s goal is to increase understanding of what a computer does, what a program does and the step-by-step nature of computer programs.
Originality/valueThis is a unique and a different approach – the norm being to start students off writing code in some language. In Dancing Computer stages children as readers of programs, allowing them to pretend to be a computer in a fun and engaging activity while also learning how computers execute real programs.
1. Introduction
The objective of the Dancing Computer project is to develop a system for teaching computer programming through dance with a reading-first approach based on the principles of science, technology, engineering, art and mathematics (STEAM) (Radziwill et al., 2015). STEAM extends the concept of science, technology, engineering and mathematics (STEM) by adding art, exploiting the potential learning impacts of expression and creativity. The effects of this system on students’ understanding of computer science principles are analyzed through use of pre- and post-assessment of students’ ideas surrounding programming, as well as through evaluation of students’ performance during the Dancing Computer activity.
Ultimately, the goal of the project is to introduce programming to a wider and younger audience while creating interest in computer science and programming, in general. If children understand the concept of executing a program and can do so in a very real physical sense, they will be better able to understand the capabilities and limitations of computers and how they are integrated into systems. Additionally, teaching children to understand the basics of programming from a young age provides scaffolding for further instruction as they grow.
Dancing Computer is an offshoot of the Theatre Engine project and the most recent Theatre Engine performance: FlashMob (Owen et al., 2014). Both Theatre Engine and Dancing Computer strive to bring an element of performance art into the world of computing and STEM in general. As computers permeate nearly every aspect of society, children need to understand how they work and the principles of programming. The Dancing Computer project aims to teach children basic programming concepts through dance.
In Dancing Computer, children are given tablet computers that connect wirelessly to a server that manages the activity. The tablets present a simple graphical programming language. The style is a syntax-light puzzle-piece format consisting of sequential instructions with support in the design for the nesting implicit in structured programming language. The style is designed to be graphically appealing to a wide range of audiences, including younger children and to involve little reading and limited “keywords”. The puzzle piece format is familiar and has been demonstrated and tested in systems such as SCRATCH (Resnick et al., 2009) and ALICE for many years (Cooper et al., 2000). In the default configuration, programs are presented one line at a time. This is effectively an instruction fetch operation and that terminology can be utilized with older audiences. Program statements include basic control (where to start in space), movement instructions (translation, rotation), variable expressions and general (textural) instructions. Figure 1 illustrates an example dance program as authored on the server.
Figure 2 illustrates how program statements are presented to participants in the Dancing Computer activity on their tablet computers. Each participant is presented a different program, effectively emulating the concept of differing threads of execution. All of this takes place on a dance floor consisting of commercially available colored foam tiles. The programs are acted out, as the participants pretend to be a computer. The system includes lighting and music designed to make this an exciting and engaging activity. Figure 3 is a picture of a typical Dancing Computer activity. In this example, four children are participants, each pretending to be a computer and acting out their individual thread of execution.
The research is different than other projects in computer science education because Dancing Computer puts the focus on art and performance principles, in addition to the science of computer programs and the concept of program execution. It also focuses on developing understanding of how the computer reads and executes code before it ever tries to teach kids how to write code. The project aims to be more accessible, interactive and further reaching than previous efforts in computer science education.
2. Background
Prior efforts in computer science education aimed at younger audiences have typically focused on writing programs first rather than reading existing code (Resnick et al., 2009; Cooper et al., 2000; Ben-Ari, 1998). Attempts to teach children of various ages to program have a long and storied history, from the earliest days of the BASIC programming language through the concepts of Logo in the 1970s to carefully designed graphical programming interfaces, such as SCRATCH and ALICE in the twenty-first century.
The concept of a programming language designed specifically for educational purposes has its roots in the BASIC programming language developed and widely utilized by students in the 1960’s at the Dartmouth College (Kemeny and Kurtz, 1985). BASIC was designed as a more accessible alternative to FORTRAN and Algol, common programming languages of the period. The language gained considerable popularity as an early programming education tool when it was included with early personal computers such as the Apple II. The language design, however, remains controversial to this day and is no longer considered a good choice for educational purposes.
The Logo programming language and the concept of turtle graphics was developed in the 1970’s as a tool specifically designed to teach younger people to program (Solomon and Papert, 1976). Logo was one of the first languages developed with a specific pedagogical goal in mind for a younger demographic. Even BASIC, though popular during this period due to the early availability of personal computers, was originally developed for teaching college-age students the concepts of programming. Logo includes instructions such as forward, left, right, penup and home. These instructions drive the movement of a pen on paper, drawing on a screen or even physical robots. The idea is to provide a physical output that is more interesting and easier for children to understand than simple textual output. The longstanding use of turtle graphics to teach programming (starting with the LOGO programming language) has also influenced the Dancing Computer project, with many of the dancer commands (such as translation and rotation) drawn from the turtle graphics nomenclature (Crayton and Svihla, 2015).
By taking the turtle graphics system and flipping it on its head, Dancing Computer teaches children to read code first rather than write it (much as children learn to read conventional languages before they write). Instead of controlling the “turtle”, children execute instructions themselves, physically moving on a gridded floor. By participating in these dances, children embody a computer. This helps build an understanding of not just the effects of the code they may later write, but of how a computer might execute that program. Forming more complete representations of how computers work, rather than simple if-then relationships, leads to a more in-depth understanding of programming and how a computer operates (Felder and Silverman, 1988).
The realization of the importance of computer science education for children has led to programming languages and environments such as SCRATCH and ALICE, which simplify the process of learning to program. Those tools are based on the concept of teaching children how to write code that a computer can understand. Both ALICE and SCRATCH utilize a building block/puzzle-piece system that allows children to drag and drop commands to form a program that manipulates images on the screen. By using building block metaphors, both ALICE and SCRATCH help children understand how to write simple computer code. The drag-and-drop interface also simplifies the syntax, avoiding most compiler errors.
The programming language presented to children in Dancing Computer programs (“dances”) draws inspiration from programming languages that have been designed for children, including SCRATCH and ALICE. The building block style used for fitting together programming instructions in these languages has heavily influenced the project, leading to the puzzle piece metaphor. Although users are not directly manipulating the pieces themselves, as they do in SCRATCH and ALICE, the layout is a very logical way to express the sequential statement-based nature of programming languages.
3. Research objective
As a research project, Dancing Computer proposes the simple concept that there is benefit to first teaching children to read programs before they are ever instructed in how to write them. When children are taught to read and write, they are taught reading first so they can become familiar with letters, the sounds they make and how they are strung together. Reading is considered a perceptual activity, requiring the association of letters and words with sounds (Gillen and Hall, 2003). Writing requires a superset of the skills of reading and, indeed, writing is dependent on reading as a basic skill. Programming is conventionally taught through simultaneous presentation of the concepts of reading and writing, with an emphasis on writing, resulting in a considerably increased cognitive requirement.
The goal of any project that seeks to convey computer literacy is comprehension of the functions of a computer and how those functions are exploited to solve problems. A RAND Reading Study refers to comprehension in the context of reading as “the process of simultaneously extracting and constructing meaning through interaction and involvement with written language” (Group, 2002). Comprehension is understanding. Rather than an applied skill, comprehension seeks to provide the foundation for development of applied skills and is, therefore, essential to learning. In early childhood education, early learning of writing is dependent upon comprehension. The literature on improving comprehension in early reading education cites several factors that are important in the process and that we have attempted to apply in the Dancing Computer project.
Early education in writing requires decoding skills. The process begins with the ability to comprehend words. Likewise, the process of teaching programming necessarily begins with understanding the statements in a programming language, be they textural or entirely graphically presented. Given this foundation of words/instructions, children must then make the transition from active decoding to automatic decoding, a process referred to as fluency. Best practices for developing fluency include repetition and performance, as in Reading Theater (Corcoran and Davis, 2005). Reading Theater is a dramatic approach to reading education, where students read source text orally in a social setting. Reading Theater has been shown to be effective in a wide range of populations in improving reading comprehension and specifically at enhancing the transition from reading to writing (Liu, 2000). Dancing Computer is much like Reading Theater, in that it is a social setting where participants are reading computer programs.
Comprehending basic computational concepts will make it easier for participants to learn how to write a code in the future, as they will already have a grasp on the basic elements of computing, how these elements work together and what they accomplish. Much as children are taught to read before they are taught to write, the Dancing Computer team believes that this approach can also be applied as young children are taught about programming and computer science. Rather than learning a concept and immediately having to apply it, this perceptual approach allows participants to learn a concept by directly utilizing the concept, effectively consuming before they are required to, or need to, produce.
This project aims to teach the most basic programming concepts. Like most other introductory programming tools, Dancing Computer starts with the simplest of instructions and builds up to more complex concepts as participants gain experience.
The concepts that Dancing Computer is currently able to convey are:
sequencing;
variables;
synchronization; and
message passing.
The most basic concept, sequencing, aims to demonstrate to the students that programs are a sequence of steps and that each step affects all the steps following it. The next concept, variables, teaches how computers can store values, access them and use them. Variables teach the basic concept of memory. Synchronization is illustrated by each dancer moving independently of the others, but contributing to a computed whole, like threads in a computer program. The most complex concept that Dancing Computer currently supports is message passing. This is illustrated with a physical baton that students pass to each other during some dances. Just like computer memory, each baton contains the values of variables used in dances (A = 2, B = 1, etc). Students “look up” the values on the batons, just as computer programs might receive data in shared memory from other processes. Apart from these concrete concepts, Dancing Computer also aims for students to understand the logic-based thinking that goes into communicating with a computer.
Dancing Computer is designed for a target demographic of third to fifth grade students, though the demographic has expanded as more complex tasks have been added and we have gained experience with a wide range of ages. Laying a foundation in computer science concepts for primary school students at a young age can be built upon throughout the students’ later education. The first time most students are introduced to programming, it is in front of a computer screen and using drag and drop programming tools like ALICE, SCRATCH, and Minecraft Hour of Code, among others. Dancing Computer takes a more physical, interactive, group setting approach. An extremely different approach like this could inspire younger and more varied groups of people to be interested in computer science.
Dancing Computer is part of a growing group of educational projects that aim to add artistic elements to traditional STEM education. This STEM + art (STEAM) approach helps in engaging students in learning about technical fields while educating them about the applications of STEM and the arts in the real world. By combining computer science education with performing arts (including dance and theatre), Dancing Computer and the Theatre Engine project hope to increase interest in STEM fields, particularly for under-represented groups such as women and minorities. computer science can be perceived as a boring, difficult or male-exclusive profession (Beyer et al., 2003). Dancing Computer hopes to impact these assumptions and potentially increase interest in programming as a career for young people from many different and diverse backgrounds.
Because different students learn best in different ways, the Dancing Computer project uses a variety of teaching styles to meet their needs. Typically, computer science concepts are taught in a lecture format, which may then progress to programming assignments or labs where students write code sitting at a computer. Dancing Computer aims to still engage the auditory and visual learners best served by these methods while also allowing students to experience programming through kinesthetic teaching methods as well. Including movement in programming through dance concepts allows the project to better teach a wider variety of students, in addition to better capturing and entertaining students during the activity. Dancing Computer’s active approach to learning also allows students to interact with and explore programming, rather than passively absorbing concepts through lecture. By turning programming into something entertaining, approachable and interactive, Dancing Computer better meets the needs of students across a wide spectrum of learning styles.
Dancing Computer allows children to physically act out a computer program, thereby exploiting embodied cognition to enhance the learning process (Rambusch and Ziemke, 2005). Embodied cognition postulates that the mind and the body are intricately interrelated and influence each other. A physical activity can be a more effective learning mechanism than a purely mental or sensory activity. By physically acting out a computer program, the child embodies the computer. The most basic form of embodiment is physical embodiment, wherein the child is physically acting out as part of the learning process. This activates motor-resonate regions of the brain that would not normally be as directly involved in the learning process (Rizzolatti et al., 2002). The learning impact is closely related to early tool-using behavior in children, where physical play enhances learning.
As a group activity, Dancing Computer is very social and encompasses the concept of social embodiment, which can be thought of a physical embodiment expressed by a social group. Learning is enhanced by physically acting out the programs as if the child were the computer, but the group setting imparts additional learning benefits as the child not only creates bodily states, but also perceives the bodily states of other participants. It is theorized that social embodiment has an increased impact on the learning process (Barsalou et al., 2003). Social relations help people connect and convey understanding between each other. An important social process is imitation/mimicry. The earliest level dance programs tend to be highly symmetrical in nature to effectively exploit this social process. The symmetry makes it easy for children to learn how to execute the dance instructions together. If all participants move forward three steps, it is easy for them to recognize that they have made a mistake. Later dances break this symmetry relationship, as the child learns to execute the instruction with less reliance on social interactions, but the patterns continue to retain some degree of symmetry to continue to enforce accuracy due to the group social embodiment.
4. Experimental design
4.1 Tablets and server
Figure 4 illustrates the system design and interconnectivity. Dancing Computer consists of two programs: a client that runs on the tablet computers and a server that coordinates the entire activity. Figure 5 is a screen capture of the server, which runs on a single local system, typically a laptop computer, and provides controls for the system. Figure 2 is an illustration of the application running on an Android tablet computer. Both the server and client were developed for this project using the Java programming language. The server was developed using conventional desktop Java, while the client uses the Android-adapted version of Java and the Android Software Development Kit. The server serves as both central control and an authoring tool for the dances. Programs loaded by the server are transmitted via a local Wi-Fi network to the clients by the server. These programs are then presented on the tablets in a variety of forms depending on the desired complexity.
The tablets can present a single line of code at a time, a line of code and the surrounding context or the entire program, where students are expected to read the program without assistance. The context can be presented in a dimmed form to make it more obvious that it is the context of the current instruction. Each participant follows the dance steps on a single tablet, executing the “program” or dance, on a portable gridded floor made up of interlocking foam tiles (Figures 3 and 6), just as a computer might execute lines of code. As the students dance, the server also controls lighting and sound cues, which create a more immersive experience.
4.2 Set up
The server has two major subsystems for sound and lighting. Children in the twenty-first century are very media savvy and get easily bored, so the system has been designed with music to provide a rhythmic dance experience and lighting to enhance the presentation. The sound and light subsystems are self-contained in the server and do not require external equipment other than an audio amplifier, the lights themselves and an inexpensive DMX interface. In particular, no custom (and expensive) light board is required.
The sound subsystem includes music loops and sound effects. There are several dozen music loops in three different tempos. A music loop is a sequence of music that can be repeated indefinitely. Music loops are short sound files, consisting of a few bars of music, and are designed with transition boundaries that allow for a seamless transition from the end of the loop back to the beginning. A new music choice implies a transition from one loop to another, a transition that is always made on a loop boundary, so that the transition to the new loop is seamless and musical in nature. Each instruction in the server program editor has a button that brings up a dialog box for optionally selecting sound and lighting cues, as illustrated in Figure 7. An instruction can be set to initiate a musical cue or a sound effect using this setting. As the primary sequencing mechanism in the system is execution of the computer program, this allows the music to change and, optionally, a sound effect to be played for each new instruction. While this setting is available on all instructions, the convention is to only set it on the first dancer program.
Changing the musical phrasing helps to enhance the concept of switching to a new instruction. Several simple sound effects are also included, such as a cookoo sound and applause. The most popular sound effect has been a deep bass voiced “Oh, Yeah!”, which always manages to get a laugh when it occurs.
Lighting control utilizes the standard DMX512 protocol that is available on a wide range of lighting equipment. DMX512 is a simple industry standard protocol that transmits lighting control data to lights (USITT, 2013). DMX lights are “daisy chained” so a single, inexpensive cable goes from the computer to the first light, then another cable continues to the next light. The experimental setup uses an ENTTEC DMX USB Pro interface and four Chauvet Colorband PIX light bars configured for nine channels. The light bars are each mounted on an Odyssey LPT2 tripod T-stand. A lighting configuration program allows for the creation of combinations of lights, called cues that are optionally selected by the dialog box for setting sound and light cues on an instruction. The server communicates with the DMX interface using the ArtNet protocol (License, 1998/2017). ArtNet is a standard protocol that maps data received on a UDP port to DMX channels. This allows the server to work with any DMX interface that supports ArtNet. The ENTTEC DMX interface includes an ArtNet listener as a standalone program.
Menu options are available in the server to set light and sound combinations for events other than instruction execution. These include an initial setting, so music and sound can be selected when the program is loaded and started, but before the first instruction is executed. Also included are settings for an error condition, which is typically indicated by an error sound effect and red lighting, though the desired cue is under user control. The server also has controls that allow the operator to manually select light and sounds cues at any desired time. Experience with theatrical projects has shown that it is very important that the server operator have wide flexibility during a performance or dance.
As participants step through the dance, the lights change color to denote step changes, making dances more engaging. The changing lights work as a reminder for the participant to look down at their tablet when the step changes. They also add a more professional performance aspect to the dances. The server also has the capability to define light cues for certain events – such as participant errors in executing a dance – making the lighting a more interactive aspect of dances as well. Sound output occurs through an amplifier connected to the server with a 3.5-mm cable. During each dance, the server plays music along with the dance steps – as the dance progresses, the music can transition, building on itself in complexity and speed to make dancing entertaining and fun. With each step, the song may have a new sound or instrument added to it. Sound effects were also added to the dances to denote when participants were supposed to start and stop dancing, as well as to denote when errors in the dance occurred. Together, transitions in sound and lighting engage participants while communicating changes in dance steps.
The complete setup includes 36 interlocking floor tiles, four stands with mounted lights, a Roland BA-330 speaker/amplifier, a laptop computer, DMX interface and associated cables. Complete setup in a new location requires approximately 20 minutes for a team of three-4four persons familiar with the design setup.
4.3 Evaluations
The Dancing Computer activity is divided into four stages: pre-assessment, instruction, dancing, and post-assessment. During pre-assessment, participants’ prior knowledge of programming is evaluated through a focus group discussion. Participant responses to basic questions about their knowledge of computers and programming are used to gauge their interest in and past experience with the subjects. Questions asked to the groups included: “Does anyone know what a computer does?” and “Is there anyone here that knows what a program is or does?” Instructors end the pre-assessment by asking “Do you think you could learn to program?” Participants respond, then the instructors move to the next step.
Next, comes the instruction phase, where the basics of the dancing computer system (namely, the meanings of the symbols and instructions shown on the tablets) are taught through a PowerPoint presentation or, for smaller groups, an interactive hands-on tutorial using tablet computers (Figure 8).
After the initial instructional presentation and explanation of the process, the instructors act out a dance while the participants watch. One of the instructors will walk in a specific pattern and the participants will have to give exact commands to the instructor in order for them to repeat the same dance. The dance is repeated until the participants give the correct set of instructions. The usually required no more than two repetitions.
After instruction concludes, participants are ready to dance. Participants take turns stepping through dances – usually in groups of four, but sometimes in larger groups of six or eight as they progress. Beginning dances are relatively simple, with dancers executing similar instructions in unison. Intermediate dances typically have dancers start on different sides and execute different sequences of instructions. Advanced dances introduce more challenging computing concepts such as variables and message passing. Participant’s progress from beginning dances to more advanced ones as they become more comfortable with executing dances.
After all participants have had the chance to do as many dances as time allows, a post-assessment is administered. The post assessment is usually through another focus group. But a written survey where participants write their own dances is used when time and circumstances permit. The same three questions are asked for the post assessment.
5. Experimental evaluation
The Dancing Computer project’s target audience is students ages 8-10 in groups of about 20 students. However, the project has been presented to students of various ages in differing group sizes and settings. Since spring of 2016, Dancing Computer was presented at six different locations to various school groups and summer camps, reaching approximately 250 students.
The pre-assessment was given to each group of participants that participated. Most of the younger groups aged six to eight contained at least three or four children on average that showed some interest in computers. In some instances, a few participants had experience with coding prior to the assessment. Children responded with a variety of answers indicating general knowledge of how computers are used in their everyday life, but little understanding of programming. When asked what a computer program is, some participants had some insight based on programming games that they had played, or because of a parent who had programming experience. Still, few participants had a concrete answer that linked programming to a computer’s actions, or indicated an understanding of programs as sets of instructions. Common responses to the questions were: “A computer can navigate the internet and play video games”. “[A program is] something that you type on a computer that tells it what to do”. When asked and “Do you think you could learn to program?” the majority of participants answered yes. The older groups of kids age 9-11 were usually hesitant to answer while the younger groups seemed enthusiastic. It is a sad fact of life that social factors typically diminish children’s confidence that they can acquire programming as a skill.
During the dancing process, participants were shadowed by instructors from the Dancing Computer team one time, then asked to rely only on the instructions from their tablets to do the same dance again. This provided a means of both providing some assistance while learning and to measuring learning, as the performance in the second iteration could be easily compared to the first. All sessions were video recorded, and the data were manually annotated using Behavioral Observation Research Interactive Software (BORIS). The annotations included the type of dance performed, the iteration (first or second take), any errors and the exact times of start, end and all detected errors. Three types of errors were marked in the content: movement, orientation and rotation. A movement error indicates that the participant either moved too many steps or not enough. An orientation error refers to the participant moving in the correct direction but then rotating once they stop so that they face the wrong direction. Rotation errors indicate that a participant incorrectly executed rotation instructions, either rotating too much, the wrong direction, too little or not at all.
Dances were classified in levels of difficulty. All participants started with an L1 dance. L1 dances have limited number of movement indications, so participants could concentrate on the instruction following and enforce greater symmetry among the dancers. L2 dances added additional dance instructions and allowed more complex movements and interactions. Variables were also included in some L2 dances. L3 dances of considerably increased difficulty were also utilized, but only for older participants. L3 dances included concepts including more complex variable interactions and the message-passing activity. L1 dances were an average of 73 seconds in length, while L2 dances averaged 106 seconds. Dances included in the analysis included four participants, though some experiments were done with larger numbers up to eight. Only dances prepared by Dancing Computer staff were included in the data analysis. Additional data were collected on dances prepared by participants, but were not included in the analysis. In general, the dances written by the participants tended to be relatively simple and short and were always executed by participants who had already had experience with the system, including the participants who wrote the dance, so the error rates for these dances were very low (only one error was recorded among five different dances that were annotated in the data analysis).
Table I presents the average duration and error rates for the L1 and L2 dances.
As can be seen, both durations and error rates always decreased from the first to the second take, which is an indication that participants were learning to understand and correctly perform the instructions being presented on their tablet. The improvement is even more significant in that the first take always included shadows, that is team members who would help the participant interpret the dance and read the instructions. The second take was entirely the participant’s own actions, though errors were corrected when they occurred to avoid participant running into each other. The average errors per dance were relatively small for an activity lasting more than a minute and a half in most cases. The average errors in Table I are for all participants in a dance. The numbers would be divided by four to determine the errors per participant.
Movement errors, meaning the dancer did not move the correct number of squares or moved in the wrong direction, were the most common, encompassing 50 per cent of all errors. Furthermore, 27 per cent of errors were because of mistakes in rotation, meaning the dancer rotated the wrong amount or rotated in the wrong direction, and 23 per cent of errors were due to an incorrect orientation change, meaning the dancer turned at some point without direction from the tablet. Orientation errors indicate either a failure to understand how computer execute instructions (a computer would not do anything it is not told to do.) or environmental distractions (friends, outside sounds, etc.). Both movement and rotation errors usually indicated confusion about the tablet’s instructions. Participants often were confused about how many degrees to rotate or which direction to move.
The duration statistics all show improved performance from the first to the second take. This demonstrates that participants are learning to read the instructions on the tablet and correctly perform them. The decrease from Take 1 to Take 2 for L2 dances is less due to learning the interface and more due to acquiring fluency. This is mostly due to the fact that all participants completed an L1 dance before they attempted an L2 dance, so they had already benefited from training. The decreases in errors for L2 dances can then be partially attributed to learning the dance, rather than just the interface, though the more complex activities in the L2 dances did require additional learning.
By the time participants reached the L3 dance, they were usually quite proficient and did not require help. In addition, the number of participants for the L3 dances was relatively small, so those data are not included here.
Post-assessment revealed mixed results. When asked what computers did a second time, some participants made the connection that computers rely on instructions from people, but other groups were less responsive. The responses range from: “A computer does what you tell it to” to “a computer can run programs”. Additionally, some participants were able to write their own dances, remembering and reproducing the Dancing Computer instructions fairly accurately. Other participants, however, wrote instructions unrelated to those shown in the Dancing Computer activity, e.g. “kick line” and “free style”.
6. Future work
Though the Dancing Computer project already teaches many different programming concepts, still more could be addressed through different software features. In addition to variables, pieces could be added in the future to implement conditional or loop behavior. Conditional pieces could direct participants to do certain instructions based on variable value (if X = 2 […]) or other custom factors (“If you’re on a red square […] ”), while loops could direct participants to repeat instructions based on a counter variable (“While X < 3 […] ”). Adding complexity to programs while illustrating more concrete programming concepts could involve older participants or those with prior programming experience while furthering the computing metaphor.
For advanced participants, the computing metaphor can be furthered by instruction in concurrency. Just as each dance represents a program, each dancer can represent a thread in that program. Furthermore, by passing batons labeled with constants (e.g. A = 2) back and forth during a dance (as directed by their tablets), dancers can even simulate message passing between multiple threads. This concept was tested in July 2016, at a local engineering camp. Because participants at this camp were high-school age (and thus outside of the target demographic), more complex concepts were introduced to increase participant engagement. Participants were entertained by the baton-passing mechanic, thus finalizing this feature in the future may prove useful. Allowing users to define groups’ different constants and building more information concerning parallel computing into teaching material would both be valuable goals for the project.
Although the project’s target age group is elementary participants, Dancing Computer has seen success with older participants as well. Many older participants had heard of programming before and grasped the initial concepts quickly, which make it much easier to move on to more complex concepts during the session. Concerns that the music and stylings of the activity may seem too juvenile to older participants also proved unfounded, as high school participants enjoyed the activity with no changes to the sound or lighting. Thus, bringing the Dancing Computer activity to older participants or more experienced programmers may be worth studying in the future.
One of the major end goals of the Dancing Computer project is to create an open source project, so that educators may use the Dancing Computer activity in their own classrooms. The server will be available online, and the client would be available for free in the Google Play store. Documentation will also be written to aid teachers in setting up the Dancing Computer floor, as well as configure lighting and sound using their own materials.
Funding for this research was provided by a grant from the Dart Foundation. Original music generously provided by Bill Sallak, Assistant Professor of Music at the University of Wisconsin-Green Bay. David Kanouse provided patterns of movement that were incorporated into many of the dances. Special thanks are in order for the Michigan State University Theatre Summer Camp, the Lansing iTEC summer camp and Impression 5 Science Center for allowing the authors to work with a very diverse groups of students.
Figure 1.
Example dance program
[Figure omitted. See PDF]
Figure 2.
Statement presentation on tablet
[Figure omitted. See PDF]
Figure 3.
Dancing Computer in action
[Figure omitted. See PDF]
Figure 4.
Dancing Computer system diagram
[Figure omitted. See PDF]
Figure 5.
Dancing Computer server
[Figure omitted. See PDF]
Figure 6.
Example dance floor
[Figure omitted. See PDF]
Figure 7.
Selecting lighting and music cues
[Figure omitted. See PDF]
Figure 8.
Instructions shown to participants
[Figure omitted. See PDF]
Table I.Average durations and error rates
| Dance | Count | Duration | Movement | Orientation | Rotation |
|---|---|---|---|---|---|
| L1 - Take 1 | 42 | 84.02 | 1.43 | 0.55 | 0.55 |
| L1 - Take 2 | 26 | 54.18 | 0.38 | 0.38 | 0.27 |
| L2 - Take 1 | 19 | 114.59 | 1.53 | 0.84 | 0.74 |
| L2 - Take 2 | 11 | 84.76 | 0.82 | 0.82 | 0.55 |
© Emerald Publishing Limited 2017