Monthly Archives: May 2013

My latest app project: 5K Race Timer

I happened to attend a meeting a little more than a month ago for the committee that organizes the Dragon Run. This is one of the school's biggest events and requires quite a group of people to make happen. One of the biggest challenges that the group faces is the timing of the race and management of this data for the 120+ runners that participate in the official event.

The scheme used in previous years has been a very well thought out system of spotters with pencil and paper lists and a race timer placed at the finish line. When runners register, they give an estimated time for their run, which places them in a few different speed categories. Each spotter has a list of runner numbers from each category so that they are searching for particular runner numbers throughout the time span of the race. When a runner crosses, the spotter records the time on their sheet. This time is then later fed into a spreadsheet that gives everyone's time. These results are then collated and printed to give the results list after the race.

I'm trying not to be a hammer looking for a nail here, but this seemed like a perfect opportunity to try to use the power of the computer to reduce some of the mental and paper load of this task. My learning obsession with Python web apps and even more recent desire to learn about databases quickly helped me see some easy ways to do this. These were the main points that I wanted as part of the UI:

  • Upon seeing a runner approach the finish line, the spotter should be able to send a 'stop' command at the moment that runner crosses the line. Calculating the finish time relative to the start of the race and recording that information is screaming for a computer solution. This capitalizes on the human spotter's ability for to recognize a runner's number by sight, leaving the rest of the work to the program to do.
  • We would need a simple interface for starting the race and stopping individual runners with a button press.
  • A non-trivial number of runners register on the day of the race. There needs to be a way to manually add runners to the database easily.
  • Mistakes also come up in recording times and entering data. Editing a runner's information, including finish time, is a necessity.
  • Manually entering all the runners into the database before the race? Heck no. The organizers use a spreadsheet to record all of the registration information, which is a CSV file asking to be made and inputted to the database automatically.
  • Creating a list of runners based on category and ranked according to race finish time is another exhausting task when done purely by spreadsheet. This process in the program should make the most of SQL queries and Python/Bottle template features to generate the race results automatically.
  • To properly see if this system would work, I'd need a way of showing numbers passing by similar to what actually happens during a race. I put together a Javascript simulator to do this using Raphael that can be found here. This was especially important in testing the system with my student volunteers.

The organizers agreed to let me run my software as a beta test to see if it would work for future years. More insight and conversation led to the idea of a mobile application to be used to enter runner numbers. I agreed that this would be an easier way to locate runners than looking down a list, but had no idea how to do this. I did research and figured out the jQuery Mobile would be the way to do it. This was a difficult learning process having never done this sort of thing before. I battled with the "ghost click" problem for a while until discovering that the 'touchend' event was an easy fix.
Screen Shot 2013-05-26 at 5.12.20 PM


Here's the software as used on race day:

UPDATE Mar. 2016: I've taken down the site to save some memory on my server. Write me if you are interested in the details.

The system worked really well, but ran into some of the same challenges that the pencil-and-paper spotters have been battling since the event's inception. It's really hard to simultaneously grab the numbers of a group of 4-5 runners that all come in at once. The system that my students devised for identifying who was going to enter a particular runner approaching the finish line broke down in two specific instances of this, and we missed runners. Luckily pencil and paper picked up the ones we missed. Definitely still in beta. The process of generating results lists and recording times overall worked quite smoothly, and I'm really happy with how it turned out.

Notes:

  • Bottle, Twitter Bootstrap, jQuery Mobile, and vanilla Javascript were all in play.
  • I learned at the race that there are already software packages out there. Now that I've done a quick search, it seems that while there is a lot of software out there, the ease of running it through a web interface (and snagging runners through a mobile interface) is a relatively young feature. This project was about me learning to do some new things, and in the end it cost me (and the school) nothing other than time.
  • I learned a lot about user centered design through this project. Usability was a necessity, so I had to start from there and work backwards to build the code needed to make it happen. I really like thinking this way,

Speed of sound lab, 21st century version

I love the standard lab used to measure the speed of sound using standing waves. I love the fact that it's possible to measure physical quantities that are too fast to really visualize effectively.

This image from the 1995 Physics B exam describes the basic set-up:
Screen Shot 2013-05-16 at 3.43.30 PM

The general procedure involves holding a tuning fork at the opening of the top of the tube and then raising and lowering the tube in the graduated cylinder of water until the tube 'sings' at the frequency of the tuning fork. The shortest height at which this occurs is the fundamental frequency of vibration of the air in the tube, and this can be used to find the speed of sound waves in the air.

