ABSTRACT: Research into students’ understanding of complex systems typically ignores young children because of misinterpretations of young children’s competencies. Furthermore, studies that do recognize young children’s competencies tend to focus on what children can do in isolation. As an alternative, we propose an approach to designing for young children that is grounded in the notion of the Zone of Proximal Development (Vygotsky 1978) and leverages Activity Theory to design learning environments. In order to highlight the benefits of this approach, we describe our process for using Activity Theory to inform the design of new software and curricula in a way that is productive for young children to learn concepts that we might have previously considered to be “developmentally inappropriate”. As an illuminative example, we then present a discussion of the design of the BeeSign simulation software and accompanying curriculum which specifically designed from an Activity Theory perspective to engage young children in learning about complex systems (Danish 2009a, b). Furthermore, to illustrate the benefits of this approach, we will present findings from a new study where 40 first- and second-grade students participated in the BeeSign curriculum to learn about how honeybees collect nectar from a complex systems perspective. We conclude with some practical suggestions for how such an approach to using Activity Theory for research and design might be adopted by other science educators and designers.

Award Recipient: This paper received the award for the Best Design Paper at CSCL 2011!

ABSTRACT: The Semiotic Pivots and Activity Spaces for Elementary Science (SPASES) Project was implemented as a proof of concept. Our goal was to demonstrate that with the right set of technological supports, young children can start their learning trajectory in science off on the right foot by engaging in rich scientific investigations into complex science topics. The SPASES curriculum was successfully implemented in two multi-age classrooms of 43 students aged 6-8 years at a progressive elementary school in Los Angeles, CA. Pre/Post-test results show that these 6-8 year old students were able to develop a conceptual understanding of force, net force, friction and two-dimensional motion after participating in the SPASES curriculum which leveraged their prior experiences and ability to engage in embodied play as a form of scientific modeling.

ABSTRACT: All too often, designers assume that complex science and cycles of inquiry are beyond the capabilities of young children (5-8 years old). However, with carefully designed mediators, we argue that such concepts are well within their grasp. In this paper we describe two design iterations of the BeeSign simulation software that was designed to help young children learn about honeybees collect nectar from a complex systems perspective. We summarize findings from two studies that suggest that this design has been successful in teaching and motivating these young children and demonstrates how activity theory can guide design.

You may also want to try BeeSign 1.3 or read more about the BeeSign Project.

Context of use:

BeeSign was designed to be used in kindergarten and first grade classrooms, as part of a group inquiry process lead by a teacher. In the original BeeSign study, the teacher lead groups of around 8 students in discusing the behavior of honeybees while sitting around a shared smartboard where BeeSign was projected. The interactive whiteboard allowed everyone to see the current state of BeeSign as well as allowing students to directly control the interface. In addition, the whiteboard makes it easy for students to label the simulation window, draw their predictions of how bees will behave, and also represent the way that bees did behave in prior BeeSign runs for easy comparison and discussion.

The key thing to keep in mind is that BeeSign was not intended as a “game”, but rather a simulation where students can explore the behavior of the hive with the help of their peers and an adult. So, if you ask students to simply “play” it is likely they won’t know what to do. However, it is possible to structure the activity in many ways, including games. For example, with the “random dance game” mode, it is possible to hide the description of the hives, and randomly assign one to the behavior where bees dance, and one to the behavior where bees simply return to a flower. Then, a guessing game can be played where students vie to be the first to raise their hand to indicate that they know which hive is dancing and which was not. This game was introduced during the CCRP project and the students were not only excited to play it, but it also appeared to help them cement their understanding of the patterns in bee flight that emerge from watching the different hives collect nectar.

Getting started and changing files with the Teacher Panel:

When you first start BeeSign, it will load the default “file”. Each file specifies an initial arrangement of flowers, hives, and other variables. You don’t need to use the files as you can change each variable individually, but I have found that collecting a group of settings into one file makes it faster to change settings when engaged in a BeeSign session with the students.

To select a new file:

1. Click the Teacher Panel button in the top center of the screen .
2. Then, click the “files” button in the top of the teacher control panel.
3. If you select a file in the list on the left, a description will appear on the right.
4. Click “Open” when you have chosen a file.

Note that some of the more advanced variables that effect the entire simulation can be accessed from within the Teacher Panel. If you click the button next to one of the features within the Teacher Panel, you will see a brief description of each feature.

