Commenting On Big Blogs Feels Worthless

Most articles you read about improving your visibility online will point out the importance of regularly commenting on other blogs. It demonstrates that you’re adding value to the online community, it brings people back to your blog, and generally creates a good impression.

All of that’s true for small to medium sized blogs. I’m sure I’m the same as most, I feel great when people take the time to comment on my posts. I’ll make an effort to check out their blog if they have one, try to engage with them in return. I can do this because my comments come in small enough numbers that I can effectively respond to all of them.

That impact doesn’t seem to apply to larger blogs though. If a single article picks up a lot of comments in a short period of time, is the writer going to feel the same need to engage? Probably not. Even if they are going to make that time to engage, new readers don’t know that and may be discouraged from adding to a huge comment thread.

No Benefit Means No Motivation

I rarely comment “just because”. I’ll comment on a blog because I want the writer to know how much I appreciated their post. Or I’ll comment on a blog because I want to disagree with a point or engage in discussion.

If the article has lots of comments then I feel that the impact of anything I write in praise of the writer is going to be reduced. I’ll also feel that any points I made in criticism or in discussion are likely to be overlooked. Whether that’s true or not, if I feel that my comments provide no benefit either to the blog writer, myself or the general discussion, it’s natural to be less motivated to take the time to comment.

Just Say It

I write a lot about trusting your hunches when it comes to design, and going with gut instinct when it comes to design. Same applies for commenting on big blogs. If you have something to say, then say it. Don’t let yourself be demotivated because you think your comment will get lost in the crowd.

I used ProBlogger as an example because it’s a good demonstration of how feelings can be misleading. I’ve added comments to threads at ProBlogger even if 100 or more people had contributed before me. Those comments have still, sometimes, had an impact. Darren Rowse has responded to them, people have linked back to my site from them.

More surprisingly, those comments have had the same kind of impact as when I’ve been in the first two or three comments on articles in blogs of similar size (ProBlogger or otherwise).  If there are a lot of comments then people reading them are likely engaged in the conversation. Less people might read your individual comment than if you were first or second to respond, but more of those people are likely to be engaged with what you wrote.

Why The Hell Do You Have A Commenting Strategy Anyway?

If you’re just commenting to bring in traffic to your own site, then what’s the point. Even if you’re making sure to avoid just writing “great post”, you’re still only commenting for your own ends. You’re only really going to engage if you comment because you want to.

A commenting “strategy” should be no more than two things; find good blogs that post interesting articles, and make some time each day to read and comment. Don’t target specific blogs as “must comment”, don’t stop commenting on a blog because it doesn’t give you any traffic benefit.

Your comment is your own, and your contribution is unique. That doesn’t change whether you’re the only person commenting on a blog, or you’re the thousandth person to write something. If the article made you think of a comment, write it.

There’s a very narrow view of web accessibility, and it’s a view that caters to a tiny percentage of internet users. Rather than taking a holistic approach to the topic, both designers and clients overemphasize a checklist of supposed accessibility features. They should instead be focusing on a wider view of accessibility.

What Percentage Of Visitors Do You Support?

Everyone wants to stop support of Internet Explorer 6. If the number of IE6 users on a website drops below 10%, perhaps that’s time to stop support. Maybe it’s 5%, maybe it’s as low as 1%.

Those who require a screen reader, or closed captioning, or manual assistance to use most websites are probably less than 1% of general visitors. I’d guess they’re *certainly* less than 5%. If those were users of a specific browser we’d be talking about abandoning support. So why do we bend over backwards to support such a tiny proportion of these users?

Sometimes You Need To Support

I’ve worked for public sector clients, and they have a legal requirement to ensure their websites are fully accessible to the visually, physically or hearing impaired. There’s obvious reasons for that, they’re providing a public service that needs to be available to all. In some countries private companies need to ensure their sites are similarly accessible. Of course if you have a legal requirement to ensure this type of accessibility, then you need to fulfil that.

Sometimes You Don’t

I don’t really care that much if my website is accessible to the visually impaired, or the physically disabled. I write clean and valid code, but largely because it’s good practice to do so and, once you get in the habit, easier than hacking. I’m not going to exert specific effort on an audience that’s irrelevant to me.

I don’t feel a moral duty to provide this kind of accessibility for my own site. I provide it insofar as it matches my general design and coding practice, but that’s it. I wouldn’t support users of a specific browser if they made up a tiny percentage of my audience and required special effort. Exactly the same applies to any other group of users.

