Tuesday, June 26th, 2007

Digg’s new comment system and jQuery

Category: jQuery, JSON, Showcase

<p>There has been a lot of talk in the Digg community about their new comment system. Joe Stump implemented the new system, and in the process he took out Script.aculo.us, and created a jQuery plugin based solution.

By far the most complex portion of the comments system was how dynamic it was going to be. Threads would be zipping in and out, we’d be creating 90% of the HTML dynamically in the DOM from JSON, posting and editing over AJAX, etc. It was during design that Micah and I also plotted to remove script.aculo.us and replace it with the smaller jQuery library. The entire comment system is, in fact, a series of jQuery plugins.

Probably the coolest, technically speaking, portion of the new comments is the manner in which most of the page is created. No longer do we create static HTML in PHP and send you a huge HTML page. Instead we give you the basics and, via AJAX/JSON, we make requests to the API and dynamically create the DOM using the FlyDOM jQuery plugin. The FlyDOM JSON templates are a stroke of genius if you’re looking at loading JSON dynamically into the DOM. The advantage of this is that initial page loads are much snappier and you can load the threads you wish to read on demand.

There are a lot of comments on whether this is actually better, with shots like “use innerHTML instead” and “now if I have JS turned off I am on of luck”.

Related Content:

Posted by Dion Almaer at 7:33 am
25 Comments

+++--
3.7 rating from 95 votes

25 Comments »

Comments feed TrackBack URI

I’m wondering what type of heirarchy method they used. All I’ve read about so far is how much people dislike their new system, mainly from a usability standpoint: js disabled it won’t work; need to click to see the threads (if reddit can do it, why not you? :P).

Why is it that the first thing that came to mind was MPTT (nested sets) or even using simple heirarchy system for multiple threaded levels where there’s an order and there’s a depth on each reply.

Frankly, I think it’s terrible that the Digg team still hasn’t got their act together and made a manageable comment system. For example, with the two above systems, all replies at all levels can be fetched in one query.

Otherwise, props on using jQuery.

Comment by Peter Goodman — June 26, 2007

The new implementation is nice technically speaking, I suppose. But if I actually care about the comments I end up clicking the ‘all comments’ link and bypassing all of that. Take it as a blessing in disguise. Most of the digg comments kinda sucked anyway.

Comment by rick — June 26, 2007

Take it as a blessing in disguise. Most of the digg comments kinda sucked anyway

haha!

Comment by Tobie Langel — June 26, 2007

A technically cool implementation that improved performance but hurt usability.

Comment by Ryan — June 26, 2007

The new system makes the comments kind of useless. The performance is poor, most comments are hidden, and the extra bloat to add this functionality makes it less readable as I’m trying to navigate between the comments and the expand/collapse nodes. I prefer the old system that was simple and compact, although I will say that its nice that the load times are better, but it wasn’t really much of an issue in the first place except for the extremely popular diggs.

Comment by Andy Kant — June 26, 2007

A few replies to a few comments, etc. First you’ll want to check out why we show all replies collapsed to begin with. That was a design decision by our lead designer, Daniel:

http://www.deltatangobravo.com/archives/2007/june/comments

Basically, we tried to balance the wants of our power users (full threading) with the needs of our new, less experienced users (who are confused by threaded commenting systems).

As far as innerHTML goes, this is something we’re looking at, but went with JSON to try and speed up download times. We might investigate innerHTML at some point.

Digg is already fairly useless without JS turned on so we didn’t go out of our way to make everything work without JS (seriously, who’s browsing the internet with JS turned off these days?).

Finally, I’d say it has been a big win as users appear to be using the new comment system as intended. Discussions seem to be cleaner, more on topic and easier to follow.

This all being said, we are working on a few tweaks that should start cropping up sometime soon that should address the majority of everyone’s complaints.

–Joe

Comment by Joe Stump — June 26, 2007

@Joe said:
seriously, who’s browsing the internet with JS turned off these days?

Screen readers? Googlebot?

Comment by Russ — June 26, 2007

