My last post ( Comments! ) has me thinking about a few hard-and-fast laws that I keep in my head when I’m thinking about website design.

I quoted “Nobody Wants To Register For Anything, Ever” like it was a well-defined rule that everybody understands, without really qualifying it. Of course, I assume everybody knows this about the internet, but I thought I might share my too-obvious-to-need-discussing rules, anyways.

Nobody Wants To Register For Anything, Ever

This seems practically given, but you’d be surprised at how loosely people seem to understand this rule. Registration for a site is a pain in the pooper. Nobody wants to do it. The only way to get someone to register a name and user combination for a site is to convince them that there is some tangible benefit.

Landing pages often (and should!) offer big, bright sales-pitches telling everybody about how amazing the product is, why they will love it, and to register now – it’s free! Mint.com understands – setting up a Mint account involves no small amount of effort, so they are sure to prime potential registrants with a big sales pitch to get them through the process.

Some sites offer live demos of their product – Lazy Registration and Anonymous Participation are strong techniques for getting people involved enough in a site that they want to register. Amazon.com knows lazy registration – as users browse their site, they gather data about them, building a shopping cart and a pile of ‘preferences’, and soon users start to see why they might want to register.

Developers have to understand that users must be coerced convinced to register.

The Longer A Registration Takes, The Less Likely Somebody Will Do It

Of course, the easier a registration is, the more likely it is that a user will get across the finish line. For every step, every bit of user data that the developer requests, the user has to take a bit of time waiting, filling out forms, and wondering exactly why JimBob’s Bacon Factory needs his e-mail address and phone number.

Seriously, I am pretty unfriendly towards an as-yet-unused web service or store I’ve signed up for sending me a status update that means nothing to me. Some sort of direct interaction that I would have otherwise missed? (“apike has commented on your blog!”) – welcome. Discount offers and sales? Slightly relevant. Newsletters? Don’t care. And the poor behavior of some web services with my e-mail address makes me less likely to want to give it out again in the future. Yes, as a developer, I know we take down e-mail addresses in order to offer password recovery as a feature. As a user, though, I don’t care enough about my account to _want_ password recovery. Security questions are even worse.

The worst thing in the world – when I go to a site, I want to use a service, they ask me to register, take down my address, e-mail, phone number, zip code, and blood type, and then tell me that I can’t register because I’ve already registered with that e-mail account. I can’t log-in, because I’ve forgotten my password, so now I have to go through whatever convoluted password-retrieval they have set up. I am then assigned a safe, secure password (“x871@@moobs”) by some internal process, one that I would be totally unwilling to memorize on my own, and mention that I can go through the even-more-obscure process of changing it- without even offering a link. I guess I’ll have to learn enough about their system to go into the site preferences. Ultimately, the point of this entire escapade is … to view an article. Way to GO, Linux Magazine, New York Times, or whatever, you have successfully made me utterly unwilling to try to view articles on your website.

Savvy internet users just have a ‘throwaway’ identity that they use for every crappy website registration in the world. One name, one e-mail address, one password, endlessly reusable. Of course, being as different websites have different requirements for passwords (“Your password must be at least 8 characters long, composed of letters and numbers, and cannot start with a dictionary word.”) – a single password doesn’t always work. They think they’re promoting security, but what they are actually promoting is me using a throwaway password (“fuckthisshit99281″), saving their password in GMail (insecure!), and eventually leaving their site and never coming back. What, do they think, I’m going to give them my secure passphrase (or, worse, construct a new one) for their half-assed non-existant “social networking” features? I want security from e-commerce solutions and my student account – from everything else, I just want convenience.

reddit is, in my opinion, the no-contest king of the registration world. reddit offers Anonymous Participation, but it shows the user buttons that he really wants to press. Oh, he wants to press ‘em bad. But when he does, it tells him that in order to participate, he needs to register. The horror! Okay, he’s not going to go to all that trouble just to tell the world that he likes Onion articles. Here’s the thing, though – the registration is all right there in front of him, and it looks so easy – they don’t even need his e-mail address- how could he lose? It’s sales-pitch and quick registration all in a devastatingly effective one-two punch. Sure, sometimes people lose accounts because they don’t remember the password and they didn’t include an e-mail address, but it’s reddit- the stakes are low and re-registration takes 3 seconds.

