I'm describing my big Bloomsday Halifax project by writing up what I did at each location. This is the second in the series, covering Episode 2 of "Ulysses": "Nestor".
In the book, Nestor takes place at Clifton Lodge School, converted from a stately home, where Stephen Dedalus is teaching. I had originally planned to use the Halifax Grammar School as the stand-in location, but it's quite a distance from the locations before and after it, both in Point Pleasant Park. I had also considered the Atlantic School of Theology building, at bit closer on Franklyn Street, but still pretty far away. Even if I wasn't strictly enforcing doing everything in order, I didn't want people to be zig-zagging around town too much. Remembering that the school was in a converted house freed me up to choose other locations that weren't necessarily school buildings. The Point Pleasant Lodge turned out to be conveniently located at the edge of the park, and is a striking-looking stone "cottage" in a late 19th-century medieval-revival style.
The grand homes along Tower Road and Point Pleasant Road nearby could also stand in for the the house, if anybody wanted to get picky.
For the background mash-up image, I found an old photo of the school's playing-field, complete with a vintage lawn-flattening roller, and replaced the old field-house with the Point Pleasant Lodge. Not the best mash-up of the bunch, but it did the job.
Like with the first episode, I didn't do anything extra in Nestor. I had considered putting a little quiz into the app ("What city sent for Pyrrhus?"), or even a live trivia contest if enough people could come by at the same time - but this was still early enough in the process that just the regular experience was enough.
Since we're still covering basics here, I thought I'd share some of how I put the basic content together.
The Bloomsday app interacts with a server-side back end called "NowHere". This is the same back end we've used for "This Is Nowhere", "Vista", "Vista20", "Labour7", and "50 Things". It's built in Ruby on Rails, since I'm an old Rails hipster from back in the day. Each project has its own "World" record, which has general configuration settings for the project as a whole, and then it has a number of "Locations" which are specific sections of the project. Here's the top part of the form I use for Nestor:
Yes I'm using a regular HTML form styled with Bootstrap like it's 2015 or something. I like to stick with what's easy to work with and flexible to change, especially in a back-end utility system. We solved the problem of handling form data on the web decades ago, and there's no need to reinvent the wheel with big front-end frameworks unless it's really necessary. The front-end apps use React Native for a smoother user experience, but that's overkill for the back-end.
When I started working on NowHere, I thought of building a lot of configuration into the World specifications, and then the location forms would adapt based on those configurations. It has turned out, though, that most of the projects we've built have been different enough that it was easier to just make custom forms for each one rather than have lots and lots of if statements everywhere. This is the "_bloomsday_form.haml" component that gets swapped in if the World model says it's a "Bloomsday"-type project. The database table for "locations" has columns for latitude, longitude, radius, name, tags, is_active, etc. - but it also has a lot of text_1, text_2, text_3, text_4, text_5, etc. columns, which can be used differently for different projects. In this case there is "About the Location" but also "Preview", "Special Intro", and "Special Experiences", which are just labels on various "text_1", "text_2" etc fields.
One of the main configurations I do still handle from the world profile is custom location tags. Other projects had a whole set of different tags to cover things like accessibility or media usage, but in Bloomsday there are just three tags used to more clearly specify a special kind of experience that requires custom UI in the app. We'll get to those later!
Using the CMS means that the app is mostly just about behaviour and communication, while the actual content is almost entirely on the server-side. This lets me continue to change content until the very last minute, without having to go through the tiresome and fraught process of publishing apps and getting them approved by the App Stores just to change some wording somewhere.
I did have a small panic though when I realized late in the process that I only set up the app to fetch the data from the server when it first starts, not when it wakes up or otherwise changes state. This is good in some ways for consistency, but it meant that once someone started the app and signed in, it would be stuck with that data unless they fully quit and restarted it. This kept me from actually sending out links to the app stores until the night before Bloomsday, so I could be sure everybody had the final content. Next time, I'll at least have a "reload data" button in the Info panel. Another reason I'm already looking forward to next year!