Category Archives: innovation

The Brooklyn Museum API – Q&A with Shelley Bernstein and Paul Beaudoin

The concept and importance of museum-based API’s are notions that I’ve written about consistently (boringly, probably) both on this blog and elsewhere on the web. Programmatic and open access to data is – IMO – absolutely key to ensuring the long-term success of online collections.

Many conversations have been going on about how to make API’s happen over the last couple of years, and I think we’re finally seeing these conversations move away from niche groups of enthusiastic developers (eg. Mashed Museum ) into a more mainstream debate which also involves budget holders and strategists. These conversations have been aided by metrics from social media sites like Twitter which indicate that API access figures sometimes outstrip “normal web” browsing by a factor of 10 or more.

On March 4th 2009, Brooklyn Museum announced the launch of their API, the latest in a series of developments around their online collection. Brooklyn occupies a space which generates a fair amount of awe in museum web circles: Shelley Bernstein and team are always several steps in front of the curve – innovating rapidly, encouraging a “just do it” attitude, and most importantly, engaging wholly with a totally committed tribe of users. Many other museum try to do social media. Brooklyn lives social media.

So, as they say – without further ado – here’s Shelley and Paul talking about what they did, how they did it, and why.

Q: First and foremost, could you please introduce yourselves – what your main roles and responsibilities are and how you fit within the museum.

Shelley Bernstein, Chief of Technology. I manage the department that runs the Museum’s helpdesk, Network Administration, Website, gallery technology, and social media.

Paul Beaudoin, Programmer. I push data around on the back-end and build website features and internal tools.

Q: Can you explain in as non-technical language as possible what exactly the Brooklyn API is, and what it lets people do?

SB: It’s basically a way outside programmers can query our Collections data and create their own applications using it.

Q: Why did you decide to build an API? What are the main things you hope to achieve …and what about those age old “social web” problems like authority, value and so-on?

SB: First, practical… in the past we’d been asked to be a part of larger projects where institutions were trying to aggregate data across many collections (like d*hub). At the time, we couldn’t justify allocating the time to provide data sets which would become stale as fast as we could turn over the data. By developing the API, we can create this one thing that will work for many people so it no longer become a project every time we are asked to take part.

Second, community… the developer community is not one we’d worked with before. We’d recently had exposure to the indicommons community at the Flickr Commons and had seen developers like David Wilkinson do some great things with our data there. It’s been a very positive experience and one we wanted to carry forward into our Collection, not just the materials we are posting to The Commons.

Third, community+practical… I think we needed to recognize that ideas about our data can come from anywhere, and encourage outside partnerships. We should recognize that programmers from outside the organization will have skills and ideas that we don’t have internally and encourage everyone to use them with our data if they want to. When they do, we want to make sure we get them the credit they deserve by pointing our visitors to their sites so they get some exposure for their efforts.

Q: How have you built it? (Both from a technical and a project perspective: what platform, backend systems, relationship to collections management / website; also how long has it taken, and how have you run the project?)

