electronic museum

Entries categorized as ‘collections’

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

April 16, 2009 · 4 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 :-)

Categories: IT · api · collections · community · innovation · mashup · technology · web2.0
Tagged: , , , , , , ,

Creative Spaces – just…why?

March 4, 2009 · 48 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?

Categories: collections · community · content · innovation · museum · 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…

Categories: collections · exhibition · gallery · museum
Tagged: , , , , ,

Omeka – an online exhibits framework

March 17, 2008 · Leave a Comment

Tom Scheinfeldt contacted me through a comment on the Electronic Museum blog. He’s MD of the Center for History and New Media (CHNM) who among other things produce Zotero – a kind of semantic webby bookmarking toolbar.

Omeka logoCHNM 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.

Omeka - ExhibitThe 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 AdminOmeka 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.

Categories: api · collections · community · content · exhibition · gallery · museum · objects · software · web2.0

Semanticism. Semanticness. Semanticitivity.

December 10, 2007 · 3 Comments

Ever found yourself struggling to answer the question “but what is the Semantic Web? Can’t you give me an example…”?

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.

Categories: collections · conference · museum · search
Tagged: ,

The book is dead. Long live the book

November 15, 2007 · 5 Comments

It’s obviously that time of year again. A while back I opened the front door to find two books on the door step: a Yellow Pages and a standard phone book.

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.

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

Categories: books · collections · museum

Ceci n’est pas une tag

October 12, 2007 · 4 Comments

There’s an interesting post over on the conference.archimuse.com blog where Jennifer reports that research they’ve been undertaking on the use of the steve.museum tagger shows that greater than 75% of all new tags given to images in the experiment weren’t words originally associated with the image by museum staff when cataloguing.

It’s a tag!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.

Categories: collections · community · tagging
Tagged: , , , , ,

Au revoir, Science Museum…

September 23, 2007 · 4 Comments

The 14th September 2007 marked the end of an era, for me anyway. I’ve been at NMSI, the National Museum of Science and Industry, for just over 7 years, and that was my last day.

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…

Categories: collections · community · content · experimental · folksonomy · innovation · mobile · museum · sms · technology · ugc · web2.0

Open Education search

September 5, 2007 · 3 Comments

As some of you might remember, I put together www.museumcollections.org.uk a while back to demonstrate what could be done for collections searching with next to no cash (a fiver to register a domain), time (20 mins, tops) or effort (cut and paste). Underneath this is Google coop, an implementation of the big G’s search engine which lets you search across multiple websites. In this particular example, I added a bunch of domains or sub-domains featuring museum collections and also asked people (so far about 20) to contribute if they wanted to add further domains to the list.

lost?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?

Categories: collections · mashup · museum · search · web2.0