electronic museum

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

April 16, 2009 · 5 Comments

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 :-)

→ 5 CommentsCategories: IT · api · collections · community · innovation · mashup · technology · web2.0
Tagged: , , , , , , ,

(Selling) content in a networked age

April 1, 2009 · 4 Comments

I’m just back from Torquay where I’d been asked to speak at the 32nd annual UKSG conference. I first came across UKSG more than a year ago when they asked me to speak at a London workshop they were hosting. Back then, I did a general overview of API’s from a non-technical perspective.

This time around, my presentation was about opening up access to content: the title “If you love your content, set it free?” builds on some previous themes I’ve talked and written about. Presenting on “setting content free” to a room of librarians and publishers is always likely to be difficult. Both groups are – either directly or indirectly – dependent on income from published works. I’m also neither publisher nor librarian, and although I spent some time working for Waterstone’s Online and know bits about the book trade, my knowledge is undoubtedly hopelessly out of date.

Actually, I had two very receptive crowds (thank you for coming if you were there!) and some really interesting debate around the whole notion of value, scarcity and network effects.

Like any sector, publishers and librarians have their own language, their own agendas and their own histories of successes and failures. Also like any sector, they are often challenged to spend time thinking about the bigger picture. Day jobs are about rights and DRM, OPAC and tenure. They aren’t (usually) about user experience, big-picture strategy or considering and comparing approaches from other sectors.

What I wanted to do with the presentation was to look at some of the big challenges which face (commercial) material in the networked world by thinking a bit more holistically about people’s relationship with that content, and the modes of use that they apply to the stuff that they acquire via this networked environment.

The – granted, rather challenging – title of the presentation is actually a question cunningly disguised as a statement. Or maybe it’s a statement cunningly disguised as a question. I lost track. The thing I was trying to do with this questatement (and some people missed this, more fool me for being too subtle) was to say: “Look, here’s how many people are talking about content now: they’re making it free and available; they’re encouraging re-use; they’re providing free and open API’s. They’re understanding that users are fickle, content-hungry and often unfussy about the origin of that content. What, exactly, do we do in an environment like this? What are the strategies that might serve us best? Can we still sell stuff, and if so, how?”

The wider proposition (that content fares rather better when it is freed on the network than when it is tethered and locked down) is a source of fairly passionate debate. I’ve written extensively about Paulo Coehlo’s experiments in freeing his books, about API’s, about “copywrong“, about value, authority and authenticity. The suggestion that if you free it up you will see more cultural capital is starting to be established in museums and galleries. The suggestion that you might, just might, increase your financial capital by opening up is for the most part considered PREPOSTEROUS to publishers. Giving away PDF’s increases book sales? Outrageous. Apart from the only example I’ve actually seen documented, of course, which is Coehlo’s, and that seems to indicate a completely different story.

There are fine – and all the finer the closer you examine them – levels of detail. Yes, an academic market is vastly different from a popular one: you don’t have the scale of the crowd, the articles are used in different ways, the works are generally shorter, the audiences worlds apart. But nonetheless, Clay Shirky’s robust (if deeply depressing) angle on the future – sorry, lack of future – of the newspaper industry needs close examination in any content-rich sector. I don’t think anyone can deny that the core proposition he holds up – that the problems that (newspaper) publishing solves (printing, marketing and distribution) are no longer problems in the networked age. I don’t think that what he’s saying is that we won’t have newspapers in the future, and he’s definitely not saying that we won’t need journalists. What he is saying – and this was the angle I focused on in my slides – is that this change is akin to living through a revolution. And with this revolution needs to come revolutionary responses and understanding that the change is far bigger and more profound than almost anyone can anticipate. The open API is one such response (The Guardian “Open Platform” being an apposite example). Free PDF’s / paid books is another. Music streaming and the killing of DRM is another.

