Opening up possibilities

A few nights ago I was trying to convey to a friend my incredulity at being able to assemble things like the brains for the Colony creatures.

Here’s something to blow your mind: parts to fully-functioning gieger counter in about 40 minutes. Thank you open source.

In blatant disregard of my pledge to not let projects be led by the technology, I’m now sat at my workbench, listening to the sounds of the universe, wondering what I can connect this up to…

19 steps to creating good, engaging experiences for museum and gallery visitors

On Monday, Public Historian made a request:

Can someone recommend (or, oh my, “curate”) the most awesome/vital/important things to come out of #museumnext? Too much information.http://twitter.com/publichistorian/status/5180816482

On Tuesday, @MuseumNext asked a question:

Does the Cathedral and the Bazaar apply to museums? – http://bit.ly/AkIgzhttp://twitter.com/MuseumNext/status/5196698213

The wikipedia article that @MuseumNext links to includes a list of 19 steps to creating good open source software. My response to this was that I was excited by the prospect of a similar list for open museums.

We rattled off 19 steps that, for the most part, swapped in museum terminology for the software design terms. When I first started writing this post on Tuesday afternoon, it was with the intention of digging a bit deeper to check that what we had here wasn’t just some diverting wordplay. I thought I’d supplement each step with references to things that were discussed at the MuseumNext event and it would nicely serve as a redux for Suzanne and others who weren’t able to attend.

Anyway, it didn’t quite work out like that. We really did cover a lot of stuff at the event and most of it was brainstorming in small groups – so even the attendees only have a small part of the overall picture of what happened there.

I gave up on this post for a bit, but I’ve not managed to bring myself to delete it. The thing is, these steps are just too relevant to my work and I feel I need them in the system (equivalent of pinning them up on the wall by a desk) as a reminder as to what’s important for a meaningful participatory approach. So, I’m going to press the publish button after all…

Apologies to Suzanne that this isn’t the nice summary we had both hoped for, but also an invitation for people to chip in with their thoughts. Maybe we can yet use these 19 steps as a framework about which to curate awesome/vital/important things. The comments are yours…

1. Every good project starts by scratching an individual’s personal itch.

Over the day and a half of MuseumNext I met a lot of people who are very passionate about a whole range of different things. We know this is the driving force behind good projects.

We also saw examples of projects that scratched itchy participants: for example Advice: Give it, Get it, Flip it, Fuck it and the Living Library. Maybe a combination of the two is the driving force behind great projects?

2. Good curators know what to write. Great ones know what to rewrite (and reuse).

@MuseumNext included the caveat “works if you say everyone is a curator”.

I’m going to reference the original essay “it’s almost always easier to start from a good partial solution than from nothing at all.”

After Nina‘s presentation on the Friday morning, someone asked where was a good place to find out more about awesome projects – Nina’s blog being an obvious place to start.

I’ve done nothing much more than dip my toes into the world of museum/exhibition design, but I’m aware of a number of people in that area blogging and reporting back on inspiring projects. There also needs to be a place where we can celebrate and openly discuss our failures too (there may be such a place already, either online, or in the form of face-to-face exchanges such as MuseumNext) so we can learn from our, and others’, mistakes. I tried to do this with my How to Wow series of posts and I know it’s not necessarily easy, but it reaps its rewards later down the line.

In our group discussing the Exhibition Gaming wild idea, we kept coming back to the belief that institutions starting to work with games-based projects should think in terms of a programme of games-based projects to give the institution an opportunity to learn and develop.

We also commented that our sessions had generated a lot of questions and that it would be unrealistic to try and answer them all in one project. Choose a few key questions, design for those, then incorporate the successes into the next project.

3. Plan to throw one away; you will, anyhow.

Again, from the text of the original essay: “starting over with the right idea is usually more effective than trying to salvage a mess”. [reference]

