There are a lot of articles around the place giving generally good advice on how to be a better blogger and get noticed. Alastair Rankine highlights one of the key problems with slavishly following this advice – you become boring:

I was initially attracted to Atwood’s blog for its relatively simple premise and smart delivery. With startling regularity over an extended time he managed to deliver bite-sized morsels relating to the stated domain of programming and human factors. He writes well and generally illustrates his point in a clear and easy to digest style. It’s quite engaging.

…

It seems quite apparent that Jeff Atwood has stepped outside his expertise recently, and that this is something he did comparatively rarely in the past. I haven’t gone groveling through his past posts, but from my recollection I’m pretty sure his hit rate used to be better.

What I think has gone wrong is that Jeff, like most bloggers who go pro, is trying to keep to a regular posting schedule even when he’s too busy to do it well or has nothing good to post about. Regular posting scheduled is a universal recommendation on how to blog lists and it’s got a lot of merit. If you blog more often, you’ll get better at it. The more content on your site the more likely searches will lead people to your site. The more you comment in response to other people’s sites the more likely they’ll notice you and respond, including linking back to you.

The problem is that life and inspiration don’t work on regular schedules, they fluctuate. If you quit your day job just to blog you can probably keep life under control enough to post every day but inspiration still isn’t guaranteed. If you’re trying to start a new company or maintain a day job, your life probably fluctuates so that some weeks or even months you just don’t have time to sit down and write a good blog post. Similarly with inspiration, sometimes you’re doing something so interesting great blog topics just keep popping up and sometimes you’re doing stuff that’s fairly mundane and you don’t have anything too interesting to contribute to the conversations going on in the blogosphere. That’s ok, just don’t post anything for a while or simply point to the interesting stuff that’s going on without comment.

It’s a fairly common process which probably should be named after Robert Scoble since he seems to go through the process over and over again. For most people it’s a one way process where they get stuck being boring, but Robert seems to have turned it into a cycle:

1. Blog based on what you know and are passionate about
2. Become popular
3. Feel an obligation to your audience to blog a certain way or blog regularly. Sometimes this is trying to please everyone, sometimes it’s trying to go pro and others it’s just getting caught up in the hype of being a celebrity.
4. Become boring or lose credibility.
5. Reflect, refocus and go back to blogging about what you’re passionate about.
6. Become popular again…

I think this process is why I read so few blogs from people who make their living from writing/publishing. The interest I have in blogs is to hear from people on the front lines doing the interesting stuff, not the ones that are just writing about it and it’s really hard to be an A-List blogger and get much else done. When I do read full time bloggers it’s usually because they make good filters for the great torrent of information that flows around the internet, allowing me to read the good stuff and skip the rest.

Finally, to provide something constructive, let me point to Planet Intertwingly. Since subscribing to it my list of articles to consider more carefully and/or blog about has started overflowing. Sam Ruby hosts it and it’s full of seriously smart people with a strong tech focus. I’m pretty sure it picks up all the Planet Apache blogs (also good quality), but I take it as a huge compliment that my name appears in that list anyway.

Andy Herron:

Tomorrow  is a day I’ve been looking forward to for quite a few years.  Dylan Just, one of my best mates from uni, is starting at Ephox.  He’s not yet on Planet Ephox but I think we’re fixing that tomorrow morning.

 Indeed that has been fixed. Welcome on board Dylan! Any other Ephox folk who want to start blogging – just let me know!

Some interesting responses to my complaint about feed readers stripping CSS:

• Nick Bradbury – Response: On Stripping Styles For Security
• Sam Ruby - Stripping Styles

There's a common misperception that my complaint was about all styles but in fact I was just referring to inline styles on the basis that they are actually part of the content, not just presentation. Sam Ruby points to a feed from Wikipedia that is exactly the use case I had in mind. Many of the comments however want to strip styles to preserve a uniform look in a "river of news" type of reader, for example Nick's comment:

The real problem isn't security, though: it's presentation (ironically). Leaving styles intact makes sense if you're reading one post at a time, but it makes less sense in a river of news where posts from multiple feeds flow down the page. The purpose of a river of news isn't to retain the presentation of any single post, but instead to provide a common presentation for all posts, making it easy to pick out the ones that interest you.

If you don't download external stylesheets (which probably aren't referenced by the feed anyway) there's a very good chance that the resulting presentation will be consistent, without stripping out important visual information. Even if you're reading one item at a time rather than a river of news, it's far more efficient for the styles to be consistent so I doubt there's any real call for rendering entries the same way they appear on the site. Consistency is important to everyone, but data loss should be a concern for everyone and right now we're losing a lot of data.

