A site for the DonorsChoose Hacking Education contest. Chosen as one of the 25 showcase apps. View at macsforclassrooms.com
DonorsChoose accepts proposals from public school teachers for items they need for their classrooms. The contest invited developers and data crunchers to use their data to make discoveries and build apps that improve education in America. The judging criteria was as follows: Which app or analysis has the greatest potential to engage the public and impact education?
I decided to do a closer study of the trend of requests for technology. I noticed right off the bat that a lot of teachers wanted Apple products--the words iPod, iMac, Macbook and iPad kept appearing as I browsed the proposals. I thought about why that might be and what Apple symbolizes as a brand. Computers represent access to an overabundance of information that is central to this era, so it's important for teachers to educate their students with it. Apple pioneered in broadening the market of personal computers, making their functions accessible and appealing to everyone. This notion has maintained their popularity ever since, so teachers must see them as a good immersion point for getting their students to understand the technology.
As I thought more about what must make these devices desirable to public school teachers, I came up with two interesting stats to attach to each proposal: WalkScore and household income. The idea behind plotting the WalkScore was that it is, to a certain degree, a measure of the urban-ness of a location. Places with no public transportation that are spread out are often low-population, rural towns, so a device that can access the web goes a long way in connecting it's users to the rest of the global village. As for plotting household income, I thought it would be an interesting measure of how likely the students were to have access to or even have encountered a computer before (Apple or otherwise) seeing as how far below the poverty line many families appear to be living. I also figured a map would be a good addition to give some indication of what parts of the country are active on DonorsChoose.
Disclaimer: Please view in a standard, modern, non-mobile browser. Internet Explorer 8 and below will not work.
The site pulls in requests from DonorsChoose, and then makes a call for each proposal and completed request to the APIs that return the WalkScore and household income data. The data is handled by a PHP script that grabs and then writes all the data used on the site into a JSON file, which is then read by the Javascript.
The PHP grabs data from three different APIs. One challenge I encountered was being limited by the number of calls I could technically and realistically make to the three APIs I'm using (not including Google Maps). One call for each of my keywords to return results (iPod, iPad, iMac, Macbook), times two for both unfilled proposals and completed ones, is eight calls to DonorsChoose alone. From the up to 32 individual proposals that it returned (16 open requests + 16 completed), it has to then pass the latitude/longitude values for each to both WalkScore and Infochimps (my household income data supplier). All together, that means 40 requests to three different servers, and remember, I said not including Google Maps. No wonder it went so slow the first time I tested it.
I realized that new results from DonorsChoose didn't really need to be pulled in every time the site was accessed, since I seemed to be getting new ones only every few days. Furthermore, there was no point in re-fetching data from the other APIs every time either. So I added a timestamp value to the generated JSON file, so that the PHP can check to see when it was last overwritten with new data. If it's been greater that 48 hours, it will re-fetch and write new data, otherwise, it keeps what's there.
View the the PHP file that writes the JSON here.
Some things I used:
The graph is generated with HTML 5's canvas element, and the mouse click events that allow elements outside of the canvas to be modified. The canvas actually expands beyond the square it appears to sit in, which allows to the "stem" of the selected completed proposal to appear to be coming outside of the active area.
View the main Javascript file here.
I plan to make the site work on mobile browsers, which it currently doesn't because the Kinetic script uses mouse events rather than touch events (an unfortunate glitch I discovered too late). I'd also like to find a way to have the PHP pull in the JSON more efficiently, so that those that view the site that have the task of fetching completely new data don't have to wait much longer than those that view it straight from the already-written JSON file.