eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Over the past two weeks, there have been dramatic shifts in the Weblog software landscape. First, Google announced a brand new, “easy-to-use” version of its Blogger Web-based blogging tool last week—the first new version since Google acquired the company in February 2003. SixApart then announced a new licensing scheme for its Movable Type software, creating discord among the blogging community as it moved toward charging high-end users of the latest version of the tool. And then this past Monday, Dave Winer, a Harvard Law School Berkman Center fellow and former head of Weblogging tool vendor UserLand Software, announced that he and the company will open-source license the Frontier scripting and Web server kernel of UserLands Manila and Radio products.
In a wide-ranging conversation with eWEEKs Steve Gillmor, Blogger co-founder and Google Program Manager Evan Williams runs through the changes in the software, the company, and the RSS and ATOM content syndication ecology.
Whats going on with the new Blogger?
To give you a little context, since weve been here at Google the last year or so weve been working mostly on the back-end stuff, building out the infrastructure, working on scalability and viability issues. Weve done a few features, rolled most of the pro features into the free version a while back, and built out the support department.
This is our first major release in terms of user-focused things. It has three major elements: First is an ease-of-use factor, from the design of the home page and the sign-up process to the interface. We did a bunch of user testing and are aiming to appeal to a much wider, less technical audience than blogging has ever reaching before. We feel weve made good strides in that direction.
The second part is building out some of the community aspects. A few of the major features are comments and profiles, both of which help drive the connections between users, which is of course a big motivation for why people are blogging.
And then the third is improving the experience and esthetics of the blogs themselves and the flexibility with what you can do with them. There are the new templates and the new URLs—every post has its own page—and some new flexibility in the templating language.
Templating language?
The templates in Blogger have a very simple templating language [that drives] how to put the content in the page. We added some new tags that extend the language, conditional tags that allow you to show different things on the home page than you show, say, on an archive page. Theyre pretty simple, but they offer a lot more flexibility.
For more collaboration coverage, check out Steve Gillmors Blogosphere.
The templates are built using these new extensions?
The core of the templating language is still the same. All the old templates still work, theres just more flexibility.
Give me an example of some new tags.
Conditional tags are basically like IF statements, but they have a simple syntax. If youre on what we call a post page—a permalink for a post—where its the only post on that page, you might not want to put all the things in your margin, like all your archives or your entire blogroll. Or you might want to put a link back to your home page. It doesnt make sense to have a link back to your home page on your home page. So instead of having a bunch of different templates that might be harder to manage, you use these conditional tags.
Next page: E-mail and the Blogger API.
E
-mail and the API”>
Can you speak to the templating engine via the new mail-in post feature?
No, thats purely for content. The templates can only be modified via the interface or the API.
Are there any differences with the API, or does it still work with the old Blogger API or the metaweblog API?
There are no changes to the API in this release. The Blogger 1.0 API is still supported, and the ATOM API is supported as well, as much as its been developed anyway.
Is there any way to access the API externally from your site and make changes dynamically?
You could. Theres nothing built-in to do that … you mean, be able to edit your post on page or something like that?
Exactly.
Thats possible; youd have to script it yourself. Id love to see people do that.
Would this be a SOAP interface using the ATOM code?
Yes, or the old XML-RPC with the Blogger API.
Next page: Commenting on Comments.
Commenting on Comments
How are comments architected?
Comments are contained on the post page. Theyre published and posted on Blogger.com, and then pushed out to the users blog, whether its on BlogSpot or they host it themselves. Its up to the blog owner whether or not they want to limit the comments to just members of the blog, registered Blogger users, or allow anonymous comments.
In the design of both the comments and profiles, were aiming to connect users more tightly while still giving them their own space—as opposed to some more community-driven sites where there are a lot of inter-user connections but not as much freedom of expression nor outward-facing features such as having your own URL or customizing your own design.
Profiles are essentially simple About Me pages that reside on Blogger.com. Theyre linked from comments on the persons blog and linked from the templates, and then they link out to peoples blogs.
The Blogger.com references are in effect a security model?
Its both security and our architecture in general. All the dynamic stuff is on Blogger.com—all the application stuff, I should say. Blogger always publishes static HTML out to peoples sites. That makes it portable and more compatible; you dont have to install anything. Anytime youre inputting content, you go back to Blogger.com.
Are comments available as a separate RSS feed or are they incorporated into the feeds?
No, comments arent in the feeds yet. Well look at that if it seems that people have figured out a good way to do that. Im not aware that theres a standard way to do that yet.
And ease of use?
On the home page especially, weve made it a lot more obvious what Blogger is and why you might want to do it. The old Blogger home page that we replaced was basically the design weve had since early 2000. Were speaking to a little bit different audience now, and the goal with Google is to push blogging into more of a mainstream Internet user, so we designed more for them.
Next page: Blogger Meets Gmail?
Blogger, Meet Gmail
Youve also been involved somewhat on the Gmail team?
Not heavily involved. Weve been working on this release pretty steadily. We have not [done] much more than just brainstorming.
Where do you see the potential linkages between Gmail and Blogger?
Im not sure. Its not something either team has had a lot of time to think about, since weve both been pretty heads-down on these releases. Ive always thought the potential integration between e-mail and blogging was interesting. We have the Post into E-mail feature, and we also have e-mail out from your blog. Publishing content, whether its on a Web page or via e-mail or RSS, is more or less a delivery mechanism, and should be up to the receiver of information. Beyond those kinds of high-level ideas, we havent sat down about how were going to hook Blogger and e-mail together. But if we think theres a really great thing we could do for users, then were going to explore that.
Beyond the e-mail-in features, if there was some way of talking to the API at the same time as you were entering content …
Yes, thats a good idea. Theres some stuff we could explore there.
Youre continuing to support some flavor of RSS in Blogger Pro?
Yes, for that subset of users. Nothings changed in this release in terms of feed support. All the users continue to get ATOM feeds by default with full content, and anyone who had RSS before can continue to use RSS 1.0.
Is ATOM the Bomb
?”>
What is the logic behind sunsetting RSS feeds moving forward?
We think feeds in general are important. Its still early in terms of feeds—for most users even knowing what theyre for—and what were aiming to do is make it as easy as possible for them. We felt the easiest and best user experience would be to say “do you want a site feed, yes or no?” and in order to do that we picked a feed format that we thought had the most potential going forward and, importantly, was linked with the API that we support.
Thats one of the beauties of ATOM that gets overlooked; its the same format for the API as for the feed. If there are a lot of these feeds out there, we think it will be easier to develop toward it, and the extensibility of ATOM will take out a lot of support and potential confusion for our users.
Theres also the fact that for those who care—a lot of them are old Pro users who still have that option—there are other services like Feedburner for instance, which will translate and give you RSS for your ATOM feed if thats what you want. There are always options available for the more sophisticated users who want to get into that.
Could Feedburner be a service thats transparent to the user? You have to go off to another site, and do what with it? How does that work?
Feedburner, yes, the user would have to do something there. But it seems the users who care about that type of thing are exactly the users who can handle going off and doing that. The majority says site feeds, great, and to present them with the options would not necessarily be that helpful.
Since youve got your API and the ATOM API support, couldnt you or a third party develop or build a bridge that would handle these transforms for the users with older readers that dont support ATOM, particularly since its not even fully completed?
Sure, thats something we could do, and have looked at doing and will continue to look at. Its just like anything—the costs versus the benefits for users—and what seems to be important for them hasnt weighed out too favorably for that yet. But we think its important to a lot of people; well definitely look at it.
From a pragmatic perspective rather than a political one, if youve got the ability to e-mail into the system and e-mail out of it, you have the ability to send this data to a third party who could do a transform and make the whole issue go away.
Potentially, but we try to separate the political issues from whats best for our users as well. There are tons of things we can do that seem easy and worthwhile, and every day were weighing those against each other. We have things like comments and profiles that we think are going to make a much bigger difference to the majority of our users than the format of their feeds. So in the next round of stuff, maybe well be able to look at that.
What about work going on in the RSS space, such as enclosures for example?
Its another thing we might look at. Right now most of our users dont have the ability to upload large files, so Im not sure if a lot of them would be able to take advantage of that. Im interested in enclosures—I havent actually played with them much myself.
Theres the peer-to-peer work as well, technologies such as BitTorrent to spread that load. Since ATOM ostensibly encompasses most if not all of the capabilities of the RSS format, there should be no reason why that kind of functionality couldnt migrate as well?
I agree. Theres a lot of work to be done there, and were hoping to keep on top of it.
Next page: Redirect, Your Honor?
Redirect, Your Honor
What about linking a single sign-on strategy across Gmail, Google and Blogger?
That would be great. Weve had migration issues, of course, since we have a user base that dates back long before we came to Google. Its something we definitely will look at.
Theres been some feedback regarding the Blogger redirect policy. Can you illuminate?
People have noticed—and it isnt new to this release at all—a lot of the links on Blogger.com go through redirects, either on Blooger.com or Google.com, before they send you to the destination. This happens on the list of recently updated blogs, Blogs of Note, and even the Help articles. It also happens on comments: If you put a link on a comment, it gets redirected through Blogger.com.
And the reason for that?
There are actually three reasons for it, which are fairly unusual. One, a lot of the content on Blogger is published with an internal install of Blogger—the intranet version—and that redirects URLs to not reveal the referrer, as a lot of intranet publishing systems would, so that people outside would not see the [internal] names of your sites and pages. We use that same system in the content that gets pushed out to Blogger.com. Its not necessarily on purpose, its just because its an intranet publishing system. That ones fixable, and were going to look at that.
Why would you want to fix this?
The reason it exists is for content that is published on the intranet. In this case were using the intranet publishing system to publish publicly, so theres no reason for it. It doesnt really do anything harmful, it just mainly confuses people, but in that case it does attempt to redirect and slows people down for a second.
But we wouldnt completely stop doing the redirect. The second reason we do redirects, which is fairly important, is that Blogger.com has a really high page rank, partially because of the site and partially because its linked from Google.com. Therefore anything we link on Blogger.com, we flow a lot of page rank to. We dont want there to be a possibility of Blogger blogs having an unfair advantage in the index, just because theyre Blogger blogs. So when people click on ones that are recently updated, we send them to a redirect that Google knows not to flow page rank through.
The third reason for redirects is when they show up in comments, as a comments spam protection. Its similar to the page rank issue, where people spam comments oftentimes just for page rank. That just wont work for Blogger blogs because they will not be assigned page rank by Google.
If you fix the first one, will that have an effect on the second two?
Fixing the first one would mostly mean changing the method so its the second one. The first one is the only one that really affects the user because it slows them down first. The others use a method thats much more transparent. The people will still notice it and were going to explain that—were definitely not doing it to collect data or anything. Its just the reasons I mentioned.
This wouldnt have an effect on applications or other data mining operations like Technorati that could be examining referrals?
It shouldnt. At least in Technoratis case, theyre focused on crawling the contents of the blogs themselves. They certainly count links, and thats a good point. It may affect them if they count links in comments, but thats something that I think they try and avoid. And Movable Type has a similar feature thats optional, on the comments side.
Next page: A Fork in the Road.
A Fork in the
Road”>
There is certainly continued concern about the forking of RSS. Earlier, you referred to it as RSS, not as ATOM; Sergey Brin used the same generic RSS term in a recent conversation. Theres a consensus out there that RSS is the syndication technology that people are aware of and are increasingly developing an affinity for, primarily, in my view, because of the speed with which you can absorb not only blogs but more traditional publishing information. Are you thinking in terms of a release thats going to target the RSS environment?
Yes, were certainly excited about RSS. Ive actually been using “RSS” as a generic term internally because for a lot of people, its exactly what you said: Thats what you hear about. And it often gets distorted into RSS versus ATOM when RSS itself isnt one thing, its three or four different things, depending on how you slice it.
I think it was Dave Winer who said that he thinks ATOM will just be considered a flavor of RSS. I thought that was astute because as far as familiarity, people have certainly heard the term “RSS” more. I dont think the name RSS 2.0 versus ATOM versus 1.0, which are completely different animals, is really worthwhile for the vast majority of people to understand what it is, especially when most feed readers will support all of them.
Do you have any kind of relationship, or do you plan one, with micro-content reader and router toolmakers?
We are very interested in it. Were talking to folks, mostly on a casual basis now. We dont have any big plans along those lines, but it will certainly be an increasingly crucial piece of the publishing tools in this ecosystem that were in.
Do you see API capabilities as becoming more significant?
I do. Hopefully were going to soon be seeing a lot more interesting API tools. Theres been a lot of work on the digesting side of feeds, the crawling and parsing of feeds by aggregators and search tools. But combining them back together and maybe publishing them and using the API tools has a lot of potential that hopefully well see being experimented with soon.
Do you see that potentially interacting with what youre doing with Gmail?
Im not sure. Ive heard some people mention Gmail could be an RSS reader, and for mainstream users theres some question whether or not people are going to take the effort to run a separate aggregation tool or just have it in their e-mail or news page. Im not sure what the Gmail team is thinking about that; I havent been talking to them about that exactly, but there are lot ideas out there right now. Its mostly a brainstorming phase for us anyway.
In talking with Sergey, he seemed to appreciate the idea of extending Gmails functionality to an offline persistent mode, perhaps via something like Ray Ozzies Groove architecture. In the blogosphere, those feeds that tend to support the full content and improve the value proposition of speeding up access to Web information are at the core of RSS momentum.
I agree. The offline point is an interesting one. Sometimes I find the feed reader most valuable when Im offline, being able to read Web content.
Barring an alliance with Groove, to the extent the Blogger API is addressable, you could flow data into e-mail as a persistence mechanism.
There are a lot of people doing great work on client-side aggregators already.
Next page: Putting People at Ease.
Putting People at Ease
Whats Bloggers status with Mac users?
Half the Blogger team are Mac users, so our supports better than ever for them.
Can you call out specific ease-of-use features?
Theres the home page. We collaborated with Adaptive Path and Doug Bowman of Stop Design—some really great user experience folks—and I think they just nailed it.
What specifically do you like about it?
I like the home page, the Create a blog in three easy steps, the iconography—both the visual appeal and the verbiage. Weve yet to see the numbers on this, but we did some studies. There are a tremendous number of people who come to Blogger through links on other blogs perhaps, people who are on the verge, potential users.
And when they get their own home page, theres a fairly high barrier to parsing it and figuring out what it might be. I think this one is going to perform a lot better in terms of pulling people in, and once theyre in with the combination of having comments on automatically and the profile right there, getting into the blogging value proposition is much faster.
Have you talked to the Orkut team about sharing profile information?
We have had thoughts about that; we kind of serve different purposes now. Orkut is still in a beta and by invitation only; its hard to explore that seriously. But certainly lots of people would be interested to see some integration there.
The combination of RSS and a blogging engine in some ways obviates the need for a separate social network. Its a more granular social network infrastructure.
I agree. Ive read some stuff about that, maybe from you, about how blogs are a more organic way to do essentially the same things they do on a social network. Its mostly about putting yourself out there and finding other people of interest. With blogs you have an ongoing interest. Well see where the social networking sites go. I think theres going to be a lot of convergence potentially, in terms of functionality.
In recent weeks, someone did a quick hack on the Technorati API to multiple responses to a blog entry. Interestingly, that approach preserves the brand of the individual Weblog, which is likely related to things like page rank as well. Do you see value in that or the potential of the new Blogger to have some impact in that area?
I think that was a great idea. Theres probably a need for various methods. Not everyone who comments on a blog has a blog, It really depends on the nature of the discussion, the nature of the users, whether or not that makes more sense than inline comments. Its great to have that flexibility. If people can use that Technorati hack with Blogger, thats great. If they use it in combination with comments, thats great. Well see how that works.
Can you write that hack to your API?
I think itd be possible. I havent looked at it in detail.
Can you look at it in detail?
Sure, when I get a chance.
Check out eWEEK.coms Messaging & Collaboration Center at http://messaging.eweek.com for more on IM and other collaboration technologies.
Be sure to add our eWEEK.com messaging and collaboration news feed to your RSS newsreader or My Yahoo page