Digital interaction design
Microsoft's Hacking STEM is a library of Arduino-based learning activities for elementary school students. We were asked to create a potential new entry to the catalog, including both a physical experiment and a digital interface.
We were also tasked with basing the experiment on a learning objective from the Next Generation Science Standards (NGSS). We chose the standards:
4-PS3-4: Apply scientific ideas to design, test, and refine a device that converts energy from one form to another.
ETS1-3: Plan and carry out fair tests in which variables are controlled and failure points are considered to identify aspects of a model or prototype that can be improved.
Our project won an award for Best Technical Implementation during a showcase at Microsoft in Redmond, WA.
Our response was the Trebuchet Trials: a 4th grade level activity that explores transformation of energy in a medieval trebuchet.
Students assemble a trebuchet out of printed cardstock templates, attach an accelerometer to the arm of the trebuchet, and begin recording potential and kinetic energy values on a digital interface.
Students can interchange the amount of weights and types of projectiles they use, and record data simply by playing with the trebuchet. Historical data is kept accessible as students play, and prompts them to actively look for patterns. They then apply the knowledge from playing to a series of challenges. For example, students are asked to launch projectiles with a certain amount of kinetic energy or to compete with their teammates for the farthest launch.
We developed this activity with the help of teachers, students, and Microsoft Education.
It comes with a set of build instructions, and costs roughly $4 per student, exluding the Arduino and laptop.
I took ownership of the digital interface design and physical computing aspects on the project, creating the functional prototype with HTML, CSS, JS, and P5.js. Some notable features are:
Mapping between physical and digital space
Moving the trebuchet's arm will make the digital trebuchet follow along in real-time, a response to our learning that an interface for kids needs to be particularly engaging and delightful.
Calculating kinetic and potential energy
Using a mix of timing and position functions, potential and kinetic energies of the system are calculated and updated in real-time as students use the experiment. Instant feedback makes the interface more engaging and allows students to focus on identifying patterns, not drawing charts.
Setting specific goals
A challenges section encourages students to apply their learning to achieve specific goals. Teacher feedback and prototype testing has shown that students are more engaged when given specific desired outcomes.
Teacher preparation is minimal; they only need to print out a set of templates onto cardstock and gather a few other common supplies. The templates contain build instructions, namely a series of cutting, folding, and taping tasks that are split among groups of three students.
An interactive prototype is coming soon–the current version isn't quite responsive yet, and would probably look terrible on your screen. Hang tight!
Ideation & down-selection
A DIY speaker, hydroelectric turbine, genetically breeding robotic cats... our initial ideation and research aimed to expand our knowledge of the STEM education space. Concepts were developed by selecting interesting NGSS standards and devising a digital-analog experiment to teach that standard. Inspiration was also gathered from pioneers like Mitchel Resnick, who espouses a constructivist approach to STEM education (essentially, learning through experience).
We honed in on three of our ideas: a trebuchet, a speaker, and a hydroelectric turbine, and created physical and video prototypes to better flesh out each one.
We then gathered feedback from stakeholders–kids responded positively to the speaker and the trebuchet, while our Microsoft contact expressed reservations about the potential chaos of classroom trebuchets. Teachers seemed receptive to the idea and gave us confirmation on the appropriateness of its educational value.
"In fourth grade we do an energy unit and this could perfectly tie into the unit and actually work better than some of our existing Science experiments... I would totally purchase this kit for our energy unit next year if you created it."
– Katie, 4th grade teacher
Ultimately we moved forward with the trebuchet. We knew that it was engaging for kids, and that the educational aspect was valid, but that one of our larger design challenges would be securing stakeholder buy-in. We also were unsure of some of the technical aspects–which sensors could we use to collect the data needed to calculate energy?
Testing & refining
After narrowing to the trebuchet, we made a set of updates to the physical form and began generating ideas for the digital interface.
Our next set of questions focused on learning if the assembly and experimentation were age-appropriate, and testing assumptions about how data recording and analysis might work.
We developed a Wizard of Oz prototype that simulated how these pieces might work together–a fake sensor and a layered Figma document allowed us to show dynamic energy “results” as the participants used the trebuchet.
The tests inspired a set of significant changes–mainly that the experimentation aspect would focus on the counterweights and the projectiles, as opposed to the position of the arm. We removed a paper data tracking worksheet and opted to integrate data-tracking into the interface. We also changed the data visualization from a line graph to a bar chart to better connect with the type of data being collected.
Validation in the classroom
We had the opportunity to test with a group of eighteen 4th graders during their classtime at a local elementary school. This was our chance to evaluate if the activity would descend into chaos–a potential death knell for the trebuchet. We also tested an updated physical form, now with a more period-accurate sling-and-pouch design to hold the projectile.
Surprisingly… it didn’t! After a short demo, we had kids form groups to assemble and test the trebuchets. The building process was significantly quicker than we imagined, the educational value was apparent, and we received positive feedback from both students and the teacher.
“Blake usually struggles a bit with school subjects and isn't as engaged as the other kids. But he loves building, and it was nice to see him really brighten up today.”
– Katie, 4th grade teacher
“I would buy this for one trillion dollars!”
– Angel, 4th grader
We also discovered room for improvement; for instance, the pouch for projectile launching had a high rate of failure–we decided to move back to the cup design in order to reduce frustration with launching. Additionally, it quickly became a game of "who can launch this this furthest?". The kids weren't exploring the full range of variables in the trebuchet.
The teacher also suggested that we incorporate specific goals for students to achieve in order to make the experiment more guided. We used this feedback to develop a set of challenges in the digital interface.
I felt that the success of this test was largely due to the fact that our homemade trebuchet just wasn’t that good. It launched fairly short distances even with a bunch of weights added– but that happened to be the perfect way to control chaos in the classroom, while still allowing for fun and play.
We kept this in mind as we developed a cheaper cardstock template version of the experiment.
Developing the tech
While we were testing and validating the viability and desireability of the experiment, I took ownership of testing its feasibility. What types of data did we need to collect, what (cheap) sensors could give us that information, and then how could we process that information in an engaging way?
To measure kinetic and potential energy, you need to be able to measure mass, speed, and position, so I looked at some of Microsoft's current ways of measuring these values. Mass is typically measured with scales, speed with infrared sensors, position with a mix of different methods.
How could we do this with as few sensors and as simple wiring as possible? After a lot of experimentation I realized that I could measure just about everything I needed with an accelerometer (~$5).
Through some clever math, the accelerometer could give us speed and position, but not weight. We decided on a discrete weight system–students place weights in a container and increment the value in the digital interface.
The tradeoff here was that students needed to manually input the number of weights into the interface, but in return would need to only attach one extremely simple sensor.
Developing and testing the interface
The development of tech and interface were in direct conversation with one another; we were often limited by our ability to solve certain technical constraints. However, some features were developed only through tinkering with code: for example, I discovered a way to automatically graph every trial after launch. This helped fulfill our goal of reducing manual information input.
Another round of testing with kids focused on testing the relationship between the digital interface and the physical trebuchet. The functioning prototype used a barebones interface to display current and historical energy data measurements as students played with the experiment.
We also tested the hypothesis that setting specific goals would make the experiment more engaging, which turned out to be true. Students started to show teamwork and focus when we prompted them to aim for specific goals.
However, our interface was not as engaging as we anticipated; the kids were still focused on the trebuchet. In response, I developed an interactive trebuchet graphic that mapped 1:1 with the arm position of the physical trebuchet and introduced a graphical overhaul to the rest of the interface.
Reflecting on the experience
Designing with such a tight set of constraints gave our team the ability to rapidly ideate, downselect, and test our concepts and assumptions. We were always able to fall back on a set of key questions–is this achieving our desired NGSS standard? Will this cost less than $10 per student? Would this work in a classroom?
Possibly the most difficult aspect was meeting the needs of multiple stakeholders–teachers, students, and Microsoft Education would sometimes give clashing feedback. Our use of prototypes–from behavioral, to video, to functional, varied according to the particular stakeholder, and allowed us to triangulate design insights through our interactions with each party.
There a number of things which we would have liked to implement, given more time. In order to accomodate any kind of available weight, I could create a calibration sequence at the beginning of the experience–this would allow us to avoid the manual input of weights in the interface.
The cardstock template system was our simplest build implementation, but it could have been made even simpler and allowed for more experimentation on the students’ part. A next step could be to allow for students to add their own DIY pieces to the trebuchet.