I caught up with Vicky Lee last week and asked her a bunch of questions about the app. Here’s what she had to say:

Q: Please introduce yourself, and tell us about your involvement with the Museum of London iPhone app project

I’m Vicky Lee, Marketing Manager for the Museum of London. As part of the launch campaign for the new Galleries of Modern London I’ve been working with creative agency Brothers and Sisters to develop a free iPhone app – Streetmuseum – that brings the Museum to the streets.

Q: Tell us about the app – what it does, and how you’re hoping people will use it, also about how successful it is being

Streetmuseum uses augmented reality to give you a unique perspective of old and new London. The app guides users to sites across London where over 200 images of the capital, from the Museum of London’s art and photographic collections, can be viewed in-situ, essentially offering you a window through time. If you have a 3GS iPhone these images can be viewed in 2D and also in 3D, as a ghostly overlay on the present day scene. The AR function cannot be offered on 3G iPhones but users can still track the images through their GPS and view them in 2D, with the ability to zoom in and see detail. To engage with as many Londoners as possible, images cover almost all London boroughs. Each image also comes with a little information about the scene to give the user some historical context.

What we bet on from the start was that users would enjoy finding images of the street they live or work on and would be quick to demonstrate this to their friends and colleagues – helping to spread the word about Streetmuseum but also raising the profile of the Museum itself, particularly among young Londoners who we have previously struggled to reach. We hoped that the app would spread virally in this way within days and it certainly seems to have worked as in just over 2 weeks the app has had over 50,000 downloads. It’s just been released in all international iTunes stores so we’re expecting this figure to rocket over the coming weeks.

Q: Why did you choose to build an iPhone app as opposed to something else (Android, web, etc)

When I wrote the brief for a viral campaign to promote the new galleries and reposition the Museum of London, I had no idea we would end up launching an app. I hadn’t for one moment considered that we could afford to develop an app but Brothers and Sisters’ instinct from the start was that this was what we needed to change perceptions about the Museum. As soon as we understood how the concept fitted in with the overall marketing campaign (which also uses images from the Museum’s collections) it was the only option we wanted to pursue.
As with most Museum projects we were limited by budget so it was a case of either iPhone or Android but not both. To launch with maximum impact our feeling was that we had to go out with an iPhone app, therefore benefiting from the positive associations with the Apple brand and securing the interest of the media. We hope now to be able to secure funding to develop an Android version of the app in response to the many requests we have received.

Q: Can you tell us a bit about the financial model? Did you build it in partnership with someone else?

As a free museum reliant on funding, we would not have been able to create this app without collaborating with Brothers and Sisters. The partnership was mutually beneficial, generating media coverage for both parties and new business leads for the agency. Using images from the Museum’s collections meant that all the content was readily available so this kept costs down. Licensing agreements on certain images made it complicated to charge for the app, however it was always our intention to launch this free in order to reach the widest possible audience.

Q: Overall, what have you learnt about the process so far?

Simple works best. We originally planned to include user generated content but dropped this idea to ensure we stuck to our budget and timescale. Ultimately the idea is not that original but its simplicity has made the app an easy sell, both nationally and internationally.
I’d certainly give myself more time in future – we delivered the app in an incredibly short amount of time which gave little opportunity to review how it worked in practice. With more time we could have carried out user testing and refined the concept further to end up with an even slicker product.

Q: What else have you got planned for mobile at the MOL into the future?

We’re keen to keep the momentum going and stay ahead of the field, so, together with Brothers and Sisters, we are already looking at how we can develop this concept further. If we can secure additional funding we’d like to explore different subject areas and tie-in with future exhibitions and gallery redevelopments. Most importantly though we need to build upon what we have already achieved and keep evolving to ensure that any new apps continue to be newsworthy. We are also looking into the possibility of adding more images to the current Streetmuseum app and developing a version for Android phones.

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.

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

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?

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 - 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…

CHNM have recently produced an open source application called Omeka (Swahili for “to display or lay out goods or wares”..) – a product specifically pitched at museums or other cultural institutions wanting to put their collections and exhibits on the web.

To date the offerings in this space tend to follow one of two distinct and reasonably unsatisfactory flavours: Either you choose an ‘out of the box’ templating and publishing system (albeit with the promise that you can “edit your own templates”) which come with systems like MultiMimsy or TMS, or you choose to start from scratch and build the entire thing from nothing.

The former is generally pretty bad form for the user: most of these products are generic, badly designed and force museums to follow a prescribed path of development with little flexibility to change or choose their collections management system. The latter is complex and expensive, and although carries with it huge amounts of flexibility, it also has the burden of any bespoke system.

Tom and his team noticed that over the course of several years working with the museum sector that:

“We found ourselves building more or less the same website over and over again, or at least the feature set“

