Oh, how terribly boring this will be to most of you. And on Valentine's Day no less! Then again, my near complete lack of posting in the past, oh, 6 months, means there really is no "most of you" anymore. Pity. Shame on me for squandering the ear of what was once a vibrant and argumentative group of shut-ins.
Anyway, this is a geek-ish post, so be warned. It's not as geek-ish as what Luke's been writing lately, but then I'm not nearly as smart as him. (As him? As he? See what I mean?)
In looking for a good way to conduct polls on our blogs at work, I came across this post by Dan Wolfgang of Eat Drink Sleep Movable Type. Movable Type sadly lacks any kind of built-in polling mechanism, so Dan thought up a clever way to do it.
The basic scheme is to create a separate blog for polls. The possible answers are put into the Extended Entry field, and a PHP template parses that and creates a poll form, assigning each answer a number and using the comments of the post to store the votes. That is, the poll form submits to mt-comments.cgi, which stores the number associated with the selected response. Clever.
It works quite well, though Dan's implementation had some key flaws that prevented us from using it as is.
- Blocking people from voting again by using IP addresses. This is pretty heavy-handed, considering how many people are working on some kind of private network, and share an external IP with tens or hundreds of their coworkers. I didn't want to block an entire company after one person voted.
- Dan's system relies on going to a completely separate page to vote on a poll. Once you've voted, you see the results. Then you have to click back back back to get back to the original post you were reading, assuming you started in a different blog. We wanted our readers to be able to vote right on the page, without leaving.
- Dan's system was effectively limited to 10 response choices by using an array of colors for the results bar, and having no way to start over once the array was exhausted.
- The results display was a bit blocky and huge for our taste.
So, long story short, I fixed it, thusly:
- Used cookies to block re-voting. Possibly easier to circumvent than IP blocking, but on the whole more elegant, in my opinion.
- Stripped down the poll to the bare necessities, and then include a poll the main blog via an iFrame. This allows all the voting to take place inline (see below). Downsides: Sizing the iFrame is a bit of trial and error, depending on how many choices the poll has (have yet to find a reliable way to dynamically size iFrames), and on some browsers, iFrames can exhibit some very strange caching behavior. Doesn't happen often enough to be a great concern, though.
- The color array resets when it gets to the end, allowing unlimited choices.
- Changed some styles to make the results a bit cleaner and slimmer. I would still like to fix this more, allowing more flexibility, but it works well enough for now.
Using an iFrame is of course not necessary, having unadorned polls like these would work nicely in a pop-up window. If you prefer adornment, adorn away.
- More flexible results display, with the background color bar independent from the text. Right now, including more text than the percentage (number of votes for that choice, say) breaks unless the bar is long enough to cover the text. Dan solves this by keeping the text out of the bar, but I like it in.
- Animated results bars. Spiffy.
- A way to have an "other" choice, with a text field to store the response.
- Exercise more, eat better.
That's about it. Most of the basics are exactly as Dan laid out, so all credit to him for working out this system. This just represents some small refinements to suit my needs.
Here's the code, and an example poll.
What do you think?