We’re happy to formally announce the launch of Support Details, our first planned public product. This is one of those ideas which was in the works here at Imulus far longer then need be. In fact the idea was discussed in ’03 and sadly it fell off the radar until this year. Support Details is an attempt to add clarification to browser related issues between non-technical web visitors and their clients & customers.

This idea started as way to save time. To solve odd browser issues our team was always asking the clients questions like:

“What browser are you using?”, “Which version of Flash is installed?”,”Do you have cookies enabled?” “What is your screen size?”

You get the point.

We simply were losing too much time to explaining the “how to” aspect; hence Support Details.

To be useful the product had to determine what browser a customer was using, along with any other configuration data which could be detected. Then, it needed a reliable way for capturing and sending the data over to the person who was working on the problem.

The concept is simple. That is part of the reason we believe it works so well. Yet, we’re always open to good suggestions for improvement and we’re eager to hear your feedback.

For a long time here at Imulus we had trouble keeping track of internal company information. Client datasheets, software licenses, Imulus specific programming tips, bug tracking, email setup documentation, employee calendar links, etc. This problem was not something isolated to just us, every work environment I’ve been a part of has struggled with documenting and finding information. Generally the solution ends up being a massive repository of excel documents or a shared hard drive full of text files and snippets. Neither of these solutions are practical or scalable.

Our answer to this problem was an internal company wiki. Our goal was to have a central resource that was easy to update and easy to get information out of. It needed to be searchable, easy to edit, and secure. Being a .NET shop we decided to go with ScrewTurn a free open source wiki for .NET environments. A few other alternatives are: Wordpress plugins and hosted solutions such as pbwiki.

We’ve been using this solution since last August and it has been a huge time saver. Our project manager no longer gets flooded with requests for, “that spec requirement the client sent over,” and our programmer’s no longer have to use local text files to keep track of bugs in their code.

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.

For years we have always done milestone approvals either by verbal approval or simple email confirmations. When I used to work at Refinery (now G2) we tried doing the legal / contract version of project approvals. I found that method to be cumbersome and difficult to quickly deploy. We’ve decided to try something new and I think it’s worth sharing. We’ve decided to use Wufoo. Using this service we can share pre-developed approval forms which log client acceptance along the development process.

I’ve blogged about Wufoo in the past. I think these guys are one of the most underated Web 2.0 companies out there. Their interfaces a rocking and their shit just works real well. We’ve setup about 14 pre-defined forms, which can be shared with our clients for approvals which take less then 30 seconds to read and submit.

Here is an example.

Here is what we are hoping to achieve with this shift in our process:

Deliberate Action. It’s too easy for a client to just give verbal approval, or reply to an email. Filling out a short form is a deliberate step which requires the user to read before taking action. It falls outside the normal workflow enough to be memorable.

What am I Signing? A short explanation helps the client understand the impact of what they are signing without all the legal mumbo-jumbo of a contract. It’s enough to explain the point and nothing more.

What’s Next? Once signed, what does that actually mean to the client. This is a friendly reminder of the next steps which will be taken on the project along with a statement about what it means to give approval to this task.

Get to Know Us. A quick “Thank you” followed by a “Did you know?” We see this as another opportunity to interact with our clients in a way which helps us better know each other.

I sincerely hope you try using Wufoo to replace the old sign & fax forms of the 80’s. I’d like to hear the results if you do make the switch.

It’s called charging people a monthly fee.

Why are so many web-services scared to charge their user base? Especially when the service kicks ass like Facebook or Twitter. TechCrunch is saying that 1 in 5 people on the web have accessed Facebook. I’m sort of thinking that there is something of value there for that many people have an interest. Why then are these companies still looking for a way to make money when the answer is in their face?

Charge us!

Facebook is struggling with ad supported revenue and Twitter is anyone’s guess. Their customers are asking to be charged and would gladly pony-up some cash if it meant a better service.

Facebook and Twitter set bad examples for start-ups by not charging. It creates the impression that all web-services must be ad-supported. This simply isn’t a good approach to building a long term sustainable service. Locally, I try to attend the monthly Boulder / Denver New Tech Meetup, and I’m continually heartbroken by all the startup founders looking for ways to capture VC funding when they already have a fairly nice service to offer. It’s as if everyone is trying to cash in on building the ‘next big thing’ by growing fast and selling to Google.

I fully understand giving a service away in the beginning in order to draw in the users, but have a clear plan to stop the free services and convert to a paid model. The “try before you buy” model isn’t used enough. Facebook could charge for users who’ve been on their services for over 1 year. Twitter could easily charge by volume of Tweets.

I can already see the comments coming in about how charging will diminish the social / community value of these services. Yet, I would be MORE likely to use these services if I was confident they would be here in the future and not sold off to Google, Yahoo or Microsoft.