electronic museum

Entries categorized as ‘web2.0’

Many me

October 7, 2009 · 13 Comments

I first joined Twitter in 2007. In fact, if www.whendidyoujointwitter.com is correct, I joined on 20th February 2007.

My first account was @dmje. I tweeted in that way that everyone seems to first tweet – a sporadic few “just what the hell is this Twitter thing all about?” followed by a long gap, followed by a re-emergence as more people I knew found themselves on it. I also, of course, blogged (“All Noise, No Signal“) and have been slowly eating my words (some of them, not all) ever since.

For a long time, my @dmje account worked well. But after a while, I started to become very aware that the person that I am (opinionated, personal, direct, a little bit sweary..) was different from the person I either *should* be or was somehow expected to be (professional, supportive, focused).

At that point in time – in fact, prompted by a slightly sweaty moment in which I tweeted a few bits and bobs which I probably shouldn’t have from a professional perspective – I decided to make @dmje a private account and create a new public persona, @m1ke_ellis. Again, according to whendidyoujointwitter, this happened on 22nd May 2009.

I went through a fairly painful process of moving across *some* contacts to my m1ke_ellis account but leaving others at @dmje. My criteria? Very, very loose, but broadly based around: “If we’ve met and drunk a beer together then @dmje, otherwise @m1ke_ellis…”. There are exceptions to this rule, though. Obviously :-)

I’m now maybe 5 months down the line, and I’m still not entirely happy with the outcome; although each time I think about the possible alternatives I always come back to what I’ve done as being the best way, albeit far from perfect.

Here’s the thinking:

The good:

  • I can continue to rant, unabridged and privately (except, obviously, to a group of trusted and known personal friends) using my @dmje account. I use this account far more than my public one (sadly, nearly 10,000 tweets…)
  • I follow about 120 people, I have about 110 people who I’ve allowed to follow me. These people are real to me. In true Dunbar style, I see my Twitter stream for @dmje and feel a personal connection with each and every person on that list.
  • …I can therefore cope with the quantity and noise
  • Tweets to and from the @dmje account are much more conversational, much less “broadcast”
  • I can retain a “professional” persona at @m1ke_ellis, tweeting about work and technology related stuff. This is particularly useful at conferences and so on
  • Having a public account of some description is useful when it comes to feeding a stream to blogs, profile, and so on

The bad:

  • By far and away the single worst thing about this approach is this: I’m not two people, and although this can sometimes get ugly (yes, I ranted about Creative Spaces; no, I wasn’t particularly “professional”, but I feel passionate about some things..)
  • From a marketeers perspective (and I don’t subscribe to this viewpoint at all, btw), I’ve done A Bad Thing by splitting my Twitter accounts. While I’ve watched some people moving up to thousands of followers, I’ve split my juice (urg!) across 2 accounts. Actually, more – I also use @bathcamp and @eduserv for other specific purposes. If I was after followers (I’m not), I should probably have stuck with a single “me” account.
  • Maintaing two or more accounts is challenging, logistically. Although Tweetdeck (my preferred desktop client) and EchoFon (mobile) both support multiple accounts now, it is very easy to tweet the wrong thing to the wrong account. More to the point, it is hard to maintain momentum with an account if your attention isn’t on it all the time

There is a deeper point to all this: Embracing social media requires a fairly complex understanding of personality and tone of voice. I might be a more professional me over at @m1ke_ellis, but how is that me different to the me at @dmje? You’re not likely to hear about my kids, my wife, my life, my hangovers, the gig I just went to, the #bus14 journey I nearly got killed on.

But there again, if you’re listening to the professional me then you probably don’t want to hear that anyway, right? Or do you? How real is the me who just talks about work? Not very, in one sense, because my family and that other stuff is (obviously) waaaay more important than my working life. And it’s not like I can effectively split my interests in that way. I live and breathe web stuff – this is far from being a day job for me.

Actually, I think the most successful social media people and companies manage to balance this rather better than I have. Take @andypowe11 for example. He’s public and not only tweets about metadata and work stuff but also rants on occasion, too. He’s got better self control than me (he’s as rude, but swears less..), but still.

I don’t like Twitter as broadcast mechanism, and I think naturally once you pass a level of followers/followees that is what it becomes, unless you’re on top of it all of the time. Personally I dislike it when I “@” someone and they don’t reply; clearly someone with thousands of followers is unlikely to respond all of the time. Twitter then moves from being a conversation to being something different, a something which I feel doesn’t carry the personality which social media perhaps should.

Categories: community · museum · web2.0
Tagged: , , , , ,

Pushing MRD out from under the geek rock

July 13, 2009 · 11 Comments

The week before last (30th June – 1st July 2009), I was at the JISC Digital Content Conference having been asked to take part in one of their parallel sessions.

I thought I’d use the session to talk about something I’m increasingly interested in – the shifting of the message about machine readable data (think API’s, RSS, OpenSearch, Microformats, LinkedData, etc) from the world of geek to the world of non-geek.

My slides are here:

Here’s where I’m at: I think that MRD (That’s Machine Readable Data – I couldn’t seem to find a better term..) is probably about as important as it gets. It underpins an entire approach to content which is flexible, powerful and open. It embodies notions of freely moving data, it encourages innovation and visualisation. It is also not nearly as hard as it appears – or doesn’t have to be.

