Over the past few months we’ve moved back and forth between Intense Debate and the default Wordpress comment system for Imulus Insights. Over this time period I’ve had the chance to get a bit more fully involved with Intense Debate’s foundation, plugin, and structure. This process has for the most part been a massive headache. However, I have to admit that if the service weren’t something we felt had potential we wouldn’t have stuck with it. I’m a fan of admitting when something isn’t a good fit and moving to find a different solution. In this case the benefits seemed worth it so we stuck with it and now Intense Debate is fully integrated and styled into our Wordpress install.

That said. I have some criticisms.

Let’s take a brief look at some of Intense Debate’s HTML:

Okay, I’m not going to spend too long on this as I think the image above illustrates pretty well why working with Intense Debate’s DOM structure is a nightmare. Still, I’ll talk about a few of my major annoyances.

Wrapper, wrapper, wrapper, small-wrapper, smaller-wrapper…

First, Intense Debate is filled to the brim with what seem to be uncessary divs, wrappers, classes, and ID’s. For the life of me I just can’t see why they would need five or six wrappers for specific elements. I just don’t think their users really need that much customization potential. If it was my call I would make the trade off between four wrappers with ID’s and Classes for a simpler system that’s easier to work with. Granted, maybe I can’t ajax in every element on-demand but at least the product would be easier to work with.

Names should be used to make things easier, not harder.

Second, the naming convention they use could be a lot more straight forward. Instead of:

#IDSubscribeToThisWrapper

perhaps stick to something a bit simpler:

#idc-subscribe

Document your DOM.

Third, provide better documentation for your developers. I spent a good chunk of time on the Intense Debate CSS documentaiton page, and while the page is a good start to documentaiton, it by no means has the depth of information that is required to “style” each indvidual element of Intense Debate. If you’re going to add ~200 classes and IDs to customize the applicaiton, at least document it so I can see what I’m working with.

I spent some time on the comment customization layout on the Intense Debate site — and while some of the options are nice, it’s not quite enough. For instance, Intense Debate allows you to link to your own CSS file for style customizations. However, they don’t offer any sort of example CSS file if you want to see how they did things to begin with. This… would be a nice thing to have. Granted I can work with a web inspector to see their styles, but it’d be much nicer to have a tangible CSS file that I could go thourgh.

My wish.

I recognize that some of the above criticisms are being done in order to provide their users with the most amount of customization possible. However, I feel that if customization is the end goal Intense Debate should take a different approach all together. Here’s what I suggest:

Give customers two choices.

1. The ability to use your generated HTML in a widget format (like currently exists)
2. A set of Wordpress template tags that can be used to run functions dynamically without generating the HTML

I would have a substantially reduced amount of criticism is I was able to use the Intense Debate service without having to deal with there ridiculously dirty HTML. Template Tags would allow me to pick and choose what portions of the service I want to incorporate, as well as the ability to style things exactly to my liking with my own HTML stucture. No more !important; declarations, no more individualized Intense Debate only stylesheet, just simple, clean, easy to use Wordpress template tags. This is how the majority of plugins currently work for Wordpress and I see no reason that Intense Debate can’t follow that method. And considering they’ve been purchased by Automattic I’m hoping this is in the works.

End Verdict

I have to admit that the comment traction gained from using Intense Debate is worth the sacrifice of dealing with it. However, I hope they realize they have a long way to go to make their service developer friendly.