Feedback in Feeds
Some of you may have noticed if you’re regular subscribers that I’m currently working on the Feedback In-Feed that I added a few days back: specifically, trying to make it less obtrusive. However, one of the things that I didn’t realize in all my efforts is that I almost always already *have* the user’s homepage information: if they’ve left a comment on the site, it’s stored in a cookie in their browser (which is probably what they’re going to be submitting the form through).
“But”, I hear the audience crying, “You can’t see their cookies! They’re posting the form from their aggregator!”
Ah, my feeble minded friends, this is true, but this is unimportant. What matters is the user agent which hits the final form – which is stored (now) in the same directory as this blog, meaning it has access to all the cookies set by this blog. Including, as it happens, the name and URL of the person, assuming they’ve left a comment here before.
Of course, this has some limitations: persons who have not commented here before will not have a homepage set, or whose cookies have expired. (They expire after one year in WordPress, it seems.) Still, at the cost of saving space, I have gone the route of removing the homepage from the form, as well as pulling out some of the HTML I didn’t really like in the first place, and cleaning it up in general. I’ve been working on this over the past few days, in large part with help from jc, who was helping me figure out ways to make controls smaller. He said that my feedback form was “Somehow even more annoying than Adsense in feeds” – something that I was loath to admit, but in the end had to agree with.
Since I know there are a large number of people who read this who never comment, there is also a built in “more info” link, via which users can set their Name/URI. So, if you have any interest, feel free to use that link to set your name/URI, which will then be stored with the data.
Another thing that I’m doing, which I hadn’t yet written or talked about in public yet (despite Danny’s conviction otherwise) is the fact that I am capturing the referer information for the feedback, and exposing it via the RDF interface, attached to the review. This is a more generally useful property: a review for something can come via Amazon, a blog, or any other of a number of things. I’m simply using it to store the referer information: So I know whether someone came in via Planet Swhack, Planet RDF, Planet Mobile, LiveJournal, Bloglines, or any other of a number of web resources. Sometimes, of course, there is no referer information, in which case it was probably an aggregator, but I haven’t gotten far enough to analyze that yet. Unfortunately, User-Agent in most of these cases probably doesn’t make a bit of difference: The form is going to be posted via the browser, not the aggregator.
Danny advocates an extremely minimalist feedback mechanism, but I think that that’s less likely to get people to submit feedback, especially once they realize he asks for more information afterwards. LiveJournal’s polls always get more feedback than comments, because they’re low impact in comparison. The same idea applies here: but something which is just a tickybox or a simple form press is not enough to provide the user with a sense of offering helpful feedback. I hope that I’m achieving (for the most part) low impact as well, by redirecting to the referer once the form is posted – but I want to have low impact, informative, useful feedback. I think the recent design changes will help that.
I do think that this is the right idea, and that implementation is the problem, rather than anything more basic in the idea. So, I’ll be working with the implementation to make it better as time goes on.
June 5th, 2005 at 3:28 pm
One issue: my browser has these cookies, sure – but I don’t think NetNewsWire does (although it does use webkit, and in an earlier release *did* have cookies and password info from the browser, apparently that was fixed as a bug…) and I wouldn’t expect most of the non-browser-but-still-html-based clients to have them either. (This was something that came up in Russell Beattie’s version of the experiment, although the more problematic discovery was that for actually comments, you really *did* want people to read other comments first.)
Also, it never occurred to me that “more info” was to *give* more info, rather than to *get* more info, which is what it usually means…
June 5th, 2005 at 6:41 pm
Mark: I’d already thought about the NNW-like stuff, and was aware that it could be a problem. I don’t have NNW (no money) so I can’t test with it, unfortunately. What it really comes down to is that the metadata for who it’s from isn’t vitally important: it’s nice, but half the time people didn’t fill out the homepage box anyway.
In reality, a large chunk of my readers come through web based aggregators. Of the estimated ~100 regular readers I get via RSS, 30 come from bloglines, 35 come from LiveJournal. A large chunk of my readers also come through http://planet.swhack.com/ or http://planetrdf.com/: both of which will have the user’s cookies stored, assuming they’re reading on those pages.
I’m not sure if these kind of browsers use completely seperate cookie sets, or disable them altogether. If it’s the former, they can use the “info” link to set a cookie within the aggregator, one would think, if there’s some way to open a link inside the aggregator.
The (info) link both gives information (What is this?) and lets you set it (via the form). The more important part to me is the first paragraph, which just outlines what exactly this goofy form is doing in the post for people who are new to the weblog. It’s not the most intutive thing in the world, I’ll admit, but it is better than the nothing I had before.
June 6th, 2005 at 1:32 am
FWIW, I’m in NNW right now, and it would seem to have access to cookies, since all the fields above were pre-filled.