blogger tips for web developers

I've been using Blogger since 2001, so I'm pretty familiar with how it works (or doesn't, in some cases). I thought I'd share a few tips for anyone who might be using Blogger for the first time.

initial configuration

There are couple of key things to be aware of when you start:

  • You definitely need to go through [Settings → Formatting] thoroughly.
    • It sets the timezone and timestamp format, for a start.
    • It also lets you set up a "post template", some preset markup to appear when you start a new post.
  • Blogger has two templating systems: the newer "layouts" and the older "classic templates". Layouts are only available if you host on blog*spot, either with a blogspot.com URL or by using a custom domain name. If you host your site on your own server, you cannot use layouts - you can only use templates. Since I host my own sites, all the following instructions relate to templates.
  • The blog design is controlled by one single template (HTML with some "blogger tags"), with conditional code for different page types.
  • Get to know the conditional Blogger tags.
    • They let you change display for the homepage, post pages and archive pages.
    • Note that label index pages (tag pages) get the homepage template.
  • Change or disable the Blogger NavBar in the Template tab.
    • You can choose a suitable colour or turn it off.
    • You can only turn it off if you are hosting on your own site.
  • Some tags only work inside the <blogger></blogger> tags, others work anywhere.

better titles

Blogger's default <title> choices aren't to everyone's taste:

Main/index page
Name of blog
Post/item page
Name of blog: title of post
Archive page
Name of blog: Month YYYY

The homepage isn't really an issue, but for post pages I prefer the post title first and then the blog name. That is, put the most specific information first - it's more readable and better for SEO. I'd prefer to follow that scheme for archive pages too, but the date is only available in the preset format. The best you can do is add the word "archive" to clarify things a bit. This solution is adapted from Blogger Meta Tags:

<mainpage><title><$BlogTitle$></title></mainpage>
<ArchivePage><title><$BlogPageTitle$> Archive</title></ArchivePage>
<itempage><title><blogger><$BlogItemTitle$></blogger> | <$BlogTitle$></title></itempage>

This will produce:

Main/index page
Name of blog
Post/item page
Title of post | Name of blog
Archive page
Name of blog: Month YYYY Archive

You can use the same solution to control the contents of meta tags.

avoid indexing of duplicate content

Blogger's archive pages include the entire post. What that tends to do in Google is return sometimes-bizzare combinations of keywords, or your archive page will rank more highly than the specific relevant post.

I do two things to try to stop this. First, I use rel="bookmark" in links to posts; and I include relevant robots instructions on archive pages:

<ArchivePage><!-- Don't index duplicate content --><meta name="robots" content="noindex,follow" /></ArchivePage>

This seems to work, but YMMV.

control inserted code

Out of the box, Blogger will top and tail your posts with <div style="clear:both;"></div> and <div style="clear:both; padding-bottom:0.25em">. This is primarily to enable float-based positioning of uploaded images, without forcing your average blogger to learn float layouts. For similar reasons, line breaks are converted into <br /> tags.

To disable these settings, go into [Settings → Formatting]. The options are "enable float alignment" and "convert line breaks" respectively. If you disable the line breaks option, note that you will have to add paragraphs yourself. This doesn't bother me as I generally don't use the inline editor to write long posts anyway.

whitespace

Whitespace isn't ideal - Blogger does mess around with it a little. One thing to be aware of is that conditional code will leave whitespace. So if you have three options on three lines, you will always get three lines in your source code. Only the relevant lines will render anything. If this bugs you, put all the options onto one single line.

Also, only the first line of your post body will be indented correctly. All following lines will be flush left. This doesn't happen to comments so I assume the whitespace rules expect one big div or paragraph with break tags. I don't think this one can be fixed.

annoying things you can't change

There are some things I've not yet found a way to change.

  • Tags are called "labels" and are appended to your post in their own paragraph: <p class="blogger-labels">Labels: <a rel='tag' href="URL">tagname</a></p>
  • Label index pages show the full text of every single post. So, if you publish a lot with that label, that page is massive. It needs pagination, or an option for summary view.
  • Line breaks in comments are converted to uppercase breaks - <BR/>
  • Comment attribution comes with a hard-coded icon indicating the commenter's authentication method and their supplied name (or "anonymous") as in this example: <span style="line-height:16px" class="comment-icon anon-comment-icon"><img src="http://www.blogger.com/img/anon16-rounded.gif" alt="Anonymous" style="display:inline;" /></span>&nbsp;<span class="anon-comment-author">Anonymous</span> ... well ok, you can "change" this by using display: none; and inserting your own chosen code. But, the original will still be in the markup.
  • If you upload an image through Blogger's interface, it displays at 400px wide and links to the larger image. Of course, if you want your images to be 400px wide this is a brilliant feature! ;) Personally when this is an issue I just upload images manually, or use Flickr.

If any of those are deal-breakers for you, Blogger might not be the right tool. Personally I've decided I can live with them - although yes, that does mean I had to accept my post pages won't validate when comments have line breaks. That's an annoying validation error, but not one which causes actual problems. So I've decided that yes I can live with it.

a gripe about support

Blogger is massively popular. While that's cool and all, it does mean that the support system is basically designed to avoid tens of thousands of low-expertise users spamming their inbox. It's all done by volume, near as I can tell - you vote for features and you effectively vote on bug priority. It's understandable, but you still feel a bit like you are shouting into a void when you try to send feedback.

conclusion

I've never claimed Blogger is a perfect tool. There are plenty of things I'd change, but overall it's pretty good and you can produce a good quality site - break tags in comments aside :)

In a way, the thing to accept with Blogger is that - like most popular blog tools - it's aimed more at the mass market than professional web development. That does introduce a few limitations, but overall it's still a well-featured tool that's really easy to use.

Labels:

exposing microformat content in the browser

It has been noted, over at the relaunched Webmonkey, that Microformat support seems to have dropped out of Firefox 3.

What has actually happened is that FF3 has an API for microformatted content but no UI to display it. There was a concern about how to alert the user and then how to let them access the data.

The short story is that even with Firefox 3, you'll need to install an add-on like Operator to take advantage of microformats data on the web. The reason the user interface is missing is because, as Kaply says, "there was never any agreement as to how to expose (microformats)".

Mozilla and the Firefox developers variously considered a sidebar or a toolbar, but decided that both would take up too much screen real estate.

Is this really such a difficult question? Why not just display the microformats logo next to the RSS logo in the address bar?

It's extensible - after clicking you would get a list of available microformatted items, just like you get a list of available feeds. It follows an existing paradigm set up by the RSS logo, specifically that the data on screen is available in another format. It takes up a tiny amount of screen real estate.

Opera already adds a logo in this manner when the content is available as a widget:

Opera toolbar showing RSS and Widget icons

It's hardly a stretch to imagine a Microformats icon as well (ignoring the fact that I'm no icon designer :)):

