david mosher

personal and semi-professional opinions of a web designer and developer living in saskatoon, sk, canada

Front End Web Debugging Techniques : Isolation

I must be getting older. My idea of "fun" on a Friday night is to go downstairs and write a blog post with some of the ideas that have been percolating in my brain for the last few months. I am disappoint. Oh well, my impending senility is your benefit! That is of course if you're into front end web development at all.

So, I've been talking with a few friends lately about this idea of "good habits" with regards to front end web development and I started stewing on a bunch of ideas on how I could write about something like that in an effective way. Sorry to say that this blog post will not be about good habits relating to code but rather as they relate to debugging front end code. I think the latter is valuable and you'll still get a decent idea of some good habits to work with going forward. Enough rambling, onward!

Isolation, Your First Stop

You've just fired up your browser and checked out an existing application from your repository of choice. You get the app running and go to take a look at the state of the front end because you have a bug to fix. A nice shiny red bug sitting there in front of you. Eager to dig in you open Firebug / Webkit Inspector and find yourself looking at no less than 50 separate CSS files and 40 javascript files. YIKES!

The bug card you have says some buttons aren't appearing properly in IE7 and the latest Chrome. So you dive in with your front end tweaker and start disabling styles dynamically hoping you can affect some change in the cascade that will fix the bug live in the browser right there in front of you. Bam! Looks good in Firefox/Chrome and then you open IE and things go to hell. Sound familiar?

It's at this point that you should really stop what you're doing and try to isolate the problem. I've spent more than enough time hacking in this way to know that it's a lost cause and infinitely frustrating to boot. The best way to fix a rendering issue in a case like this is to isolate your problem so you can control the number of variables you are testing.

Here's how I like to break down my isolation debugging process:

1. Create a Test Case

Open a new html file in Textmate or your favorite code editor and create a brand new HTML page. I like to keep a skeleton page so I can do this quickly. This page should have no stylesheets or scripts loaded.

2. Replicate the Environment

Bring the HTML in question into your sample page as it appears in your production code. Also bring only the CSS that applies to those elements and put them in a style block in the head of your sample page.

3. Verify

You probably have some assumptions about what you think the problem is, this is the step where you verify that. Open your sample page in the browsers you want to test in and see what kind of results you get. The goal here is to eliminate the thousands of lines of other CSS and JavaScript that might be altering the way your markup is displayed.
(download)

4. Refactor

Once you've verified things are behaving the way you want you should probably refactor that HTML and CSS to contain less presentation in your markup. Often markup from legacy applications has been touched by many different people with varying interpretations about how to write HTML; that's ok but given you spent the time to isolate this problem you may as well do some cleanup.

5. Verify ... Again

You've made changes, run your test page through the browsers you are testing for again. Repeat step 4 and 5 until you've got a good baseline to work with. It's also good to remember the answer to http://dowebsitesneedtolookexactlythesameineverybrowser.com at this point. :)

6. Integrate

You were able to eliminate a bunch of redundant CSS selectors and redundant markup. Great! Now it's time to inject your newly refactored code back into the mess of 50 CSS and 40 javascript files. This can be challenging based on how many dependencies you touched in your refactoring but at least you have a baseline of what to expect now.

Integration is going to result in some more rendering anomalies but now you have a core set of solid CSS/HTML that you know will work. What you do now is go through Firebug/Webkit Inspector and start disabling styles in the cascade that also affect your elements until you get the result you are looking for.

Conclusions

You will probably still have to fiddle but at least you will have eliminated a significant amount of frustration by isolating the problem and proving out your assumptions about how the markup and css will behave in other browsers. Of course you could avoid a significant amount of this cross browser troubleshooting by using something like Compass and SASS, but that's a topic for another blog post ;)

I hope this was helpful to you and I wish you luck on improving your front end debugging process and reducing the amount of frustration experienced.

3rd Party Comment System Roundup