PB: The API sits on top of our existing “OpenCollection” code (no relation to namesake at http://www.collectiveaccess.org) which we developed about a year ago. OpenCollection is a set of PHP classes sitting on top of a MySQL database, which contains all of the object data that’s been approved for Web.

All that data originates in our internal collections management systems and digital asset systems. SSIS scripts run nightly to identify approved data and images and push them to our FreeBSD servers for processing. We have several internal workflow tools that also contribute assets like labels, press releases, videos, podcasts, and custom-cropped thumbnails. A series of BASH and PHP scripts merge the data from the various sources and generate new derivatives as required (ImageMagick). Once compiled new collection database dumps and images are pushed out to the Web servers overnight. Everything is scheduled to run automatically so new data and images approved on Monday will be available in the wee hours Tuesday.

The API itself took about four weeks to build and document (documentation may have consumed the better part of that). But that seems like a misleading figure because so much of the API piggy-backs on our existing codebase. OpenCollection itself – and all of the data flow scripts that support it – took many months to build.

Cool diagrams. Every desk should have some.

Cool diagrams. Every desk should have some.

Q: How did you go about communicating the benefits of an API to internal stakeholders?

SB: Ha, well we used your hoard.it website as an example of what can happen if we don’t! The general discussion centered around how we can work with the community and develop a way people can can do this under our own terms, the alternative being that people are likely to do what they want anyway. We’d rather work with, than against. It also helped us immensely that an API had been released by DigitalNZ , so we had an example out there that we could follow.

Q: It’s obviously early days, but how much interest and take-up have you had? How much are you anticipating?

SB: We are not expecting a ton, but we’ve already seen a lot of creativity flowing which you can check out in our Application Gallery. We already know of a few things brewing that are really exciting. And Luke over at the Powerhouse is working on getting our data into d*hub already, so stay tuned.

Q: Can you give us some indication of the budget – at least ballpark, or as a % compared to your annual operating budget for the website?

SB: There was no budget specifically assigned to this project. We had an opening of time where we thought we could slot in the development and took it. Moving forward, we will make changes to the API and add features as time can be allocated, but it will often need to be secondary to other projects we need to accomplish.

Q: How are you dealing with rights issues?

SB: Anything that is under copyright is being delivered at a very small thumbnail size (100px wide on the longest size) for identification purposes only.

Q: What restrictions do you place on users when accessing, displaying and otherwise using your data?

SB: I’m not even going to attempt to summarize this one. Here’s the Terms of Service – everyone go get a good cup of coffee before settling down with it.

Q: You chose a particular approach (REST) to expose your collections. Could you talk a bit about the technical options you considered before coming to this solution, and why you preferred REST to these others?

PB: Actually it’s been pointed out that our API isn’t perfectly RESTful, so let me say first that, humbly, we consider our API REST-inspired at best. I’ve long been a fan of REST and tend to gravitate to it in principal. But when it comes down to it, development time and ease of use are the top concerns.

At the time the API was spec’ed we decided it was more important to build something that someone could jump right into than something meeting some aesthetic ideal. Of course those aren’t mutually exclusive goals if you have all the dev time in the world, but we don’t. So we thought about our users and looked to the APIs that seemed to be getting the most play (Flickr, DigiNZ, and many Google projects come to mind) and borrowed aspects we thought worked (api keys, mindful use of HTTP verbs, simple query parameters) and left out the things we thought were extraneous or personally inappropriate (complicated session management, multiple script gateways). The result is, I think, a lightweight API with very few rules and pretty accommodating responses. You don’t have to know what an XSD is to jump in.

Q: What advice would you give to other museums / institutions wanting to follow the API path?

SB: You mean other than “do it” <insert grin here>? No, really, if it’s right for the institution and their goals, they should consider it. Look to the DigitalNZ project and read this interview with their team (we did and it inspired us). Try and not stress over making it perfect first time out, just try and see what it yields…then adjust as you go along. Obviously, the more institutions that can open their data in this way, the richer the applications can become.

_______

Many, many thanks to Shelley and Paul for putting in the time to answer my questions. You can follow the development of the Brooklyn Museum collections and API over on their blog, or by following @brooklynmuseum on Twitter. More importantly, go build something cool :-)

Creative Spaces – just…why?

There’s been a fair bit of buzz around the launch of the NMOLP (National Museums Online Learning Project) – now apparently renamed as “Creative Spaces” for launch.

I’ve known about this project for a long while – when I was at the Science Museum, very initial discussions were taking place at the V&A about how to search and display collections results from more than one institution. The Science Museum were invited to take part in the project, but in the end didn’t because of resourcing and budgetary issues.

My second touch on the project was from the agency end – the ITT briefly crossed my desk at my current employer, Eduserv. We considered bidding, but in the end decided that it wasn’t a project we could deliver satisfactorily given the particulars of the scope and budget.

Back then – and I think now, although someone from NMOLP will have to confirm – the project was divided into two main sections: a series of “webquests” (online learning experiences, essentially) and a cross-museum collections search. The webquests can be seen here, but I’m not going to consider these in this post because I haven’t had time to spend enough time playing to have an opinion yet.

The Creative Spaces site is at http://bm.nmolp.org/creativespaces/ – at first glance, it’s clean and nicely designed, with a bit of a web2.0 bevel thing going on. It’s certainly visually more pleasing than many museum web projects I’ve seen. The search is quick, and there’s at least a surface appearance of “real people” on the site. I hesitate to use the word “community” for reasons that I’ll highlight in a minute.

Design aside, I have some fairly big issues with the approach that is being taken here:

Firstly, this site, much like Europeana (which I’ll get my teeth into in a future post…) seemingly fails to grasp what it is about the web that makes people want to engage. I’m very surprised that we’re this many years into the social web and haven’t learnt about the basic building blocks for online communities, and are apparently unable to take a step back from our institutional viewpoint and think like a REAL user, not a museum one. Try looking at this site with a “normal person” hat on. Now ask yourself: “what do I want to DO here?” or “how can this benefit me?” or “how can I have fun”? Sure, you can create a “notebook” or a “group” (once you’ve logged in, obviously..). The “why” is unclear.

