We’re going time travelling! Well, not really, but we’re going to pretend it’s last week because that is when this blog post should have been up. If anyone has cruised through my experience with 3907B last semester, you may have already picked up on the fact that I am a notorious procrastinator to the point of near insanity. Tim Urban’s article “Why Procrastinators Procrastinate” is probably one of the best, simplified explanations of chronic procrastination, at least in terms of how it tends to affect me personally.I’ve taken a lot of strides towards dealing with my so-called ‘instant gratification monkey,’ but it still wins sometimes. Point is, the set up of this fellowship: One blog post a week, one meeting a week at least – is generally really, really great for my specific problem, as it keeps me very accountable. Dr. Graham is also very kind and awesome at giving me little reminders that I’m slacking, as can be seen from his tweet to me the other day.

On to the good (and maybe not so good) stuff! The second week of my fellowship, Dr. Graham and I discussed exactly what I wanted to do in terms of the digital aspect of this project. We had originally spoken about creating an app and getting it on the Google Play store by Christmas; however following my first post, we thought that maybe I should look at trying to build my project using Twine. This is because A] I already have some experience working with Twine from past courses, so I would have a foundation to build upon, as opposed to trying to learn a whole new platform. B] Twine is browser-based, so the entire project would likely be significantly more accessible, which is a pretty huge focus of Digital Humanities. Conveniently, Dr. Graham had created a “Low Friction AR Template” for The Institute on Digital Archaeology Method & Practice this past summer. As such, my task for the week was to put together a test Twine to see how I felt about using the platform for this, and looking through the JavaScript on which the template runs.

You can find my test Twine here. Keep in mind that unless you are able to access Carleton University, this will be fairly unexciting for you. My trial is pretty well a direct rip off of Dr. Graham’s template, with the only changes being the picture on the introductory page, hiding a very nifty 3-d model that demonstrated Twine’s capabilities, and of course, changing the geolocation data to that of areas on Carleton’s campus. This was because my biggest focus was on making sure that I could actually get the geolocation aspect to work.

For ease, I made the three areas that would trigger an event places I frequent on campus: University Centre, Patterson Hall (where the history department is housed), and Southam Hall. I used two different methods of getting the latitude and longitude of my points. First, using Google Maps on my iPhone while in class in Southam Hall, I dropped a pin on my location and then ‘starred’ it. Second, I used the campus map on Carleton’s website to make sure I was choosing the right buildings and confirming positioning, before cross-referencing back to my phone and once again dropping a pin and ‘starring’ it; this is the method I used for Patterson Hall and University Centre. I had a feeling that at some point I would have to physically go to this places to get a better point, but figured it would work for the trial. I decided it would make the most sense to test my Southam Hall trigger first, seeing as I was sitting in the exact same spot that I was in when I created the point… I was thrilled that at very least, the script in my Twine was working with my phone’s geolocation services, but could not figure out why on earth my action wasn’t being triggered. I spent at least ten minutes following that wandering around Southam Hall, even going outside trying to trigger the action. I couldn’t seem to get the action to go off. I figured that perhaps my buffer was too small, as I had left it the same from Dr. Graham’s template: 0.0005. I thought that maybe that was too small, and decided to make it larger the next day.

However, later on that day, I was in a room in Tory Building explaining to a friend that my application wasn’t working. I was showing her what I meant, when an action was triggered. Two of my points were triggered, actually. To better demonstrate this, I thought to open Google Maps and screenshot where I was in relation to the points that had been triggered, which have been circled in blue in the image to the left.

I decided to actually figure out what having the buffer set at 0.0005 actually means. The only thing I could find was a Wikipedia (shudder) page about Decimal Degrees, that has a chart saying that at 0.000_ decimal points, the ‘”qualitative scale that can be identified” is an individual street or land parcel. Well then. Considering that Carleton’s campus sits on sixty two hectares of land (or 0.62km2) it would very well make sense that multiple ‘action points’ were triggered when I was in a central location with that large of a buffer. The only explanation I have for my initial test in Southam failing is that since my phone is older, perhaps its location services are not quite as precise as I had hoped.

With this improved knowledge of decimal points in term of latitude and longitude, as well as the possible shortcomings of my device, I’ll be trialing the simplified test application again this week with a smaller buffer. If anyone has any thoughts or advice on how to best work with geolocation triggers in a small space, you can find me on twitter!

Next post we’ll be switching gears a bit, and focussing on the content of my project, stay tuned!