I know there’s lots of strong opinions about the new BMW Muesum in Munich (although I can’t be bothered to remember what any of them are) but this is undebatably clever.  714 metal spheres hanging from thin steel wire winches powered by individual high-precision stepper motors.

Now is a good time to cut your expenses.  Now is not a good time to cut your gallery budgets.

Cut your operating expenses.  A lot.  Ruthlessly.  I get it.  Streamlining is evolutionary.  But that’s the easy half.  You can cut and you can cut, but you can’t cut your way out of nobody-wants-to-come-here-because-it’s-boring.  Cutting does not lead to that destination.  What are you saving money for?  It’s a question worth pondering.  You can bail and bail, but if you don’t also paddle, you’re still going to sink.

Now is not the time for modest half-measures in your galleries.  Maybe just keeping your head down and your chinstrap fastened is all it will take for your endowment to eventually rebound.  But take a closer, more honest look at your pie charts.  Attendance declines were trending well ahead of the economy.  Don’t overly conflate the two.  Have you ever been to a penny arcade?  No, you haven’t.  Why?  There aren’t any more penny arcades.  (At the height of their game they were cooler than you.)  Time may be on your endowment’s side, but time is not on your side. Three more milquetoast business-as-usual 1990s hands-on interactive galleries from the same three business-as-usual 1990s hands-on interactive companies could be fatal. You have two crises to manage.  Don’t let the big one slip.

Philanthropy still exists.  But when there are more ideas competing for fewer dollars, it isn’t the cheaper ideas that win.  The better ideas still win.  Just fewer of them.  You’ll have a better time getting $2,500,000 for your bold, innovative idea than you will getting $250,000 for your mediocre one.  And it’s a lot less humiliating to ask for.  Let the financial timidity of rival projects be to your advantage.

Boy, am I going to be ashamed of this post a year from now.  Gratuitous multi-touch, comrades.  Shoehorn one into your next gallery or get left behind.

The multi-touch exhibit bandwagon has left the station. We’ve all by now seen Microsoft Surface.  (We’ve all by now had Microsoft endlessly dangle the prospect of loaning us one.)  Ideum has just launched a really nice museum-targeted version they are calling mt2 and unveiling with a Yahoo! Maps-based interactive at the Don Harrington Discovery Center.

Why fight it?  Your phone is already ringing.  And museumssuck.com is here to abet the insanity with a quickie getting-started-on-the-cheap glimpse of surface multi-touch.

I’m not going to talk about, like, adaptive thresholding adjacency algorithms.  Because I’m not that smart.  Welcome to museumssuck.com.  But supergeeks who are into that have made production-ready-ish software that does it and you and I can download it for free to make multi-touch interactives with a wow-factor-shelf-life of about twelve more weeks.  So hurry up!

Here’s the least you’ll need:

The magic pixie dust is the vision framework software.  There are lots now it seems.  Microsoft has whatever it has, and I think there’s an SDK, but you’re on your own with your Microsoft.  I’m pretty sure Ideum used NUI’s Snowflake 1.0 on the mt2.  The three big free and open source projects, though, are: reacTIVision, Touchlib, and tBeta (which isn’t to diss BBTouch, Bespoke, or Touché because I’m not qualified.)  I’m a reacTIVison fan, but by no means an authoritative one.  Read up and choose what suits you.

What, you may reasonably ask, is a vision framework?  Well, lots of frameworks means lots of answers to that question.  If you’ll permit me to be broadbrush and reacTIVison-oriented, it’s ninja optical-tracking, blob-detection-type software.  Your input device is a camera and your output is a bunch of data about who’s touching what, where, and when.  In the case of reacTIVision (and most others) this data is OpenSound Control (OSC) messages via UDP in the TUIO protocol.  If I just blew your mind there, take a wikipedia detour.  It’s pretty easy stuff, really.  Which may clear up as you read about the next pieces you’ll need…

You’ll need an OSC client.  That is, you’ll need a way to hear OSC messages via UDP (or in some cases MIDI.)  And then you’ll need a TUIO library.  This leads us off into more platform-specific directions than I mean to go.  If you’re a C++ person, your app will be the OSC client and there is tons of sample client code out there.  You Flash kids are going to need something called Flosc.  Flosc is a Java-based server that can hear OSC as UDP and then make it into XML for Flash.  And if it sounds to you like that may cause speed issues, well, you’d be right.  But it works.  Youtube “multitouch flash” and see.  But there is an OSC path to every pot.  And a TUIO library for that matter.  C#, C++, Java, Python, Flash, MaxMSP, Director, Pure Data, Quartz, Processing.