Opera toolbar showing RSS and Widget icons, plus added microformat icon

It feels pretty natural and you're already used to the RSS icon appearing in that location. Obviously there's an upper limit on how many logos you'd want, but that issue applies to the RSS icon too.

The security and maintenance issues of how to process the data do remain, of course. How do you update the processing routines, for instance? But even that seems like a minor issue when you consider how often Firefox updates get pushed out.

Updates seem like even less of an issue when you consider the frequency of new microformats being released - ie. not very often. Seriously, plenty get discussed but the list of actual "specification" grade microformats has barely changed in the past 18 months. In fact, off the top of my head I don't think it actually has changed in the past 18 months.

So, my suggestion to browser makers could be summarised like this:

  • When microformat content is identified in the page, display a microformat icon in the same way the browser displays the RSS icon.
  • Only support those microformats designated "specifications". Or even just support hCard and hCalendar, which are the ones most likely to be useful to the user in a browsing context.
  • When the specs change, include the parsing changes in your next update.

It's just a thought. At any rate, the lack of UI to access the Microformat API in Firefox just means that nothing changes for the time being. People who want to use Microformats use something like the Operator extension. Sometime in future the UI issue will no doubt get resolved one way or another.

Labels: , , ,

new look for the 200ok weblog

After three years, I thought it was about time to launch a new look for this site. Although I liked a lot of features of the old design, it just wasn't hanging together any more.

So I've gone down the path of "realign, not redesign". I've kept the garden theme, but changed the layout around and properly incorporated the stamp. I've made the bookmarks a bit more prominent and dropped the out-of-date linkroll (haven't decided if I'll bring it back later, and if so how/what format). In general, I've just updated it to a fresher look.

A couple of functionality changes...

  • Tags will now go to post index pages instead of Technorati (older posts will slowly get converted to the new system)
  • I've added a combined feed with both the posts and bookmarks. The posts-only feed is still available too, of course.
  • The old "extras" feed will keep working but I'm retiring it from the site (it was never a particularly logical combination of content).

Some quirks do come through from strange hard-coded Blogger restrictions.

  • Tags are called "labels" and they come hard-coded with their own description and paragraph tag.
  • The logo on label index pages doesn't link back to the homepage, because it seems to apply the homepage template.
  • Comments display the authentication method of the user, although I can live with that (show us yer Openid ;)).
  • Pages with multi-paragraph comments won't validate thanks to Blogger's love of uppercase break tags.

So anyway, that's where I'm up to :) Feel free to comment or email with feedback (or you spot any bugs).

Labels: , ,

dragonfly: developer tools for opera

It has become more or less expected that browsers will release developer tools. Firefox really pushed this concept with its developer toolbar and, of course, Firebug.