Simulations:

The BeeSign window displays two simulation windows side-by-side to make it easier to compare the bee behavior in two different situations. Each window consists of a hive and a background. You may then add flowers to the simulation window. When you press the play button in the bottom left corner of the screen, the bees will begin flying around the hive, and will visit any flower that they find in order to collect nectar.

Below each window is a small clock. This clock displays how much time has passed since play was pressed. If you press stop next to the clock, only that window will stop. This way, it is possible to stop one or the other window in response to an event such as the hive being full of nectar. It is then easy to compare how long it took for the hive to fill up. If you unclick the check-box next to the clock, the specified simulation will not run when you press play.

Arranging a simulation window:

To move flowers around within the simulation window:

1. First, pause the simulation.
2. Then, click on the flower and hold the mouse button down.
3. Move the mouse to move the flower.
4. Let go of the mouse button when you are done moving the flower.

Note that you can move flowers between the simulation windows. To delete a flower, go to the editor panel (described below) and click on the trash can.

To add a new flower, click on the cupboard below the left simulation window. Then, you can drag a flower from the cupboard to either simulation window.

Editing Variables:

Each of the objects (the hive, flower, background) within BeeSign has a number of variables that specify how the object behaves within the simulation. To change one of these, click on the edit button next to the item. The edit button is a small black and yellow circlethat is located at the bottom right corner of the object. If you do not see any edit buttons, they have been temporarily disabled. They can be turned back on using the drop-down menu located inside the cupboard that is used to add new flowers (see above). When you click on the edit button, an editor panel will appear. You may then change the variables, and click the x in the top right corner when you are done.

Below is an example of the edit button that you will see for a hive.

Note that you can change the number of bees in the hive, the amount of nectar that the hive requires to be full, the behavior of all of the bees in the hive, and the minimum nectar quality that the bees in the hive are willing to collect.

In addition, each editor panel also has a section labeled “Represent”. This is how you can decide what additional information might be displayed next to the object. In this case, the user has chosen to display the amount of nectar as “both” an image and words. The image is a bar-graph to the left of the hive, and the words display the exact amount of nectar. It is also possible to tell an object to represent “nothing” in which case you will see an image of the object, but no additional information regarding it.

Below is an example of a flower editor panel. Note that there is a trash can to the right of this panel. If you click this trash can, it will delete the flower from the window.

Note that the flower editor panel has tabs which make it possible to change the look of the flower, the quality and amount of nectar, and the smell of the flower. You can also change the representation that is attached to the flower, similar to the hive.

The match button:

One of the ways to use BeeSign effectively is to help students conduct experiments where they look at two simulation windows that only differ with respect to one variable. So, for example, if both windows have the same number and arrangement of flowers, but the bees in one dance, and the bees in the other do not, then it is possible to see whether the dance makes a difference in how quickly the bees will collect nectar. To make it easier to arrange the windows in this way, you can arrange either window, and then simply click the “match” button beneath it . This will automatically arrange the second window in an identical manner. You can then change the one variable that is the focus of your experiment.

Contact:

For questions, comments, or suggestions, please contact Joshua Danish.

Try BeeSign 1.3 | Instructions

BeeSign 1.0 was originally created as part of the BeeSign project for use in the First BeeSign Study. The current version, 1.3, was created for use with Cross-Curriculum Representational Practices Project (CCRP).

For a list of all materials related to BeeSign, click here

Wait, what is an interactive whiteboard and why are you using one?

An interactive whiteboard is essentially a whiteboard that you can control as if it were a computer. Typically, you hook an interactive board up to a computer so that a) the computer screen is projected onto the whiteboard, and b) you can control the computer projection by interacting directly with the board. One of the major interactive whiteboard brands lets you use your finger (or any other object) to control the board, while another requires a special stylus that looks like an electronic whiteboard marker.

Figure 1: A student labeling BeeSign on an interactive whiteboard. Click to enlarge.

My criteria

The way I use the interactive whiteboard is a bit different from most teachers, who either use it as an easy way to present information from the front of the classroom or as a way to let students come up to the board and make changes. However, here are some of the issues I encountered and the resulting criteria for a whiteboard and software.