Revolutions are uncomfortable. The wholesale examination of an entire industry is horrifically uncomfortable. Just take a look at the music business and you’ll see a group of deeply unhappy executives sitting around the ashes of a big pile of CD’s as they mourn the good ‘ole times. But over there with music, new business models are also beginning to evolve and emerge from these ashes. Spotify is based on streaming, Last.fm is based on social, Seeqpod is a lightweight wrapper for Google searches, The Pirate Bay ignores everyone else and provides stuff for free.

Which ones are going to work? Which ones will make money? Which ones will work but displace the money-making somewhere else? The simple answer, of course, is that no-one really knows. Some models will thrive, others will fail. Some will pave a new direction for the industry, others we’ll laugh at in five years time.

So where can the answers be found? Predictably for me, I think all sectors (including academic publishing!) need to take a punt and do some lightweight experimentation. I think they need to be trying new models of access based around personalisation, attention data and identity. They need to examine who gets paid, how much and when. They need to be setting stuff free in an environment where they can measure – effectively – the impact of this freedom across a range of returns, from marketing to cultural to financial. If they do this then they’re at least going to have some solid intelligence to use when deciding which models to take ahead. And it may be that this particular industry isn’t as challenged as most people assume, and that the existing models can carry on – lock it down, slap on some DRM, charge for access. It’d be far less uncomfortable if this was the case. But at least that decision would be made with some solid knowledge backing it up.

Open Access is one clear way of forging this debate ahead. But once you get under the apparently simple hood of the OA proposition, it actually turns out that not only are many institutions simply ignoring guidelines to produce OA versions of published works but that the payment models are complicated and based on a historical backdrop which to many seems inherently broken. I’d be interested to hear from someone with way more knowledge than me on the successes and failures or market research done on setting content free in this way.

It was clear to me in talking to a range of people at UKSG – librarians, publishers, content providers – that there are huge swathes of evidence missing – surprising, perhaps, from sectors which pride themselves on accuracy and academic rigour. When I asked “how many people aren’t coming to your site because search engines can’t see your content?” or “what is your e-commerce drop-out rate?” or “how much of your stuff do you estimate is illegally pirated?”, very few had coherent – (or even vague) (or any!) – answers.

More telling, perhaps, is that the informal straw poll question I posed to various people during the conference: “Do you feel that this is a healthy industry?” was almost always answered with a negative response. And when I asked why, the near-consistent reply was: “It’s too complicated; too political; too entangled” or from one person: “the internet has killed us”.

I’m really not as naive as I sometimes appear :-) I know how terribly, terribly hard it is to unpick enormous, political and emotive histories. When I suggest that “we need to start again”, I’m obviously not suggesting that we can wipe the slate clean and redefine the entire value proposition across a multi-billion dollar, multi-faceted industry. But I think – simply – that awareness of the networked environment, a knowledge of how people really use the web today and an open mind that things might need to change in profound ways are very powerful starting points in what will clearly be an ongoing, fraught and fascinating discussion.

→ 4 CommentsCategories: api · museum
Tagged: , , , , , , , , , ,

Creative Spaces – just…why?

March 4, 2009 · 49 Comments

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.

There, unfortunately, is where the praise is going to stop. And here’s the three reasons why:

Firstly, this site, much like Europeana (which I’ll get my teeth into in a future post…) utterly fails to grasp what it is about the web that makes people want to engage. I’m astounded 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 – just 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.

For starters, the functionality is massively underwhelming. 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 COLLECTION SEARCH, you can send an ECARD, you can SAVE THINGS TO YOUR LIGHTBOX, you can CREATE A WEB GALLERY. And this was FIVE+ YEARS AGO. Even then, I was underwhelmed by what we managed to do. Now, looking at NMOLP, I’m not underwhelmed – I’m…speechless…

Secondly, there just simply isn’t a reason WHY. Why would I possibly want to create a profile? Where is my incentive? C’mon guys – this is social web 101. Let me quote Wikipedia, when they talk 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 the sterile, shallow experience you have on NMOLP. Now ask yourself – “where would I spend MY time?”. Get it yet?

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. C’mon, 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, please create an API or at the very least an OpenSearch feed. If the issue is something around copyright – get your arses 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 THE INTERNET, 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. When I first saw the technical specification, my response was – “well, why not just spend £20-30k on a Google Search Appliance and simply spider the sites?” – and I haven’t changed. Why re-develop the wheel?