Nick also commented that preserving styles while maintaining security isn't too difficult and Sam Ruby and Paul Querna pointed to the sanitization rules wiki page, so the technical challenges seem to be solvable, but there's still one problem: users. The thing is, people too regularly abuse HTML and use inline styles for presentation rather than just visual data either from a lack of understanding or a desire to push their advertising. How do we solve that?

The first line of defense is to remember that feeds are opt-in, if people misbehave and push advertising or generally do annoying things in their feed you can easily unsubscribe. Social pressure is always the best solution but it's not 100% effective so we'll probably need some technical measures as well.

The second line of defense unfortunately is likely to be user preferences1. It's important that they are available on a per-feed level so that you can disable styles in feeds that do the wrong thing, but preserve the visual data in those that get it right. I wonder if there are a few simple heuristics that could be applied. For example stripping any style that's applied to the entire content would fix the common case of people using inline styles to change the font face or size instead of just adjusting their stylesheet. I'm sure there are a few other simple rules that could be identified to prevent the most common abuses of inline styles without having to strip all CSS.

I'm glad there's some discussion of this beginning as it's the only way we'll find good solutions that let us keep the benefits of feeds that we have and expand on them by leveraging newer technologies.

1 – unfortunately because complicating software by providing more options is never ideal↩

I got some really positive feedback on the various community/openness projects that I've been spearheading within Ephox from one of our OEMs today. Apparently they've discovered our early access program and are already trying out our brand new Express Edit functionality1.  It's really nice to actually hear from clients that these elements are useful as we haven't really managed to build up a community, even if we are seeing gradually increasing traffic. For a while now we've had potential new employees commenting on Planet Ephox which is great, but we haven't really heard from clients taking advantage of it, even if we've seen some of the indirect effects via analytics and support cases.

Now getting great feedback from one client is satisfying but it's not the end game – of course we want to impress all our clients like this by whatever means it takes. What I find most exciting about this is that it demonstrates to the sales and marketing teams that our openness and even our engineering practices2 are actually valuable to clients, particularly OEMs where the relationship is more important and long term. The business users and product managers probably don't care about automated tests and early access, but the engineers that have to actually integrate our product do. If we can provide them with tools like the hints and tips on LiveWorks! or early access to new features, they can better integrate our products and get the most out of them for the actual end users. In the end, that's what everyone should be working towards and we can and will help out on multiple levels.

1 – Don't forget to let us know how it goes and how we could improve it btw….↩

2 – continuous integration, TDD and all the other things we do to ensure quality↩

Mindy McAdams gives advice about how students should test their online page designs, the trouble is the statistics she's looking at are lying to her.

You can see that although the screen resolutions larger than 1024 x 768 add up to more people (4,512 vs. 3,524), the single most common resolution in use (among people who read this blog, that is) is 1024 x 768. You can also see that the number of people viewing the site at the old standard, 800 x 600, is quite small.

Conclusion: It is sensible to design this blog to look good at a resolution of 1024 x 768, and to test it at some higher resolutions to make sure it doesn’t become unusable.

This is wrong – just because people have a screen resolution of 1024 x 768 doesn't mean they are using all of it for viewing your web page. Once you get to screens that big it's quite common for people not to maximize the browser window, so the actual page rendering area is much smaller than the screen size would suggest. Additionally, you can't assume that people have the stock standard browser install anymore – there are a huge number of browser toolbars that people wind up with (often preinstalled) that take up screen space, not to mention people who read the blog in a feed reader with a list of feeds down or tabs down the side.

While there might be some merit in tracking your user base and designing to the majority, you need to track the size of the actual page rendering area, not the screen resolution to get any idea about what your users will see. The best approach however is to design a site that scales well from small screens up to larger screens as gracefully as possible.

Moving on to browsers:

Conclusions: Web pages must be tested in at least three browsers: Firefox, IE 6 and IE 7. Pages for this blog should also be tested in Safari, although that may not hold true for all sites (see below).

Seriously, test in Safari – even if only the Windows version. Once you get your pages to work well in Firefox and IE 6, you've done 99% of the work to get it to work pretty much everywhere. While you're there, test in Opera too. Why limit your audience when you've done all the hard work to get the design to work cross browser anyway? Either design for one specific browser to minimize the effort required, or design for all of them – the second browser you support is the expensive one, once you've got that you may as well have them all.

So how should students (and professionals) test their online page designs?

On as many browsers and platforms as they can manage. You never know what configuration your next paying client might have and you want to make sure the site looks great for them or they'll pass you by. Numbers and statistics don't matter – that million dollar client counts as one hit just like the millions of people you don't care about. Don't miss your chance by being lazy.