I’m also interested at how underwhelming the technology is. Take a look at www.ingenious.org.uk – a NOF digitise project which I worked on maybe 5-6 years ago. Now, I’m not over-proud of this site – it took ages, nearly killed a few people from stress, and the end result could be better, but hey – it has cross collections search, you can send an e-card, you can save things to your lightbox, you can create a web gallery. And this was more than five years ago. Even then, I was underwhelmed by what we managed to do. NMOLP doesn’t seem to have pushed the boundary beyond this at all, and as museums I think we should always be looking to drive innovation forward.

Secondly, I’m not sure that there is a reason why. Why would I possibly want to create a profile? Where is my incentive? Here’s Wikipedia talking about the Network Effect:

“A more natural strategy is to build a system that has enough value without network effects, at least to early adopters. Then, as the number of users increases, the system becomes even more valuable and is able to attract a wider user base. Joshua Schachter has explained that he built Del.icio.us along these lines – he built an online system where he could keep bookmarks for himself, such that even if no other user joined, it would still be valuable to him“

The other day, I had a Twitter conversation with Giv Parvaneh, the Technical Manager at NMOLP regarding this post, which talks about “monetizing” media. He blogged his response here. Now, we had a minor crossed-wires moment (it’s hard to discuss in 140 chrs) – but my point was not that museums should “monetize” everything (although, I DO think that museums should learn about real business practices, but that’s another post altogether). My point was that users need to feel special to take part. They need to be part of a tribe, a trusted group who can do and say things that they find personally useful. They need experiences with integrity. If you’re not sure what I mean, just spend some time on the Brooklyn Museum collections pages. These guys get it – the “posse“, the “tag game“, the openness. Compare this back to what feels like a shallow experience you get on NMOLP. Now ask yourself – “where would I spend MY time?”.

The second major reason is that, once again, we’re failing to take our content to our users. This is a huge shortfalling of Europeana. People want experiences on their own terms, not on ours. Let’s not have another collections portal. Spend your social media money adding and updating entries on Wikipedia, or create an object sharing Facebook application. Or just put everything on Flickr. And, please, please create an API or at the very least an OpenSearch feed. If the issue is something around copyright – go back to your funders and content providers and sit them down in front of Google images for an hour so they can begin to understand how the internet works, before renegotiating terms with them!

The final reason hangs off the search facility. My vested interest here is of course hoard.it – and if you want to hear our rantings about the money spent on big, bad technology projects, then keep an eye out for our Museums and the Web Paper. We aren’t necessarily suggesting that the hoard.it approach should be the technology behind cross-collections searching. But we are suggesting that the approch that NMOLP have taken is expensive, old, clunky and ultimately flawed. Although it is a trifle over-simplistic as a response, why not just spend £20-30k on a Google Search Appliance and simply spider the sites. Why re-develop the wheel and build search from scratch?

If I was less of a grumpy old man, I’d feel bad about being this negative – I like the people involved, I like the institutions, and I understand the reasons why (museum) projects spiral into directions you probably wouldn’t ever choose. But then I remember that this site cost taxpayers just short of £2 million pounds, and that Europeana will cost €120 million. And then I realise that we have an obligation to keep badgering, nagging and criticising until we start to get these things right.

At the end of the day, Frankie sums it all up much more succinctly in his email to the MCG list than I do in this post. He simply asks: why?

The person is the point

This is just going to be a quickie, mainly so I get it out before I go away on holiday never to remember it again. At some point I might expand on it.

Over the last few weeks in particular, we’ve seen the public finally sitting up and noticing Twitter. It’s been on the BBC, all over the news and makes for interesting watching on Google Trends, too:

Twitter / UK / 12 months

Twitter / UK / 12 months

About a year ago, my assessment of so-called “lifestreaming” was that it was all a timesink. Back then, I hadn’t pulled as deeply on the Twitter crack pipe as I have since, or do now. Looking back (nearly 5,000 tweets and 300 followers in), my thoughts are on the one hand changed – radically – and on the other, mostly the same.

My views have changed in terms of signal / noise ratio because Twitter has deeply, deeply affected me, the way I work and the way I consume and receive content and news. I can’t think of a technology that comes even close. The panic – and it is panic – that I feel when I consider a world without Twitter is, actually, pretty worrying.

