What PhD supervisors are for

I had a great chat with my supervisor on Thursday, after helping out with a Masters seminar. As regular readers may have worked out, I’ve been having a great deal of trouble trying to get a coherent testable design to test out of my half-formed ideas and lofty ideals.

The problem was trying to think of a cheap way to test some of the theory I’ve come up with. I’d got hung up on trying to think of a way to track visitors round a site and test their reactions to that. Until I solved that I was handwaving the issues of breaking the story into natoms, and balancing the conflicting needs of multiple visits in the same space. Those two problems both felt more within my comfort zone. The problem is that I’m not a technologist, that bit is so far out of my comfort zone that I’d need to enlist (or pay for) one. On top of that, the tech itself isn’t that cheap – getting a wifi network into some of the heritage places I know, with their thick stone walls and sheer scale, isn’t about buying just one wifi router.

I’d mentioned the other problems (particularly in the one of negotiating conflicting needs) in the seminar. (The students had been reading about a variety of museum interpretation experiments for their “homework” and we discussed the common issue that many of the experiments focussed on the issue of a visitor in isolation, and hadn’t thought enough about multiple users in the same space). Afterwards I spent twenty minutes with Graeme, my supervisor, in his office. I felt he’d finally got what I’d been trying to say about a “responsive” environment, and his interest was particularly focused on the two issues I’d handwaved. We talked about low-tech ways or exploring both of those, and of course THAT’S what I should be doing, not worrying about the tech. These are both things I can do (I think!) rather than something I can’t .

So by the end of our chat, when Graeme had to return to his students we’d worked out the rudiments of a simple experiment.

• What I need is a relatively small heritage site, but the possibility of lots of choices about routes, lots of intersections between spaces. What Hiller calls a low depth configuration (that last link is to a fancy new on-line edition of the book, by the way. It’s worth a read).
• I need to work with the experts/curators of that site to “break” the stories. Break is a script-writing term, but it feels particularly appropriate when thinking about cutting the stories up into the smallest possible narrative atoms. (Although maybe “natomise” is better!)
• Then I need to set up the site to simulate some of responsiveness that a more complex system might offer. Concealed Bluetooth speakers for example, or  switches like these that can be controlled by Bluetooth.
• Finally, rather than try and create the digital system that tracks visitors and serves them ephemeral natoms, I can do a limited experiment with two or more humans following visitors around and remotely throwing the switches that might light particular areas of the room, play sounds or what ever other interventions we can come up with. The humans take the place of the server, and when they come together, negotiate which of their visitors gets the priority. Graeme suggested a system of tokens that the human followers could show each other – but the beauty of this concept is that the methods of negotiating could become part of the results of the experiment! The key thing is to explain to the participants that the person following them around isn’t giving them a guided tour, they can ask questions of him/her, but s/he isn’t going to lead their experience.

So, now I have a a thing that it is possible to do, with minimal help and with a minimal budget. And its a thing that I can clearly see has aims that come of the research I’ve done, and results that inform platonic ideal responsive environment I have in my head. If it works, it will hopefully inspire someone else to think about automating it.

That’s what supervisors are for!