Open Letter To Google Blogger Team

Dear Blogger Team,

I'd like to share some of my thoughts about some of the things you've been doing lately and my concerns over the general direction you're heading in.

You've created a great service and I appreciate the effort you've put into both making it freely available and making it better. You understand that there was a serious need to enhance Blogger reader's presentation and have done something really cool with Dynamic Views.

Dynamic Views are a great leap forward. My issue is, it might be too big of a leap and I don't think the current Internet ecosystem is ready for it.

You seem to have favored Dynamic Views rather than making minor yet significant enhancements to the current templating system which is in major need of updates.

Updating the current template system to provide more options to template designers first, and building Dynamic Views on top of it by allowing the new Dynamic Views components to reuse the old Blogger tags would have been a better course IMO.

Below I've tried to explain why I disagree with the current direction and give suggestions on how to improve the current Layout system.

P.S. I think Open Letter are generally odd but there isn't a direct contact email.

Good Templates Are Important

Out of all the blogging systems out there, Blogger seems to have the least active template community even though it is very popular. The templates are for the most part also not as nice.

The reasons I think this is true is because writing templates for Blogger is harder than on other systems and the templating language is very limited. I have written custom templates for Blogger, WordPress, Roller and Joomla among other CMSs.

There are some oddities as well that make it seem like it was written by designers and not for designers. That's not a dig, just an observation.

Things have been improving regarding third party templates but to get templates that are at the same level as other blogging CMS's requires a lot of ugly JavaScript hacks that are against some of the web's best practices.

Javascript Is Not A Substitute For a Good CMS Templating Language

Don't get me wrong, Javascript is great! Being forced to use JavaScript to make templates comparable to other platform templates is not.

There are a lot of drawbacks to using JavaScript to structure content. In addition to alienating users that prefer to leave Javascript support turned off here are the top things that come to mind.

Page Rendering Speed

This is one of my biggest gripes. We all must have some sort of Internet ADD because web surfers tend to leave a page quickly if they don't see what they want. Site performance also has a negative impact on search engine ranking it seems.

Sites on Blogger render slowly compared to other CMSs. One of the contributors is the use of JavaScript in Gadgets. Adding more JavaScript just seems to make things worse.

Blogger seems to deliver the actual page quickly. Checking Webmaster Tools googlebot spends an average of about 500ms downloading pages from Blogger.com. The Site Performance tool shows a page shows pages take over 10s to load. Blogger Buzz takes over 16s to load. Firebug's numbers match this.

Compatibility Issues

Even with common JavaScript libraries, there are issues that popup between different browsers. It's bad enough trying to get the HTML/CSS working right in all popular browsers, adding the complexity of debugging javascript as well seems unnecessary.