On the other hand, my views about institutional Twitter have changed only a little. Back then, I questioned that Twitter has a place at all in an institutional setting. Now, with some water under the bridge, I’ve tuned my assessment of this. My current take on this is that there are only a few ways in which institutions can create convincing, fun, and followable Twitter streams.

The first of these is when it is automated (for example, Towerbridge – and this particular example is a genius use of various bits of technology). The second is at the opposite end of the spectrum, and that is when institutions are given personality, usually because the person doing the tweeting can sit outside the corporate MarketingFluff (TM). The obvious example is the always-great Brooklyn Museum. The third is when it is just plain useful, giving rapid updates on a topic in a way that other channels can’t.

As the interest grows, we’re starting to see the cultural sector increasingly wanting a slice of the pie, and the first thing they’re asking is how do we engage with this new channel? How do we mix it into our offering and make it work for us?

Right now, many of the museums on Twitter are using it in an informal, below-the-radar context. The problem is that as the thing goes more mainstream, we’re likely to see the same old problem we’ve seen with institutional blogging: it just ends up becoming the same old shit from marketing leaflets, regurgitated into new channels.

Twitter, like blogging, needs an edge, a voice, a riskiness. As long as institutions can retain this – i.e., do it for a reason – then, IMO, things will get more interesting. If they don’t, we’ll probably all be unfollowing museums as quickly as we can slide down the steep, slippery trough of disillusionment…

Specification Hell

I just spent my afternoon working on a 50-page functional specification. 

Now that I’ve been on the agency side for more than a year, I’m confident in reporting that agencies hate reading specifications almost as much as clients hate writing them. 

The world is full of dry documents, and I try (probably like most people) to avoid them as much as I can. That’s why I spend as little time as possible on Mr. Nielsen’s site or over on the W3C. What always strikes me about specifications for websites, however, is the extreme contrast between the engaging, colourful, user-centric thing which is the intended end-result and the grim, stultifying 100-page dirge which is usually provided at the beginning of a web project.

Functional specs have emerged from a kind of pastiche of needs. On the one hand you have the client who is forking out tens or hundreds of thousands of pounds. Not only do they (obviously) want to know what they’re getting for their money, but specifications are impressive, aren’t they? Nothing like an enormous great fat wad of a document to really show the agency that you mean business. From the agency side, you have a bunch of project managers and web developers: the PM’s are desperate to assign days and the web developers are desperate to avoid those “ooh, you couldn’t just…” moments later on in the project.

Under the hood is also a kind of legal wrangling which everyone hopes they won’t ever need – what if it all goes to shit, relationships break down and all those “sure, I’ll just do X” or “they said they’d do Y” moments come back to haunt you?

The net result is grim, particularly when you take a step back and consider the impact on creativity, innovation or “moving things forward”. When developers and PM’s are working to the letter of a specification, it’s no wonder that those additional extras get left behind. When your document binds you so closely to a fixed output (“the dropdown on the right displays X, which when selected does Y to div Z”) you don’t have a hope of being flexible, let alone able to take on board user needs or requirements.

In my experience, the reality is far from the dotted “i” and crossed “t” scenario which forms the backdrop to specifications. Developers are terrible (as is everyone, IMO) at estimating effort, usually resorting to doubling their initial guess because they know someone somewhere is going to take the piss later on; PM’s are terrible at taking flexibility on board; clients are terrible at writing specifications (or reading documentation). 

People are, after all, human.

What actually happens in a successful web project is very different, very fluid, and relies on a series of largely undefinable communication strands between client and agency. Personality plays a huge role in this: I’ve worked, for example, with developers who are incapable of doing anything except working 100% to the letter (me: “this dropdown has 10,000 items in it” – them: “that’s what you asked for”), and I’ve worked with clients who are 100% happy for the agency to drive the entire process, just wanting “a website” and no further questions, thanks anyway. 