Opera has been hinting at the release of developer tools for a while; and when dragonfly.opera.com went live, speculation was that we knew what they were going to be called. Well the release date is finally here and yes, Opera has released an alpha of their developer tools - Opera Dragonfly.

Opera Dragonfly

The name was chosen because "dragonflies are highly evolved predators". That is, dragonflies are fast as hell and eat bugs for breakfast :) The name also makes a nice nod to Firebug, which is an undeniable source of inspiration.

features

So what's in the first release? From Opera's official email:

The alpha release includes the initial implementation for the JavaScript Debugger, CSS Inspector, DOM Inspector, Command Line and the Error Console, as well as the Scope module, which allows Opera Dragonfly to communicate with the Opera browser. This will be followed with a second alpha in the coming weeks, which will add inline editing support, improved remote debugging, improved threading in the JavaScript Debugger and infrastructure for localisation. You can read about the current features at <http://www.opera.com/dragonfly/>

One of the key reasons for the alpha release is to collect feedback from developers, to gauge how Opera Dragonfly covers their needs. We will use this feedback to improve Opera Dragonfly as it moves into beta and then full release. Feedback can be given at <http://www.opera.com/products/dragonfly/feedback/>

The Opera Dragonfly team will be maintaining a blog at <http://my.opera.com/dragonfly/blog/> where you can follow the progress of the application.

A really significant feature will be the ability to debug content for devices on your computer - yes, debug mobiles with a real keyboard. That's a pretty cool feature.

reactions

So far common reactions are that people are really looking forward to the inline CSS editing/CSS inspector; and some users report that it's running quite slowly for them. It is an alpha release though, so it's not time to panic about the speed issue.

The first release runs as a separate window from the main browser; which is absolutely brilliant on a dual-monitor machine (like my work machine). However it's not quite so awesome on a single monitor or widescreen; but the single-window mode will take care of that.

Basically, every feature request I've seen so far has been for stuff already listed in the "coming soon" paragraph on the Dragonfly homepage. That's great news, really - the features are clearly well matched to the target audience.

Frankly I'm mostly excited that other developers will now be able to debug in Opera the way they do in Firefox. The lack of a Javascript console and CSS debugger has been a consistent complaint... :) Opera really isn't hard to build for, but the lack of a debugger did make it uncessarily difficult to bugfix existing sites.

notes on trying dragonfly

As it's not been 100% clear - Dragonfly is included in Opera 9.5 Beta 2 release. It's not like Firefox, where you go and find an extension; it's just included in the package. The required code is downloaded when you first run it; and updated automatically after that.

I do recommend you install the beta separately from the currently release; and later when Opera 9.5's official release arrives, you should uninstall the beta and upgrade the stable release. To put it another way, don't install stable releases over the top of beta releases, or vice versa.

Also, when you fire up Dragonfly, note that you need to click on the script you want to inspect; or click into the DOM tab for the CSS inspector. Check out Chris Mills' Introduction to Dragonfly for a full run-through.

No matter how you slice it, Dragonfly is a sweet new tool for web developers; and as more features get rolled in, it's just going to get better.

Labels: , , , , , ,

old power structures, killed in 140 characters

The article you should read today is The Nuclear Option by Mark Pesce.

The MD walked into this meeting believing she held all the cards; in fact, GregoryP is the one with his finger poised over the launch button. With just a word, he could completely ruin her business. This utter transformation in power politics – “hyperconnectivity” leading to hyperempowerment – is another brand new thing. This brand new thing is going to change everything it touches, every institution and every relationship any individual brings to those institutions. Many of those institutions will not survive, because their reputations will not be able to withstand the glare of hyperconnectivity backed by the force of hyperempowerment.

We've always had networks of friends; and news would spread through those networks but it could take days, weeks, months or even years. Information would lose momentum or simply be too far out of date to be useful by the time it got around.

But these days, all of these people can be connected. Information can travel through extended networks faster than ever before - seconds, minutes, hours.

So what? Well, information has long been recognised as power. What's changing right now is who controls information. Anyone with a phone in their pocket can be connected to Twitter all the time. They can tweet for help if they get arrested or they can Twitter about the aftermath of being bullied by a large company's MD.

Where it gets really powerful is those 140 character messages can instantly go to other people who can help you. In Mark Pesce's post, he describes the way the MD's bullying could be globally publicised in minutes... and there's not a thing her old school power base could do to stop it.

The formerly disempowered can now hold the power. Just like that. Because they think it's pretty cool to send messages to friends on Twitter.

Enough from me. Go read Mark's post.

Update: Mark has YouTubed his presentation on the topic...

The Nuclear Option (Part 1 of 2), The Nuclear Option (Part 2 of 2)

Labels: , , ,

about

Web development and standards, as seen by Ben Buchanan.

subscribe

elsewhere

[More bookmarks]

No Clean Feed - Stop Internet Censorship in Australia