If I was less of a grumpy old man, I’d feel bad about slagging off a new project this hard – 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 puppy cost the taxpayer 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, slagging, criticising until someone – finally – gets it 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?

→ 49 CommentsCategories: collections · community · content · innovation · museum · web2.0
Tagged: , , , , ,

Why 3 won’t replace 2

February 23, 2009 · Leave a Comment

I was at the Hague during the latter part of last week, doing a keynote at CATCH // Museum 2.0. The organisers had seen me talking at “Kom je ook?” and asked me to go over again.

This talk – “Why the Social Web is here to stay (and what to do about it)” is an expansion on the one I did in December last year at Online Information. That one focused a bit more on the enterprise, wheras this one was specifically pitched at cultural heritage.

The message is much the same: connecting with others is deeply important to people. The social web connects people. Therefore, the social web is deeply important…

Anyway. Here are the slides

→ Leave a CommentCategories: conference · content · museum
Tagged: , , , , ,

The person is the point

February 6, 2009 · 5 Comments

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…

→ 5 CommentsCategories: community · content · innovation · marketing · museum · social network · web2.0
Tagged: , , , ,

Ten things a web designer would never tell you

February 6, 2009 · 2 Comments

Following the barcamp (BathCamp) that we ran last year, I was looking for a way of maintaining some momentum around the local tech scene, and decided to put together a monthly evening meetup. The first of these was on Wednesday 4th Feb.

Talking at the event were two pretty well known people from the web industry: Paul Boag (Boagworld and Headscape) and Ryan Carson (Carsonified).

Paul did an exceptional talk entitled “10 things a web designer would never tell you” – a tongue in cheek (but scarily accurate) parody of the approaches taken in many web projects. I particularly liked “4. Form a committee to provide feedback…(before you know it you will have a design everybody can tolerate)…” and “6. Enforce corporate style guides to the letter”. Actually, the entire list is pretty easy to check off if you’ve been involved in this kind of stuff before. Comment if this all seems horribly familiar!

Interestingly, Paul followed the talk up with a blog post taking the same tongue-in-cheek tone and got so many comments from people who thought it was actually straight advice that he first of all had to move the “THIS IS TONGUE IN CHEEK” message from the bottom of the post to the top and I see just now has even had to add a new post: “For those of you hard of humour“. Funny stuff.

Anyway. Here’s a video of the talk that I took on a friend’s Flip. Quality is slightly poor (not the Flips’ fault but my failure to get a bigger file up to Vimeo..)

Ryan did a talk on the excellent Ubiquity plugin for Firefox. I’ll be posting the video of his talk just as soon as I can squeeze it through my limited home bandwidth.

→ 2 CommentsCategories: content · design · museum
Tagged: , , , , , , ,

The problem with process

February 3, 2009 · 12 Comments

This blog post has been lurking as an idea in my drafts folder for a long time, waiting for me to write something about the issues of “enterprise” and “lightweight”. 

If you haven’t gathered it already you’re either new here or have been seriously thick skinned when I’ve ranted on about why I think IT is crap and what we need to do about that. In a nutshell: IT should help people. It usually hinders them. We should try harder. 

That’s the general thrust of what is actually a very straightforward argument. I seem to spend far too much of my time looking at failed potential and not enough looking at astonishing goodness.

From this you’d probably gather – and you’d be mainly right – that I understand, and have much more time for, “lightweight” than I do “enterprise”. I think you can get closer – much closer – to the true horizon of “good IT” with rapid, lightweight approaches than you ever can with heavy, expensive ones. 

More process, please

Process hell. Thanks johnbullas / Flickr (click for bigger)

I do, however, also understand the need for control, for backups and safety, for security. The problem I have is that so, so often these processes are over-specified. And the problem with over-specification is that it flies in the face of the way we normally go about our lives.