Bam.

Are we building blog software? A comic publishing engine? A CMS? A forum? A photography site? A tutorial? A wiki? Almost anything we build on the internet is going to want some sort of comment system. As it turns out, comments are hard. In many systems, getting the comments right is the hardest part. Some systems – like phpBB – are just comments all the way down.

So, why are comments hard?

On many sites, the ‘comment’ system is the only way that users can interact with a site. Everything else is just ‘passive viewing’. But with user-facing input comes a bevy of new problems.

Security

We now have to guard against Bobby Tables and XSS injections. XSS injections can be sneaky, too – if, for example, we have failed to set a ‘charset’ encoding for our site, User J can set it for us, and then use the alternate charset to get stuff past our HTML-filtering radar. Bam, all of a sudden we’re serving Scareware.

Spam

A user-facing input is a target for every spammer and SEO greaseball on the face of the earth. Be it through Bayesian filtering (Akismet), turing test (CAPTCHA), moderation, popularity ranking, or voodoo magic, the Spam must be managed.

Hit & Run Comments

Most of the time, on a blog, comments are hit-and-run. User Q leaves a comment and then escapes, never-to-be-seen again.

On more-frequented sites, or sites with a little bit of community, if User Q put enough emotional investment into a comment, he might check back once or twice to see if somebody else has responded. One of the critical indicators of whether User Q will come back to check on his or her comment is whether or not he or she believes that it will be responded to – so a high traffic website will do better than a low traffic one.

There are numerous where User W has commented on my blog, I’ve commented ‘back’, and – I’m sure- User W never returned to see my response. Why would they?

How do we bring User Q back when somebody has commented on his post? Some services (Facebook) send an e-mail, which is frustrating and kludgy, but it works. Some services just assume that they’re awesome enough that we will be back, and when we do, there will be a glowing orange envelope to show us that someone has commented on our comments – but this requires User Registration, which is a whole new can of worms, because nobody, anywhere, wants to register for anything.

Structure

Flat Chronological

On most blogs, and many forums, commenting is Flat Chronological – a single line of comments, top to bottom, in the order that they were posted. Flat Chronological is, easily, the king of the commenting styles – it’s the easiest to implement and the most common. We find it in phpBB, twitter, Wordpress, and just about everything else in the universe.

There are some problems with Flat Chronological, though.

First!

With chronological comments, the first guy to the party (User A!) will always be the first guy you see in the comments. Some people take their hunt to be ‘first’ so seriously that they don’t even care what they type, so long as they’re at the top. So they usually type ‘first’, as if it is an internet badge. Sometimes, they say ‘frist’. They don’t have TIME to correct that bad boy, because nothing’s more embarrassing than having “First!” be the second comment.

Scroll Scroll Scroll Scroll Scroll Post

So, User N has read the article. He wants to comment! He checks the first few comments to see if anybody has said what he wants to say- nope, they all just read “First!”. He immediately scrolls to the very bottom of the 369-comment-pile and makes his voice heard. Of course, User N’s argument has already been made 289 times in the pile. But he don’t care, because who wants to sort through 369 comments?

Nesting

And now, User Y and User G want to have a conversation in the comments. How does User G write his comment so that everybody knows that he’s calling User Y a “fudgecaptain”, and not, say, the original-poster? Well, he has to reference User Y somehow, often by typing “@UserY” – of course, anybody who’s reading the post now must scroll up to UserY’s comment to see what User G was talking about. So, in order to tidy this up, User G must nest a little bit of context into his post – User Y’s comment. Modern forum engines do this so often that there’s a button for it, and the nesting can go pretty deep.

Tree Chronological