I just tried the new system and it doesn’t seem all that bad. The only real drawback is that you can’t browse through the comments like you could before.

I would be interesting to see how many extra requests to the servers you will now get because of people clicking on the ‘view replies’ links and if that ends up hindering performance or not.

I have to agree with Joe on the javascript question. Most people probably don’t even know how to turn off javascript or for that matter what it is to turn it off! OK, Digg’s core user base might, being largely technical but most people don’t.

Comment by Robert — June 26, 2007

I’m sick of people acting like requiring Javascript is the cardinal sin of web design. Sure, it’s an accessibility (and SEO!) concern, but it’s just one of many that you could easily glom on to and obsess over. The fact is, there’s no such thing as flawless web development. I envy the people who have the budget to focus on a hundred minute accessibility details. I believe in accessibility, but in the real world I’ve found any slack in the budget to be taken up by clients’ esoteric requests. Ultimately I’ve found clients are receptive to accessibility issues in a passive way, but they’re really dead-set on whatever bell or whistle they’ve been dreaming of.

More importantly though, the web developers are the engine of change. Why does IE7 fix so many CSS bugs rather than just going off in its own properietary direction? It’s not because of some W3C recommendation, I’ll tell you that. The same thing is starting to happen with Javascript as well. We need the technology, and screen reader developers better figure it out. There’s no reason Javascript can’t mostly work in a screen reader. If we cower in our little box of best practices, we’ll never see any progress.

Comment by Gabe da Silveira — June 26, 2007

Have to agree with Russ … sites need to work without javascript. Maybe not be as awesome, but it still needs to work. That’s why so many people promote graceful degradation of javascript – why else do we go to all these lengths to hook on events onload when we could just embed everything explicitly in the markup?

As for the new comment systems, I can’t say I like them. I think the faulty assumption on DTB is: “When you choose to open a new thread (a conscious choice) it’s also easier to understand how the conversation is structured as you’re choosing pathways intentionally, no matter what you consider your skill level with discussion forums.” This is basing an assumption that any given comment thread on Digg is worth clicking – it’s not. I’ve oftentimes scanned the comments in the past – usually one or two threads are worth following, and the rest are trash (even using the +digg filtering). To ask comment scanners to click threads to ‘discover’ the good ones … that’s no good.

Technically speaking, the implementation seems elegant from an engineering standpoint, but the fact that the comments don’t come in in the initial markup (which I think is a drawback and a usability issue) and the heavy reliance on DOM manipulation (innerHTML, as hacky as it is, is simply faster) makes me really skeptical.

As DBT puts it: “If there was a comment thread with a couple of hundred comments or more, the sheer size of the html download and rendering simply froze your browser for a few seconds or longer as it loaded the page. Yeah, that’s a problem. Totally lame and unacceptable.”

Yeah, now we get our browsers frozen as the whole page’s DOM is loaded into memory. Would you trust IE to display a huge static file or a huge DOM tree? Hmm….

Comment by r — June 26, 2007

I’ve done a similar thing for an intranet portal / dashboard application – a 3 phase loading process:

1) page skeleton structure, (nothing in the main content wrapper)
2) portal widget skeletons (headers, button controls, but nothing in the widget content areas themselves)
3) actual widget content

(think netvibes / igoogle / pageflakes)

It’s just a simple process of making an initial call ondomready to the server for the page skeleton, then in the call completion handler for that, select the child elements by class name (using whatever technique your framework & you prefer), a foreach on all those elements with successive requests to some kind of request dispatcher service, and so on. Add the cname hack to beat the 2 requests per host restriction, and the page loading really flies, instead of the browser locking up while it parses a massive HTML DOM.

This approach to page loading really helps for what ends up being a very complex HTML structure. I’ve found that the delay in rendering is acceptible because you can give visual clues to the user with animated loading indicators along the way that things are being done, plus they can see the page filling out before their eyes.

Comment by Ben — June 26, 2007

@Russ – it’s a common misconception that JavaScript doesn’t apply to screen readers. Screen readers simply sit on top of and communicate with a regular web browser which is generally JavaScript capable.