We've all seen it. The classic tutorial on [insert popular web framework here] that has us building a blogging system in twenty minutes or less. It's actually getting kind of old and I'm growing sick of seeing what I'm able to create with only platform x,y and z. I'm more interested in how I can use a web framework that doesn't hold my hand by providing a bunch of "one size fits all" defaults. I like flexibility and choice. I like it when the web framework I'm using allows me to mix and match third party systems easily. One third party web framework component that is becoming more popular is commenting systems. Let's take a brief look at three of the most popular systems to see what each offers us.

Intense Debate

Media_httpfarm3static_zwrdw
I first experienced using intense debate when reading a couple blog posts on John W. Longs wise heart design. Created by automattic of wordpress fame, Intense Debate (ID) is a hosted commenting system that utilizes some sexy javascript and social network integration to allow you to add comments to pretty much any page on the Internet. My experience with the sign up process for intense debate was actually pretty frustrating as the log in system didn't seem to recognize my OpenID and you can't create an account for the purposes of installation with anything except OpenID or their hand rolled registration.

I was expecting to be able to sign up using any of the social networks they allow you to sign into their commenting system with. Room for improvement for sure but at least it doesn't affect the actual commenting sign system sign in. On the plus side, once you do get an account created setup is pretty painless and involves pasting some simple javascript into the page that you want to add comments to.

Sample Code

Media_httpfarm5static_kejjk
Media_httpfarm3static_edxfh
How about the user experience when commenting on a site? This is where I really appreciate the power of third party commenting systems, with the value added by extra features I didn't have to code. Things like email notifications when someone replies to a thread, sign in using any of the social networks I'm a part of (ID supports Facebook, Twitter, and Open ID at the time of writing), automated threading, profile linking, upvote/downvote, comment history, and integration with popular blogging platforms like wordpress, blogger (hint hint Posterous, it would be nice if you added this!). 

I was also pleasantly surprised that a tweet about a bug in the email notification system yielded a really fast response from their technical support team. Did I mention it's free?

JS-Kit Echo

Media_httpfarm3static_rbiqf

I haven't used JS-Kit (JSK) on any live blogs but my good buddy Nathan Heagy let me know of it's existence a few months ago and I was intrigued to see what it might offer. Some differences from other systems is that JSK allows you to publish comments from a larger variety of places and broadcast those comments out to more than just the web page the comment thread is embedded on (ie: google friend, yahoo friends and FriendFeed in addition to the regular social networks). JS-Kit also has image uploading, YouTube video embedding, a basic comment formatting interface and lots more. These features are nice, but I don't think they add as much value and here's the kicker: JS-Kit isn't free. They have a 30 day free trial available but after that pricing starts at $12/year but is based on the amount of traffic your site gets.
The code seems easy enough to understand:

Sample Code

Media_httpfarm5static_huuwm
JS-Kit is ok but Intense Debate being free and providing essentially the same core features without all the "bells and whistles" appeals to me much more. YMMV ;)

Disqus

Media_httpfarm3static_vhgyp

The veteran in hosted commenting systems, Disqus has been around for a lot longer than either Intense Debate or JS-Kit and it shows. Disqus offers the most in terms of supported platforms for connecting to and rebroadcasting to as well as the media features that JSK offers (video and image publishing). Setup is slightly more involved; if you want to add things like Facebook Connect and Akismet (for spam protection) you need to provide API keys. Again the code is very easy to inject into any page, static or dynamic.

Sample Code

Media_httpfarm5static_jifnk
Disqus also gives you the power to control the look and feel of the commenting interface right inside their control panel. This is a pretty nice feature for people who aren't so technical that they want to hack away at the CSS manually. The fact that right out of the gate Disqus is free and offers just as much power as JS-Kit and Intense Debate makes it a pretty attractive option.

Conclusion

These are just a few of the options out there if you want to implement a commenting system and don't want to write it yourself. I hope you learned something reading this (I sure did writing it). I made sure to research all the facts as best I could before writing but in case I missed anything please feel free to let me know in the .... commenting system Posterous has built in :]