stowaway/dev

Search results for "collaborative "

Bournemouth Soundseeing: collaborative authorship

2007Oct1818:03

Context: BA Interactive Media Production – Level I Authorship Unit; following on from some introductory ideas about Collaborative Authorship, we asked you to contribute to an online social space: http://impserver.bournemouth.ac.uk/bournemouthsoundseeing/

Join in

Anyone reading this who wants to join in the collaborative audio – please do!

Bournemouth Soundseeing

The Bournemouth Soundseeing project is an example of a space which provides scope for user participation. Here we have an example of the kind of thing you might consider for your own project to make an online social space, and this mini-project was designed to give you something concrete to examine as you consider problems like:

finding a balance between providing users with some freedom to participate, and the imposition of your own design constraints
every design constraint you impose is a barrier to participation
how even a simple practice project can throw up a lot of production issues
the biggest problem: what is this stuff for?

We consider some issues regarding design, production, and feasibility; and then speculate as to how we’ll form the next $188b start-up (Google’s current market capitalisation).

Architectures of Participation

In this project, there is a set of ‘designed-in constraints’: contributions must be short audio files, in mp3 format, and somehow tied to a location. Besides that, the user is free to do anything they like. At first glance you might think that this allows for little freedom. However, you can over-anticipate what your users will do.

When we built this page we conceived of it as a way of painting an audio portrait of Bournemouth, where the portrait is built up by ‘people in Bournemouth’. It soon became clear, though, that users don’t do what you might expect them to do: if you zoom out, you’ll see that some users have added audio in Scotland, Guernsey and Sussex. Indeed, the functionality of the page allows you to add audio to the North Pole if you want to.

Also, not all contributions were ‘audio portraits’ of Bournemouth, even if they are located in Bournemouth; some examples play along with the ‘authorial intention’ of the site, such as the recording of the singing hobo, or the sounds of the sea; others, however, were tenuous at best: The Frosties rap is delightful, but a perfect example of how your users will do things you didn’t anticipate. I love this kind of unpredictability, but of course, designers (and advertisers) don’t, so much… :)

Some of you also decided to be deeply reflexive and contribute debates about Collaborative Authorship. Theory points go to you.

Barriers to Entry

So some things we can talk about include the fact that how the ‘architecture of participation’ is designed will impact on whether people will take part and join in. To join in this project, you have to get some device that records, find something to record, get it onto a computer, turn it into an mp3, and upload it to the site. It’s worth noting that if you can motivate your user to make the first step, there’s still – as you found – hurdles to leap (such as figuring out how to turn your mobiles phone’s .amr file into an mp3). So we might wonder why anyone would be motivated to add anything to this page? And for each hurdle that they must overcome to join in, what is their pay-off?

We might note that all of you who added content knew that your peers were likely to find it and listen, as they were hoping you might do the same? Did the fact that your clip might be played in the lecture influence your decision to contribute? How much of online participation is about performativity, knowing an audience somewhere will get an insight into your carefully controlled online identity? How much of that performativity can you capture and harness? We’ll come back to this later in the unit…

Production Issues

The technology used in this project includes:

Javascript-based use of Google Maps API (Application Programming Interface)
XHTML / CSS for serving documents
FLASH audio player
PHP4 to build a dynamic page / process data upload
MySQL to store captured data

As mentioned in the lecture, those who contributed to this project were effectively beta-testing it. When this was built, it was tested by the person who built it. That person will never do all the things with it that your users will do with it. This is a very good illustration of some of the things you will need to do when you build your projects: testing it yourself will not do! You need to get other people to use it and see what happens. All sort of unexpected things will happen.

Some of the issues that have been found so far (don’t worry if you don’t understand the jargon here for now):

incomplete uploads of mp3 files result in balloons without audio; some kind of file integrity test would be nice.
on IE6 / PC / Windows XP: closing a bubble without pressing the ‘stop’ button fires the audio player again: a IE6 specific piece of Javascript code to fix this would be nice.
the Google Maps bubbles render nastily on IE6 / PC / Windows XP: outside our control?
Safari has caching issues, and a slightly different Document Object Model (javascript issues): complicated code to force reloads would be nice
Firefox / Mac / OS X runs Google Maps like a dog: worth investigation (‘running like a dog’ is technical jargon for ‘performance issues :)

When you make your projects, we won’t expect you to have solved every one of these types of problem with your site; we would, however, expect you to identify them, by leaving some time for people to use and test your site!