So, in order to solve the Nesting problem, every techie out there immediately springs to the first solution that comes to mind. A tree. Now, a tree offers a pretty simple tradeoff. The Good is that it eliminates the nesting problem pretty effectively. The Bad is that it breaks the page’s chronology- it’s hard to tell when a post was made, based on position. Determining what’s new, and deciding where to start and which leaves to follow, can be disorienting. The Ugly is that a conversation now takes place along the X axis instead of the Y axis – and browsers do not handle ‘horizontal’ that well.

So, going full-on Tree Chronological can be sluggish and complicated. A common solution is to have a broad, flat tree containing ‘groups’, which contain ‘categories’, each one containing ‘threads’, which then contain Flat Chronological content. This would be your canonical ‘forum’.

Flat Popularity

Let’s say we ignore the Nesting problem and move right on to the Scroll Scroll Scroll Scroll Post problem – in order to sort comments by importance with a chronological list, we have to read every one of them. That’s just ugly – how do we deal with that?

Well, why not rank the comments by importance? That way, we can tell which are the best comments and just push them right to the top. On top of that, spammers can be punished pretty rapidly, and pushed so far down the rankings that nobody will have to look at them. Popularity, though, is hard.

How do we keep the popularity system from getting gamed? If we just let people Like or Dislike whatever they want, whenever they want, they’ll just upvote themselves until they’re at the top. If we limit the votes to once-per-cookie or once-per-IP… well, most of the people I know can think of trivially easy ways to get around that. So, then, we can just restrict voting to Registered Users – remembering that nobody, anywhere, wants to register for anything. People can still, though, register for 30 or 40 accounts by hand and then use a script to automatically upvote their contributions and downvote the contributions of others. Even if were were to go so far as to CAPTCHA everybody who tries to upvote or downvote something, people could still game the system by forming ‘upvote blocs’ like the legendary Digg power-user bloc – and there’s not a developer out there who thinks a captcha for every upvote is a good idea.

So, you need a pretty advanced algorithm, social or technical, to reduce the percentage of people who can successfully game the system.

Of course, it need not be that advanced if you don’t have a big audience. The level of ’system gaming’ is really more determined by the importance of having a top spot. A top spot at reddit or digg is worth something – it might mean 9000 or 10000 visitors to your site. A top comment at reddit or digg confers temporary bragging rights and permanent-but-meaningless ‘karma points’. A top comment on, say, my blog, wouldn’t even be worth gaming the system for.

Okay, so then, you also need to determine which comments you should push to the top – how do you determine which is the ‘best’ comment? Sorting by average rating is harder than it looks, and the solution is head-splatteringly unpleasant: How Not To Sort By Average Rating – honestly, the upvotes-minus-downvotes system still works fine for me – while it’s not the most accurate, is still my favourite technique. Everybody understands it, at least.

Okay, so, let’s imagine we have a reasonably-secure and reasonably-sensible popularity system for sorting ‘reply quality’. With a ‘flat’ popularity system, we’ve totally broken the ‘chronology’ of the comments – that means, we get single comments that try their very best to shoot to the top, but conversation has died entirely because it’s impossible to determine who spoke first.

Tree Popularity

So, now we have the system of reddit – a reply-tree, with nodes sorted by popularity. We get easily followable nested conversations, and we get sorting-by-importance, both in the same creamy package. This, of course, suffers from the most technical challenges of the bunch – sorting by popularity and making a tree’s “horizontal” conversations readable. It’s still hard to find ‘new’ posts.

Having the popularity on the vertical axis, though, and chronological postings on the horizontal axis, is still a very solid way to organize a discussion. I’ve certainly sunk enough time into reddit’s system.

Alternatively, consider Slashdot – a Tree Chronological that uses popularity to hide unpopular comments and embolden popular comments. I’d argue that Slashdot has the problem where popular comments responding to unpopular ones are shown with no context. (“You’re wrong. The correct answer is: tumbleberries. +5 Insightful! “) – but it’s just another example of the myriad ways that popularity and chronology, trees and ‘flat’ structures are used to form a comment system.

Comment Size

