Paradata

When I was thinking of what to do for this project, I was mainly thinking of time. Not time as in history, but personal time. Life is busy right now - I've got four jobs with ten hours each, a class, my MRE, and several extra curriculars. Time to experiment is not something that I have a lot of. To that degree, I decided to try to use this project to create time by multi-tasking. I wanted to choose something that could apply to as many things as possible, and so I settled on something that my MRE and my Ingenium work have in common - using Twine.

There are a few different geolocated audio tour apps out there (Echoes.xyz being one), but Twine had an aura of creativity and freedom of expression that I didn't feel with Echoes. With Echoes, you're limited to what they decide you can do with the app. With Twine, you're limited to what you can code - which is a much wider field, especially when you have online tutorials and folks to support you. Especially when I stumbled across Dr. Graham's Twine forum post about geolocation, it made Twine feel like a real possibility. The fact that it matched my needs for Ingenium and my MRE as well were also a major point in deciding to use Twine.

Returning to the factor of time (and specifically my lack of it), that's also why I decided to return to my shipwrecks data. It's a data set that I have free access to and that I'm already familiar with, which made it a lot easier to plan a project.

At the beginning of term, before reality hit, I had some big dreams - I messed around with computer vision and created some cool art with vqgan + clip (see [[Project Ideas]] doc), considered aerial photogrammetry, and also tried out projection mapping using VPT and Quicktime. I was also considering doing a sonification of Prides past, or something involving trans history, because I'd like to see more of it both inside and outside of academia. All of these aligned more closely with my initial computer vision path, and those ideas are all of interest to me still, but reality eventually set in and I realized that I didn't have the time to do both the historical research required for a new topic and create a digital project where I'd need to teach myself a bunch of new skills. Realistically, it was going to need to be one or the other. Given that it's a digital history course, I decided to reuse an old dataset and spend my time learning to do something new - and something that would be applicable to my other work.

I began learning Twine from the course tutorials, and created two very rough games - one called "All Sound is Queer," based off a paper by Drew Daniel, and the other called "Sonifying Shipwrecks," which took users through how I sonified my shipwreck data as part of the sonification tutorial (available in rough form on itch.io and as an .html file in my hist5706 repo). I focused on learning to cue and add audio and images, as well as getting familiar with how Twine worked, how it got published, etc. I also learned how to add alt text (without character limits! which is very important to me. I ended up diving pretty deep regarding accessibility for folks who are blind or have low vision, and found that Twine is one of the more accessible game engines due to how well it works with screen readers. I downloaded one the free screen readers and had plans to test my own work later on).

During that time though, I focused mainly on the basic mechanics and narrative devices - like the links, variables, etc. (I really struggled to get variables to work successfully). I didn't focus much on the look, beyond changing the basic colours based on a web tutorial. My formatting notes are available in [[Twine take 2]].

When it came time to work on my final project, I took that basic knowledge as a starting point and dove deeper.

Geolocation is a central part of my MRE and Ingenium work, and so I started there. I compiled all the relevant links that I could in [[Geolocation readings]], diving into the forum as well as other Google searches. I found more of Dr. Graham's work as well as past student Kathryn's tests, and tried to learn from those.

The official Twine documentation was more confusing than I could handle (I personally found all the official Twine documentation to be too confusing and so found alternatives through forum posts or learn-to-code sites), and so I zeroed in on Dr. Graham's work. In a meeting he mentioned that the official material was based on his work, so I figured that I may as well go to the source anyways and ignore the Twine cookbook.

My exact notes are in [[Geolocation Attempt 1]], but they're a bit messy so I'll summarize. I started with going through Dr. Graham's 'ar-archaeology' repo, and read all the material. I also reread the earlier material from my geolocation readings, just to feel prepared. Funnily enough, it was the earliest steps that gave me the most trouble. Downloading the template was quite the challenge, because I misunderstood how to do so. My computer wouldn't let me download and save the link as an html file, so my initial workaround attempt was to copy the javascript from the repo and paste it into the javascript section of Twine. It technically worked, but it left me with an absolute mess and didn't populate the content properly. The right passages were there though, which was an encouraging start.

I ended up needing the view the page 'raw' and then saving it from there, which worked. I opened it in Twine, where it took over an hour to load. I stopped it at approximately the hour mark and just went ahead because I assumed all the relevant content was already in there and that the program just didn't register that it was ready. I just kind of ran with that, and then started digging into the template. I played it in Twine several times to try to get the hang of it, though the geolocation aspect made that a challenge.

It was at that point that I decided to include a back way to each of my points, because it was incredibly annoying to not be able to move on due to my incorrect location.

I then started editing the template, and changed the co-ordinates in the StoryInit passage to co-ordinates around my neighbourhood. I figured that would allow me to test it better if I could actually be in those locations easily. I kept the JavaScript code the same, because I didn't feel confident dealing with that yet, and instead just tidied it up a bit.

My project requires more of a linear approach, and so I started to break down the format into geographic zones along the Ottawa River. I also removed the elseif statements and changed them to a more binary choice - users either were or weren't in the right spot, instead of being in one of several spots. It made it a lot easier for me to organize my work.

I lettered the stops a through e, and provided each one with an error option. If the person wasn't in the correct location, instead of saying 'try again' until they get to the right spot, it offers the opportunity to continue on to the next stop regardless of their location. I chose to do this for several reasons. First of all, because I understand how incredibly annoying it is when technology doesn't work, or when you think you're in the right place but can't get it to work. This circumvents that frustration, and provides an alternative means of accessing the content if there is some sort of technical error. Secondly, I wanted to make sure that this content was available both as a site-specific work but also available elsewhere for folks who can't access the Ottawa River pathway. Thirdly, I wanted to make sure that the Twine was accessible for those with accessibility issues, and to make it so that it can be enjoyed by someone who is stationary, whether by preference or necessity.

After I had completed the approximate layout, I moved onto starting to add content. I added about twenty shipwrecks, and then went back to add images. I tried to include a few Google maps frames, using the newly added river mapping by the Ottawa Riverkeepers, but I wasn't able to make that work. I also wasn't able to have the images appear when I moved the files onto my phone (apparently Androids don't recognize the file system/structure in the way that Twine needs), so I tried to turn my Twine into an APK file. When I tried that, I ran into the unfortunate issue of the main software that was used to do this no longer existing (as of summer 2021), and due to how recent that was, there weren't any tutorials that showed alternatives. That took me over a week to get past, though I held back from asking in the chat because it wasn't immediately relevant. I also have issues with reaching out, but that's my own personal insecurities about showing that I'm struggling. In my searching, I eventually stumbled upon a thread on Reddit, of all places, that suggested Monaca. It's an 'HTML5 hybrid mobile app development' site, which uses Apache Cordova (the new paid-only version of the original software). They have a free account option where you can only build three apps per day, but that was more than enough for me. It can publish to both the Apple Store and Google Play, which suited my needs.

After I figured all of that out, I realized that I really hated how the Twine default/basic CSS looked. Appearance for me is important with digital work, because in the museum field I'm used to having it matter in regards to digital products and I haven't quite unlearned that. I definitely had a moment where I was considering giving up and switching to Echoes.xyz, because it seemed to have a much nicer user interface and it just looked a lot nicer and more professional, which I want my projects to look like. To over come that, because (at that point I thought) it would be ridiculous to abandon the project now, I started diving into CSS.

It look a lot of time to learn how to do the things I wanted to do, and it was mostly trial and error. I gave up on the official Twine documentation pretty quickly and moved to w3schools - a website focused on teaching CSS (https://www.w3schools.com). It made things a lot easier, and I figured out background images, fonts, and borders. Over the span of two weeks, I figured out how to add padding to the sides of text, so that it's not right up against the borders. I also managed to make the textbox transparent, which made it start to look less like a 90's website. Since I wanted this to properly work and look alright on both laptop and mobile, I started looking into responsive CSS to try to figure out how to get images and content to automatically resize.

As I got to filling out the Ottawa area shipwrecks and preliminary text, I realized that there was really no good reason for me to be using geolocation when overlaying the whole of the Ottawa River onto the walking path. The adventure functioned just as well (if not better/more clearly) as a desktop-only adventure, which kind of threw me into a tailspin. Why was I using a geolocated option if it doesn't enhance the experience? It honestly kind of detracted from it, so after a lot of reflection and talking with a classmate (thank you Danielle!) I decided to change it up.

Instead of using all the shipwrecks along the Ottawa River, I decided to focus on the twenty shipwrecks located along the Ottawa River Pathway/Trans-Canada Trail between Kettle Island and Britannia Beach. In this new version, the geolocation is a requirement because it reveals the physical locations of the shipwrecks/wreck sites as users walk along the path. The geolocation is central instead of an aside, which I think makes more sense. I had also noticed that in my original version, I was getting disengaged while using the tour because of the number of options to click through. I got a couple classmates (anonymity preferred) to help test during a social chat session and I think they were too – we really only enjoyable got through two of the six stops (and that was static and while comfortable in our own dwellings). Seventy-two options to read through is just too much, and having approximately twelve shipwrecks per stop would also be a lot to read through while stopped on a public path.

That led me to start thinking about how to describe the stops to get people to stop in the right area, which lead me to a mini crisis of 'why am I even using Twine' instead of Echoes.xyz. Echoes would auto trigger the sound to start and I could make it kind of like a podcast, which would make the associated info pop up without the person needing to click on the right link/passage at the right time - all in all, a much better user experience (and arguably more accessible). The only downside is that the tour is only available in the right/planned location. That's not a problem when I already have my map made, but it is a problem when it comes to my Ingenium work and MRE work, which don't have a static method of engaging with the work already created.

For this final project though, I decided to switch gears and try out Echoes to see if it would do if I wanted it to. Exploring and learning about Twine has been incredibly valuable and I've learned much about CSS, html, and responsive design, but I do want that easy user experience for anyone using this walk.

Echoes is both much more me-friendly and user friendly. It has less of the typical 'DH' skills required, but I figure that after spending so much time on Twine it was fine to switch and enjoy the relative ease. Within the span of three hours, I had already finished laying out the walk as well as the first stop. It doesn't allow me to embed photos the way that I want to (it only allows for cover images), but its automated functionality is worth it in this case. For most of the steamboats, especially the older ones, I wasn’t able to find images anyways, so it’s really not too much of a loss. For the cover images, I either used historical images of the vessels (where possible), or I used screenshots of the Ottawa Riverkeepers'/Brian Redmond's contributions to Google Maps of the Ottawa River around Ottawa, ON.

When I decided to go with fewer shipwrecks, I felt it necessary to expand on my original research/database. I did further combing of the Sessional Papers and New Mills List, and found a new wreck site (the G. B. Pattee). I also included more detailed information on each of the wrecks, to further separate this from my earlier shipwrecks project.

One interesting aspect of the new research was realizing that the wreck identified as the Minie by the Underwater Society of Ottawa is actually probably something else. The Minie (also Minnie, Minnie Bell, and Alva) was retired at the end of her use, not sunk. Similarly, the wreck identified as the Lady Colbourne by the Underwater Society of Ottawa (not included on their initial map but presented through a plank and nail from the ship, held as an artifact by the Symmes Inn Museum), may actually be from the Ann Sisson (which has been confirmed to be found within Britannia Bay area and can still be visited).

The aim with this walk is not to create a guided audiowalk, with specific narration to lead the movement, but instead create static posts that can be visited independently (so users can start or stop in any area and order to learn about the shipwrecks near them). In an ideal world, it would be great to be able to paste QR codes or info on the stops in the relevant areas in the physical world to do actual site-specific work, but I don't think that's in the scope of my current project.

Wrecks don't obey arbitrary borders between provinces, and so to represent the locations of the shipwrecks while still making it an Ottawa-based walking tour (for practicality), I chose to present Quebec-side wrecks using a rectangular echo shape instead of a circle. The circle shapes are for wrecks within the immediate area of the circle, located close to the Ontario side.

For the soundscapes, I used my own recordings of the Ottawa River. Unfortunately, I did not think ahead and get recordings during the summer, but I do have recordings from early-late Autumn and early-mid Spring (the beginnings and ends of steamboat season). I also added in a steamboat whistle and a bell sound, from the Mississippi steamer "Natchez," one of the few steam-powered paddlewheelers still rolling and the German “Nixe.”

I had an issue with the steamship sound files - the website had wav and mp3 files downloadable, but they weren't able to be played when downloaded. To get around that, I played the sounds on the website at my computer's highest volume and recorded it via video on my phone.

From there, I mixed the sounds and recorded soundscapes together, creating four main steamboat soundscapes. I then turned the written descriptions for the shipwrecks into mp3 files using https://ttsmp3.com/, a text-to-speech-to-mp3 site. I dislike hearing myself for gender reasons, and found it much more comfortable to hide behind a different voice. The most pleasant tone to use was US English/Joey, mostly due to sound equipment's issues with higher pitch voices (see this really interesting article). I dislike reinforcing that, but I also want to make the words clear and as pleasant as possible to listen to, given that the steamwhistle noises that appear in the soundscape are rather unpleasant already.

I re-entered audacity and starting importing the spoken-text mp3s into the soundscapes. I made the soundscapes quieter when the voice was speaking, but let some noise continue through to make a smoother experience. I then exported it as an mp3, and then used various mp3 to m4a converters to make it a file that Echoes.xyz accepts. I had to use a variety of converters, as many limit the amount of audio that can be converted per day.

After uploading the files to Echoes.xyz to complete the experience, I made a static website using Google Sites to serve my QR code, link, and associated paradata. I tried to make the site seem ‘touristy’ and ‘sharp’, to create a semi-official presence around the walk (which you have probably already seen, given that you're on the website now).