There is no golden bullet, but in my experience there are a few approaches that have proven themselves time and time again.

  1. Be prepared to be flexible, both as a client and as an agency. Rigidity is almost always going to go wrong. Start the process (as client) knowing what you want but be prepared to accept different approaches. If you’re on the agency side, be creative enough to think about (and suggest) approaches that you’ve seen out on the web – say AJAXy validation or particularly good ways of going through a sign-up process. Clients usually like nice things.  
  2. Put legal measures like contracts in place but remember that the chances are you won’t end up in court and it is usually better to devote more time to talking and meeting consistently and regularly during your project than to writing huge, hefty legal horrors. Use a standard contract, attach a design brief, get everyone to sign it. Then move on.
  3. Always (always!) have a single point of contact defined early on in the process. Never step outside of the golden rule – the contact is between these two people: one from the client, one from the agency; any other communication goes through you, with no exceptions. Make sure communications are logged (usually via email, but bug trackers, Basecamp, Google Docs etc etc ultimately do the same thing). 
  4. If you’re a client with a vision or an agency with a solution, create it as visually as you possibly can. Instead of writing vast documents, create the following (in increasing order of effort and usefulness):

    - hand-drawn sketches of the site map, key pages, user interactions, “pinch points”

    - wireframes, initially in Powerpoint but ultimately in something like Axure or Protoshare. You can also use wikis or tools like Google Sites to re-create key bits of the new site

    - if you have really hefty bits of functionality which can’t be explained easily with a wireframe, consider building a working prototype. I can hear the intake of breath here – yes, it’s a hell of a lot of effort, but if you have a friendly web dev who can knock out something in a day or two that explains functionality better than a 100 page document, it will pay for itself in no time at all.

The best web projects I’ve worked on have had a core document which clearly explains the overarching reason for the redevelopment, any constraints (either technical or otherwise), and then references a sitemap and a wireframe or prototype. Somewhere in the background is usually a contract, too.

That’s it. The rest is down to clear, open communication, flexibility and – perhaps most important of all – a shared committment to make the new site better rather than just “redesign” it.

Incidentally, if you hear (or use) the phrase “content migration”, the project has probably failed already :-)

Launchball: we did it differently, and got it right..

Yesterday there was a flurry of excitement on Twitter (a “flutter of tweets”?) as the Science Museum’s Launchball was named SXSW “Best of Show“. This is an awesome achievement. SXSW is a hugely well regarded conference and for a museum to win not only the Games section but the coveted BOS as well is just enormous news.

I was still at the Science Museum as Head of Web for the first two thirds of the Launchball project, a fact of which I’m incredibly proud. As it happens, I got to do the fun bit without any of the hard work which always takes up the final push for the summit of any digital project…

Launchball is by pretty much any standards an enormous success. It has received over 1.5 million page views in the first six months of life. After I posted it to Digg it took on its own virality, taking the Science Museum web server down because of the immense levels of traffic. It has a following which you can see in the fact that users feel enthusiatic enough about it to create entire sites dedicated to possible solutions. You can see by the comments on this site, for example, how communities started to evolve around the game.

The success of Launchball is, in retrospect, fairly easy to ascribe. I thought it might be interesting to focus on the elements that I feel made up this success, given my (two-thirds) complete knowledge of the way that the project was driven. Fundamentally, these elements centred around freedom in the way the project was allowed to run, flexibility and adaptability of content and testing teams, creativity of the people involved and a certain element of luck that all the elements came together in the right order and at the right time.

We (the web team) pushed for – and were given – a huge amount of scope in helping to define the creative concept behind the game. This is relatively unusual in my experience – often the web team is seen as a service mechanism to deliver content by curators, education staff or other content teams. In this instance, I pushed very hard for recognition that – given the people involved – the web team creative input was absolutely key to delivering a successful experience for Launchpad Online.

Way back at the beginning of the project – looong before any creative agencies were involved – we sat down in a small group knowing only the budget and timescale, and braindumped what we thought we should aim to do. I’d had a tiny fledgling idea about a physics engine environment which encouraged users to play and “learn by stealth”. I’m a Heath Robinson fan (who isn’t?) and an inventor at heart, and the idea of having an environment in which you could play around with a bunch of gadgets, solve some fun problems and maybe learn something too was hugely compelling.

We started by running a brainstorm with the content team, and then honed this down with just the web team. We chose to have a defined output of 3 or 4 concepts. My brainstorms always begin with this: “We have infinite budget, infinite time. Now what do we want to do?”. I see little point in being constraining when what you’re trying to do is capture everything…

Out of this we came out with 4 key concepts – “Build it and share it”, “Ask an Explainer”, “Simulation”, “Real Experiments”. Each had social elements, interactivity, and were designed to be built around a central Flash-based interactive.

