(Blog delay note: I actually wrote this on Dec. 12, but I haven't had a net connection from my laptop until now.)
Testing the UT system on the street today, I realized what a practical challenge this whole idea of "public authoring" poses to interaction design. As I mentioned in the previous post, Urban Tapestries does not use GPS or any other form of automatic location awareness. In order to post a note at a location, you have you know where you are and indicate it on a map of the city. That means that as I walked around with the PDA, I had to slowly, manually move my location point along the screen like a token across a game board. This isn't a big deal when you're sitting still, but doing it while walking feels burdensome, like dragging a restless pet that keeps stopping to sniff a tree. As with all site-based mobile applications, there's a constant attentional conflict between looking at the device and tuning into your surroundings and companions. My natural inclination is to walk for a while without looking at the screen, stop, sit down and explore some threads for the area on the device, move on, stop and add to my own thread, etc. Using interactive technology outdoors can be great as long a you can negotiate a subtle balance of stimuli: when the environment is quiet and relatively unchanging, you respond by searching the device for interesting content. When the environment itself is more stimulating, you put the device away for a while.
The problem is that any technical difficulty with the device throws that balance off immediately. If you're not sure when you'll be able to use the device because, e.g., its network connection is unreliable, than you have to attend to the device and its connection status in a way that compromises its use. I know it sounds like I'm insisting on perfectly seamless pervasive computing, but that's not really the point. It's more that in order to have a good mobile networked experience, I think you need an interface that lets you do the most important things (e.g. authoring and accessing others' contributions) whether you are actually connected or not, and even blurs the distinction between connected and unconnected states, so that networking can happen when possible but not get in the way. I'm sure this is a very tricky thing to do, but it will be necessary if we want to share community networking practices like public authoring without waiting for the networks themselves to become perfect.
Nonetheless, I liked wandering around with the feeble UT iPAQ and writing things, and even more, I liked discovering other people's writings. (My brother and co-tester felt differently, I must say.) I'm convinced that there will be as many different implementations of this idea as there are ways of seeing a city, and some form of it or other will eventually become as intuitive as sending picture postcards was at the turn of the (20th) century.
Update: The day after I wrote this, I got a look at the Urban Tapestries client that was built in Java to run on the Sony Ericsson P800 smart phone. (It was supposed to have been ready for the trial, but apparently some XML-RPC coding delays held it up.) This version is much speedier and actually does the thing I hope for above, i.e. it connects to the network when possible and remains usable in unconnected mode. Also, the sound and image capture functions work! Hopefully, a version more like this one will see the light of day in a future trial.