A few weeks ago, Google announced support for analytics inside mobile apps and some cursory support for mobile sites:

Google Analytics now tracks mobile websites and mobile apps so you can better measure your mobile marketing efforts. If you’re optimizing content for mobile users and have created a mobile website, Google Analytics can track traffic to your mobile website from all web-enabled devices, whether or not the device runs JavaScript. This is made possible by adding a server side code snippet to your mobile website which will become available to all accounts in the coming weeks (download snippet instructions). We will be supporting PHP, Perl, JSP and ASPX sites in this release. Of course, you can still track visits to your regular website coming from high-end, Javascript enabled phones.

And that is the extent of the documentation you will find anywhere on Google on how to run analytics without javascript. The code included is handy if you happen to run one of their platforms, but the Walker’s mobile site runs on the python side of AppEngine, so their code doesn’t do us much good. Thankfully, since they provide us with the source, we can without too much trouble, translate the php or perl into python and make it AppEngine friendly.

How it works

Regular Google Analytics works by serving some javascript and a small 1px x 1px gif file to your site from Google. The gif lets Google learn many things from the HTTP request your browser makes, such as your browser, OS, where you came from, your rough geo location, etc. The javascript lets them learn all kinds of nifty things about your screen, flash versions, event that fire, etc. And Google tracks you through a site by setting some cookies on that gif they serve you.

To use GA without javascript, we can still do most of that, and we do it by generating our own gif file and passing some information back to Google through our server. That is, we generate a gif, assign and track our own cookie, and then gather that information as you move through the site, and use a HTTP request with the appropriate query strings and pass it back to Google, which they then compile and treat as regular old analytics.

The Code

To make this work in appeinge, we create a  URL in our webapp that we’ll serve the gif from. I’m using “/ga/”:

def main():
application = webapp.WSGIApplication(
[('/', home.MainHandler),
# edited out extra lines here
('/ga/', ga.GaHandler),
],
debug=False)
wsgiref.handlers.CGIHandler().run(application)

And here’s the big handler for /ga/. I based it mostly off the php and some of the perl (click to expand the full code):

from google.appengine.ext import webapp
from google.appengine.api import urlfetch
import re, hashlib, random, time, datetime, cgi, urllib, uuid

# google analytics stuff
VERSION = "4.4sh"
COOKIE_NAME = "__utmmobile"

# The path the cookie will be available to, edit this to use a different cookie path.
COOKIE_PATH = "/"

# Two years in seconds.
COOKIE_USER_PERSISTENCE = 63072000

GIF_DATA = [
      chr(0x47), chr(0x49), chr(0x46), chr(0x38), chr(0x39), chr(0x61),
      chr(0x01), chr(0x00), chr(0x01), chr(0x00), chr(0x80), chr(0xff),
      chr(0x00), chr(0xff), chr(0xff), chr(0xff), chr(0x00), chr(0x00),
      chr(0x00), chr(0x2c), chr(0x00), chr(0x00), chr(0x00), chr(0x00),
      chr(0x01), chr(0x00), chr(0x01), chr(0x00), chr(0x00), chr(0x02),
      chr(0x02), chr(0x44), chr(0x01), chr(0x00), chr(0x3b)
  ]