To re-iterate what one or two other people have said it’s very poor form to code JavaScript functionality with no kind of fallback. No one says it has to be as fully featured as the full JavaScript experience but it should enable core functionality. One should always approach development by building a pure server side implementation first and then progressively enhancing (or overriding) that server side implementation with JavaScript.

If you have functionality that really is only applicable with JavaScript enabled then the interface for that experience should be added with JavaScript rather than hard coded within the HTML. That way with JavaScript off the user won’t encounter interface elements which do nothing.

It’s very hard to estimate how many people don’t have access to a browser without JavaScript support but some heavily controlled corporate environments might be a good example of where one could encounter this.

Comment by Ed Eliot — June 26, 2007

>> It’s very hard to estimate how many people don’t have access to a browser without JavaScript support but some heavily controlled corporate environments might be a good example of where one could encounter this.

should of course have read:

It’s very hard to estimate how many people don’t have access to a browser with JavaScript support but some heavily controlled corporate environments might be a good example of where one could encounter this.

Comment by Ed Eliot — June 26, 2007

No they shouldn’t.

>>One should always approach development by building a pure server side implementation first and then progressively enhancing (or overriding) that server side implementation with JavaScript.

Comment by therandthem — June 26, 2007

testing comments

Comment by Andrew — June 26, 2007

sorry, i barfed my last comment. should be:

why else do you think <a href=”#url_for_action” onclick=”action_for_url();return false;”> is such popular syntax…

Comment by r — June 26, 2007

Yes, some screen readers are Javascript capable (such as JAWS, which I believe sits on top of IE or Firefox – correct me if I’m wrong). But it’s not exactly fully fledged. The screen readers generally try to listen for events such as onclick and refresh their “buffer” of what the content looks like and relay this to the user.

Whilst it is possible to have AJAX-ified apps work in screen readers, their behaviour is generally unpredictable and, even if it “works”, is a usability quagmire for the user.

Whilst some above have argued that not catering for non-Javascript users in web apps is justified (I think it depends on the circumstances), my point was really that Digg is not a web app. It’s an aggregate news site that allows commenting. Possibly a prime example of content that SHOULD be accessible to all by its very nature.

At its core, it’s merely some headings, paragraphs and lists which perfectly describe the content. Whilst the new way of doing things may or may not be justified, not having a “plain” version just seems inconsiderate.

Comment by Russ — June 26, 2007

I think it is a great improvement – as mentioned, most digg comments suck, and page load times on the most popular diggs were getting ridiculous, having 5 or 6 tabs open with the most popular articles would freeze FF for a few seconds, as it was loading a giant page for each…
Now, as far as the implementation goes, it seems quite good, but there should be the option to display all comments by default… (I’m not a digg user, so perhaps there already is?)

Comment by yoink — June 26, 2007

1.) The comment system should fully degrade in all meaningful purposes for Google bot (both pagination and thread permalinks work fine).

2.) I’ve come up with a few ideas for how to make the thread children viewing compatible with non JS enabled browsers.

This all being said, at the end of the day actually participating in the comments system (e.g. posting comments, digging and burying) will continue to require JS due to how we’re structuring our AJAX calls. I might be able to work around this, but it’s low priority right now.

Thanks for everyones thoughtful comments. Much more insightful than some of the other flames … er … criticisms we’ve received.

–Joe

Comment by Joe Stump — June 27, 2007

“It’s very hard to estimate how many people don’t have access to a browser without JavaScript support but some heavily controlled corporate environments might be a good example of where one could encounter this.”

Let the corporate piglings suffer.

Comment by Sam Hill — June 27, 2007

@Ed Eiliot – According to thecounter.com about 4% of people don’t have JavaScript see http://www.thecounter.com/stats/2007/May/javas.php

Comment by Chris O'Brien — June 27, 2007

sgsagsadgs

Comment by Henry — June 28, 2007

Just testing this

Comment by Sunsu — July 11, 2007

i like pie

Comment by i like pie — July 25, 2007

a good system, i like it

Comment by ohr — September 12, 2007

Leave a comment

You must be logged in to post a comment.