Blogs are about content. GWT (which I assume is what you're using) is meant for interactive application type sites. Content sites need to be indexed and found through Search. Application sites are about making a rich user interface.

Search Engine Crawlers

Excessive use of JavaScript is not very search engine friendly.

Even though it seems Googlebot can interpret at least some JavaScript (it's indexed the Google Product forums?), we don't know how much and what other crawlers support it. Can AdSense interpret the content of the site if it's in a Dynamic View? Can other search engines? Other advertiser's contextual and quality crawlers?

There's no real way to test if the code is even compatible with the various crawlers even if they do support JavaScript.

Modifying page elements can also throw up flags for cloaking, excessive ads or whatever else they're trying to determine about a site.

I've read a number of complaints about sites switching to Dynamic Views and losing their search engine traffic which caused them to switch back.

Incompatibility With New Features Like Rich Snippets

Microformats are a great way to help identify structured content and have been becoming more popular.

All the major search engines can display rich snippets in their search results. Search engine robots sophisticated enough to interpret the JavaScript and analyze the generated HTML document instead of the source can identify microformats but there are a couple of problems. Since customization of Dynamic Views is not going to be something everyone will do, adding related tags will be an issue for a lot of people.

The bigger problem is that when new features for search spiders and tools come out, Dynamic View sites may not be compatible. For example, Google's Data Highlighter, which helps teach Google how to understand the structured content on your site, cannot be used with sites using Bloggers Dynamic View templates.

Limited Customization

Instead of providing greater ability to customize the design of blogs, you have limited it.

Even if I wanted to create my own Dynamic View, I couldn't unless I wanted to host the javascript on my own website which defeats one of the benefits of using blogger in the first place.

How JavaScript Should Be Used

I'm not saying give up on JavaScript, or even Dynamic Views for that matter, but I think you're doing it wrong.

You're not just reinventing how blogs are displayed, you're reinventing how blogs are accessed. Blogs are not, and should not be like tweets or web applications. They're content rich sites. Content that should be easily accessed and indexed and searched for.

GWT is for building rich content applications. The Blogger backend interface would be great for GWT. The blog itself, not so much. Heck, even the GWT blog isn't using Dynamic Views.

Take a key from how Slashdot.org is set up. First they put some HTML on the page, then JavaScript is used to enrich how a user interacts with the site as well as to add more content without reloading the page or going to a new one.

This is what Slashdot looks like with (left) and without (right) JavaScript enabled.

This is what Blogger Buzz looked like with and without JavaScript enabled when you first switched it to Dynamic Views.

Nothing, nada, zilch. The only relevant text actually in the HTML is the page title.

Why couldn't the blog be presented in normal HTML and then instead of reading the feed to draw the content, the javascript read the DOM for the initial set of posts or something like that?

Maybe that's why as I'm editing this I noticed Blogger Buzz stopped using dynamic views?

How To Improve Blogger's Templating System

Below I've compiled a list of some of what I consider improvements to the current templating system that would allow greater flexibility in template design.

Google writes a lot of things in Java and the Blogger Layout tags remind me of JSP TagLibs. I've been using the assumption that that's what they are, or similar to, to try and limit the suggestions to things I think would have a great impact yet not be too difficult to implement on the Blogger backend.

Improved Loops

Loops can be a lot more powerful with just a few simple tweaks that shouldn't even impact server performance. With these small changes in place I think I could create static Blogger templates that can rival those of other blogging platforms, even come very close to the look and feel of some Dynamic Views.

Loop Index

Adding a simple index variable can make loops that much more powerful. You can do things like format every other element differently (ie alternating table rows, or reformatting older posts on an index page);

More magazine styled homepages could be developed for example, without resorting to restructuring the HTML on the client with Javascript.

An implicit loop index, such as <b:loop:index/> would be the simplest to use from and end user perspective.

Item Count

Lots of possibilities open up by just being able to know how many elements are being processed in the loop.

Only one element? OK, we'll do this. No Elements? Hmm.. maybe we should put an error.

Maybe something like <b:loop:numItems/> would be nice?

Loop as General Iterator

It would be nice if the loop could be used like the JSTL forEach tag where you can specify a begin and end. Maybe a maxIterations behind the scenes incase someone does something stupid and creates an infinite loop condition.

<b:loop begin="1" end="10">
This is Line Number <b:loop.index/>
</b:loop>

Better Conditional Support

It seems impossible to do AND and OR within the cond attribute of b:if.

It should be possible to write <b:if cond='data:blog.pageType == "item" || data:blog.pageType == "static"'>

Not having this ability causes duplication of code.

Some More Scripting Functions

Would be very nice to have access to common functions available in other languages. Things like common String functions (indexOf, length, substr, etc).

It would be great to be able to split a post up into paragraphs and then insert something like an info box floating to the left after the 3rd paragraph. Or use it to break up long posts into multiple pages.

Ability to search an array like data:post.labels and see if it contains a certain label.

Maybe using Apache Velocity or similar would be a good idea?

Better Post Snippet and Thumbnails

This was a great addition to the template tags but other systems are more flexible. Both post.thumbnailUrl and post.snippet seemed to have been designed with a very limited scope, specifically the Related Posts gadget. It would be a bad design decision to hard code set values for the width and length into these so I'm hoping that exposing those attributes wouldn't be too difficult.

Post Thumbnail Width

I like how you can pull the first image in a post rather than having to define a separate post image as in other blogging systems. Expanding thumbnailUrl so it serves more like a general post image tag would be nice. Overriding the name to imageUrl would be nice so that both thumbnailUrl and imageUrl work for backwards compatability.

Seriously, considering Picassa can already create a cropped square image of any size this should be a no-brainer! It would be great if I could do something like this:

<data:post.imageUrl size="100" />

With the default size left to 72px for backwards compatability.

Better Post Snippet and/or Post Body

Controlling the length of the snippet, as well as selecting to (or not to) preserve line breaks while still stripping HTML would be great!

The added functionality can be added to either post.body or post.snippet. I think it would be less confusing if it was added to post.body, with an override of post.snippet for backwards compatibility. In these examples I'm going to use post.body.

There are two ways you might be implementing snippets on the back-end. Either as a separate data item that is computed whenever a post is published or computed on the fly whenever the field is requested. The following suggestions should be implementable in either case.

Size

It would be nice to control the size of the snippet to allow for it's use in different areas. A default value equal to the current value for snippet should be set with the ability to set a max number of characters, broken on word boundaries.

Preserve HTML

Whether the snippet should preserve the HTML within the post. With this feature, templates can implement what you're doing with jumpTags without the need to actually add jumpTags (&lt!--more-->) to every post. This would be great for people with established blogs that want to update their design..

There should be three options. yes, no, linebreaksonly. Which should be pretty self explanatory.

With preservehtml size becomes a little bit difficult to implement. Might be better to keep post.snippet and post.body separate and preservehtml becomes preserve linebreaks?

In Use

With these features a template can implement something like this:

<b:if cond="data:post.thumbnailUrl">
     <img src="<data:thumbnailUrl size="100" />"<
     <data:post.body maxlength="100" preservehtml="no" />
     <if:else/>
     <data:post.body maxlength="150" preservehtml="no" />
</b:if/>

I don't like the idea of having to escape the html but I'm suggesting a lot of improvements and don't want to make extend expr a priority.

Feed Tag

It would be nice to be able to access a site's feeds from within the template, without having to resort to javascript.

You take a slight processing hit for performing the operations that would normally be done with Javascript but you save by not having to handle additional external connections and bandwidth.

Attributes are feedtype (blog/comment) and label (or Category and tag if that gets implemented). I don't know enough about how feeds are handled behind the scenes but I would like to be able to do something like this:

<b:feed type="default" label="reviews" maxitems="5" >
<b:loop values="feedItems" var="item">
<data:item.title/> <data:item.link/> <data:item.media$thumbnail/> 
</b:feed>

It's more complex than this but this is the general idea.

Widget Display Control

It would be great if you you could have some control over whether a widget is displayed or not based on pageType.

One of the major reasons for this feature has to do with AdSense. They generally don't like ads to display on certain types of pages. There are many other applications for this feature as well such as creating more compelling homepage designs or providing different sidebars for index and item pages.

For each widget there should be these checkbox options:

Display on Homepage
Display on Index (Excluding Homepage)
Display On Search
Display on Archive
Display on Post
Display on Static Page

It might be easier to implement as "Do Not Display..."

Right now, if you wanted to do something similar, you couldn't just wrap the section, or even the widget with those conditional tags as it causes problems in the Layout designer (section isn't shown and it causes error in call to rearrange). You'd have to put the code within widget content and then it disappears if the widget is deleted then added.

Better Pagination

The Older/New Posts links are fine but having pagination features with more control would be nicer.

Something that can display page numbers and actual post titles instead of just "Older" and "Newer"

Variable Improvements

Get Rid of Variables in HTML

This is an easy one I think. Strip out the Variables from <b:skin/> when displaying a page.

They're not standard HTML tags. They're commented out so you can't access them through the DOM. What's the point of them? They just make the page longer which has negative implications for readers and search engines.

Standard Variable Declaration Format

Why two different types of variable declaration formats? One for the page skin, and one for the template skin.

Get rid of the one that looks like the old blogger template format and keep the new taglib looking format. So that it's consistent.

Also

Length Variables Should Be Numeric

In the layout variables for length, I see that the values are appended with 'px'. These values should be numeric and you should be able to perform standard arithmetic operations on them. Or create a new type for numeric.

This would solve a lot of problems with css issues on different browsers. I should be able to just type width: $(main.width - right.width - left.width - 2*default.margin);

Global Variables

I want to be able to declare global variables in the template that can be accessed and manipulated from anywhere. More variable types including boolean would be nice.

Template Validator Should Include Line Numbers

Update: This has been fixed with the new rich text template editor.

This is more of a display bug as saving the template gives line numbers but when you preview a template that isn't well formed, you get an error. It would be very helpful if the error included the line number like you do when you try and save the template.

Categories Not Just Labels

Many other systems include Tags and Categories. Blogger only includes only Labels. Would be nice if Labels could be split up into Tags and categories. Or Labels become Tags and Categories are added.

It makes it a lot easier to organize content and make it easier for users to find.

Current Date Object

Just a little convenience object to be able to place the current date into the template without resorting to JavaScript

<top:date format="YYYY"/>

AdSense Improvements

There are a lot of ways I think the AdSense integration can be improved but I think the biggest one is channel integration.

I believe the AdSense Revenue Sharing API has support for Channels. For each AdSense widget, the user should be able to select an AdSense Channel, including for the ads in posts.

Channels can be overridden/explicitly set in the templates using something like <data:adsense channel="Channel Name"/>

You've made some improvements since I first wrote this. I noticed in some cases you're actually creating Ad Units in the new format that can be tracked better within the new interface.

That's Just The Tip Of The Iceburg

There's more I can probably suggest but I think that's enough for now.

I think I have an idea of where you're going with the new changes but I'm not sure if this is the best way to go about it.

Now let's just hope someone reads this :)