class GaHandler(webapp.RequestHandler):
	def getIP(self,remoteAddress):
	  	if remoteAddress == '' or remoteAddress == None:
			return ''

		#Capture the first three octects of the IP address and replace the forth
		#with 0, e.g. 124.455.3.123 becomes 124.455.3.0
		res = re.findall(r'\d+\.\d+\.\d+\.', remoteAddress)
		if res:
			return res[0] + "0"
		else:
			return ""

	def getVisitorId(self, guid, account, userAgent, cookie):
		#If there is a value in the cookie, don't change it.
		if type(cookie).__name__ != 'NoneType': # or len(cookie)!=0:
			return cookie

		message = ""

		if type(guid).__name__ != 'NoneType': # or len(guid)!=0:
			#Create the visitor id using the guid.
			message = guid + account
		else:
			#otherwise this is a new user, create a new random id.
			message = userAgent + uuid.uuid1(self.getRandomNumber()).__str__()

		m = hashlib.md5()
		m.update(message)
		md5String = m.hexdigest()

		return str("0x" + md5String[0:16])

	def getRandomNumber(self):
		return random.randrange(0, 0x7fffffff)

	def sendRequestToGoogleAnalytics(self,utmUrl):
		'''
		Make a tracking request to Google Analytics from this server.
		Copies the headers from the original request to the new one.
		If request containg utmdebug parameter, exceptions encountered
		communicating with Google Analytics are thown.
		'''
		headers = {
			"user_agent": self.request.headers.get('user_agent'),
			"Accepts-Language": self.request.headers.get('http_accept_language'),
			}
		if len(self.request.get("utmdebug"))!=0:
			data = urlfetch.fetch(utmUrl, headers=headers)
		else:
			try:
				data = urlfetch.fetch(utmUrl, headers=headers)
			except:
				pass

	def get(self):
		'''
		Track a page view, updates all the cookies and campaign tracker,
		makes a server side request to Google Analytics and writes the transparent
		gif byte data to the response.
		'''
	  	timeStamp = time.time()

		domainName = self.request.headers.get('host')
		domainName = domainName.partition(':')[0]

		if len(domainName) == 0:
			domainName = "m.walkerart.org";

		#Get the referrer from the utmr parameter, this is the referrer to the
		#page that contains the tracking pixel, not the referrer for tracking
		#pixel.
		documentReferer = self.request.get("utmr")

		if len(documentReferer) == 0 or documentReferer != "0":
			documentReferer = "-"
		else:
			documentReferer = urllib.unquote_plus(documentReferer)

		documentPath = self.request.get("utmp")
		if len(documentPath)==0:
			documentPath = ""
		else:
			documentPath = urllib.unquote_plus(documentPath)

		account = self.request.get("utmac")
		userAgent = self.request.headers.get("user_agent")
		if len(userAgent)==0:
			userAgent = ""

		#Try and get visitor cookie from the request.
		cookie = self.request.cookies.get(COOKIE_NAME)

		visitorId = str(self.getVisitorId(self.request.headers.get("HTTP_X_DCMGUID"), account, userAgent, cookie))

		#Always try and add the cookie to the response.
		d = datetime.datetime.fromtimestamp(timeStamp + COOKIE_USER_PERSISTENCE)
		expireDate = d.strftime('%a,%d-%b-%Y %H:%M:%S GMT')

		self.response.headers.add_header('Set-Cookie', COOKIE_NAME+'='+visitorId +'; path='+COOKIE_PATH+'; expires='+expireDate+';' )
	  	utmGifLocation = "http://www.google-analytics.com/__utm.gif"

		myIP = self.getIP(self.request.remote_addr)

		#Construct the gif hit url.
		utmUrl = utmGifLocation + "?" + "utmwv=" + VERSION  + \
			"&utmn=" + str(self.getRandomNumber()) + \
			"&utmhn=" + urllib.pathname2url(domainName) + \
			"&utmr=" + urllib.pathname2url(documentReferer) + \
			"&utmp=" + urllib.pathname2url(documentPath) + \
			"&utmac=" + account + \
			"&utmcc=__utma%3D999.999.999.999.999.1%3B" + \
			"&utmvid=" + str(visitorId) + \
			"&utmip=" + str(myIP)

		# we dont send requests when we're developing
		if domainName != 'localhost':
			self.sendRequestToGoogleAnalytics(utmUrl)

		#If the debug parameter is on, add a header to the response that contains
		#the url that was used to contact Google Analytics.
		if len(self.request.get("utmdebug")) != 0:
			self.response.headers.add_header("X-GA-MOBILE-URL" , utmUrl)

	  	#Finally write the gif data to the response.
		self.response.headers.add_header('Content-Type', 'image/gif' )
		self.response.headers.add_header('Cache-Control', 'private, no-cache, no-cache=Set-Cookie, proxy-revalidate' )
		self.response.headers.add_header('Pragma', 'no-cache' )
		self.response.headers.add_header('Expires', 'Wed, 17 Sep 1975 21:32:10 GMT' )
		self.response.out.write(''.join(GIF_DATA))

