The past couple weeks, we have been crash-coursing PHP via Wayne Graham’s surely famous slide decks. We’ve been doing this despite not (yet) delivering our task for the fall semester—the redesign of the Ivanhoe webpage.
It’s a necessary shift. While we’re fortunate to be assisted by the Scholars’ Lab dev team—including Scott Bailey, a holdover from last year’s Praxis cohort—if we’re going to improve on the game’s workings, we have to be able to get in and make those changes, and we also need lots of practice in making those changes. Start any later, and there just won’t be enough time to develop skills or features.
But, as is often the case in academic study (as also, I suspect, in DH), this problem isn’t so much disappearing or even receding as it is mutating: taking on a new and more urgent form. In this case, that’s the design of the Ivanhoe game itself. Our hope is to take the Ivanhoe that presently exists and implement some of the features that almost-but-didn’t-quite make it in last year, while also streamlining the frontend with the aim of making players return to the game at more regular intervals.
In all of this, we’re holding onto the principles we had established for the Ivanhoe site, but couldn’t quite yet put into practice there: leaving as much as possible open to the players themselves to customize, so they can experience it in the ways most amenable to their own textual plays. We hoped to symbolize this on the site by incorporating an array of styles that would allow users to approach the website in, if not the infinite ways that we hope Ivanhoe will afford them, then at least enough that they can choose their own stripe of Ivanhoe. Of course, this means implementing these styles across multiple pages, rather than the landing page alone—this was the hurdle we were at when it became imperative to switch tasks.
We are at the point now of signing off on our prototype game design, which has been heavily informed by the conversations we had about the site itself. And perhaps it was necessary, if roundabout, to approach things this way. After all, the experience of a text is rarely smooth and never instantaneous. Why should a project devoted to furthering our textual experiences prove any different?