We then presented these concepts to the various stakeholders – the content teams, sponsors and education experts and used their feedback to focus and distill the final vision for the interactive and site. In the end we took the first concept but took popular elements from the others. The end result was the vision of a physics engine environment. We used mindmap software and Powerpoint to develop wireframes so we could convey our ideas to the stakeholders. Here’s a segment of one of the key documents:

You’ll notice that the whole concept of a “stage” upon which various gadgets are moved is already pretty well established – we still hadn’t taken on a creative or technical agency, wanting instead to be very sure we had a strong vision and brief to take to them at the right time.

One of the key things that we wanted to get right all the way through the process was to avoid a very obvious temptation: to try and re-create the Launchpad exhibits in a virtual medium. This would have been terribly easy, and completely wrong: Launchpad itself is a very physical experience, deliberately avoiding virtuality on-gallery. Instead, we wanted an environment which spoke to the essence of Launchpad: experimentation, fun, a strong element of self-guided learning, but without aping the physicality of the exhibits.

Once we had sign-off of the concept, we then went through the briefing and pitching process, choosing the wonderful Preloaded as the design agency. Behind the scenes, we used Eduserv (more specifically, Stephen Pope, one of the best web developers I’ve ever had the pleasure to work with…) to hook in the Sitecore CMS to store levels and user preferences. Outside, of course, was a framework of project management, run by “I’m just good at nagging” Jane Audas…

Preloaded did an astonishing job with the concept, taking it from paper-based design and really running with it to make it something with enormous class and style. The addition of ambient washes of music came from nowhere, for example, and really add hugely to the experience.

Round about this time I left the museum, so missed out on – as I say – the inevitable last minute tweaks, irritations, budget issues and timescales that always lurk around any project. From a distance, it all looked smooth, and maybe that’s all that counts :-)

Either which way, I’d just like to say a massive well done to everyone involved. I think Launchball really sets the bar (really, really high…) for not just museum interactive exhibits but for online gameplay as a whole. It’s just absolutely great that the world seems to have recognised this as well.

All noise, no signal. Lifestreaming is a timesink

The fascination with various “lifestreaming” tools continues apace. Brian Kelly has been getting particularly excited about the regulation (or not, as his fellow Twitterers are shouting) of these tools. “We should have standards” he says. “No! Standards are boring”, everyone replies…

In this particular area I have to say I pretty much fall on the side of the anti-standards bods – lifestreaming should be about spontaneity and not regulation – but there are still some interesting issues about the modes of use of these tools, and I can understand what Brian is pointing out.

The reason why there are issues is pretty clear: lifestreaming is a paradigm shift; it’s disruptive and hence different from everything that has come before. In some ways, tools like Twitter are IM-like in the way they work. In others they’re a little bit more like a chat room. In others, they’re like an email thread and in yet others more like a discussion board.

There’s no surprise therefore that we’re all a bit confused. Throw into the recipe tools like Twitterfeed (passes feeds to your Twitter stream), Hashtags (enables you to tag tweets), Twitter Facebook app (feeds your tweets to Facebook status) or Twittervision (type ‘L:’ for location…). Then lightly saute before throwing in some finely chopped Pownce (it’s the new Twitter, only ‘better’) or Jaiku (Google bought it so it must be good..) or Tumblr (who really knows what ‘microblogging’ is anyway?)…and it’s hardly surprising that we’re feeling the need for some sanity.

This is classic Gartner hype in action. The emergence and adoption of these technologies is rapid, exciteable, reactionary. Darwinian evolution is choking the ideas that don’t work and elevating those that do.

Take the Twitter Facebook app as an example. Both Brian and I installed it at pretty much the same time. It links your Twitter updates to your Facebook status. All good, you think – I only have to do this once, updates both – excellent. Then you realise that actually the use mode is different: Twitter isn’t being used as a “what are you doing” tool (the original intention) but instead has become a way of having a conversation with your fellow users. In this context, linking it to Facebook makes no sense, as the following screen shot demonstrates. Shortly afterwards, both Brian and I (independently) removed it.

twitter on facebook

In “conversation” mode, Twitter doesn’t actually work – if I’m friends with person B and they’re friends with person C then all is fine from my perspective if I’m having a conversation with B. If, however, B is having a conversation with C, I just get B’s side of the discussion. And that, frankly, is rubbish…

Pownce might be about to help out here – it gives you the option of posting comments to public/all friends/selected friend. But then we’re really back to square one: sending a message to “public” and you might as well use Twitter. Send it to a single friend or a group and you might as well use email or Facebook messaging.