So now we know what to do with our requests at /ga/ when we get them, we just need to make the proper requests to that URL in the first place. So we need to generate the URL we’re going to have the visitor’s browser request in the first place. With normal django, we would be able to use template_context to automatically insert it into the page’s template values. But, since AppEngine doesn’t use that, we have our own helper functions to do that, which I showed some of in my last post. Here’s the updated helper functions, with the GoogleAnalyticsGetImageUrl function included:

import settings

def googleAnalyticsGetImageUrl(request):
	url = ""
	url += '/ga/' + "?"
	url += "utmac=" + settings.GA_ACCOUNT
	url += "&utmn=" + str(random.randrange(0, 0x7fffffff))

	referer = request.referrer
	query = urllib.urlencode(request.GET) #$_SERVER["QUERY_STRING"];
	path = request.path #$_SERVER["REQUEST_URI"];

	if len(referer) == 0:
		referer = "-"

	url += "&utmr=" + urllib.pathname2url(referer)

	if len(path)!=0:
		url += "&utmp=" + urllib.pathname2url(path)

	url += "&guid=ON";

	return {'gaImgUrl':url}

def getTempalteValues(request):
	myDict = {}
	myDict.update(ua_test(request))
	myDict.update(googleAnalyticsGetImageUrl(request))
	return myDict

Assuming we use getTemplateValues to set up our inital template_values dict, we should have a variable named ‘gaImgUrl’ in our page. To use it, all we need to do is put this at the bottom of every page on the site:

<img src="{{ gaImgUrl }}" alt="analytics" />

My settings file contains the GA_ACCOUNT variable, but replaces the standard GA-XXXXXX-X setup with MO-XXXXXX-X. I’m assuming the MO- tells google that it’s a mobile so accept the proxied requests.

One thing to keep in mind with this technique is that you cannot cache your rendered templates. The image you server will necessarily have a different query string every time, and if you cached it, you would ruin your analytics. Instead, you should cache nearly everything from your view functions, except the gaImgUrl variable.

But not this year.

This year, we had a plan.

Actually, we came up with the plan after our no-show defeat last year, but we smartly held onto it for this year (thank you, iCal). On the day of the contest, we replaced every image of artwork on the Walker website with an image of a pumpkin.

And the rest of the pages (click to embiggen):

Calendar

Collections and Resources

Artists-in-Residence

Visual Arts

Design Blog

We ended up winning in the “Funniest Pumpkin” category.

Because we serve all of our media from a single server using lighttpd, and our files are all uniformly named, we were able to implement a simple rule set in lighty to replace the images. Instead of the requested file, each image was re-directed to a simple perl script that would grab a random jpg from our pool of pumpkin images, and send it’s contents instead. Part of the plan was that we would only serve these images to people visiting our site from inside our internal network. The rest of the world would see our website just as always. In our department, we all unplugged our ethernet cables and ran off of our firewall’d WiFi, which effectively put us outside the network, seeing nothing different on the site. We had a hard time holding back evil cackles as people came to us wondering how our site was hacked, and watching it slowly dawn on them that this was our pumpkin.

The images we used were all the creative commons licensed flickr images of pumpkins I could find. There were 54 of them. Here they are, for credit:

• Pumpkin
• My Geek-o-Lantern.
• Pumpkins!
• mini pumpkins
• My favorite season
• Tux Pumpkin!
• Thanksgiving, Orcas Island
• the last pumpkins
• candy pumpkins
• Jack O’Lanterns
• Dreams of Mellowcreme
• R.I.P. Punky
• Inside the Amber Pieces of Cloth Time
• Pumpkin Trio on Flickr
• Cannibal Pumpkin
• Pumpkin Avalanche
• Day 320 One of my favorites
• IMG_0589
• halloween bokeh
• Spooky
• pumpkin rows.jpg
• My front steps
• Halloween 2006
• Halloween 2005
• Fall
• pumpkin twins
• fructele toamnei
• Pumpkin Harvest
• small pie pumpkin
• Pumpkins – Space Invader
• You smiling at me
• after the storm
• You Must Be Daddy’s Little Pumpkin I Can Tell by the Way You Roll
• Mini citrouilles / Mini Pumpkins
• Jack
• Duaflex: Pumpkin Patch
• ‘WELCOME GREAT PUMPKIN’
• pumpkin lit
• Don’t overdo it this Halloween
• Smiler glow
• Hypnotised pumpkin
• sad pumpkins
• Red Eye
• winking pumpkin
• Black Cat Pumpkin
• Take me to your….tricks and treats!
• Which one?
• Pumpkins and Gourds Everywhere!
• smiley pumpkin
• Spongebob Pumpkin Pants
• Silk Garden Lite Socks
• i like how cute the tiny pumpkin is
• Happy Halloween From Sunny New Jersey!
• patch o’ pumpkins

Reviewing our current site to inform the mobile site

The web framework we use for most of our site has the ability, with some small changes, to load different versions of a page based on a visitor’s User Agent (what browser they’re using). This would mean we could detect if a visitor was running IE on a Desktop or Mobile Safari on an iPhone, and serve each of them two different versions of a page. This is how a lot of mobile sites are done.

This is not the approach we went with for our mobile site, because it violates two of the primary rules (in my mind) of making a mobile website:

1. Make it simple.
2. Give people the stuff they’re looking for on their phones right away.

Our site is complicated: we have pages for different disciplines, a calendar with years of archives, and many specialty sites. Rule #1, violated. To address #2, I took a look at our web analytics to figure out what most people come to our site looking for. This won’t surprise anyone, but it’s hours, admission, directions, and what’s happening today at the Walker:

Top Walker Pages as noted by Google Analytics

So it seems pretty clear those things should be up front. One of the other things you might want to access on a mobile is Art on Call. While Art on Call is designed primarily around dial-in access, there is also a website, but it isn’t optimized for the small screen of a smartphone. We have WiFi in most spaces within our building, so accessing Art on Call via an web interface and streaming audio via HTTP rather than POTS is a distinct possibility that I wanted to enable.

Prototyping with Google AppEngine

I decided to develop a quick prototype using Google AppEngine, thinking I’d end up using GAE in the end, too. Because this was a 20% time project, I had the freedom to do it using the technology I was interested in. AppEngine has the advantage of being something that isn’t hosted on our server, so there was no need to configure any complicated server stuff. In my mind, AppEngine is perfect for a mobile site because of the low bandwidth requirements for a mobile site. Google doesn’t provide a ton for free, but if your pages are only 20K each, you can fit quite a bit within the quotas they do give provide. AppEngine’s primary language is also python, a big plus, since python is the best programming language.

In about two days I built a proof of concept mobile site that displayed the big-ticket pages (hours, admission,etc.) and had a simple interface for Art on Call. Using iUi as a front-end framework was really, really useful here, because it meant that the amount of HTML/CSS/JS I had to code was super minimal, and I didn’t have to design anything.

I showed the prototype to Robin and she enthusiastically gave me the green light to work on it full-time.

Designing a mobile website

A strategy I saw when looking at mobile sites was to actually have two mobile sites: one for the A-grade phones (iPhone, Nokia S60, Android, Pre) and one for the B- and C-grade phones (Blackberry and Windows Mobile). The main difference between the two is the use of javascript and some more advanced layout. Depending on what version of Blackberry you look at, they have a pretty lousy HTML/CSS implementation, and horrendous or no javascript support.

To work around this, our mobile site does not use any javascript on most pages and tries to keep the HTML/CSS pretty simple. We don’t do any fancy animations to load between pages like iUi or jQtouch do: even on an iPhone those animations are slow. If you make your pages small enough, they should load fast enough and a transition is not necessary.

Designing mobile pages is fun. The size and interface methods for the device force you to re-think how to people interact and what’s important. They’re also fun because they’re blissfully simple. Each page on our mobile site is usually just a headline, image, paragraph or two, and some links. Laying out and styling that content is not rocket surgery.