The problem is in the execution. A quick Google search for speed of sound labs for high school and university settings all use tuning forks as the frequency source. I have always found the same problems come up every time I have tried to do this experiment with tuning forks:

  • Not having enough tuning forks for the whole group. Sharing tuning forks is fine, but raises the lower limit required for the whole group to complete the experiment.
  • Not enough tuning forks at different frequencies for each group to measure. At one of my schools, we had tuning forks of four different frequencies available. My current school has five. Five data points for making a measurement is not the ideal, particularly for showing a linear (or other functional) relationship.
  • The challenge of simultaneously keeping the tuning fork vibrating, raising and lowering the tube, and making height measurements is frustrating. This (together with sharing tuning forks) is why this lab can take so long just to get five data points. I'm all for giving students the realistic experience of the frustration of real world data collection, but this is made arbitrarily difficult by the equipment.

So what's the solution? Obviously we don't all have access to a lab quality function generator, let alone one for every group in the classroom. I have noticed an abundance of earphones in the pockets of students during the day. Earphones that can easily play a whole bunch of frequencies through them, if only a 3.5 millimeter jack could somehow be configured to play a specific frequency waveform. Where might we get a device that has the capacity to play specific (and known) frequencies of sound?

I visited this website and generated a bunch of WAV files, which I then converted into MP3s. Here is the bundle of sound files we used:
SpeedOfSoundFrequencies

I showed the students the basics of the lab and was holding the earphone close to the top of the tube with one hand while raising the tube with the other. After getting started on their own, the students quickly found an additional improvement to the technique by using the hook shape of their earphones:
Screen Shot 2013-05-16 at 4.03.13 PM

Data collection took around 20 minutes for all students, not counting students retaking data for some of the cases at the extremes. The frequencies I used kept the heights of the tubes measurable given the rulers we had around to measure the heights. This is the plot of our data, linearized as frequency vs. 1/4L with an length correction factor of 0.4*diameter added on to the student data:
Screen Shot 2013-05-16 at 4.14.22 PM

The slope of this line is approximately 300 m/s with the best fit line allowed to have any intercept it wants, and would have a slightly higher value if the regression is constrained to pass through the origin. I'm less concerned with that, and more excited with how smoothly data collection was to make this lab much less of a headache than it has been in the past.

Visualizing the invisible - standing waves

I wrote a post more than a year ago on a standing waves lesson I did. Today I repeated that lesson with a few tweaks to maximize time spent looking at frequency space of different sounds. The Tuvan throat singers, a function generator, and a software frequency generator (linked here) again all made an appearance.

We focused on the visceral experience of listening to pure, single frequency sound and what it meant. We listened for the resonant frequencies of the classroom while doing a sweep of the audible spectrum. We looked at the frequency spectrum of noises that sounded smooth (sine wave) compared to grating (sawtooth). We looked at frequencies of tuning forks that all made the same note, but at different octaves, and a student had the idea of looking at ratios. That was the golden idea that led to interesting conclusions while staring at the frequency spectrum.

Here is a whistle:
Screen Shot 2013-05-13 at 3.10.40 PM
...a triangle wave (horizontal axis measured in Hz):

Screen Shot 2013-05-13 at 3.09.45 PM