And that’s it.  Software-wise.  Next you’ll need to make the actual multi-touch surface thinger.  Mind you, there are simulators that exist for development purposes, for you software-only or small cubicle participants.  The reacTIVison folks make a TUIO simulator that you can use with any platform.  Download that and the stuff above and you’re pretend-multi-touching.  Thank you, drive through.

But you’re going to need a table eventually, right?  So what is the least you’ll need then?  Well, obviously you’ll need a…

Camera.  We could talk for days about camera variables.  Or so long as the we didn’t include me, we could.  There’s lots to know about cameras and multi-touch and that’s why there are so absurdly many blogs in this world.  At museumssuck.com, tech posts come big picture/small budget.  You’re working-ish today and you’re on your own from there.  So let’s talk hundred dollar webcams, shall we?

Let’s step back, though, for the sake of a core concept.  Your table has one surface.  The input is a camera.  The output is (probably) a projector.  You see the problem already, don’t you?  The surface has to be cleanly illuminated if the camera is going to be able to see correctly what is happening on it, and the table has to be dark if the visitor is going to be able to see the projected images.  The solution is to do these tasks in different light spectra.  The projector uses (for obvious reasons) the visible(-to-humans) spectrum.  Your camera, then, will use IR.  This means two things to your purchase of a cheapo multi-touch camera.  The first is that your camera must be able to see IR.  Most will.  But sometimes they will deliberately filter it.  Usually with a filter you can just remove, but sometimes there will be an IR filtered lens.  That won’t work.  The second is that your camera must NOT see visible light.  And if you’re dealing in webcams, this means you are going to need a special, separate IR pass filter.  Handily, your visitors come from the factory already unable to see IR. Now back to general camera junk.

Get Firewire not USB.  Higher frame rate, higher resolution, lower compression (means lower driver overhead.)  If you’re planning to jam this all into reasonably-sized casework, you’ll also need to choose a camera that will take a separate wide-angle lens.  Oh, and get CCD, not CMOS.  $111 will get you a Unibrain Fire-i that is all of these things.

IR LEDs.  Because you’re doing this museumssuck.com-style, you will need some wide-angle IR illuminators.  What for?  To light up your surface with IR so your IR camera can see it better.  This is called Diffused Illumination and is the quickest, dirtiest method for doing optical multi-touch.  Other common and affordable methods are Frustrated Total Internal Reflection, Diffused Surface Illumination, and Laser Light Plane.  You’ll probably end up learning about these, because they have significant advantages over DI.  But they’re trickier to build and (more importantly) trickier to blog about, and the basic operating principle is the same.  So: DI, it is.  Next…

A surface.  Where would you be without this tutorial?  You need a surface.  A sheet of plexiglass’ll do.  Glass.  Acrylic.  Clear, flat, won’t flex.  And it will need a diffuser layer for the projector image.  But it needs to let some light through.  Tracing paper works.  Vellum.  Mylar.  Lee Filter.  You get the idea.

If you’ll allow that the software implied a computer, that’s it really.  Connect a firewire cam to a PC, aim it an IR-illuminated sheet of vellum-covered plex, download and run reacTIVision and -poof- you’re a multi-touch whatzit.  Mind you, that doesn’t include an image to touch, which is going to be limiting, so let’s add…

A projector.  Actually that somewhat betrays the spirit of museumssuck.com, because you can use an LCD for prototyping or if your surface is small enough.  Whatever.  I don’t have much to say about either anyway.  Don’t forget about wide-angle considerations for casework and such.

Now you’re really done.  Or museumssuck.com done anyway.  Here’s a diagram from the reacTIVision site:

Blah, blah, blah, download and run reacTIVision, and -poof- is where we left off.  You’re done.   If spitting OSC messages counts as done.  You’re spitting OSC messages.  By default you are spitting them on localhost (127.0.0.1) port 3333.  You can change that by editing your reactivision.xml config file.  Which brings us back to the OSC client and TUIO library you chose above.  Together those’ll turn spat OSC messages into usable classes for your preferred programming language.