Moving on, let’s consider how much effort people put into individual comments. The size of the text-box and the tools that one gives a user to work with help determine what the comments look like. Consider, again, reddit. The reddit comment box is small, and tools to format comments are in some variant of WikiCreole – minimally accessible. Thus, reddit comments are, on average, very terse. The very-terse comments work well with reddit’s popularity-tree comment structure – some might argue that reddit’s comment structure wouldn’t work with longer comments. “Huge wall of text” reddit conversations, you’ll find, can be very hard to follow; A wall of text with a tree structure, like that, gives you a read that feels like a “Choose Your Own Adventure” book.

On the other hand, StackOverflow is designed to support large, verbose comments. It could be considered mostly a “Flat Popularity” system – while each “Answer” can be commented on, these comments are a second class citizen in the StackOverflow world. The answers, though, they’re big. When a user writes one, he gets a Big Comment Field and Writing Tools.

Reddit is about quick repartee, and Stack Overflow is about blowing your load on a single comment – and you can see it right there in the design of their respective comment systems.

Personalization

One can also look at how much personalization is allowed (or requested) in comments. A site has to be pretty popular to get it’s users to the point where they’re willing to personalize at all – while it might have been popular in the early days of the internet to plaster our mugs on every website that asked for it, this is 2009, and we’re all getting sick and tired of writing down our home city, favourite breakfast, or programming-language-of-choice.

Every System Is Different

Of course, there’s no “one true” comment system – each comment system, each commenting strategy has it’s own pros and cons, and creates a slightly different sense of community. A phpBB forum style, especially one with very many categories, is hopeless for a limited-audience website (say, a blog) – the broad tree and low comment density makes the community feel empty, which means that people will rarely check on their posts, which then means that people will post less often, further lowering the comment density… well, let’s just say that it’s a spiral that ends in an empty forum. The best comment system for a low-traffic site is probably a simple Flat Chronological – it’s easiest to understand, and nobody wants to have to learn a new system for just one site.

On the other hand, some sites – blogs, even- have Flat Chronological comments that get way out of control.

Very-restrictive systems can be good for keeping spam and system abuse under control, but very open systems are more likely to attract people.

Some people like personalization and vast closed systems. For these people, a Facebook. Some people like anonymity, an open system, and massive amounts of tentacle rape porn. For these people, a 4Chan.

Conclusion

So, I’ve taken almost 2000 words to say something that everybody already knows: Comments are hard, and if you’re building a system with comments, you should have a good, solid think about them before you dive in. Maybe you should write a long blog post about them to help clarify your thoughts on the matter.

It didn’t work for me, but you can always try.

Aside: I’m publishing this at 9:45 tomorrow morning, because that seems like blog-post prime time. You’re at work, sippin’ your cup of coffee, you’ve worked your way through your fast distractions, and you’re looking for something to save you from work for another 15-20 minutes.

I have a new job (for those of you who don’t already know) working on this sort of thing.

The tech-team is pretty on-the-ball, too, I don’t feel like I’m the only guy on the team, which is nice.

Communication between coworkers, though, is narrow and seems to be coordinated mostly through the lead-dudes, which means large swathes of code are redundant or work in totally different ways based on the developer who was working on that section at that time.

I’m not making it better – having the sheer audacity to use JSON for AJAX communication instead of the site-standard “big chunks of preformatted HTML” – and refusing to do any HTML manipulation in controller code – means that my code looks totally different from that of my co-workers’. I’d imagine, though, that if all of the code’s not going that way soon, it should be, and I’ll bust heads to make it so.

Here we have the ancient problem faced by developers – do I maintain consistency in the codebase by doing things the-same-wrong-way-as-the-rest-of-the-developers, or try to gradually improve things by refactoring when I encounter code that doesn’t jive with my personal philosophy?

Wherever I work with a codebase, I want to … fix things, so that they work The Right Way. The only problem is that it’s hard to separate things that are actually best practices and things that are just personal preference. Indentation, for example? Personal preference, unless you’re a Python programmer, at which point it becomes oddly important.

Here are a list of “rules” of web coding that I consider to be both valuable and worth fixing code over. I would like to see whether you think they’re worth the refactoring.