“Accessibility” Doesn’t Mean Accessibility

There’s a big difference between the narrow definition of accessible and the wider meaning of the word. It’s very possible to make a site that checks all the relevant boxes of web accessibility guidelines, and still be ugly and difficult to use. It’s more than possible, in fact, it’s pretty much the norm for public sector websites around the world. They’re a living demonstration of why checking off items on a list is no substitute for making a site widely accessible and usable.

I want websites to be *usable*. Usable is a more important definition than the narrow list of what makes a site “accessible”. That incorporates clean code and validation of semantic markup, so it covers most of the bases of “accessibility”, but it’s not the main focus. Usability is about making a website design easy for the most people possible. “Accessibility” is all too often about making a site equally unfriendly for all.

A pain for designers

We web designers are always talking about the difficulties of designing web sites that will be compatible across various browsers. And new version of the likes of Firefox, Safari and Opera always trumpet about how they so closely adhere to standards. Usually they direct you to look at how well their browsers deal with the Acid test, as a demonstration of how good their product is.

From a purely design point of view, in terms of rendering CSS correctly, the biggest advantage of web standards is that it means that designs will be rendered consistently. And for a long time we’ve never had that. Regardless of how great a browser was supposed to be, there was always some glitch or other.

Even the supposed standards compliant browsers couldn’t render pages consistently. I know, there’s been numerous times where a page that looks fine on Firefox has layout disasters on Opera or Safari, or where Firefox has failed to deal effectively with mouseover menus. And of course Internet Explorer 6 has been a law unto itself, and Internet Explorer 7 still behaving unusually from time to time.

While being the most criticised for lack of standards compliance, as a designer I’ve always been aware that glitches in Internet Explorer are easier to fix (‘Be Realistic, Be Like Internet Explorer’). Unlike the other browsers, you can specify conditional stylesheets for IE – stylesheets that only load if a particular version of IE is being used. My biggest problems have always been tracking down CSS hacks that deal with inconsistencies between Firefox, Safari and Opera. They seemed to exist in some kind of idealised world – where they didn’t need to have conditional stylesheets because, hey, they were all compliant so there wouldn’t be any problems! Some hope.

But then one day everything pretty much worked

The last couple of weeks I’ve been working on a relatively complex site design. I tend to work initially previewing the site in Safari, as the browser that most accurately renders the CSS to what it’s supposed to look like. I usually get a reasonable way into a design before I start looking at cross browser issues and tracking down fixes.

So earlier this week I decided to check out how it was rendering in the latest versions of the other browsers. I was very aware that with the addition of Chrome, there’s another browser that has to be addressed in terms of compatibility.

Across the latest versions of Firefox, Opera, Safari and Chrome, there was one single glitch based on my initial CSS. That was a Chrome issue related to margins and a fixed footer, and was solved in the main CSS file without any hacks (i.e. the solution fixed the Chrome issue but was relevant and harmless to all the other browsers). 

Internet Explorer, both versions 6 and 7, still have problems of course. But I know that I can fix them without having to hack the main CSS documents. They at least have a practical solution to a known problem with the conditional stylesheets. And with Internet Explorer 8 looking to genuinely be compliant and consistent, one day (although it will be years away given how many people still use the antiquated IE6) the problems might be eliminated altogether.

Be idealistic when it’s practical

Non-Microsoft browsers used to piss me off as a web designer. Internet Explorer always had problems and an obvious and reasonably elegant solution. Firefox, Safari, Opera etc were like the worst kind of idealist – they wouldn’t address practical problems because those problems weren’t supposed to exist. The fact that they did exist was conveniently glossed over. And so a designer had to find arcane hacks to CSS code to make it work properly.

Now, perhaps, we’ve finally reached a stage where those problems are ending. Where I can design with one browser and be genuinely confident that it will render the same in the others – or at the very least it will only glitch in Internet Explorer allowing me an easy fix. Long may it continue.

• Apple Safari
• Google Chrome
• Microsoft Internet Explorer
• Mozilla Firefox

I’ve seen a lot of powerful recommendations for Firefox 3 over the last few weeks. I’ve been using it in beta version for a good while now. Firefox’s extended functionality and web developer specific add-ons make it invaluable. And as a designer I test my sites on Internet Explorer 6, 7, Firefox, Safari and Opera. There’s always glitches.

