Let the corporate piglings suffer.

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

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.

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

>>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.

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.

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.

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.

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….

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.

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.

Screen readers? Googlebot?

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