Initially, when I did my design mockups in Photoshop, I wanted to use a numpad on the site for Art on Call, much like the iPhone features for making a phone call. There’s no easy input for doing this, but I thought it wouldn’t be too hard to create one with a little javascript (for those that had it). Unfortunately, due to the way touchscreen phones handle click/touch events in the browser, there’s a delay between when you touch and when the click event fires in javascript. This meant that it was possible to touch/type the number much faster than the javascript events fired. No go.

Instead, the latest versions of WebKit provide with a HTML5 input field with a type of “number”. On iPhone OS 3.1 and better, it will bring up the keypad already switched to the numeric keys. It does not do this on iPhone OS prior to 3.1. I’m not sure how Android and Pre handle it.

Mocked up Art on Call code input.

Implimented Art on Call code input.

Comparing smartphones

Here’s a few screenshots of the site on various phones:

Palm Pre

Android 1.5

Blackberry 9630

Not pictured is Windows Mobile, because it looks really bad.

A future post may cover getting all of these emulators up and running, because it’s not as straight easy as it should be. Working with the blackberry emulator is especially painful.

How our mobile site works

The basic methodology for our mobile site is to pull the data, via either RSS or XML from our main website, parse it, cache it, and re-template it for mobile visitors. Nearly all of the pages on our site are available via XML if you know how to look. Parsing XML into usable data is a computationally expensive task, so caching is very important. Thankfully, AppEngine provides easy access to memcache, so we can memcache the XML fetches and the parsing as much as possible. Here’s our simple but effective URL parse/cache helper function:

from google.appengine.api import urlfetch
from xml.dom import minidom
from google.appengine.api import memcache

def parse(url,timeout=3600):
	memKey = hash(url)
	r = memcache.get('fetch_%s' % memKey)
	if r == None:
		r = urlfetch.fetch(url)
		memcache.add(key="fetch_%s" % memKey, value=r, time=timeout)
	if r.status_code == 200:
		dom = memcache.get('dom_%s' % memKey)
		if dom == None:
			dom = minidom.parseString(r.content)
			memcache.add(key="dom_%s" % memKey, value=dom, time=timeout)
		return dom
	else:
		return False

Google AppEngine does not impose much of a structure for your web app. Similar to Django’s urls.py, you link regular expressions for URLS to class-based handlers. You can’t pass any variables beyond what’s in the URL or the WebOb to the request handler. Each handler will call a different method, depending if it’s a GET, POST, DELETE, http request. If you’re coming from the django world like me, this is not much of a big deal at first, but it gets tedious pretty fast. If I had it to do over again, I’d probably use app-engine-patch from the outset, and thus be able to use all the normal django goodies like middleware, template context, and way more configurable urls.

Within each handler, we also cache the generated data where possible. That is, after our get handler has run, we cache all the values that we pass to our template that won’t change over time. Here’s an example of the classes that handle the visit section of our mobile site:

from google.appengine.ext import webapp
from google.appengine.ext.webapp import template
from google.appengine.api import memcache
from xml.dom import minidom
from google.appengine.api import memcache
from utils import feeds, parse, template_context, text
import settings

class VisitDetailHandler(webapp.RequestHandler):
	def get(self):
		url = self.request.get("s") + "?style=xml"
		template_values = template_context.getTempalteValues(self.request)
		path = settings.TEMPLATE_DIR + 'info.html'
		memKey = hash(url)

		r = memcache.get('visit_%s' % memKey)
		if r and not settings.DEBUG:
			template_values.update(r)
			self.response.out.write(template.render(path, template_values))
		else:
			dom = parse.parse(url)
			records = dom.getElementsByTagName("record")
			contents = []
			for rec in records:
				title = text.clean_utf8(rec.getElementsByTagName('title')[0].childNodes[0].nodeValue)
				body = text.clean_utf8(rec.getElementsByTagName('body')[0].childNodes[0].nodeValue)
				contents.append({'title':title,'body':body})

			back = {'href':'/visit/#top', 'text':'Visiting'}
			cacheableTemplateValues = { "contents": contents,'back':back }
			memcache.add(key='visit_%s' % memKey, value={ "contents": contents,'back':back }, time=7200)
			template_values.update(cacheableTemplateValues)
			self.response.out.write(template.render(path, template_values))

