So I have been standing here, outside 240, filming the installation for the past half hour, and I just want to say that ths experience is entirely different from the experience I had inside, let alone the virtual experience on our web site. The tweaked installation runs incredibly slow, almost imperceptibly slow. On the site that would be unbearable, but outside, on the actual official viewing spot, it is calming. Well, the site is not even working. My old Mac must have overheated… Sigh…

Our professor was suggesting that we could document our experience of having a geographically separated team designing our gizmo for our installation. But I have this feeling that our biggest problem isn’t really our geography, it’s the simple lack of access. Our biggest progress was made approximately during the last one and a half weeks, yet we saw several days where Angela was in town but we could not do any work on our installation either because the room was in use all day, or simply because the office separating the elevator lobby and our classroom was locked and no one was available to open that door for us. We literally wasted at least four days because we physically could not get into our own classroom (in a building we were told would have access 24 hours a day, 365 days a year). It’s not the remote aspect; it’s the “last mile”—or, in our case, literally, the last inch (that is, the thickness of a locked door). So I could not even mount a set of information panels I freshly made yesterday because when I got back (from the cold, outside, in Butterfield Park, because students in our program apparently have no access to proper, ventilated studio spaces, and for obvious reasons I was not going to use rubber cement or spray fixative in the only studio space I actually have access to—I don’t want to literally blow up the studio we all love) the door was already locked. In hindsight, during our group meeting yesterday we could have easily defended our (unreasonable, I admit) slowness—we could not make any progress not because Angela was not in town, nor because I could not understand her code until I got my own Arduino, nor because of the steep learning curve of figuring out how to drive the stepper, nor even because the wheel was slipping and we could not make it not slip; we could not make progress simply because we could not get into the classroom to work on the installation. This has to be the stupidest reason ever why work could not be done, but it’s true, and it’s sad. And it has absolutely nothing to do with us allegedly treating this “real-world commitment” as mere “schoolwork.” And I fear this will repeat in our next installation, because 49 is another space we simply cannot get in.

Yesterday I finally remembered. I was talking to the professor a few days ago and thought there was a third point that I forgot, and indeed, there was a third point that I forgot. So here it is: We keep talking about agile, but agile values “working code.” And one way people doing agile keep their code working was to use TDD (test driven development) or BDD (behaviour driven development) techniques. They iterate quickly, but they don’t iterate in a vaccuum. Before they code, they write the test first. (Or at least that’s my understanding after taking that Coursera course.) To do agile, we have to first have our success criteria—a fluid set that changes over time, of course—set down. Success criteria, however, are sorely missing in our case: We just don’t have them. We know something is wrong, but we haven’t really defined what we mean by right. So no matter how short our iterations are, we still can’t be doing agile; if there’s a word for what we’re trying to do, we can probably call it hacking. And yes, this came out of that project too.

Unified English Braille distinguishes between many things that Unicode doesn’t distinguish. For example, UEB distinguishes between the seconds (of an angle) sign, the inch sign, and the double prime, whereas Unicode use the double prime for all three. How, then, can an automatic translator from Unicode to UEB be designed? Wouldn’t this require artificial intelligence?

How do you document something that does not yet exist? If the way to go about the project is “to make the best art piece you can and see what comes out of it,” how do we even draw up a plan when the art piece does not yet exist? Perhaps, the way to do this is to go back to our team’s “manifesto” (for lack of a better word)?