Last step:  Stretch and shrink pictures.  Drag pictures.  Spin pictures.  Two of you at once.  You drag a stretched picture while she spins a shrunk picture.  Drag and spin a Google map!  Enjoy it while it lasts.  In two years every Elo will have plug-and-play capacitive multi-touch and your Google map spinning projection table will be deleted from your résumé and posted as a joke on museumssuck.com.

Oh, and I’ll see you on the brilliant and friendly nuigroup.com forums.  Because you’ll be there a lot soon.

I was just going to use Google Apps free version to handle the email for museumssuck.com, but I kept getting the following vague error message: Google Apps does not currently support this domain name. At first I thought maybe it was a DNS propagation lag or something, so I waited another day: Google Apps does not currently support this domain name. And that’s when it occurred to me.  Museumsareboring.com: Welcome to Google Apps! Museumsarefuckingboring.com: Google Apps does not currently support this domain name.

Now, any of you who know me professionally are liable to know two things.  The first is that I think advanced content filtration algorithms are absurdly silly. The second is that I am pretty darn good at advanced content filtration algorithms.  I once sold a (funny, I thought) article that would explain these two seemingly contradictory facts, but the magazine refused to run it or return the rights to me.  Which at the time seemed like a suitable-to-the-topic Hellerian outcome.  (In the magazine’s defense, I wanted to call the article “Can a Robot say Vagina to a Thirteen-Year-Old?”  In my defense, the article included a scene where adults with PhDs debated this very matter at earnest length.  I offered to change the title to “Is Fucck a Bad Word?”  Negotiations broke down after that.  If I recall, the article concluded with the following technical summary of writing content filtration algorithms: “Sckrroo this b-lschytt.”)

Anyway, my perverse ears pricked.  And I couldn’t wait to test my chops against mighty Google.  The nutshell verdict:  I’m waaay better at software-spotting naughtiness than Google Apps.  From a decade of broadcasting user input from middle school kids.  I should make my algorithm available as a catchily-named web service.  Maybe I’ll get Google-acquired.  Hmmm… mouthsoap.com?

Shit.com can’t run Google Apps.  Shits.com can.  (I assume the second-s rule is to give you the benefit of the doubt for the use of hits.  As in yoursiteshits.com.  Or greatestbeatleshits.com.  Etc.)

Ass is the one that always gave me fits in that regard.  I tried bass.com: Welcome to Google Apps! Ok.  Hmmm.  Ass.com?  Welcome to Google Apps! Asshole.com?  Welcome to Google Apps! I guess they decided not to get mired in ass algorithms altogether.  Good choice, Google.

Hmmm… museumsareassholes.com?  That’s not as catchy.  Guess I’ll have to load my own SMTP.

Today I made a snazzy Flash interface for a digital photography archive.  What did you make?

In our defense Richard Wilson spent about $900,000 doing this installation for the Liverpool Biennial.  I got a chance to see his Slice of Reality installation when I was at Millennium Dome.  Yeah, but I bet he doesn’t know Flash.

Thirty minutes every month every employee works directly with visitors in the museum. A micro shift on the gallery floor.  The marketing intern, the IT director, even (nay, especially) the CEO.

Know your visitors.  Meet your visitors.  Watch your visitors.  Overhear your visitors casually make dismissive jokes to each other about your life’s work.  It’s important for staff, all staff, to remember what the product is.  (Not what the product aspires to be in your membership mailers.  What the product is.)  The most difficult and important step in problem solving is problem identifying.  And the problems that matter are the problems that visitors have with your museum.  (And, sister, there are lots.  Brother, get started.)

The goal of a good museum is to be a good museum.  And if a good museum gives you money by the hour, that is a goal that should be on your personal radar.  It is no use to have cubiclefulls of creative problem solvers if you don’t point them at the right problems.  Does your IT department think about how they can proactively invent tools to enable museum professionals to make a better museum?  Please.  They don’t even wonder what a “museum professional” does all day (besides jam the printer and forget his email password.)

If your employees mutiny, you didn’t implement it right.  Working in a museum is neato; that’s why you’re not making twice as much for the same work at Verizon.  Caring about whether or not you work for a good museum is rewarding.  The pitch is: “Our museum sucks and we want our best minds on the floor figuring out why.”  You may tweak the wording.  And don’t give me “not-a-people-person.”  Your Photoshop guy can put on a clean shirt and be pleasant for half-an-hour a month.

Get good minds and get them museum-oriented.  The first part is useless without the second.