Inconsistency is the rule, not the exception

There are certain design inconsistencies between Firefox versions 2 and 3. Just as there are slight inconsistencies with Safari and with Opera. None of them are major, none of them have a significant impact on functionality and usability. But they do impact aesthetics – important to me as a designer – and they are irritating.

Take a look at a site I recently designed – www.cannon-on-sports.com. Particularly, look at the spacing directly above the search bar in the right hand column. The search bar is stored within a div called #search, and the top margin of that div is set as 20 pixels.

That works fine in Firefox 2 and in Safari 3. In Internet Explorer 6 and 7, Firefox 3 and Opera there are issues. There’s a double counting of the margin that I can’t track down in the CSS. But here’s the crux. I can fix that easily in Internet Explorer.

Microsoft causes the problems, but they help me solve them

I can do that because Internet Explorer allows me to use conditional comments to load new CSS. I can target stylesheets that are only loaded for Internet Explorer, either universally or for specific versions.

Conditional stylesheets are often highlighted when pointing out the flaws in Internet Explorer’s CSS support. And there are definitely many flaws. In an ideal world there wouldn’t be any need for conditional stylesheets. But it’s not an ideal world. There remain standards inconsistencies not only between different browsers but between different versions of the same standards.

You always find little glitches when you’re putting together a CSS page. When those glitches exist in Internet Explorer I know that I can solve them. There are many times I’ve wished that other browsers provided for conditional stylesheets.

I’d like my support to be realistic, not idealistic

I’m not claiming that there are no flaws in my CSS coding. Nor that any particular browser is better than another in its CSS support. The point here is that there are continuing inconsistencies. For all its flaws – and in pure standards support Internet Explorer is severely flawed – Microsoft appear to have acknowledged that and give me as a designer a way to easily target their browser.

Others browsers may be purer. They may be objectively better in dealing with CSS. But as a designer, aiming to give a strong experience to all browser users, they could do more to help me.

Accessibility is about far more than just fulfilling the standard W3C guidelines. I’ve talked in the past about the importance of usability of the web, and the common failures of websites to provide that usability.

Basic guideline failures

The W3C guidelines may be flawed, but they are still a useful guide. And it’s clear that social network sites fail these most basic tests of accessibility. As a simple test I took a look at the results for the home pages of some popular social networking sites on W3C’s validator:

• Facebook fails validation with 66 errors.
• Digg fails validation with 79 errors.
• Myspace fails validation with 149 errors. It also makes use of tables for layout, even within a largely div based structure.
• Twitter fails validation with 11 errors – despite the simplicity of the home page for a new user.

Now I’m aware that the dynamic nature of these sites can make validation more difficult to achieve. But we’re looking at very significant failures, not just a few errors. Correct and validated code is important for providing the most usable experience for site visitors regardless of the way they access a site, and these major portals all fail badly.

Reliance on CAPTCHA

Many social networking sites make extensive use of CAPTCHA. That’s the little image of text that you’re asked to enter to prove that you’re human, if you’re submitting content to a site. It exists to protect against being spammed by robots, which is a fine aim, but it blocks sites to people who access through non traditional methods.

Purely from the visual point of view, CAPTCHA can be confusing. Even I make mistakes in entering CAPTCHA information about 10% of the time. Imagine how much more difficult it can be for people who have poor vision.

CAPTCHA usually offers an audio alternative, but that doesn’t always help. It requires a user to have a soundcard, and for the recording to be clear and audible. It also doesn’t take into account users who have both visual and hearing impairment. A tiny proportion of users to be sure, but the users who genuinely need support.

And generally CAPTCHA reduces usability. Anything that adds a level of complexity to the navigation of a site has a negative impact on general usability.

Do they care to improve?

I think it’s unlikely that these accessibility issues are a major issue for the social networking sites. They have millions of visitors and a high media profile. But they should care more – accessibility and usability go hand in hand. Even if these sites aren’t under the same legal restrictions and expectations as many corporate or public sector sites, to be accessible to the widest possible audience, I think there is a moral responsibility also.

And even without any moral responsibility, there’s a practical benefit. The more usable the site is, the wider the potential audience. Working on overall accessibility  makes physically impaired visitors potential users/consumers. And having focused on the unfamiliarity many web users have with the internet in general, usability and accessibility simply makes good business sense. The more people who feel comfortable with a site the better.