They also noted that although there were tools for curators, there weren’t any for educators or webmasters: the ‘front of house’ people who wanted to create online exhibitions. They decided that they would build some of these common approaches into a framework application for delivering narrative exhibitions online.

Omeka is an open source application which you download and install on your LAMP web environment. It draws content in real time (i.e isn’t a “tick and publish” like many of the other systems in this space). At the moment you export your data from your collections management system and import it into Omeka for delivery to the web, but Tom was quick to point out that this is “just an intermediary step” and that they’re working on a database abstraction layer which will allow for “live sync” with existing collections managements systems. This is great news, and absolutely the direction that needs to be taken more in our sector.

Tom and his team used the metaphor of a blog to guide their thinking on development. They:

“…thought it should be as easy for museums to publish online exhibitions as it is for individuals to start a blog…and in many ways WordPress has been our model…“

They have a drag and drop exhibit builder, a strong API and also a plugin architecture which allows users to add their own functionality. All of this is very positive news given the approaches taken to date with the systems I’ve mentioned above – very clunky, very web1 and with bad UI’s for both users and administrators.

I’m in the middle of installing Omeka to do some “real world” testing but it certainly looks and sounds very positive to me. If anyone out there has experience using Omeka (or the other systems I’ve been rude about) then please comment away. Examples of institutions using Omeka can be found on their website.

When I was talking at a UKSG seminar recently, one of the deligates asked one of the presenters exactly this – how the Semantic Web might work in practice. The response was slightly woolly – arguably like pretty much everything to do with the entire notion of “semanticness”

Now, thanks to the video below from True Knowledge (thanks Simon!) it all makes a little more sense.

That was a week ago. They’re still there, getting soggy. Unloved, unused, taking up space, wasting tree. I’m not alone. Walking down the hill to work today I saw four phone books either binned or just left, and I wasn’t looking particularly hard either.

Ask yourself: when was the last time you used either of these? For me it’s been a while. And why? Well, it’s not about the content – both guides are pretty comprehensive as a rule. Instead it’s about the fundamental process behind what it is you need to do with these bits of content.

I downloaded a copy of Microsoft Live Search mobile for my new smartphone last week – it’s a very slick application which released for the UK fairly recently. I was all ready to have yet another app sitting there for a couple of weeks before I got bored and un-installed it, but I’m bowled over by how useful it is. You really can find information on location-specific stuff – accurate, comprehensive information – via a GPRS or WIFI connection, in real time.

This kind of functionality kills the Yellow Pages dead. And that’s a beta application on a 2×3 inch screen, so it’s hardly perfect. Once you throw in Google Maps (or Google..) or any of the other search/local search providers, the concept of a physical directory is not only dead, it’s dead and buried, dug up again, cremated and scattered to the wind.

With 67% of people in Britain (6.5Mb PDF) accessing the internet and 4/5 of these with broadband, it’s hardly suprising that the web is the first place any of us go to find out basic (contact) information. Why spend any time at all fooling around in a 1000+ page directory when you can get this stuff straight away online? Who knows.

The debate continues, as it has (and will) for some time – about the future of books. We dabbled in eBooks when I worked at Waterstone’s Online, way back. In the latest copy of Stuff Magazine, two of the staff battle out the pros and cons of the book vs the ebook. Devices such as the Sony Reader, the iLiad and the Amazon Kindle – all claiming to be “the new book” keep the conversation bubbling along. Andrew Marr tested ebooks for a month and said: “Overall, I am reluctantly impressed with my ebook…” but also made the good point that they’d be better if they smelt a little musty

Books (obviously) aren’t dead: in fact it’s pretty well accepted that books do what they do infinitely better than anything else, which is why they’re still around, er, **** years later. As a user interface, the book is near-perfect: compact, easy to use, cheap, requires no battery power. Where it fails is where it comes up against what the internet is so blindingly good at: searchability, browsability, comparison, linking. The battleground (it it is such a thing) isn’t an even place: “reading” vs “looking up” isn’t a fair fight. But nowadays there’s something wrong with the notion that we should still be mass-distributing directories to everyone with a phone…

That’s a pretty extraordinary statistic, and says something deep about the ways in which museums interpret and communicate their assets. I’m sure Jennifer will be drawing her own conclusions from this, but the first and most obvious response (without having read the research in depth, so shoot me down if you have..!) is either that museums are badly out of touch with how their users interact with their assets, or that findability isn’t that important to curatorial staff. Neither of these is a particularly positive conclusion to draw.

Ultimately of course, this comes down to a user-focussed (or not) approach, both to the way that assets are presented online, and the way that folksonomies and taxonomies are applied to collections in-house. Understanding the end-users of your product is one of those holy grail things which so many people (including me) preach about, and yet is missed time and time again. So often, it’s the organisational perspective which ends up being presented, and not that of the user. Inevitably, it’s users who end up losing out.