Also, the focus of this project is PHP and MySQL, so you’ll almost certainly find that learning to use a third party API (especially if it is Javascript!) will be too much to conquer within the next 4 weeks… don’t feel you have to crack everything in your first iteration. Concentrate on the idea, the feasibility, and in technical terms, the practicalities of capturing, storing and retrieving data.

What is this stuff for?

And really, this is the hardest part of developing projects like this. In the lecture we discussed where we might go with an idea like ‘Bournemouth Soundseeing’. We considered the idea of targeting Bournemouth’s tourism industry as a way of making some money; you collaboratively suggested some problems and solutions in taking this approach.

The proposition

A set of information about Bournemouth might be useful to tourists visiting Bournemouth. Allowing people (and businesses) to add their own content might be a inexpensive way to populate the site with useful information. A popular site might attract paying advertisers.

Limited media types

Audio files are somewhat limited. We might expand the functionality by allowing the addition of images, videos, or just plain old text. Database complexity increases.

Vandalism

What if people add porn soundtracks? Irrelevant fluff? Solution: moderation. Except it isn’t really a solution, of course. We could add an RSS feed, and some poor bored person would monitor it, and ensure that vandalism is removed. The BBC spend more than £1m per year on moderation. Can you cover that with advertising revenue?

Copyright Infringement

This works both ways: copyright infringing material may get added: the moderator will have to remove it. But also, will people know whether they can use the material that is on the site? Someone might hear the sounds of the sea and use it themselves, having been inspired to be creative.

Flickr allows you to specify the ‘copyrights’ you wish to retain over your image, and we could do the same. Contributors specify whether people can reuse the audio.

We might even use Flickr’s API to allow people to upload images from there, instead of reproducing the fuctionality here.

Overabundance of information

The map could be overrun with information, and become bewildering. So we might add a tag cloud, or search facility. Contributers use keywords to describe their content, and users can filter out stuff they don’t want to see, or specify information that they do want to see.

Inappropriate use-context

While we might have thought our target audience were people planning to come to Bournemouth, advertisers might want to access them when they’re here. You don’t look two weeks ahead for a KFC when you’re going on holiday. Unless you’re a KFC freak.

One idea we had was to use the ‘iStations’ so people can access it in the street. However, what we really want is for them to have the info in their pockets.

We have one nice clean dataset, moderated by our tea-boy. Data is added via an ordinary browser, but we build a platform for a mobile phone. People searching for info stumble upon a nice French restaurant round the corner and take a detour.

Advertisers don’t like UGC

This is a constantly evolving problem. Before Google bought YouTube, there was (to my knowledge, and I’ve been using YouTube for at least 18 years) no advertising on there. The nut to crack was the fact that advertisers want to control what media their brand gets associated with. No brand wants to be associated with potentially offensive material…

Google have introduced advertising to YouTube, using their keywords / pay-per-click system. Perhaps a chink is opening here. But we’re still talking Pot Noodles, rather than banking.

Wold dominion

So we’ve figured out (at least in our idle daydreams) how to make the site a going concern. We have a clean, functional dataset, and we tick over some revenue.

Our plans for world-dominion now turn to mobile phone manufacturers, who will build better mobile phone services than we can. We started out as a service using a mashsup of APIs. We start providing an API to our own data, with geo-data, meta-data in the form of keywords, and license this data to third parties who want to charge people to access the data through their whizzy iPhone interface.

As the slashdotters often say:

Get data
Serve data
…
Profit!

Remix Culture

Next week we’ll go back to a slightly more theoretical context and investigate the ‘Remix Culture’ that pie-in-the-sky ideas like this are a part of.

Finally

I would like to thank the following people who collaborated in the authorship of this post: the students of BAIMP2; Annie Hunt; CEMP; the CEMP website team; Mike Molesworth; James Jordan; Hugh Chignell and MARP 06-07; Google; IT services and their maintenance of the impserver; Bournemouth University; the open source community responsible for developing Textpattern, phpBB, PHP and MySQL; the developers at Macromedia and Adobe for providing Flash; the developers of the mp3 audio format; the developers of the JPG image format; Tim Berners-Lee and the W3C for building and developing HTML; the CSS working group; Microsoft, Apple and the Linux community for developing www browsers; Marc Anderssen and the Netscape browser developers; the Unix community; the inventors of TCP/IP; the American military types who worked on the ARPANET; Charles Babbage; and Aristotle. Apologies to all those who contributed, who I haven’t mentioned. You know who you are!

Author: joe
Categories: CEMP, system:lectures, lecture, collaborative, authorship, audio, mashup, google, map,
Comments: 1