Dealing with parsing XML via the standard DOM methods is a great way to test your tolerance for pain. I would use libxml and xpath, AppEngine doesn’t provide those libraries in their python environment.

Because the only part of Django’s template system that AppEngine uses is the template language, and nothing else, we have to roll our own helper functions for context. Meaning, if we want to pass a bunch variables by default to our templates, something easy in django, we have to do it a little differently with GAE. I set up a function called getTemplateValues, which we pass the WebOb request, and it ferrets out and organizes info we need for the templates, passing it back as a dict.

def ua_test(request):
	uastring = request.headers.get('user_agent')
	uaDict = {}
	if "Mobile" in uastring and "Safari" in uastring:
		uaDict['isIphone'] = True
	if 'BlackBerry' in uastring:
		uaDict['isBlackBerry'] = True
	return uaDict

def getTempalteValues(request):
	myDict = {}
	myDict.update(ua_test(request))
	myDict.update(googleAnalyticsGetImageUrl(request))
	return myDict

In my next post, I’ll talk about how to track visitors on a mobile site using google analytics, without using javascript.

Photo by k0a1a.net.

Minneapolis-based Northern Lights.mn has announced the second year of Ar(ists) on the Verge:

Northern Lights announces a second round of Art(ists) on the Verge commissions (AOV2). AOV2 is an intensive, mentor-based fellowship program for 5 Minnesota-based, emerging artists or artist groups working experimentally at the intersection of art,  technology, and digital culture with a focus on network-based practices that are interactive and/or participatory. AOV2 is generously supported by the Jerome Foundation.

Northern Lights was founded by former Walker New Media Curator Steve Dietz. The grants this year will be juried by Dietz, along with Kathleen Forde, Curator for Time-Based Arts at the Experimental Media and Performing Arts Center (EMPAC) in Troy, NY, and the Walker’s chief curator, Darsie Alexander.

The resulting show  show at the Weisman Art Museum from last years grantees was worth checking out. It is good to see work being done to create our own new media art structures here in Minnesota, rather than watching cool things like Eyebeam happen from afar.

And by the way, Northern Lights’ blog, Public Address, has become one of my favorite reads for neat artwork being made around the world. I confess I find a lot of art blogs rather dry and esoteric, but not Public Address. And, this may seem somewhat mundane and obvious, but near every post has an interesting image, which is nice for an art blog.

On your computer, select the “City of Minneapolis Public WiFi” network.

Open your browser and point yourself to walkerart.org. That should do it. You may be directed to a user agreement log in screen and then the “walled garden” of Minneapolis city information and lists of other accessible community sites. The Walker is listed under Area Arts & Culture > Arts & Museums > Art Museums.

Wireless Log In Screen

Minneapolis Dowtown Area Walled Garden Portal

A brief history of Minneapolis Municipal WiFi

Several years ago, the City of Minneapolis joined with USI Wireless to build out a city-wide network. The goal was to provide access for city government and citizens. The city would be a core tenant, paying USI, and USI would sell access to citizens. The city required USI to build a community portal and USI must provide grants out of it’s profits to non-profits working to bridge the digital divide.

Over the last several years, the network has slowly been built out. Right now there are some problem areas, which include Loring Park and the Minneapolis Sculpture Garden. My understanding is that these areas should see service sometime soon, though I’m not sure of any exact plans on the Sculpture Garden.

There are a couple things I have really liked about the network:

• We’re doing it. A lot of cities have talked about building municipal wifi, and then discover large problems and things don’t work well. There have been some issues with in Minneapolis, it is taking longer to build the network than originally thought, but my impression is that it has worked fairly well.
• It’s network neutral. The agreement between the city and USI specifically requires USI to not hinder any type of traffic over another.
• Parts of it are free. This is how you can get to our site for free.
• It’s low cost. The cost for being a subscriber is pretty low, compared to other wire-based providers.
• It’s local. USI is a local company.

For more information on the network and the history, Peter Fleck has been blogging about Minneapolis WiFi for some time.