• The stylus limits access: When you have a room full of 6-year-olds scrambling to make adjustments to your whiteboard, sometimes it behooves you to have a way of limiting their access so that they can’t just run up and start poking around (think conch shell!). Other times, that might be exactly what you want.
• The finger is easier, but maybe too easy: It is, particularly for 7-year-olds, considerably easier to use your finger to control an interactive whiteboard than it is to use a bulky stylus. The unfortunate corollary to this, though, is that anytime you touch some interactive whiteboards, things will start moving around. It is incredibly difficult to annotate a simulation if moving your marker across the board moves an object instead of labeling the object.
• Annotations are tricky: The interactive whiteboards I have seen ship with tools to let you label whatever screen is displayed. I’ve seen some teachers use this incredibly effectively to label different parts of a math problem while working through the solution. The problem with this, though, is that you have to “freeze” the screen to label it, which is not terribly useful if you want to see how your labeled prediction matches up to a simulation that is running. One solution is to build the annotation tool into your simulation. Another is to make sure you can still use normal whiteboard markers.
• Is the whiteboard fragile? One of the trade-offs that comes in having a whiteboard that is designed to be an interactive whiteboard vs. a normal whiteboard that is converted is how casually you can treat the whiteboard. In a recent study, for example, we were afraid to use normal whiteboard markers on our interactive whiteboard because they aren’t 100% removable and the teacher we were working with was afraid they would stain the board. On the other hand, cheaper boards that no one minds staining aren’t always as easy to control.
• Portability: Simply put, some interactive whiteboards are easier to move around the classroom or to a different classroom than others. The tradeoff is often that less-portable whiteboards are more stable and require fewer recalibrations, etc.
• Height: You may or may not have a lot of flexibility with how high some whiteboards stand. Working with kindergartners who can barely reach 1/2 way up a board, though, has made me very aware of how easily a whiteboard can be lowered and whether the software can be controlled on the bottom half of the screen. That’s why a number of key BeeSign elements are on the bottom.
• Control of your software: Interactive whiteboards tend to have ways of letting you use the right button on your mouse, or trigger the equivalent of a mouse rollover event. Similarly, they also have built-in virtual keyboards. However, these are a real hassle to use and are best avoided. Some software relies heavily on these, and other software does not. I also discovered that when developing in Flash (the tool I used to develop BeeSign, and the tool that was used to develop the SPASES client) a double-click does not work as well on an interactive whiteboard. You can’t always design your own software, but you can definitely test-run the main software you will use on an interactive whiteboard to confirm that it works properly. Some boards are better than others, and your needs will dictate the kind of control you need in your whiteboard.
• Shadows: Unless you are using a rear-projection interactive whiteboard (read: the most expensive ones) you will have some shadows on the screen from people standing between the projector and the whiteboard. While these shadows can be minimized by mounting the projector on the ceiling or buying an interactive whiteboard with a built-in projector arm, both alternatives are somewhat more expensive. My partial solution in designing my own software is to try and put as much functionality as possible on the sides of the screen, or on the bottom. This keeps people from having to stand directly in front of the projector. Again, though, we can’t always design our own software, so this, too, is something to keep in mind.

That’s it for now. If you have other suggestions, please let me know! Otherwise, as I run into opportunities or problems I’ll be sure to update this list.

Examples

To see which projects and publications involved interactive whiteboards, click on the the Interactive Whiteboard tag to the right.

The CCRP project has two main goals:

1. To further examine students’ understanding of complex systems related concepts in the context of honeybees collecting nectar.  In short, a follow-up to several aspects of the first BeeSign study with a modified curriculum to reflect lessons learned from the prior implementation.
2. To further our understanding of students’ representational practices by examining them in both science and language arts.  This will provide some important contrast and further unpack the influence of context upon students’ representational activities.

This is a collaboration with Kylie Peppler and David Phelps.

This project also makes use of the BeeSign simulation software.

Young students are good at pretend play. The defining feature of pretend play is not that it is fun (although it often is). The defining feature of play is that it has both an imaginary situation and a set of rules. It is focus on a set of rules that makes play an interesting “pivot” and allow us to put play to work. Like play, the physical world (and computer simulations of force and motion) follow a set of rules. SPASES uses computer-enhanced, embodied play as a means for children to uncover the hidden rules of the physical world.

This project is a collaboration with Noel Enyedy, Fabian Wagmister, Jeff Burk, and Girlie Delacruz Adreani.