I was reminded looking again at Johnny Lee’s Wiimote hijinx of a drawerful of these handy, little SparkFun 3-axis accelerometers I inherited from a project of yore, and I decided to post this simple project as a quick overview of, um, why they are neato.  You could make this project with a Wiimote, too.  Or the nearby 3-axis accelerometer of your choice.  What’s handy about these little SparkFuns is that they are bluetooth-less, battery-less (and power supply-less–it takes its 5V straight off the serial) and gallery-rugged, and they have a little PIC chip already turning the data into RS-232 for you.

The Project: Turn an LCD monitor (and a SparkFun accelerometer and a PC with the Shockwave application we write) into a ball maze.  (Yes, quite like the toy you could alternatively purchase at a Woolworth’s for less than two American dollars.  It’s supposed to be a quickie intro to tilt and gravity interactivity, smartass.)  Anyway, let’s take a closer look at these parts…

Shockwave?  Not really.  Not necessarily.  I wanted (to the extent it is possible) to try to standardize all the demos on this site so that it doesn’t take 114 weird plug-ins to come here.  Shockwave seemed like a logical choice.  Why?  Well, it’s web-based, so I can run demos live on the site.  It can be object-oriented when that is what you are explaining.  It can be timeline-based when that is what you are explaining.  You can do code examples in lingo so that they make sense to non-coders.  You can do code examples in javascript so that they make sense to everyone else.  And, most relevant to today, it can do true 3D complete with physics.  So it seems like the best single platform for platform-agnostic demos.  I’m going to make my ball maze with Shockwave and the Havok physics engine; you can use whatever 3D development platform you prefer.  (I tend to be a Unity fan, by the way, just as a matter of flag waving.)  You could even do 2D physics in Flash if that’s how you roll.  You’re about to see how easy the SparkFun will make it for you to switch around.  I should add that since mine is Shockwave, I’m also going to use this brilliant SerialXtra by Geoff Smith in order that my Shockwave app can hear the incoming accelerometer junk.

LCD Monitor?  Not really.  Not necessarily.  I wanted something handy you could hold and tilt (and show a ball maze application on.)  Maybe you put an LCD in tiltable casework.  Or just project onto a tiltable surface.  Or make a more Wii-ish handheld controller.  It depends on your actual content.  If you don’t care to be overly literal about this ball maze metaphor (or you still use a CRT) you can just hold the SparkFun in your hand and have, like, a magic wand controlled ball maze.  (Take two dollars to Woolworth’s and ask for one of those, smart guy.)

SparkFun Serial Accelerometer Tri-Axis v5?  Not necessarily.  They’re $89.95 plus shipping.  You could make one for less with the logic/serial chip of your choice (PIC, Atmel, etc.) if you’re that way bent, but unless you’re making 1,000, is it really worth it?  Not to museumssuck.com.  But here’s the magic:  Plug this gizmo into your serial port and what does it do?  It says over and over and over as RS-232 its calculated gravity value as a vector.  (Say what? It takes its static acceleration, which is basically caused by gravity, and its dynamic acceleration, which is caused by someone tipping it or bumping it or waving it, and gives you the combined effect as x, y, and z values.)

What’s so cool about that?  Well, gravity vector (the value the SparkFun is calculating and sending you over and over) is a standard environment variable in any 3D physics engine.  So, in the barest oversimplified terms, all your “application” needs to do for a very realistic, accurate effect is build (or import) a 3D model (you can make a simple ball maze out of primitives: a plane, a sphere, a few boxes for walls… all run-time code, no beforehand 3DS Max), initialize a physics engine, and then keep letting the SparkFun redefine gravity over and over.  Your scene just sits there while gravity goes all weird around it.  Tip the sensor a bit and gravity stops pulling perpendicular to your scene, but instead pulls at at angle that matches the tilt of the SparkFun.  Fasten the SparkFun flat against the LCD monitor that is displaying your scene (with double-sided tape for now’ll do) and gravity pulls on your scene at an angle that matches the tilt of the monitor and therefore of the scene. No software tilting or perspective correction.  Just: ask for tilt, reset gravity, ask for tilt, reset gravity, over, and over.

Next you can add bells and whistles and graphics and scoring and collision animations and such to your heart’s content.  But the tilt mechanism at the heart of it is as simple as that.

Well, almost no code at all except building a 3D scene, applying mesh deforms and physics, writing a serial listener, parsing and converting the serial input (which invariably won’t be in the format your physics engine wants), plus all the generic game scoring and what-not.  So: a lot of code.  But almost no code for the tilt interface part was what I meant.  Which is kind of a neat trick, no?

(I’m trying to keep these tech tips brief and big picture and it seemed astray to turn “$90 accelerometers are neat” into a 3D physics tutorial.  I actually have a Shockwave/Havok/Sparkfun-based tilt interactive running in a museum and, therefore, the code on a file server somewhere.  As usual, if you actually do try any of these projects and get stuck anywhere along the way, just email.)

In an earlier post I tried to convince you that you should start using an iterative model to develop your exhibits, but I didn’t really say much about what that meant or entailed.  But I am thoroughly convinced that it is the lowest overhead way to make your museum content much better.  So, I bet I’ll further harangue on the matter at some point.  But, mercifully for us both, not today.  But to the museums who (still) have the luxury of their own in-house exhibit developers, I present to you (and encourage you to adopt) the cheapest, most effective iterative trick to keep your exhibit content fresh and optimized and evolving…

Tweak per week™

If you are an exhibit developer (or give annual performance reviews to one) take 15 minutes every Monday to walk around the museum.  (You really should anyway.)  Use one of your exhibits.  Watch visitors use one of your exhibits.  Pick a single, simple, discreet item that you regret about the design, and… fix it.  One per week.  While you’re listening to hold music.  Simple as that.

Maybe the wording of something is confusing in retrospect.  Maybe the background color is too dark.  Maybe you need a pop-up hint or a quit button you didn’t think to include.  The title graphics were rushed and they’ve always bothered you.  It should show you your time as well as your score.  You probably already have a mental list a mile long.

Do one.  Every week.  Don’t do zero.  Don’t do two.  (Don’t try to fix everything while you are fixing anyway or suddenly it’s an actual capital-P Project that will never make it to the top of your plate.)  That’s 52 worthwhile improvements, per developer, per year.  Cost is negligible and you will see the results.

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’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.

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.)