I move on, as anyone does from a job they’ve lived and loved for that length of time, with a huge range of emotions. I’m terribly sad to no longer be attached to an institution with such vast public kudos. I’ll miss the people hugely – I’ve never worked with such an interesting, creative and open-minded bunch before. I’ll probably never work on such a huge range and variety of projects. But it’s time to go, and I’m delighted and excited about the future I’ve got coming up in Bath.

As part of this post, I thought I’d jot down three or four of the key developments in the history of NMSI online since August 2000 – mainly this is indulgence, but I thought it might also cast some light on how and why things changed over the years. Personally, I’ve learnt hugely important things about the web, people, the complex set of politics which exist in any institution of this size and scope, not to mention museums online and the vast range of technologies available to us.

This is, by the way, an entirely non-exhaustive history. One day I’ll get round to charting everything out, but today is not that day

I first started at the Science Museum back in August 2000. I’d left Waterstone’s online at that point in any job when you start twitching: It was hugely hard work, but I wasn’t learning anything new. At the time, I was massively excited by the opportunity of working at the best museum in London (sorry, but it’s true..), but also arrogant enough – the dotcom boom providing 2 or 3 job offers each week – to negotiate quite hard with the museum prior to an offer. I told them I wasn’t going to come along unless they increased the pittance of operational budget which was then allocated to web, and also find some additional people to help make it happen. They agreed.

The first few months were terrifying, but exhilarating. There was a lot of blagging on my part: at the time I knew nothing whatsoever about how to put together an agenda or chair a meeting. I’d never managed a budget (having just negotiated a bigger one, this was particularly daunting…). I had a server to look after (and knew nothing about server-side technology). I couldn’t code. I had a vision, but no people who could help me do it. The museum had just reached an impasse with an agency who will remain nameless who had built them an interestingly exotic(!) “CMS”. The site had just been re-designed but loads of snagging issues remained from the old site (wait for images to load for full effect!).

I muddled through. I bought books on ASP. I junked the CMS system the agency had built and installed my own homebuilt version (not particularly popular, that move, given what had been spent…). I patched up the server as it memory-leaked and limped its way from day to day. I did frightening things like find and replace the file extensions on the entire site to convert it to .asp…(and yes, I backed up first…)

Shortly after that, I persuaded Daniel Evans to come to the museum from Waterstone’s Online. He proved an incredible asset. Just after that, the dotcom boom crashed into the world of online bookselling and the 60-strong staff at W/O was “consolidated” into 3 or 4. We felt good having escaped.

Rolling out the CPS, or Content Publishing System – a simple VBScript application which let users around the museum edit their own content – was the first major milestone for us. It marked the point at which we seriously began handing ownership of the content to the organisation. At last, people started to appreciate why they should own and change their stuff. At the same time the system largely side-stepped the “resource bottleneck” which so often exists in web teams, but also left publishing control with the web team. We tried hard not to edit too much, and it also gave us a chance to prevent Comic Sans showing its horrible face on our site…

At around this time, I started working with Ann Borda (now at JISC) to develop a concept for what would later become Ingenious. It started life as “Science & Culture”. It’s interesting to note, given the vast remit (the first cross-NMSI project) and the huge timescale (over 3 years), that the very first sketches we presented were pretty much what we finally delivered in June 2004. This was the first lesson for me, and the first real resistance I developed to that all-pervasive museum treacle: projects are better done over short bursts, with small groups of stakeholders who are capable of moving fast and deciding quickly. It took huge energy (which to everyone’s credit, they retained over 3 long years) and quantities of strong coffee to make the site happen. Although it has very obvious shortfallings (second lesson: less really is more…), I’m still proud of what we achieved.

Making the Modern World Online followed soon afterwards. For the most part, this project ran outside the web team, but we had input on accessibility and design, and helped steer it (mostly) in a strategic direction which roughly followed what we wanted to achieve for the museum online. During this time, we worked hard on developing web policies and strategies to support us in everything we did. The key lesson we learnt here (it looks obvious now, but it was a revelation at the time..) was to align – 100% – all our strategic thinking with the goals of the organisation, literally drawing lines between what the wider business wanted to achieve and what web could do to support those goals. We coupled this with incredibly close work with the Visitor Research team. Third lesson: end users are the best friends you can possibly have, and will provide you with endless ammunitation to throw at the internal politics..

Next up was continued development of Sciencemuseumstore and then the launch of the Dana Centre. The original website for this was put together out of a small budget and little time, and this time we pushed forwards with more efficiency – although a small project we did it quickly with just a sidewards glance at the politics. The site was later re-built and relaunched by Frankie Roberto, the museums second Web Developer, and by gum it looks and works a whole lot better than it did the first time around…