And here, for me, is the rub. I’m going to go out on the line here (always risky) and suggest that essentially none of these tools actually adds anything. Let me rephrase that. All of these tools do add huge amounts of noise, but to me none of them add signal. Sure, they’re fun. Sure, I check mine every so often and take part in the conversation, but they’re not doing anything useful for me apart from…er…um…

It’s a bit like those 3D world conversations when you discuss the various technical aspects of the 3D world and actually find after an hour or two you haven’t actually shared *anything* useful. It’s technology for technologies sake. I think we’re getting caught up in the fact that we *can* rather than finding a gap in need and responding to that gap.

This is not to say that lifestreaming doesn’t have a place. I can see that during a conference, being able to send comments is useful. I can see that the mobile integration factor is a pretty exciting area of development. I can see how this might help during an emergency, or during a live event like a talk as a way of garnering feedback. Here on my desktop, however, it’s just a distraction, a timesink.

Within an institution, I’m also failing to see the applications. And this is where Brian and I both converge and diverge all at the same time. I think he has a point in trying to establish the modes of use, settle these down and try and get some clarity. But unlike Brian, I’m not convinced that institutionally there is anything in it. It may be that these tools and modes of use mature, and once we’ve all skidded through the trough of disillusionment we’ll find we’re in more informed place. But for now, I’m watching (and taking part…!) with an air of cynicism.

What do you think? Do you use these tools? Do you think they have a place in institutions? Should we look to standardise, either technology or modes of use? Comments please!

Scarcity vs scale

“Musical” blokeI’ve been finishing off the openness paper this week (taking me a long time to get my ideas together at the mo..) and doing some thinking around how you manage to still make money in this brave new world of free, open, readily available everything. Actually, let’s not call it making money but creating value, either in a financial or social sense.

Ian Rogers (Yahoo), who had posted before about the music industry tendancy to ostrich the very obvious problems of their industry (today highlighted by the EMI news of 2,000 redundancies) has written a looooooong but very insightful post about where it all goes from here.

The article is really worth taking the time to read in its entirity, but the bit which really caught my eye and got me thinking in terms of the whole commercial – value – assets – openness debate was the opening phrase, and title of the presentation:

“Losers wish for scarcity. Winners leverage scale”

Think about the importance of what is being said here for a minute: In the traditional world of marketing, selling, commerce, the value of something is largely determined by scarcity. This is still the way of the [physical] world in many ways today. We buy diamonds because they are rare; we phone a plumber because he has unique skills and knows how to fix the boiler better than we do; we go to museums to see things which we can’t see anywhere else.

The problem that the music industry has – and the cultural sector – is that once you move these endeavours online the entire equation changes shape, radically.

Whereas Amazon or other retailers with “real” product sit on top of the pile by increasing value both by leveraging scale (number of visitors buying books increasing incrementally as traffic increases) and scarcity (they are the ones who ship the books, which are themselves a product, and hence valuable by their scarcity..), the ones who have to think harder are those who have content as their product. That’s EMI, iTunes, The Guardian…and museums. Why? Because as soon as you put something on the web, it can (and is) duplicated, copied, downloaded, mashed and borrowed…

To date, the general response to opening museum content up – and yes, *gasp*, maybe making it free has been, understandably, “er. what? our images [other stuff] – free? certainly not”.

Let’s unpick this a little bit more. Instead of free, substitute “more free” – think about museums actively encouraging people to “borrow” images with “embed this in your blog/myspace page” links next to any assets displayed on page. This is effectively what web browsers (and certainly Google Images) do anyway, with a simple right click / copy-paste. Extend it and you’ve got an API model – “use this content on your website”. We as a sector know very very well that this happens already – I’ve talked before about the 9% referral figure we used to get on the Science Museum website from MySpace: all from embedded images. The point here is that people are doing this already whether we like it or not.

This is a limited example, but the point is that some kind of disruption is required to make this new market work for us. In the music industry, companies like Amie Street are breaking valuable new ground by defining new business models for (music) content. In this example, music tracks start off cheap/free and get more expensive the more they are downloaded. It’s a brilliant and highly respected model.

For museums, one of the first barriers to overcome is understanding what value the long tail has – when no museums carry on-page advertising (correct me if you know of one), we’re hard pushed to ascribe value to a page view. We’re still as a sector struggling with the basic notions of how to measure success, let alone confident enough to suggest that the commercial models we have might be wrong, or at least flawed.