• Tables are only good for tabular data, bitches. — Every thousand years or so, you encounter a layout that you just can’t make work in CSS. There are some things that just can’t be done in CSS, and a judicious table can save a developer a lot of pain. A layout, however, composed entirely of tables within tables within tables, I feel, is well outside of the boundaries of what is acceptable for page layout. It’s time to introduce a little more ’semantic’ and a little less ‘presentational’ into the markup.
• No old-school HTML. — The center tag, font tag, and their many brethren have no place in modern web design. Invisible line-breaks and non-breaking-spaces can be used as part of marked-up text, but should never be layout elements.
• No inline styles. — I’m not going to lie – sometimes I’ll toss an inline style into my code, just because I’m too lazy to open the CSS file and the element is a one-off. But seriously, this is hackish, and I admit it.
• AJAX passes JSON or XML only. — I personally prefer JSON, because it’s automatically parsed by most frameworks (or a simple eval statement, if you’re sure it’s not from a malicious source). An AJAX request should never retrieve a chunk of fully-formed HTML.
• GET & POST used correctly. — POSTs are uncacheable and unbookmarkable, and should be used only when a database is modified somehow. GETs are cacheable and bookmarkable, and should be used the rest of the time.
• No HTML or SQL in the Controller— In a Model-View-Controller framework, the Model should be the only entity to see SQL, and the View should be the only entity to see HTML. The controller sits between the two, summoning abstract data from the Model, doing some light decision-making, and then passing ready-to-display data to the View, which surrounds it in that padded layer of HTML.

So, do I rip through table-based layouts and gradually replace them with CSS? Or should I just leave well enough alone? And what about Wanda? Find out next week, on Nerds of our Lives!

So, I recently discovered Yahoo Pipes.

Yahoo Pipes is a staggeringly useful platform for performing various server-side transformations on tree-shaped data. It’s designed to work especially well with RSS feeds, although it works with JSON, as well.

It’s built entirely with a slick (albeit buggy) YUI interface that allows you to link transformations together, piping the output from one into another, in a chain.

The JSON from the site is set up in such a way as to allow JSONP pulls, but its own data-access is server-side, so it’s a quick way to noodle around Javascript’s restrictive-but-secure Same Origin Policy.

I’ve built three pipes so far — a reddit pipe, which pulls all of your most recent links and comments from reddit, and posts them to http://pipes.yahoo.com/lassam/reddit

A twitter pipe, which pulls all of your recent twitter posts from your Twitter RSS feed, available at http://pipes.yahoo.com/lassam/twitter

And a #sfucsss pipe, which uses my PieRC IRC logger, from http://curtis.lassam.net/pierc/, to pull a feed of the most recent things you have said on the IRC channel #sfucsss on irc.freenode.net, available at http://pipes.yahoo.com/lassam/sfucsss.