I’m using the work “projects” rather than “exhibitions”. “Project” seems to imply more of an evolutional development to me. Maybe there’s an exhibition along the way (I’m resisting saying “at the end”)? Maybe that exhibition has changed form a couple of times?

4. If you have the right attitude, interesting problems will find you.

How often do the audience get to nominate the project?

5. When you lose interest in a project, your last duty to it is to hand it off to a competent successor.

I’m curious. How long do museum projects last for? Long enough to sometimes need to find a successor for them?

I also can’t help but think that there’s something in the notion that curators are handing over a participatory project to the audience and that a) the audience/participants should therefore be fully equipped with the skills and resources to get the most from the project and b) the curator should see themselves as only being the first in a line of custodians.

Throughout the MuseumNext event there seemed to me to be a recurring theme of institutions having to learn how to relinquish control.

6. Treating your participants as co-developers is your least-hassle route to rapid project improvement and effective debugging.

I particularly like participants-as-co-developers as a method of giving co-ownership to the project.

7. Release early, release often. And listen to your participants.

This, to me, implies testing. In my role as game designer, that equals play-testing. I’m learning to play-test components, rather than build it up into a nearly finished whole before I test it. Testing unrefined bits of things makes it easier to throw stuff out. See the section of the “Cooperation and Engagement: What can board games teach us?” video below from about 8 minutes in for an example:

“If you try to polish a prototype too early, you become married to it, and you don’t want to make changes…”

8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

This reminds me of tales told by Alternate Reality Game designers who spend ages devising the most fiendish puzzles imaginable, only to watch as the players’ hive mind strips it bare in 20 minutes!

9. Smart platforms and dumb content works a lot better than the other way around.

The original “smart data structures and dumb code works a lot better than the other way around” reminded me of Nina’s diagrams from her presentation:

10. If you treat your participants as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
&
11. The next best thing to having good ideas is recognizing good ideas from your participants. Sometimes the latter is better.

I’m not sure I can add anything more to those two. Maybe the typewriter for comments is a nice illustration of valuing your participants.

12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

*nods*

13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

Can you substitute the word “communication” for “design”? What are the implications for that?

14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.

This is how smart platforms enable users to steer around dumb content.

It’s also one of the key reasons that I work in the way that I do – it’s so much more interesting to set something in motion and then allow participants to take it somewhere you never dreamed of. Be flexible and responsive when this happens.

15. When designing entry points to the project/exhibition, make it only as difficult as it needs to be. Never throw away feedback

(Original: When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!)

I used some creative license in interpreting this one – mostly riffing off the idea of gateways…
In our games group we talked a bit about providing multiple entry points into a project. Nina also talked about offering multiple engagement points and not focusing solely on creators.

Rather than saying to make entry points as easy as possible though, I think there are cases for providing either a grain of sand to needle at what might otherwise be a no-thought-required entry (fairly literal example, the Would you go to Mars doorway to the Facing Mars exhibition), or to make entry a challenge or a thrill (Ref: Another Exclusivity Paradox: Secret Gardens, Hidden Museums). Thus making entry points just difficult enough and no harder than that.

16. When your institution’s/sector’s language is impenetrable to your audience, change your language. However, don’t patronise.

I’m mostly thinking of a comment made by someone in our group who flagged up that there was often a language barrier between institutions and that terms could have very different meanings to different organisations. I might also be thinking of grumblings in response to this post about the Ashmolean in Oxford.

17. Leave secrets to be discovered for those willing to search for them. Reward curiosity.

Particularly with reference to games and not having everything immediately apparent after the first glance, but also the Another Exclusivity Paradox: Secret Gardens, Hidden Museums mentioned above.

18. To solve an interesting problem, start by finding a problem that is interesting to you.

Motivation, motivation, motivation.

19. Provided the development coordinator has a communications medium at least as good as the participants/audience, and knows how to lead without coercion, many heads are inevitably better than one.

Use the communications medium that’s most natural to your intended audience.

Have you got anything more you’d like to add? What thoughts do these spark off for you?