I’ve made a few interactives in the past that sent SMS text messages, but I only just recently was asked to make one that could receive them as well.  I decided to post this simple, little project that anyone can do as a way to share a few details I learned along the way.  It may be a useful overview to anyone else writing their own first two-way SMS app.  I don’t think I’ll talk a lot in actual code, because I’m pretty sure the code part of this project will be universally easy to anyone about to design a two-way SMS app.  This is more of a big picture overview for someone wondering what all the pieces are.  If you’re actually doing this and you get stuck on any code steps, feel free to email me and I can fill in the blanks.

The project: We’re going to make a simple Shockwave app that will receive SMS text messages from anyone with a mobile phone and then display them on a web page as they come in.  Sound fun?  I know, but it will walk us through all the minimal steps involved in making a two-way SMS application.  Once those are in place, there’s bound to be something fun you could do with them.  Maybe.  Anyway, we’ll begin with…

The part you can’t do: This’ll be the step that slows you down if you’re following along at home.  Unless you are a mobile network provider with lots of expensive telecommunications equipment, you can’t actually receive text messages and convert them into recognizable data.  So if you’re building a two-way SMS application, you’ll need to hire a service that will do that part for you.

There are essentially two ways that the computer running your application can receive an SMS text message.  This project will focus on one, but make passing reference to the other as we go.

The first thing you could do is put a physical GSM/GPRS modem in your computer.  A GSM modem is essentially a mobile phone.  In fact, the mobile phone in your pocket probably has the ability to act as a GSM modem, given the right cable and software.  Or you can buy an internal or external GSM modem.  These can send messages a lot faster than your phone, but that probably won’t matter for an interactive exhibit.  The phone in your pocket may also give you issues with concatenated or multimedia messages.  For an actual exhibit, you’d probably want a proper modem.  For this project you could use your phone.  Remember, too, that a GSM modem obviously needs to be located in an area with GSM signal.  So, you know, think about where and how your exhibit will be deployed.  With a GSM modem you need a SIM card, just like your mobile, and the SIM card needs a service plan, just like your mobile.  But I’ll gloss over the details of that, because that is not the method we will use in our project.  (I’ll try to point out the differences as we go, though, so you can use that method if you already have those pieces handy.)

The second method is to lease access to an SMS gateway from a service provider.  And unless you do a spamtastically high volume of texting, you can’t afford to get your own SMS gateway from a wireless carrier.  So you use a service that enables several customers to share one.  There are lots of those and lots of things to consider and I could say lots about that.  But I won’t.  Because it’s really boring.  I said the part where there are lots of them, the other part worth saying is that it’ll probably cost you 3 or 4 cents-ish per message, some variables depending.  You can email me if you want to know anything more I learned about that.  For our project we are going to pretend you chose clickatell.com, because, well, my client chose clickatell.com.  (That, btw, isn’t a formal, qualified endorsement of clickatell.com.  I wasn’t too involved in this part.  My client wasn’t actually a museum but a rather large non-profit with a rather noble-sounding mission and I’m given to understand that this lead to generous terms.  Somebody on their board knew etc dot dot dot.)  You may choose who you choose and it will end up being very similar to this.  I can say that clickatell.com is very developer-friendly with excellent docs and APIs.

Service that permits two-way SMS is different than using a gateway service just to send.  Your provider will offer both plans.  You need 2-way.  Which means you need a Virtual Mobile Number (VMN: an acronymic way of saying that you have a number for people to dial, but no corresponding phone or SIM card.)  You have to apply for this and it can take a couple of days to come through.  This process includes you accepting liability to the tune of 4 cents-ish a pop for incoming messages to that number.  (I’m not sure what if any built-in safeguards are available in terms of not accidentally getting a much higher bill than you hoped.  I’ll edit this post with that info when I track it down.  Incidentally if you’ve wondered why this page doesn’t have a working demo version of the completed project, that’s why.  Sharp-elbowed, snarky blogs may tempt four-cents-a-whack revenge bots.)

Thank god that’s over. Still with me?  Probably not.  That’s not necessarily curious hobbyist-friendly, but… let’s pretend.  (You’re welcome to make your phone into a modem if you’re that determined to join in.  Go download a driver.  If you have a Motorola RAZR V3m like I do, it’s here.)  Now you have an account that will receive SMS text messages and deliver them to you any which way you like.  For simplicity sake our project is going to get them as GET data via http.  Doesn’t get simpler than that.  (How do we do that, you ask?  In my case, you tell clickatell.com where to send what and how every time your VMN receives an incoming message.  Be sure you look into APIs and available formats when you pick your service.) So let’s begin, shall we, with a visitor sending an SMS message to our Shockwave app and talk about each of the pieces we will need to build to handle it along the way.  So:

A visitor types a text message and sends it to the number that matches our app.

An expensive magic box at clickatell.com receives the message for us and sees that we have asked them to immediately send GET data via http to…

The first PHP script that we have written and placed on our web server: In the simplest short hand, this script takes GET data from clickatell.com creates variables and inserts them into a MySQL database on our server.  Just like it was sent from any html form.  In our project we are only concerned with the message string.  Our example MySQL database could be a simple three-field table with a primary key id, a datetime stamp, and the message text.  When the message comes from clickatell.com, our script makes a message variable, tidies and parses it, and inserts it as a new row in our table using the current time on the server as the datetime stamp.  That’s it.

Meanwhile elsewhere on the same server: There is our Shockwave app.  When a visitor opens a webpage that loads the app, it first makes a variable of the current server time.  Let’s call it checkForMessagesSince.  Then every x seconds (10, say) it asks a question to…

The second PHP script that we have witten and placed on our server: In the simplest shorthand, this script takes the checkForMessagesSince variable as POST data from our Shockwave app, creates a variable for $checkForMessagesSince and uses that to query our same database.  It asks for all the messages received since that time and gives us back only the oldest message received since then.  Then, as XML, it tells us two things: the message text string and the datetime stamp that matches it (or NULL as the case most often will be.)

If our Shockwave app hears NULL, it does nothing at all but continue to ask.  If our Shockwave app hears a string and a datetime, it does three things.  First it makes a variable for each.  Then it echoes the message text (Um… tada!  That’s the show, folks. Your text mesage on a webpage.  All this for that?  But it’s a variable now.  Your real app will think of something cooler to do.), and resets the checkForMessagesSince variable not to the current server time, but to the datetime from the message it just echoed (so none will get skipped.)  Rinse.  Repeat.  You may now text your exhibits.

(Of course, if you decided to play using a GSM modem, you have a little additional work, no?  You only get half of what we clickatell.com folks get.  You get a message from the mobile network, but you don’ get the neatly parsed and formatted results submitted as GET data to the URL of your choice.  If your exhibit is local/gallery (meaning non-internet) you can receive this message as serial data under a number of protocols using the syntax and commands for your device.  That’s even easier, in theory, than our project above.  Get data, parse data, show data.  But I’ll bet you can’t do the get data step without google.  I can’t and it’s boringer than the scope of this blog post.  Your modem will support AT commands, if it helps to consider that.  If your exhibit is web-based, you have one more step.  You have to be your own clickatell.com and send the nicely-formatted data as GET your damn self to the aforementioned script waiting for it that way.)

Cool, huh?  But, wait!  For the hobbyest of hobbyist, there is one last method-ish.  A clunky but SMS-service-less and, therefore, FREE cheat.  With almost every contemporary phone, you can pretend to be SMS-ing when in reality you are using email as a transport.  (I’ve actually used this cheat for a low-end send-only prototype.  Two-way adds a tricky step, but in untested-by-me-personally theory, it’s totally feasible.)  You see, almost all major carriers provide this service to their customers.  I can email your phone and your phone company will send it to you for me as SMS.  Or you can SMS my email address and your phone company will send it to me as email.  If you want to cheat-SMS an AT&T/Cingular customer, for example, simply send an email to 5555555555[their 10-digit number]@text.att.net and they will receive it as SMS.  (T-Mobile is 5555555555@tmomail.net.  Verizon is 5555555555@vtext.com.  Nextel, Sprint, and Virgin are @messaging.nextel.com, @messaging.sprintpcs.com, and @vmobl.com.  You can look up others.)  For the same matter, any of those customers could send an SMS message to yourexhibit@yourmuseum.org and the phone company will give it to you as email.  Now you’re left with an email that you need to write a reliable parser for.  (Bet you’ll be debugging that for a few hours.)  That’s wonky for a hundred reasons I needn’t point out, but it works.  And I just saved you four cents.  You can owe me.

Um, am I at Cambridge or Burning Man?  Who says steampunk is just for thirty-six year-old Linux admins with male-pattern receding dreadlocks?  (Oh.  That was me.  But this clock is cool. Was the point I started to make.)  This design is ingenious in more ways than I can blog about without wanting to retire in deference.

The functioning Chronophage clock was designed, built and funded (to the tune of $1.83 million) by philanthropist/inventor/Cambridge alum John Taylor and is currently hanging at the (not-coincidentally named) Taylor Library at Corpus Christi College Cambridge.  The face is a single five-foot sheet of gold-plated stainless steel shaped in part by controlled explosions.  There are 2,736 LEDs that are always on and revealed by three idependently-rotating perforated steel rings.

The project website is here: www.chronophage.co.uk but you can actually get more design details by googling for wowed geeks.

A (quite talented) reader from The Tech Museum of Innovation in Silicon Valley sent this photo without comment.  To, um, museumssuck.com.  To say anything further seems gratuitous.

I guess no one makes a 13-inch black and white TV with a touchscreen.  Oops.  Couldn’t resist.

Thanks! You should send william@museumssuck.com a photo from your museum.  It’ll be cathartic.  Like a twelve-step program.

Here’s a fun activity if you visit lots of museums that are short on those: try to guess what year the gallery you are approaching opened by observing the exhibits from the threshold.  16:9 or 4:3?  1280×1024 or 800×600?  CRT or LCD?  ELO or Happ?  I can tell you what version of Photoshop you made your buttons with by the drop shadow alias.

Or, try playing by hot industry meme:  Visitor feedback station?  Additional info web kiosk?  Post-visit barcode website?  Gesture recognition interactive?  (It’s: year that meme was the darling of ASTC divided by the square root of the museum’s distance from the coast, for those curious.)

And speaking of versions of Photoshop, the only reason there exists software as powerful and intuitive and feature-rich as Photoshop is because it comes in versions, right?  Iterative development.  Release, test, improve, release, test, improve, release, etc.  Keep all of the good, add a pinch of better.  Debug.  Repeat.

Virtually all commercial software is developed on the iterative model.  Even most museum websites are built to be iterative. So, why are so few exhibits?

I get it.  You just barely finish your project on time and on budget.  Sometimes the be-tuxed CEO is toasting while the last trackball screws are quietly being tightened.  And then you, your colleagues, and your scarce resources are on to the next project, already in progress two weeks behind schedule.  Maybe you’ve kidded yourself that you’ll go back for a final round of tweaks.  Maybe you even had a team debrief where you wrote several of them on a dry erase board.  Or maybe you have matured beyond kidding yourself in this vain.

Simple, focused iterative exhibit releases are one of the most efficient, effective ways to make your museum suck less. Hang on, I’m bolding that.  There.

In this and an entry or so to follow I’d like to posit a few whys and hows of iterative exhibit development.  First a few whys:

HIGH BANG + LOW BUCK. Equals trouble for exhibits that suck.  Making an exhibit typically is a significant resource investment.  Coming back a few months later and making a few well-designed improvements is resource-trivial by comparison.  And yet can really make a huge difference in visitor experience.  This is building a house vs. installing a garage door opener.  It’s a gimme.

ENCOURAGE MEMBERSHIP AND RETURN VISITS AND VISITOR SATISFACTION. Oh yeah, it helps all kinds of pie charts.  Your members and return visitors notice when exhibits improve and expand.  And when they see this as routine, they’ll come back for that reason alone.  Check that visitor survey you commissioned from your last charlatan wunderblogger consultant.  I’ll bet you some variation of “Content not updated enough” was in your top three complaints.

GREATLY EXTEND YOUR GALLERY LIFE CYCLE. You don’t need iteration, you say, because your museum has its galleries on a three-year renovation cycle.  Two questions.  Do you really, honestly have all your galleries on a three-year cycle?  OK.  Fine.  Question two:  If I could wave a magic wand and turn that three-year cycle into a five-year cycle and make your galleries better and more relevant for five years than they used to be for three…  (if at the end of five years you could respectably sell them to another museum, when you used to have to pay to store them after three until you finally had the heart to throw them away…)  can you think of two worthwhile things you could do with all the money and man hours you’d save?

HOW DARE YOU NOT? Those are exhibits.  You’re open, aren’t you?  I paid to get in here.  Let me check my stub for the disclaimer that says “We are not responsible for our Civil WRITES! gallery sucking; it was a lot cooler back in 2003 when it opened.”

(In a subsequent post, I’ll share a few simple tips for effectively implementing exhibit iteration in your museum.  Probably.  And I swear I’m getting back to the gym this week.)