• Eric at Adapted Studio put together this sweet little demo of HTML5 and Canvas in action, in the form of the Game of life. Source code is included, too, if you want to learn a few nifty things.
• Color me surprised, but Microsoft is actually purporting to work together on at least some of the HTML5 spec. This could be good. Using <video> would be much easier if everyone would do it. But there still is the nasty issue of codecs, which is even more thorny than W3C specs.
• This is from about a year ago, but John Resig (of jQuery fame) posted a very nice tutorial for Learning Advanced Javascript. It clears up a lot of confusion about seemingly advanced techniques.
• Also worth perusing is Mark Pilgrim’s Gentle introduction to video formatting. If you’re a video geek, you might know some of this, but there’s detail that might fill in some gaps. The slides are also slightly amusing. I had no idea the .mkv format came from a bunch of guys in Russia that decided to opensource it.

HTML 5 image form here.

As I explored in a previous post, we used a digital still camera to take our single frame images, then stitch them together in quicktime as a longer move. For the event itself, we used two cameras. The primary camera, a Canon 10D, was equipped with a 16mm wide-angle lens that gave us a really good shot of the entire space. The second camera, a Canon G9, wasn’t quite as wide-angle, but would be a good backup camera in case something happened to the 10D. A sample of the space:

We taped off sight lines, just out of frame, so the artists would know what was in frame and what was not.

Our events & media production team set up a very nice mount for the cameras, as you can sort of see in this blurry, hastily snapped iPhone shot:

Unfortunately, every good plan has it’s own particular achilies heel. In this case, that heel was electronics’ desire for an uninterrupted flow of electricity. Midway through the evening on Friday night, the circuit breaker that powered the computer and cameras was tripped. Power was quickly restored, and the computers were turned back on. However, the startup procedure to get the time-lapse running was not something that could be scripted or automated, so the capture did not start again until 9 AM the next morning when I cam to check on things.

The lesson here: Time lapse is awesome, but next time, use an uninterpretable power supply. Preferably one that has a loud audible warning. I probably should have thought of this, but it really didn’t occur to me how chaotic and crazy the event would actually be (I mean that in the most endearing way possible).

The fact that we lost 12 hours of the time-lapse does stink, but it also means we still captured 12 hours of the event. I’ve assembled the video, and it has been posted to YouTube, but the quailty is not as good as a quicktime file. Here is a higher-quality quicktime MP4:

Click here to view the embedded video.
Click to play, or download the original file.

To fill some of the 12-hour gap, we hastily collected photos from whoever was available and had taken photos. They’ve been put together as a short slideshow filling a portion of the 12-hour missing period.

Making a time-lapse movie is not hard. While it can be done using a video camera, it’s easier to use a digital still camera. You take a series of images at predefined intervals and stitch them together using software like After Effects, or, even simpler, Quicktime Pro. We’re using a Canon G10 and the Canon Remote Capture software to take photos every 10 seconds. I set up a test in our office just to make sure it would run correctly and without incident. Here’s the result:

Taking one photo every 10 seconds over 24 hours generates 8640 frames, creating a video just under 10 minutes long. We may end up dropping every other frame to create a shorter movie. The nice thing about using a digital still camera for this is that it produces a video well beyond even 1080P HD resolution.

In the above video, you can enjoy watching me look up documentation on Django, read a book about symfony, and my be mesmerized by a screensaver.

Homepage

The first change you’ll notice when visiting the site is that the home page got an overhaul. The rotators for New Artwork and Featured Collections were changed to display images to the full-size of their boxes and they animate smoother. This means sometimes cropping work, but we think it’s a trade-off worth making.

Articles are also displayed with a three-tier hierarchy, allowing the site to call recent writing out more prominently, even though we feature six instead of 10. The sidebar on the homepage has also been reorganized, bringing the mnartists.org blog to the top and adding links to the Facebook and Twitter profiles for mnartists.org.

The revised homepage.

Revised article page

Articles

Articles got some attention in several ways. First, we changed the way images are displayed by adding a larger expanding gallery at the top of each article, rather than having small images thumbnails listed down the left side. On the back end for editors, we also added an enhanced editor (tiny mce) to allow for richer control over formatting and even embedding other media.