I’m not (at the moment!) suggesting that we should close all our picture library operations: what I am saying is that the historical tendancy to be closed, guarded and scarce simply doesn’t work. It’s not just that users “abuse” this already (and we’d be spending a LOT of futile time trying to prevent the MySpace 9% from embedding our images), it’s that there is something really rather important going on here. Museums – we’ve said it before – are completely at home in the long tail.

Somewhere along the line we’ll understand the importance of embracing rather than denying the proliferation of copying, pasting, borrowing. To get there we need to be better at understanding what value is, and that’s hard.

[* image: curious 1950's bloke outside Bath Habitat with a wicked foot-cranked guitar-playing machine and violin. Bet he hasn't considered music rights.]

King Knol

(^ That title was vaguely supposed to be a play on “King Knut” but it didn’t really work out…)

Seb has posted about an article on OpenCulture where the author compares Google’s Knol project to Wikipedia. OpenCulture ultimately comes down hard on Google, reckoning that the Wikipedia “editing by masses” model is a better one.

A dog in a bowl. Irrelevant, but I liked it.
I’m veering around on this one. On the one hand, the Wikipedia model is clearly very powerful. If it wasn’t, then Wikipedia wouldn’t be the phenomena that it is. On the other, Google have at their disposal an extraordinary arsenal of content (most of the web) and users (most of the web-surfing population). These shouldn’t be underestimated.

Google have shown time and time again that they are willing to disrupt “traditional” models of content delivery. Stuff like “suggest a better translation” on Google Translate or using their massive user base to tag images in real time show that although Google aren’t “content” people, they actually understand the power of crowd sourcing around content as well as anyone else. Better than anyone else, in fact, because: 1. They’ve got the biggest user base (bar none) to test against and use to hone the model and 2. They’ve got the brightest people (bar none) working for them…

The criticism seems to be that Google might not use crowd volume in the Knol model and instead we’ll end up with a bunch of articles written by demi-experts which will remain unmoderated and of dubious authority. I can’t ever see this being the case, even if that is what’s hinted at in the original Google blog post. Google do crowds in a big way – be in no doubt that they have a very, very good understanding of who the “authorities” are around subjects as well as having at their disposal a reasonable-sized catalogue of content…Google will find a way of promoting “good” content and demoting “bad”.

Back to Wikipedia for a moment, which gets a load of bad press about non-authority content – a comment on the OpenCulture post echoes the apparent concerns of many:

“…the reality of Wikipedia, where articles created by knowledgeable authors are more likely to be degraded over time by hordes of inept users…”

I’ve never been sure that this is actually the case. Yes, if you’re an academic or museum curator then you’d probably spot errors in some of the detail, but let’s not forget who the normal user is here – if you want to know general stuff, Wikipedia is an outstanding source of information. If you want academically-inclined, peer-reviewed, 100% “accurate” information (whatever that might be), then hey, go look in a journal.

This is scratching at the surface of something a bit deeper which is about how important rigorously researched information really is to our audiences, but that’s another post altogether…

* thanks to Waldo Jaquith for the picture. Irrelevant, but I liked it :-)

Facebook poll: flawed, but do you care?

Facebook pollThe long and frankly fairly boring (to those other than people like me, and probably you if you’re reading this..) debate continues about Facebook data – who owns it, who shares it, how it can be attributed, how open it is.

Techcrunch as always pile into the debate with a simple point and a simple question: do people actually care? According to the poll they’re running, the stats (so far) look like the graph on left (click to take part in the poll or the comments).

The only (major!) problem with the poll of course is that the Techcrunch readership is going to be almost entirely geektypes, the very ones who do care about the issue. Does my wife, though? Or her mates? Or their mates? Nope, not really.

I just asked around a bit and in general the majority of people have the same response:

“Yes, of course I care….but I haven’t actually read the Terms of Service, or know what they are doing with my data…but I still care…”

I made a point on an earlier post about the transparency of data and also the extreme ugliness (both in appearance and techwise under the hood) of MySpace and the fact that these services still continue to be among the most popular in the world. It’s disconcerting to people like me, but I don’t think it should stop us banging on about the goodness of doing things right. I think, patronising though it is, that us “professional types” carry a sort of duty to make this stuff what we believe it should be – open, platform agnostic, accessible, etc etc etc. But let’s not:

1) Get depressed and give up if our users don’t appear to care: at the end of the day, why should they?

2) Get happy and give up because the community seems to be in agreement…