This summer I am part of a faculty fellow project (with Chris Stubbs and Chris Millet) working on arming Dr. Laura Guertin’s course EARTH 400 – Earth Sciences Seminar (FIRE) with technologies.
The MT-based course site is a great example of how a course website captures the growth of the students, the course design, and the instructor. I believe that at the end of the semester, this can serve as a good showcase for blog-assisted courses.
Then we explored the potential of location-based blogging for students’ posts on the course website, and Dr. Guertin’s favorite, Google Earth. She and her students have been using Google Earth as a tool for presentation, specifically, geography-entered storytelling. This semester, we decided to push the limit of Google Earth and really make use of this great tool.
First, as a presentation tool, Google Earth needs to be easily useable by students with little to none HTML experience. Out of the box, Google Earth presentation is based on its KML format, which, as its name suggests, uses XML format. The desktop version of Google Earth provides a simple editting capability for location-related information (where to put pins, where to draw a pentagon, etc.); however, the presentation page (the window that pops up when a pin is pushed) still requires students to design the whole HTML page. The solution is a pre-created
Google spreadsheet that has a few templates built-in, so the presentation pages have a consistant look (template) and the HTML coding is minimized. This spreadsheet then publishes the KML code to a place where Google Earth can just embed live. This also makes page-interlink easier. (Note: you will need to switch to old spreadsheet engine for this to work, as of August 2010).
For content-rich storytelling, we also need to be able to embed multimedia contents. Now audio and video can be embedded, and with the help of Kaltura, students don’t have to rely on any desktop tools for content editting.
The Google Earth community has been exchanging homemade KML files with each other, to use in Google Earth desktop version. However, for presentation, we figured that Google Earth Browser Plugin is the way to go. That way, something put online can be viewed any time by any user.
This is when I discovered the treasure island of
Google Earth API. (What a surprise for a developer.)
I remember the presentation Dr. Guertin gave in the Teaching and Learning Symposium when she talked about the lack of geographic commonsense among college students. In learning the API, I encountered a demo app
GeoWhiz and thought it would be a great addition to her courses. The team is very excited about this, but we need the app to do more.
1. GeoWhiz is designed to be a quick demo with very basic UI (user interface). Dr. Guertin also has some thoughts about the timer and score display, so we decided to redesign the UI.
2. GeoWhiz does not come with the boundaries of countires. Dr. Guertin thinks that boundaries should be displayed because the questions and the ansers are both of political geography (find the countries/US states). The problem is, Google Earth browser plugin only provides a layer with BOTH boundaries and names, i.e. if we want to see the boundary polygon of Afghanistan, we can’t avoid displaying the name Afghanistan, thus defaulting the purpose of the app.
The solution is obvious but not easily implemented — we need to provide our own boundaries. One way to do so is to draw it ourselves with Google Earth desktop — we can just trace over Google Earth desktop boundaries, one by one for each country/state. Or we can get this information somewhere. After some searches, I got some boundary coordinates that I was able to convert into KML format. To minimize the data size, I used an algorithm to throw out coordinate sets that provides more detailed information than needed. The algorithm is a simple 3-point area calcuation with a pre-determined threshold setting. Anyway, I managed to squeeze the world boundaries and US state boundaries into a 1-MB file. Now we have boundary information without having to reveal country/state names.
3. The original game only recorded hit or miss for each question, but Dr. Guertin would love to see where students think Afghanistan is, rather than that they can’t find it. Therefore, we need to capture the user movement. Unfortunately, Google Earth API does not support this function, so I had to write my own. Basically it’s a callback function triggered by user inputs to record the timestamp, and a triplet dataset (longitude, latitude, and the distance from the sea level) for both CameraPosition and LookAt setting in Google Earth. Then when play back, we rely on the differences between two consecutive timestamps to daisy-chain the placement of CameraPosition and LookAt information.
4. GeoWhiz does not record the score onto a server. OK, now it really looks like a game — why aren’t we talking to EGC already? Alright, Jason Wolfe comes to help! We decided to use a framework designed by Jason Wolfe for score recording. Jason also further improved the UI and added some sound effects.
Currently the game,
Penn State’s Amazing Race, is hosted on EGC (update 2012/03/02, EGC is going through some service change so currently the server for this game is down). In case you don’t have access to that version,
here’s a version that does not require the server to work (this version does not record your name/score). You may also want to
download it and run it on your own machine.
If resources allow us to further improve this game, we would like to:
1. Add more sophisticated sound effects.
2. Further optimize the communication between the client and the server to ensure integrity of data record.
3. Implement an interface for instructors to easily change the questions.
Jason and I also had a brainstorm session for the future potential of this game.
1. We can host a Penn State campus map and let this game become part of the new student orientation.
2. We can make it a real-time race. Multiple clients start at the same time, and each player can see where other players are, in terms of % of questions completed, in real time.
3. Or we can let the racer compete with a ghost player (highest score record keeper) to increase playability.