In the world of the geek (that’s a world I dip into long enough to see the potential before heading back out here into the sun), the proponents of MRD are many and passionate. Find me a Web2.0 application without an API (or one “on the development road-map”) and I’ll find you a pretty unusual company.

These people don’t need preaching at. They’re there, lined up, building apps for Twitter (to the tune of 10x the traffic which visits twitter.com), developing a huge array of services and visualisations, graphs, maps, inputs and outputs.

The problem isn’t the geeks. The problem is that MRD needs to move beyond the realm of the geek and into the realm of the content owner, the budget holder, the strategist, for these technologies to become truly embedded. We need to have copyright holders and funders lined up at the start of the project, prepared for the fact that our content will be delivered through multiple access routes, across unspecified timespans and to unknown devices. We need our specifications to be focused on re-purposing, not on single-point delivery. We need solution providers delivering software with web API’s built in. We need to be prepared for a world in which no-one visits our websites any more, instead picking, choosing and mixing our content from externally syndicated channels.

In short, we now need the relevant people evangelising about the MRD approach.

Geeks have done this well so far, but now they need help. Try searching on “ROI for API’s” (or any combination thereof) and you’ll find almost nothing – very little evidence outlining how much API’s cost to implement, what cost savings you are likely to see from them; how they reduce content development time; few guidelines on how to deal with syndicated content copyright issues.

Partly, this knowledge gap is because many of the technologies we’re talking about are still quite young. But a lot of the problem is about the communication of technology, the divided worlds that Nick Poole (Collections Trust) speaks about. This was the core of my presentation: ten reasons why MRD is important, from the perspective of a non-geek (links go to relevant slides and examples in the slide deck):

  1. Content is still king
  2. Re-use is not just good, it’s essential
  3. “Wouldn’t it be great if…”: Life is easier when everyone can get at your data
  4. Content development is cheaper
  5. Things get more visual
  6. Take content to users, not users to content (“If you build it, they probably won’t come”)
  7. It doesn’t have to be hard
  8. You can’t hide your content
  9. We really is bigger and better than me
  10. Traffic

All this is is a starter for ten. Bigger, better and more informed people than me probably have another hundred reasons why MRD is a good idea. I think this knowledge may be there – we just need to surface and collect it so that more (of the right) people can benefit from these approaches.

Categories: content · copyright · museum · technology · web2.0
Tagged: , , , , , , , , , , ,

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

April 16, 2009 · 6 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 · 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?

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

Categories: community · content · innovation · marketing · museum · social network · web2.0
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.

Categories: content · technology · web2.0
Tagged: , , , ,

Omeka – an online exhibits framework

March 17, 2008 · 1 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

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

March 11, 2008 · 13 Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Categories: community · content · games · innovation · marketing · museum · web2.0
Tagged: , , , , , ,

Everyware. Bring it on.

February 1, 2008 · 2 Comments

augmented reality bookI love it when people as influential as Tim O’Reilly blog about stuff which really floats my boat. I’m an enormous fan of the concept of Everyware – the ubiquitous web – augmented reality – the spime – the whole notion of accessing the web from the “real” world, not just from a desktop PC.

Tim (my mate Tim. Ha ha. If I didn’t like what he had to say I’d call him “O’Reilly”..) mentions what looks like a great book called Augumented Reality: A Practical Guide. He goes on to post about the overlaying of the web on the real world and vice versa. This is exactly where the ubiquitousness of mobile devices is likely to take us, IMHO.

On what I thought was a similar vein, I got really excited this morning when I first saw myvu and figured (before I’d seen the really boring video) that it was going to be a kind of “personal HUD“. In fact, it’s “just” a pair of glasses with a TV in them (notice how I belittle what is obviously an enormous step in technology, one that would have made Bond weep with joy only 5 years ago..).

The overlaying of virtual on real is one of my major excitement factors for where the web goes from here. As soon as you start getting stuff like Google Earth and more importantly Keyhole (now Google Earth Community) and Sketchup integration – UGC style – with that environment, the augmentation starts to gather weight as being not only exciting but useful too.

The obvious missing links are tantalisingly solveable, too. With “out and about” computing, the always-on data plan is fixing the “device is cleverer than network” issue. The remaining link – “where, exactly am I?” is nearly fit for purpose but not quite fit for purpose enough. GPS (if you have it) gets you accurate location, but as Tim says – not internally, not per floor of building, not centimetre accurate. There is of course cell location (accuracy maybe 300 m in urban locations, and available on any phone) but that isn’t cutting it, either.

I also posted about how a future where images could be knitted together and then used to create wireframed 3D environments on a map. Now chuck in the augmentation element – real time data overlaid on known location – and stuff suddenly gets very Minority Report indeed.

Categories: community · content · everyware · location based · mobile · second life · ubiquitous · virtual world · web2.0

Pirate yourself

January 29, 2008 · 3 Comments

Paulo Coelho, well known author of The Alchemist, has taken a novel (ha ha) approach to the “Scarcity vs Scale” discussion. He’s created The Pirate Coelho, a jumping off point to a Box.net storage account with PDF’s of some of his books.

There’s a description of what and why on TorrentFreak and a video of Coelho talking about how the web has challenged traditional publishig.

The figures are hard to argue with:

“…how uploading the Russian translation of “The Alchemist” made his sales in Russia go from around 1,000 per year to 100,000, then a million and more…”

Interesting stuff. He looks good with a pirate eye patch, too :-)

Categories: books · content · copyright · drm · web2.0