Fun with Firebug: Error Messages!

When working in the Firebug console, you might have noticed that syntax errors and the like show up in red on executing the command line. Great success! Exceptions thrown by the DOM, however, for some reason don't, so there is no telling whether your document.getElementById() call happily returned undefined or threw an exception on you.

If you go to about:config and type firebug.showChromeErrors into the Filter: field, and double-click that line to read true -- presto! You can suddenly see where you and the DOM disagree, and when you made some XPath syntax error, so you can tell apart cases like $X('//div[@class="post"') and $X('//div[@class="post"]') and the like.

I've filed a ticket on this weird default behaviour, but am glad I finally found this trivial cure. (I really don't want to know how many times I've wrapped a statement on the command line into a try{ ... }catch(e){e} block to figure out just if or what went wrong.)

Unbreak the scrollbar

This is a post on visitor centric design and usability, which first and foremost applies to popular blogs: don't break the native window scrollbar. It's in a way related to the advice don't reinvent native browser scrollbars, and boils down to this short tip:

If visitor comments on your posts or articles add up to more than a single-digit percentage of your page height, don't show them by default.

To get nice order-of-magnitude measures of page sizes, try this bookmarklet which shows how many pagefuls, at present window dimensions, your document fills; drag it to your bookmark toolbar, if you want to measure other pages than the one you are presently reading (visit the post, if you read this by feed reader, as feeds and feed readers try to save you from badness by stripping away potentially harmful bookmarklets).

If you visit some interesting post which does not heed this tip, perhaps Steve Yegge on size being code's worst enemy, or perhaps the sci-fi writer Charles Stross about why space colonization might not be such a great prospect, you might find that it's 300 pagefuls tall. Without its 825 comments, it comes down to about five pages, making visitor commentary a whopping 98% of the document's size, which by a margin breaks the sub-ten-percent bound.

The reason this is bad is that it breaks two important functions of the document / scrollbar symbiosis: first, it prevents a visitor from the size overview offered by the scrollbar size to scrollbar height ratio -- "How long is this document, and how far into it have I scrolled?" -- and second, it prevents you from quickly scrolling to the bottom of the document using browser native "Page end" bindings, as there is no snapping to where the post ends and comments start.

See Joe Hewitt's blog for an excellent example of showing comments only after having clicked the number of comments hidden. (If you hide comments, by default, it's a very good measure to show how many.)

I've whipped up a quick'n'dirty user script to turn a few blogs I frequently frequent into click-to-unfold-comments reading mode, as I care for the author's view first, and reader reaction only second, if at all. I didn't go the extra mile to come up with a good UI for making it extend to any blog you might encounter, but XPath geeks and Hoodwink'd dialers will probably find themselves right at home to extend it for their own reading habits, and perhaps post their own additions to the script homepage. Enjoy!