...a guitar string (bonus points if you identify which string it was:
Screen Shot 2013-05-13 at 3.12.14 PM

...and blowing across the rim of a water bottle:
Screen Shot 2013-05-13 at 3.14.04 PM

The ratios of frequencies for the guitar string are integer multiples of the fundamental - this is easily derived using a diagram and an equation relating a wave's speed, frequency, and wavelength. It's also easily seen in the spectrum image - all harmonics equally spaced with each other and with the origin. The bottle, closely modeled by a tube closed at one end, has odd multiples of the fundamental. Again, this is totally visible in the image above of the spectrum.

I'm just going to say it here: if you are teaching standing waves and are NOT using any kind of frequency analyzer of some sort to show your students what it means to vibrate at multiple frequencies at once, you are at best missing out, and at worst, doing it plain wrong.

Rethinking the headache of reassessments with Python

One of the challenges I've faced in doing reassessments since starting Standards Based Grading (SBG) is dealing with the mechanics of delivering those reassessments. Though others have come up with brilliant ways of making these happen, the design problem I see is this:

  • The printer is a walk down the hall from my classroom, requires an ID swipe, and possibly the use of a paper cutter (in the case of multiple students being assessed).
  • We are a 1:1 laptop school. Students also tend to have mobile devices on them most of the time.
  • I want to deliver reassessments quickly so I can grade them and get them back to students immediately. Minutes later is good, same day is not great, and next day is pointless.
  • The time required to generate a reassessment is non-zero, so there needs to be a way to scale for times when many students want to reassess at the same time. The end of the semester is quickly approaching, and I want things to run much more smoothly this semester in comparison to last.

I experimented last fall with having students run problem generators on their computers for this purpose, but there was still too much friction in the system. Students forgot how to run a Python script, got errors when they entered their answers incorrectly, and had scripts with varying levels of errors in them (and their problems) depending on when they downloaded their file. I've moved to a web form (thanks Kelly!) for requesting reassessments the day before, which helps me plan ahead a bit, but I still find it takes more time than I think it should to put these together.

With my recent foray into web applications through the Bottle Python framework, I've finally been able to piece together a way to make this happen. Here's the basic outline for how I think I see this coming together - I'm putting it in writing to help make it happen.

  • Phase 1 - Looking Good: Generate cleanly formatted web pages using a single page template for each quiz. Each page should be printable (if needed) and should allow for questions that either have images or are pure text. A function should connect a list of questions, standards, and answers to a dynamic URL. To ease grading, there should be a teacher mode that prints the answers on the page.
  • Phase 2 - Database-Mania: Creation of multiple databases for both users and questions. This will enable each course to have its own database of questions to be used, sorted by standard or tag. A user can log in and the quiz page for a particular day will automatically appear - no emailing links or PDFs, or picking up prints from the copier will be necessary. Instead of connecting to a list of questions (as in phase 1) the program will instead request that list of question numbers from a database, and then generate the pages for students to use.
  • Phase 3 - Randomization: This is the piece I figured out last fall, and it has a couple components. The first is my desire to want to pick the standard a student will be quizzed on, and then have the program choose a question (or questions) from a pool related to that particular standard. This makes reassessments all look different for different students. On top of this, I want some questions themselves to have randomized values so students can't say 'Oh, I know this one - the answer's 3/5'. They won't all be this way, and my experience doing this last fall helped me figure out which problems work best for this. With this, I would also have instant access to the answers with my special teacher mode.
  • Phase 4 - Sharing: Not sure when/if this will happen, but I want a student to be able to take a screenshot of their work for a particular problem, upload it, and start a conversation about it with me or other students through a URL. This will also require a new database that links users, questions, and their work to each other. Capturing the conversation around the content is the key here - not a computerized checker that assigns a numerical score to the student by measuring % wrong, numbers of standards completed, etc.

The bottom line is that I want to get to the conversation part of reassessment more quickly. I preach to my students time and time again that making mistakes and getting effective feedback is how you learn almost anything most efficiently. I can have a computer grade student work, but as others have repeatedly pointed out, work that can be graded by a computer is at the lower level of the continuum of understanding. I want to get past the right/wrong response (which is often all students care about) and get to the conversation that can happen along the way toward learning something new.

Today I tried my prototype of Phase 1 with students in my Geometry class. The pages all looked like this:

Image

I had a number of students out for the AP Mandarin exam, so I had plenty of time to have conversations around the students that were there about their answers. It wasn't the standard process of taking quiz papers from students, grading them on the spot, and then scrambling to get around to have conversations over the paper they had just written on. Instead I sat with each student and I had them show me what they did to get their answers. If they were correct, I sometimes chose to talk to them about it anyway, because I wanted to see how they did it. If they had a question wrong, it was easy to immediately talk to them about what they didn't understand.

Though this wasn't my goal at the beginning of the year, I've found that my technological and programming obsessions this year have focused on minimizing the paperwork side of this job and maximizing opportunities for students to get feedback on their work. I used to have students go up to the board and write out their work. Now I snap pictures on my phone and beam them to the projector through an Apple TV. I used to ask questions of the entire class on paper as an exit ticker, collect them, grade them, and give them back the next class. I'm now finding ways to do this all electronically, almost instantly, and without requiring students to log in to a third party website or use an arbitrary piece of hardware.

The central philosophy of computational thinking is the effort to utilize the strengths of  computers to organize, iterate, and use patterns to solve problems.  The more I push myself to identify my own weaknesses and inefficiencies, the more I am seeing how technology can make up for those negatives and help me focus on what I do best.

Assessing assessment over time - similar triangles & modeling

I've kept a question on my similar triangles unit exam over the past three years. While the spirit has generally been the same, I've tweaked it to address what seems most important about this kind of task:
Screen Shot 2013-04-30 at 3.27.28 PM

My students are generally pretty solid when it comes to seeing a proportion in a triangle and solving for an unknown side. A picture of a tree with a shadow and a triangle already drawn on it is not a modeling task - it is a similar triangles task. The following two elements of the similar triangles modeling concept seem most important to me in the long run:

  • Certain conditions make it possible to use similar triangles to make measurements. These conditions are the same conditions that make two triangles similar. I want my students to be able to use their knowledge of similarity theorems and postulates to complete the statement: "These triangles in the diagram I drew are similar because..."
  • Seeing similar triangles in a situation is a learned skill. Dan Meyer presented on this a year ago, and emphasized that a traditional approach rushes the abstraction of this concept without building a need for it. The heavy lifting for students is seeing the triangles, not solving the proportions.

If I can train students to see triangles around them (difficult), wonder if they are similar (more difficult), and then have confidence in knowing they can/can't use them to find unknown measurements, I've done what I set out to do here. What still seems to be missing in this year's version is the question of whether or not they actually are similar, or under what conditions are they similar. I assessed this elsewhere on the test, but it is so important to the concept of mathematical modeling as a lifestyle that I wish I had included it here.