Social media Sharing
Across many areas of the site, you’ll now see a link to Share this article/artwork/collection/event. Using much of the same code we developed for the Walker Calendar, sharing is now easier on mnartists.org. We connect with Facebook, Twitter, Myspace, Delicious, Google Bookmarks, and Yahoo Bookmarks, as well as rolling in email links in a few places.

The new sharing links.

Search

The one change that will probably make everyone cry tears of joy is the search results refinement. We’ve heard lots of complaints about the search, not wholly unfounded. The search actually works pretty good, but the simple search weights everything more or less equally. If you search for someone’s name, hoping to just get their artist page, it will be in the results, but there might be other things that rank higher.

The revised search result page lets you change your simple search into an advanced search, using tabs above the results to select the type of resource you want to search for. This is very similar to what google does with their search results refinements (web, images, video, maps, etc.).

Old style search results

New search results with refinements.

Artist Pages

Artist pages also got an overhaul with two big changes. First, images for each artwork will display at a new, larger size, about 519px tall and/or 520px wide. For artworks with more than one image associated, a gallery rotating gallery will cycle through the images. Previously, if an artwork had more than one image associated, only the first would show up, and the rest would be listed in the “Related Media” list.

Old artist homepage.

Revised artist page.

Secondly, we changed the way Related Media works. Now, it is simply “Media List” lists every type of media associated with an artwork. More importantly, for non-image media, such as video and audio, we embed the media in the actual page. So if you upload a quicktime file, the quicktime embed code will be generated and put right into the page. MP3 audio files will be played with the jwplayer flash player, making audio on the site a lot more nifty. We’re using the excellent jquery.media plugin to do this.

This approach to handling media isn’t without some issues, but given the variety of media already on the site and our resources to work on it, this is the best solution. We are looking at making more substantial changes to this in the future, but this is a good incremental improvement.

Artwork with video before changes.

Artwork with video after changes. (Two video files attached)

The image size and media enhancements have also been applied to the collections area of the site.

Editing text

Another change we made a month ago was adding a visual editor to various form fields on the site. Prior to the change, users could only enter a very limited selection of markup to entries, [b] for bold, [i] for italic, and [a] for a link. We’ve eliminated that and replaced it with the new editor (tiny_mce), which allows for bold, italic, underline, unordered lists, and links. While seemingly simple, it was actually quite a challenge to deal with both the legacy code and the new formatting. The text actually goes through several transformations between the editor, the database, and being displayed again. Keeping everything consistent is a non-trivial pile of regular expressions.

The new visual editor.

One thing that we will have to keep an eye on is users pasting in text from Microsoft Word. Word tends to shove a bunch of garbage pseudo-html into the clipboard, and when pasting, it can be difficult to filter out. The editor has a button to Paste from word (with the blue W) that helps.

Any issues?

If you notice any problems with the site, please let our community manager or myself know. Bugs may crop up, and we do fix things.

There are four different Walker-related groups for user contributed content on flickr: Walker Art Center, Minneapolis Sculpture Garden, Walker After Hours, and WACTAC. The social media page highlights the most recent Walker and Garden photos. We also post a good number of photos of our own, from After Hours to exhibition installation views. To make things clearer, we also added a official photography policy.

Since around September of 2008, I have been posting on twitter as the @walkerartcenter. Twitterfeed fills in some gaps with our blog posts, but I try to announce other notable things and answer visitor questions there. When the #snowmageddon happened, our twitter followers knew about it first. The social media page lists our latest 5 tweets to give visitors a good indication of what we tweet about.

We’re on the Facebook, too, and keep the page up-to-date with selected events and current exhibitions. Facebook doesn’t let Pages do a whole lot, but we’ve got 6500 fans.

And the Walker’s YouTube page has been around for over a year, first starting with the Tell us a story about your suburb project for Worlds Away. We’ve posted a few things from the archives there, and we’re slowly porting content from the Walker Channel to YouTube as well.

Setting the social media page up was made easier by using the Tweet! and jQuery.Flickr plugins.