Meanwhile, Daniel and Joe Cutting had started working on a vision for Antenna, our rapidly changing science news section. Initially, I have to be honest, I wasn’t 100% sure what exactly they were banging on about: XML and XSLT were new and mysterious things to me, and I couldn’t really see how they would help (cue sheepish grin..). Luckily they just got on with it rather than trying to explain it to me, and ended up writing a content system which revolutionised the way that the Antenna team edit and publish content. In brief, the system allows creation of a single XML-based content source which is then re-purposed to both web and gallery kiosks. Dan did some tests at some point and found that entire gallery stories could be built and published in around 12 minutes, a huge resource saving to the 2-3 days it was taking prior to that. The system is still in place today, and was really the pre-cursor to our understanding of how a good CMS system should capitalise on XML to deliver content to multiple channels. A similar approach was used by the agency who developed the fabulous Energy website, and continues to be the end-goal for Content Management at NMSI today: one “pot” of content delivering to gallery, web, mobile and anywhere else we choose…

Meanwhile, we were working hard on the Science Museum website, consolidating content, tidying up bad code, trying to CSS the whole thing. Behind the scenes, I was rallying for budget to re-develop it. Note “re-develop” rather than “re-design”: we knew we wanted to do something radical with the entire thing rather than just re-skin it: this is what we’d done in 2000 and apart from making it look better, it had still remained badly broken under the hood.

Eventually we got budget. The entire re-development project probably took about 3 years – again, far too long – but we remained incredibly enthusiastic with the vision we put together and the agencies we took on to do the work. The energy remained pretty high, which is always the most important thing. The new site went live on 26th March 2007. Beautiful, isn’t it?

At the same time (and looking back I can really see that we took on far too much in one go..) I was also working on putting together a vision for Content Management at NMSI. After a long procurement process we bought Sitecore, a fabulously powerful, standards-compliant .NET system. The ultimate, organisation-wide vision of building in Enterprise Content Management to everything content-related is still in its infancy at NMSI, but Web CM is the first, very visible starting point on that journey.

Of course we also continued to build in user generated content and new technologies wherever we could. Our web strategy took the organisational direction and applied UGC, drawing parallels between what our stakeholders wanted and what the web can usefully deliver. This ranged from SMS messaging during risqué Dana debates, encouraging visitors to bring in toys, a range of RSS feeds, allowing users to Ask Glenn – to mention but a few…

Next?

I have no doubts at all that web will continue to grow in importance and stature at NMSI. The vision, the environment, the beginnings I’ve had the privilege to be involved in – all point to an incredibly interesting future. I’ll be watching (with only occasional twinges of regret..) and undoubtedly blogging about it too.

The next huge thing on the immediate radar is the launch of Launchpad, the flagship hands-on gallery at the museum which is due to re-open – much bigger and improved – later in the year. I’ll be posting very, very soon about the online element of this. I’ve had the privilege of helping develop the concept for this and have watched it grow into something absolutely outstanding. It’s one of the best things I’ve seen for some time. But you’ll have to wait a little while before you too get to see it…

O’Reilly radar posted last week about Open Education Search, a collaboration to “build a web search portal dedicated to open educational resources“. There is more about the project on this later post, but it looks as if it will make extensive use of Custom Search, another offering in the bewildering array of free search services provided by Google.

For me, the interesting thing about using Google coop is that it places the bar for cross-domain collections searching, and automatically challenges any institutions considering the various approaches favoured in the past (such as, for instance, Z39.50), to come up with something better.

There have been rumblings in the pipeline for as long as I can remember about a national (or international) search engine for museum collections. Pretty much everyone agrees we’re in a ridiculous place right now: you have to know which institution to go to in the first place to then do the searching for the thing you’re interested in. There is no central place for finding all the Babbage-related collections on the web, for example, except for – oh, hang on – Google.

“…wait!…” shout the hardcore metadata types, “…Google apps doesn’t provide our users with the granularity they require: we need it to be better!”

Well, here’s a proposed solution to that problem: instead of a bunch of museums getting together and spending the next five years (and equivalent vast sums of money) arguing about standards, interoperability etc, before eventually self-imploding and deciding it’s all too much like hard work, how about we club together and buy a Google Enterprise or two (~£15k education price, I believe) and point it at each of the collections websites. Tweak the results, pay a designer £5k for the end result, buy a domain?

I’m being slightly fatuous (imagine!) but there’s a serious point here: Google does search really, really well, so why not use it? Yes, it’s “brute force” searching, but nothing – nothing – has come even close yet to doing it better. This is a perfection gene issue: I vote for cheap, cheerful and 90% perfect (and actually getting it done) rather than 99% perfect and still being here, £3m worse off and with nothing else to show in a few years time.

So. Anyone got £15k?