It’s much more natural for us to turn to the person next door or call a friendly web guy and ask “is there any chance you could just…”. It’s what us social animals are good at – a bit of sharing, communal back-scratching, wheeling and dealing. Look at specifications. The fact is, no one knows how the damn thing is going to work, so how the hell are is anyone going to write it down on week one of the project? Project Management is a similar veil we draw into the process mix and pretend is useful, but find me one person who can accurately forecast their time on a task, and I’ll show you a liar.

This is how we end up tied into a sterile, personality-free wasteland where every item has to be built into a specification or you have to raise a ticket with a “service desk” (generally an oxymoron, IMO) to get, say, Google Analytics code pasted into the footer of your website or redirect a URL.

The problem is: this isn’t how people do things. That’s why it bugs the shit out of every poor sucker who gets tied up in it.

Here’s the question: why can’t we ring the guy up? Why can’t we call in favours, buy the dev a pint, tell him we’ll help him out with some CSS he’s struggling with? This is the way, after all, that most business gets done – someone you know puts in a good word for a friend of yours, he does you a favour, you remember it the next time around. I’m not suggesting that goes too far – there’s a horrific cronyism at the other end of the scale – but I’m just unsure how anyone gets anything creative or effective done when there is no personality in the system. The reason we can’t do this (usually) is that there’s another process (“change control”) underneath. And under that, somewhere, hiding in the dark, is fear. 

Mitigating risk is one thing. Being over-cautious is quite another. It’s also a rapidly shrinking spiral where your systems and processes begin to close down on each other because of fear that “things might go wrong”. Lock it down, prevent the changes, project manage it to death. Kill the project before – gasp – something goes awry.

I think “lightweight” consistently shows that creativity can only come out of flexibility. I also believe that this can – with some creative, human thinking – be translated into “the enterprise”. Maybe I’m naive. Maybe it isn’t turtles all the way down, but Process.

I hope not.

→ 12 CommentsCategories: content · technology · web2.0
Tagged: , , , ,

Crowdsourcing photosynth

January 31, 2009 · 6 Comments

I wrote about Photosynth when it first came out as a plugin back in August 2007.Then, I wasn’t sure, and felt that it was a technology looking for a reason. Since then, Microsoft have done a few very, very cool things with it. The most important of these is that anyone can now create Photosynths (essentially, think image stitching, but in all dimensions..).

All you have to do is go to the Photosynth site, download the app and chuck some photos at it. It munges away for a bit and then after a bit uploads them all to the Photosynth site and gives you a link. It helps very much when you’re taking the photos to think about the fact that you want them to be connected: they obviously have to be the same scene, and I’ve found that standing reasonably still and taking around you tends to work reasonably well.

A “good synth” (the software tells you how “synthy” your selection is once it’s uploaded it – presumably a measure of how well it has managed to stitch stuff together) is pretty satisfying, although there are some obviously winning features which are missing. The single most obvious one of these is that you can’t add links or hotspots to the synth you create. For museums particularly, I think this’ll be a problem.

I did a synth a while back of the Boxkite at Bristol Museum. It’s a nice object to use (or so I thought) – it’s up in the rafters and you can walk all around it, taking photos from 360 degrees. As it happens, the result is pretty good, but not great. I’m wondering whether the software might have confused one side of the object from the other. Either way, it gives an insight into how museums could start using Photosynth to enhance collections online. More interestingly, perhaps (given the fair size of the Photosynth plugin), it could be used in-gallery (maybe with a Microsoft Surface..) to let audiences really engage with objects. Have a poke around the Photosynth site to get a feel for other museum stuff.

Extending Photosynth a bit further is what this post is all about, though.

When I saw the astonishing CNN Photosynth from Obama’s Inaugeration I started thinking about how else you could use it to enhance online experiences. I had what I thought at the time was an original idea (looking now I realise that Nick Poole had commented on my original post suggesting exactly this!) – how about using Flickr as a source for building a Photosynth?

Apollo 10 Command Module

Apollo 10 Command Module - thanks to Gaetan Lee