Then, I piped all of these things together, to create the “Social Megapipe” — ( http://pipes.yahoo.com/lassam/social_megapipe ) and am now using is as an all-purpose social-tracking widget thang (see ‘twitter++’ on my sidebar) – and it can be targeted on people who use reddit, twitter, and #sfucsss. Like Allen, or Dan.

After processing, these pipes can be consumed as RSS data, JSON data, as a site widget, or in a number of other useful formats.

“Design & Typography” articles cover a topic near and dear to my heart: Making things look pretty.

I’ve been playing around with the new font-embedding features in Firefox and Webkit recently, just out of curiosity — and I’ve discovered once again that I am absolutely in hate with Microsoft’s font rendering.

Despite, say, Jeff Atwood’s impassioned preference for Cleartype, when I’m displaying an OpenType font in Windows, it looks bad. Ugly. Fugly. I suspect that this is because the fonts were designed for print, not for display on a monitor, so when Windows’s font renderer ham-handedly tries to cram them into a pixel grid, the end result ends up being uglier than a bad analogy. I’d also guess that font-hinting at low resolutions is only peripherally included in nicer print fonts. In order to make any embedded fonts look even remotely okay in Windows, I had to increase the size of all website text by 110% — which I actually prefer, for readability’s sake, so long as none of my website users like to browse the page on ancient, tiny screens.

On the Macbook, the fonts look pristine, pure, and proper, comparatively.

One of the longest-to-load elements of my page is the external call to Twitter. That wouldn’t be a problem, except the Javascript UI elements running the left-side of the page wait for the site to load completely before they kick in- so new visitors get a few seconds of ugly UI-less page while waiting for the Twitter feed to load, then the whole thing folds up into a tidy accordion.

Hum.

I might have posted this before, but for developers looking for a shorn-down Firebug equivalent for Webkit/Safari, you can enter the following snippet into your Mac’s Terminal:

defaults write com.apple.Safari WebKitDeveloperExtras -bool true

This will give you the ability to “Inspect Element”, which is very, very useful. It brings up the Mac Web Developer Console, a sort of useful multi-tool for the web. In fact, after the appearance of the ubiquitous and incredibly useful FireBug, it would seem that most of the major browsers are going the way of integrated web-development tool modules. Nice!

FireBug

I’m not going to lie — FireBug completely changed the way that I write markup. Instead of laboriously fiddling with a CSS value and refreshing repeatedly (How does 74px look? How does 80px look? ), I just toss in a nonsense value, then inspect the element I’m working with in FireBug. From there, I can select any of the values that I want to play with, and hold the up/down keys to watch that value change in real-time. You can also add new CSS properties on the fly to see how they change the page. Useful!

The Safari Web Developer Console allows you to inspect elements and change CSS, but you can’t slide elements. Which is okay, I guess. I mean, every product works a little bit differently.

Size

The Safari Console *also* allows you to determine the full download size of a page of your website. Notably, this website’s index page, pictures and all, occupies less than 100kb of space — but Javascript plugins (jQuery, jQuery UI, and the plugin for code rendering) and sIFR eat up another 400kb of space, making the whole site a bit of a pig. Alternatively, I’ve written full-on Wordpress sites that pack tidily into less than 70kb. Google’s front-page clocks in at a svelte 36kb, and Yahoo’s front-page a beefy 1Mb.

Notably, this functionality exists in FireBug, but it’s not nearly as pretty or intuitive, so I never really played around with it.

In fact, the Safari Console has a few features that could be really helpful for someone pulling a page to bits. It lists all of the images used on the page, where they come from, and their size and dimensions. It also lists all of the stylesheets and javascript elements loaded on a page. Actually, looking at my site, one of the reasons that it’s so big is that the JavaScript Code Highlighter that I’m using depends on a number of ‘brush’ files (one for each language family being highlighted), each with a very large, identical copyright notice. I bet trimming that down could cut a couple kilobytes from this site’s hefty frame.

JavaScript

When I started programming in Javascript, I found also that FireBug logs Javascript errors in a tidy format that makes it painfully clear what’s gone wrong with the page. As well, you can toss a console.log( “foo” ) statement in your page, to print output directly to the FireBug console. For debugging, this is like sex cheese.

Notably, this also fills me with frustration whenever a jQuery library module starts throwing an obscure error. Am I doing something wrong?

The Safari Console seems also to have a console for logging. I haven’t really fiddled with it. For that sort of work, I’m almost guaranteed to go to FireBug unless it’s a Safari-specific error.

Okay, Windows, You’re Up To Bat

So, Safari and Firefox both have robust developer console systems, albeit each one with strengths and weaknesses. What does Internet Explorer have?

crickets

tumbleweed

Actually, you’d be surprised. Internet Explorer is home to a small set of development tools as well, for those developers in the unfortunate circumstance of having to develop for it as a primary. I haven’t tried any of them, and they seem to be quite the mishmash of miscellany, but it’s good to know that the tools exist.

And The Rest

Google Chrome has a very rudimentary set of built-in developer tools, although it’s so small as to be nearly meaningless &mdash you can’t even change CSS on the fly.

That just leaves Opera, and, while it was an empty field for a while, they’re currently working on Dragonfly, a yet-another-developer-console, for Opera. Considering, however, Opera’s much-greater-pull in the mobile world, they’re integrating a host of tools that work with assorted mobiles. It’s still in ‘alpha’, though, so the software might not be as rock solid as one might hope.