Yesterday I had a quick play around with VéritéCo’s Timeline JS. It’s a great little open source JavaScript library for creating “beautifully crafted timelines that are easy, and intuitive to use”. It is primarily built to load content from various online services like YouTube, Flickr, Twitter and the like; but because it is open source JS I was able to hack it to get it working with the Living Archive prototype.
One nice thing about working with a collection of performance videos: every performance — and subsequently every video — has a date. The performance, and the shooting of the video, happened at a particular time. And, luckily for us, we have most of that information in our data set.
So: having time/date data accessible, and having some open source code to work with, means that it was relatively trivial to take a set of search results like this:
And display them like this:
(The Circus Oz Living Archive is in closed alpha at the moment, so I can’t link to a working demo, but I hope you get the idea).
I was talking to Adrian the other day about the flow and direction of the project, especially the challenges of deciding what to focus my development energy on. He noted that in the environment in which we are researching (online archives, digital video, digital storytelling etc), the rate of change is so fast that we can’t possibly compete on a technical level with commercial organisations devoted to these things. And my PhD is not even about technology per se: I’m not trying to come up with some advanced or innovative technology, and I don’t see that we have that capacity in the project team. Drawing lines between commercial work, commercial research, and (what Adrian has called) ‘research research’ is a constant struggle in the project.
In that context, what I like about using a ‘live’ prototyping technique is that it utilises existing, free, technical solutions (we’ve been doing this all along: Kaltura, Twitter Bootstrap, and now Timeline), which means that we don’t have to do a huge amount of technical work in order to answer a “what if you could…?” question:
Q: What if you could view search results in a time-based interface?
A: Here, try this.
I would argue that a live working prototype (using real code, in a real environment) takes us much closer to an answer than any kind of static design, paper prototype, or prototype that uses a ‘test’ data set. What I’ve built with Timeline JS is certainly not the only answer to this question. It’s probably not the best solution. In fact — and here is where my thoughts start to get convoluted — maybe it’s not an answer at all. Maybe the prototype is really a tool to help us ask better questions.
What I’m getting at is something about the importance of prototyping in real (not idealised) situations, and the fact that designing ‘in the real world’ throws up questions as well as answers. It’s a bit of an incoherent thought for now , but there is something in there that could give me a new perspective on my PhD work so far, and a clearer idea of what I’ll be working on for the remainder of the year.
