Crowdsourcing My Blues Away (Or, The Little Things that Absolutely, Positively Save Your @ss When You’re Building a Website)

The e.politics bunker has reverberated lately with a familiar sound, words like “&%$#,” “*&%$” and “7%$#,” often combined into phrases like this: “you &%$#ing hateful little &%#@ing b*stard piece of &%$#ing @#$%!” I.e., it’s been time to learn a new piece of technology, and few things can bring out the blue language in such great and creative profusion as that process. It must run in the family — I can remember crashing noises coming from the basement 25+ years ago as my father hurled an offending disk drive (then about the size of a toaster) across the room, as was only reasonable at the time. (BTW, Dad’s latest technology project is all the rage in Ghana right now; more on that soon.)

The current fun has involved the combination of a new-to-me Content Management System on the one hand and standards-based design (in practice, Cascading Style Sheets) on the other — two things you’d think would be fairly bullet-proof 15-odd years after the Dawn of the Public Internet. You’d be wrong, of course, since no system run by human beings existing outside of the immediate personal orbit of Barack Obama will function in practice with anything resembling rational efficiency.

I’ve been using Drupal as a CMS, and it’s actually behaved in a much more civilized manner than some of its open-source colleagues have in the past (I’ve also built sites in WordPress and Joomla recently). In fact, many of my initial problems came FROM my experience with other web-publishing methods, since I would often trip myself up with inherited assumptions that kept me from noticing that Drupal employed a more elegant approach and bypassed a common problem entirely. But each CMS inevitably comes with its own internal logic, with quirks often obscure and poorly documented (the downside of distributed software development), and Drupal of course drove me quite mad here and there.

CSS stylesheets also bring their own particular brand of hell, since they’re exceptionally powerful when everything works right — which no doubt has happened on the first try at least once somewhere on this fair, green Earth. In the real world, a combination of inevitable coding errors and the differing behavior of the two major (and several minor) web browsers means that it’s almost always impossible to avoid serious troubleshooting on any complex design. And when you turn me loose with Photoshop and a coupla six-packs, the results can be a true joy to build, I tell ya.

When your work product is a CMS template rather than a static page, too often the biggest problem is simply figuring out what’s causing a problem in the first place. I.e., why is the sidebar showing up on the wrong side of the page, or not at all? Is it because of a definition in the stylesheet? Or is it something in the CMS — often, a simple button pushed or not-pushed. Some problems start out hard and end up easy, but those are all too rare, and the ones that absolutely kill you usually seem trivial at first but end up fatally crippling some key feature of the site.

Small example: in the case of the project I’ve been finishing over the past couple of weeks (to go public shortly), a weird rendering issue that only appeared in Firefox forced me to change the way I was planning to handle the appearance and behavior of the sidebar navigation elements, a fairly major piece of the initial design. But that turned out to be a plus, since I only spent an hour trying to figure out what was wrong (you can waste an afternoon or more digging around in that rabbit hole) before bypassing it entirely with a different approach that actually turned out much better in the end.

Along the way, I went back again and again to the simplest of resources: a straightforward list of CSS elements and the possible values they can have. At first I’d Google it when I needed it, but for the past week or so the page has been open in a window on my desktop most of the time. It’s been absolutely essential, in part because my biggest problem when using CSS is figuring out whether I’ve made what amounts to a typing mistake or have committed a much more fundamental error in logic.

Like any computer-read language, the CSS-HTML combo has very little tolerance for bad grammar. For example, how many times have I used a “:” instead of a “;” and blown the whole thing up — hell, we could write a blues tune about it. Browsers are no more tolerant of lapses in (my) memory when rendering (my) code, and this kind of stuff will make you nuts: in some older versions of HTML you could use “clear=all” to solve a couple of problems, which trips me up when I’m trying to remember the modern conceptual equivalent, “clear:both.” (Exciting, eh? You can see why technologists get ALL the hot chicks).

That reference page didn’t just show the limitations, though — it also showed the possibilities, and several of the visual effects on the site derive from more-obscure CSS features I learned about in passing while trying to figure out why something else had blown up. The element list helped prevent and diagnose more problems than I can remember over the course of this site’s development, which in turn left so much more room for banging my head up against I’d REALLY done wrong — usually, to cause some element on the page to bump uglies with another. When that happens, if you’re lucky it’s caused by a simple bug, but too often it reflects a fundamental problem in the logic of your page layout.

This is not something you want to discover when your deadline is hours away, and that’s where crowdsourcing entirely saved my ass: Thursday afternoon, with a major site milestone due by the end of the next day, certain images in the content section on the front page started behaving badly, appearing in absolutely the wrong place. Of course, it was only in Firefox, only on the front page, and it occurred for reasons that some four or five hours of increasingly stab-in-the-dark experimentation could not turn up. It didn’t help that after a week of intense work on the site I was a little fried out; and with strippers and blow strictly off-limits by doctor’s order, coffee would only take me so far.

But I also couldn’t feel comfortable showing the project to the client with a problem like this unresolved, since who knows how it might look on a different computer or some obscure browser variant — it’s kind of hard to get informed approval when you’re not even sure what the other person is really seeing. Before turning to the shotgun method (i.e., shooting the computer to dispel the offending spirit), I decided to ping a very valuable backstop, an email list of several thousand online communications people of a progressive bent.

Right after lunch Friday, I cast my remaining bread upon the waters and begged for help figuring out what I’d done wrong. When it came, it came fast — within ten minutes, a guy named Paul Kittredge (whom I’ve never met in person that I recall) had not only diagnosed the problem, but I’d fixed it on the development site. Turns out I’d left an extra specification in a couple of secondary elements in a sidebar at some point in the development process, and they’d ended up clashing with the images when I built out the frontpage content section several days later.

I didn’t see the problem in part because I was paying attention to the wrong parts of the code, but the fact that the results showed up only in Firefox clouded things immensely, since the behavior was so weird that I wondered if I’d run afoul of some obscure browser rendering error. In fact, Firefox was actually applying the rules MORE strictly, while Internet Explorer would have let me get away with it entirely, that raging slut. The upshot — help arrived, problem solved, current site iteration approved, and the prospect of a weekend spent entirely AWAY from software and its discontents suddenly real, and welcome.

Thanks go out to friend-of-e.politics Ha-Hoa Hamano, who also sent over a partial solution several critical minutes after Paul (such are the cruelties of the race for technology) and to other folks who made suggestions of greater or lesser applicability. So now, with clients under control and the music bug soundly bitten, let’s see if we can get some writing done around here. For a change.

– cpd