Monthly Archives: December 2010

A customer of mine uses SurveyMonkey, a popular online survey tool, to build and manage their visitor surveys. You can set up the survey to pop up an invitation to participate, which then leads on to the survey itself.

Once your survey is all set up, SurveyMonkey gives you a script tag to embed on the pages you want to run the survey on. The script tag is a simple fetch of some code hosted on the servers. The code it ultimately fetches is a simple call.

So far so simple. The catch in my case was that the customer wanted the survey to appear when the user left the page rather than when they arrived, the reasoning being that at least then they would have seen some site content in order to better answer the survey questions.

My first attempt was to load the SurveyMonkey code dynamically in the document’s unload() handler. The problem I had with this was that the library code we used to load javascript dynamically did so by using DOM manipulation to add a <script> node to the document, but as far as I could tell, this was failing because at the time of the unload(), there is no document any more. (In fact, in Firefox at least, the next page had already been rendered by the time it hit my breakpoints.)

My second attempt was to use AJAX to fetch the SurveyMonkey code and then run it via an eval(). This failed because of browser cross-site-scripting restrictions (you can’t use AJAX to talk to a server other than the one that served the current document). It took me a while to remember this; at first I thought that the fact that was returning a 302 redirect was the issue.

My third attempt was a bit of a long shot given the AJAX restriction – try to load the javascript into an iframe and then fetch it via the DOM. Needless to say, that’s not allowed either.

My fourth attempt was to proxy the AJAX request via my server. So, I set up a gateway page on my domain that took the URL as a parameter, fetched it, and then served the contents back to me. This almost worked, but the snafu here was that code uses cookies, and those cookies were being lost in transit. (On reflection, I should also have tried a simple Apache proxy, it would probably do a better job of transparently managing cookies. But even then I’d be surprised if it works.)

My fifth attempt was really disgusting – to temporarily overload before fetching the SurveyMonkey javascript. This worked in Firefox, but not in any other browser I tried (Safari & IE8). Frankly, I was somewhat relieved it didn’t work.

So I finally gave up and fired off a question to the SurveyMonkey support folks to see if there was a way of doing this, e.g. via JSONP or some other API. They got back to me after a few hours, but only to confirm what I already suspected: there is no API.

In the end I implemented my own invitation popup, which was a shame. SurveyMonkey has configuration options to control when the popup appears, e.g. every 100 visits, once per user, etc, which I was obviating by rolling my own. The invitation popup then used SurveyMonkey’s Embed HTML to present the actual survey.

They say in science there’s an inherent bias in that negative results tend not to get published. This is part of my effort to redress the balance!


%d bloggers like this: