noted on Mon, 09 Feb 2004
noted on Fri, 19 Dec 2003
noted on Tue, 07 Oct 2003
noted on Wed, 30 Jul 2003
Using Google to Create Comment Threads.
I’m really happy that Bob DuCharme wrote his article on creating backlinks, because I have been struggling to write an article using the same technique, but to achieve a different end. In his article, what Bob wanted to do was find a way to work around the web’s fundamental restriction on linking: that it be one way. What he proposed was an easy hack where if he writes an article, he could publish as part of the article a link to Google using his article as a search term. If someone else wanted to write an article that contributed to the discussion that he started, then they too could add the exact same Google link. Now, with both sites so connected, if a viewer were to visit one site, and saw the Google link to the other, they would hit the link, read the other article, hit that article’s Google link, and would then have a way to ‘go back’ to the first article — albeit in a two-step process.
I was surprised that Bob didn’t pick up on the other possibility inherent in this kind of linking. That is what I want to discuss here.
I would like to propose that if any collection of weblog posts related in content were to publish these kinds of Google links, then the search results begin to take on a new kind of significance. The results would illustrate a discussion thread. Let’s take an example, using Alice, Bob, and Carly.
Alice decides to write a post about a recipe, and publishes it to alice.ca/myrecipe.html. Alice understands the idea of using Google to store discussion threads, so she publishes a link to Google using link:alice.ca/myrecipe.html as the search term.
Bob, also a culinary artist, saw Alice’s article, and clicks on the Google link. No surprise, the search results contain a link to Alice’s article. Bob then decides to write a followup, possibly to suggest an alternate method of preparation for Alice’s recipe. He links to Alice’s post, and he also creates his link to Google, using link:bob.net/alicesrecipe.html.
Alice decides to check on her article on her web site, and clicks on that Google link she made. She’s delighted that there are now two results: one for her own site, and a new link to Bob’s. She visits Bob’s page, reads his article, and clicks on his Google link. Alas, the discussion seems to have ended there for the time being.
Carly, who’s a fan of anything Bob writes, then goes to Bob’s site and discovers the post talking about Alice’s new recipe. Carly spotted some technical errors in Bob’s post, and decides to write a post of her own suggesting corrections. She includes a link to Bob’s page, and may likewise add her own Google link.
If Alice were then to check on her Google thread link, nothing would change, but if she were to follow Bob’s Google link, she would discover that the conversation had in fact continued on.
This example illustrates several aspects of using Google to show how a discussion evolves.
The first aspect to note is that anyone using the links will not be able to get a bird’s eye view of the entire thread. This is only a real drawback if you’re trying to determine which post was the one that started it all. However, I think there’s a way to make this a bit easier. After checking on a set of Google search results, I was surprised to see that some of the search results had a date tucked in beside the page size. Curious to see how this was done, I view-sourced the link, and found out they were using a meta tag. This is what it looked like:
<meta name="Date" content="2004-01-15" />
My theory is that if web log software made a habit of a) making permalinks to pages with one article on them, and b) adding this date tag, then it would be very possible to trace a series of comments to the oldest one.
If you’re going to explore a conversational thread, then you must follow a page-to-Google-to-page-to-Google pattern of browsing. Not exactly an ideal situation from a usability perspective, but it may well be worth the tradeoff if you’re weighing this approach to creating discussion threads over allowing comments (and therefore comment spam)
There ends up being very little overhead. You don’t have to manage or maintain the thread — Google takes care of that for you. As long as people are creating their links to Google using their article URI as the search term, and also linking to the source article that they’re commenting on, then it’s possible to follow a thread to each and every article.
Things get even more interesting when you play around with some what-if scenarios. What if, for example, Bob not only created the Google link for his own URI, but also added another Google link containing Alice’s article URI? Now you’ve made it convenient for anyone visiting Bob’s page to see both comments to his page and comments to Alice’s page without directly going to Alice’s page first.
Another what-if: What if Alice and Bob were savvy web developers who got their Google API keys, and decided to create an application that displayed the search results of their URI? Now it’s possible to see on their own page the top 10 comments to their own article!
So: I’m going to put my money where my mouth is, and I’ve already adjusted my templates to include a Google Thread link at the top of every page. I’ve also written and deployed a Blosxom plug-in to add the <meta /> date tag for individual entries. In time, I’ll also write a new plug-in that will augment all links I’m citing with an extra link going to Google, so that you can see other posts talking about the article I’m commenting on. The trick, of course, is in the implementation, not the functionality.
Unfortunately, I’m not (yet?) on the who’s who list of online personalities to watch, so almost all my Google Threads will come up zilch, but I hope you’ll realize that it’s not a failure of the idea. If you want to see it in action, then please comment on something I wrote! :)
Plug-in: meta_date
The inspiration for this plug-in came from a Google search result that turned up an HTML archive of a w3c mailling list. The particular search item was interesting because the date of the file was displayed right beside the size of the file. I thought that if anyone wanted to check how ‘new’ a particular page was, they would merely need to see that information.
This particular plug-in will work fine for all static and dynamic blosxom blogs, but only with the characteristic that permalinks will refer to one specific post, instead of a page containing a series of posts, like the date archive.
While the plug-in works, the benefits to adding a date is still a bit nebulous in my mind. Questions that come up for me include:
- If this is present, and someone does a search with Date constraints, does Google use the meta tag in favour of the date/time it last indexed that page?
- The yyyy-mm-dd format is a part of an ISO 8601 specification, which you can see a note about from the W3C NOTE-datetime document. I have not seen many pages that use this tag, and I’ve seen even less documentation about it. Does Google only care about the year/month/day, or would they also readily parse the time of day? Not knowing the answer, I’ve provided support to provide the time of day in the meta tag. After Google re-indexes my site, then I hope to see what the results do. If they do nothing, then I may turn it off by default in the plug-in.
Mind you, when I say that the benefits of this plug-in is nebulous, it’s not to say that I don’t know what it would be good for, but rather, I’m not sure what good it will do. You may wish to read my post on Using Google to Create Comment Threads to see what use I’d put the date tag to.
Download the plug-in here. It requires Blosxom 2.0.
Blosxom Plug-in: personLink
Jon Udell wrote what I thought was a fascinating article about the trend for social software to require that you specify the kind of relationship you have with another person.
In his article, Jon wonders aloud why he can’t submit a URI or three that can do a far better job of describing the relationship than any ontology devised by those interested in creating these social webs. Quoth Jon:
The sum of my relationship with “R.” is: 1) he wrote some cool software that I tried and wrote about, and 2) we had an exchange, more recently, in the comments area of a website. And guess what? When I google for “R.’s” last name and mine, the first two hits correspond exactly to those two points. If there were a freeform input box, I’d have simply entered the query. (emphasis mine)
After a brief exchange with Jon, I started to do some musing of my own, and realized that we don’t really need webware to help us develop our social networks. There may be a need to manage those networks, however.
So, I put thoughts to deed and whipped up my first Blosxom plug-in (yay, me!) that looks for names in a post, and generates Google search queries that will demonstrate what public relationship, if any, I have with that person. You can download the plugin right here. Note: you should either save the contents of that link, or view-source, then save.
New Version 0+2i I have created a personLink icon that can be configured to be displayed immediately after the name. I’ve also added customization options for how you want to set up the link. You may now choose to link only the name and not display the icon, link and display both name and icon, or link only the icon.
You are welcome to link directly to the personLink icon at http://www.tenletters.com/rhahn/images/personLink.gif, or to download your own copy. I recommend setting the border of the image to 1 so that people can tell whether they clicked the image or not. Update: I don’t like the image; I’m going to rework it a bit. For now, I’m not using it; when I get something I like, I’ll upload it and turn it back on again.
If you like this plugin, please let me know. I have a couple of other ideas to try out on it, and would like to discuss them with anyone who has tried this plug-in.
Crufty Permalinks.
On the Blosxom users mailing list (found at Yahoo), there was a thread started by Dave Walker, who wanted to know if there was a way to make Blosxom URL’s less crufty.
Out of this thread came two links of note. The first was Dave’s inspiration to pose the question. The second is an old essay written by Tim Berners-Lee.
Then a guy who goes by the name Ben wrote this
And in it he said the coolest thing:
“In this light, the HTML is cruft if the person is only trying to access the story and does not care about the format. If, however, the person is specifically trying to access the HTML version of the story, the extension is necessary and worthwhile.”
Given that, I think that if you were to type something like this: http://www.tenletters.com/rhahn/category/entry, then what I ought to have returned is a list of possible representations for that entry to choose from.
Let me illustrate. Suppose you have a Blosxom blog with 4 formats: .txt, .html, .print, and .rss. if I punch in http://www.tenletters.com/rhahn/category/entry, then I should see something like this:
plain text: http://www.tenletters.com/rhahn/category/entry.txt
HTML: http://www.tenletters.com/rhahn/category/entry.html
Printable: http://www.tenletters.com/rhahn/category/entry.print
RSS 0.91: http://www.tenletters.com/rhahn/category/entry.rss
Seems like a good idea, but we’ll need to answer some tough questions.
What format should this representation be in? My suggestion would be to emit unflavored XHTML, and use only tags that also exist in HTML 3.2 and up. That means using these tags: <html>, <head>, <title>, <body>, <p>, <h[1-6]> and <a> — no other. My rationale for this is that by keeping it this simple, if a text browser requests it, they can still see the information, and it’s easy to parse. If a web service requests it, then they can parse the document as being well formed, even if it doesn’t ‘know’ what the semantics of the markup should imply. And, if it’s a web browser making the request, which will happen almost all the time, then it’ll still display properly.
Won’t this mean an extra click to get to the stuff you want? Yes, but here’s a possible workaround: we can use cookies to remember the ‘preferred representation’ and serve that instead of the menu from here on out, and should the menu need to be requested, then either the cookie gets expired, or a .menu would be added to the permalink.
What impact would this have on search engines? Probably none, since you’re returning an HTML document with links the spider can follow.
What about first impressions? What would the behaviour be if a visitor goes to http://www.tenletters.com/rhahn/, assuming that is the ‘home page’ of the blog? In this case, no menu would be visible, because the web server would have been configured to serve the default file type when given either a domain or directory name - typically, an html file.
Won’t that be confusing? I don’t think so. What we’re talking about is the best way to represent a permalink, and as far as I know, I don’t think people normally browse a site through permalinks.
Movable Type Trackbacks.
While this is a very interesting and popular idea, I’m not sure if I like the MT Trackback feature. Here’s a link to the specification I’ll counterpropose my own idea soon.
UPDATE: Looks like John Gruber beat me to it And while it’s a long, long read, it’s worth every word, for he lays out his thoughts in careful detail, leaving no stone unturned.