I needed an iconic object that would have been Creative Commons licensed on Flickr. Apollo 10 turned out to be a good one – I ran a search on Flickr and found 40 CC photos I could use, all taken in the Making the Modern World gallery of the Science Museum, my old stomping ground.

There’s no API I’m aware of for Photosynth yet. This is another missing trick – imagine if you could step straigt from Flickr to a 3D synthed view of any search… – so for my experiment I had to download the entire set of search results. For this, I used a cunning app called Downloadr, which lets you automatically download all Flickr pics which match a certain search. Then it was just a matter of re-uploading the images via Photosynth.

The result is here. Given that this is entirely made up of images taken at completely different times and by different people, I think it works pretty well. The crowd sourcing element adds a lot to Photosynth, I think. It’s still a shame that it isn’t possible to add links or otherwise play with the resulting synth – I think it’d add a lot.

Let me know if you think of other objects that could be synthed in this way and I’ll give it a go…

→ 6 CommentsCategories: collections · exhibition · gallery · museum
Tagged: , , , , ,

For the webs2, please follow the crowd

January 19, 2009 · 2 Comments

The last talk I gave – in December 2008 – was at Online Information and titled “What does Web2.0 DO for us?”.

Here are the slides (my third slide deck to get “homepaged” on slideshare…yay…):

This one was attempting to focus on Web2.0 in the Enterprise. Frankly, “The Enterprise” is a subject which fills me with fear, dread and trepidation, but the movement of Web2.0 into that space is probably inevitable as sales teams around the world spot another opportunity and sell it out to cash-rich bods wanting to “be innovative” in the name of their behemoth of a company. It’ll be interesting to watch.

The talk was popular, which I’m pleased about. Online Information is a funny old conference – the halls are stacked with basically the same company replicated about 200 times: reasonably bad CMS systems with reasonably bad sales people trying to sell to a reasonably badly informed market of people. I sound over-rude, but I have to be honest – I last went in about 2003 and absolutely nothing has changed. Which can’t be good in the tech field, right?

My slides were supposed to be about one thing (why the social web is important in “The Enterprise”, and why “The Enterprise” should take it seriously) – in the end, I actually focused on why “web2″ is important to people rather than as a “thing” in abstract. I see the connecting of people with other people as reason for believing in the social web as a sound platform upon which to build any content. I believe this engagement is key to bringing (heritage) content to the foreground; furthermore, I think that even though web2.0 has been hyped to death, we should continue to believe in what “the social web” means. Mainly, we should believe this because the social web is about people and connections and as such has enormous importance to us as social, connected animals. 

One of the problems with talking about “Web2.0″ is that the phrase carries an implicit weight with it: as soon as there is a count attached, you’re naturally looking for the current one to expire – for “Web2″ to be replaced by “Web3″ and shortly after that, “Web4″. Useful though “Web2.0″ is as a phrase, I’m with the commentators now who suggest we talk about “the web”, or – my preference – “the social web”. Not because it is any less important, but because it is more so.

Incidentally, earlier today I was researching some stuff for a keynote I’m due to give in The Hague later in February (more details soon…) and used Google Trends to check on the phrase “web2.0″. It’s interesting to note that it reached its peak during q4 2007, and has since dropped off in popularity: 

 

Web2.0 on Google Trends

You’ll see immediately that this follows the Gartner Hype Curve prediction (or at least the beginning of it) – it’ll be interesting to watch in the coming months and years how the curve settles into a dampened “plateau of productivity”. (I’d also be interested if anyone can figure out why there is a gap between 2004 when O’Reilly first mentioned the phrase and mid-2005…)

For the graph junkies, here’s the same period for the phrase “social web”:

 

"Social Web" on Google Trends

So. That’s the hype. Maybe now we can get on with producing some astonishing, user-focused content..

→ 2 CommentsCategories: museum
Tagged: , , , , ,

Specification Hell

January 6, 2009 · 6 Comments

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 :-)

→ 6 CommentsCategories: content · design · innovation · museum
Tagged: , , , ,