It would help if Google blogsearch would retain the ids from the original feed (perhaps they could provide this information in an extension element); either that or if Google blogsearch added source elements [example] to the feeds it produces.
A different but related problem is subscribing to del.icio.us feeds. I tend to see the same URL over and over. argh!
Note: One of these days I need to setup my openID so I can try that fancy URI field in your comment form.
Sam, your <title> element broke completely. I guess the page title (the <h3>) and the document title (the <title>) shouldn’t be constructed from the same content, or at least the <title> should be stripped for all markup.
On topic, I too would like Google to use RFC-4287 a bit fuller than they are. Currently it seems like they just did a search and replace on their RSS library (if they have such a thing) and then calls it Atom.
Oh, and can’t you please have your comment form redirect to the comment you just posted instead of to the front page? I guess I’m not alone in wanting to see the posted comment in context. An <input type="hidden" name="from"> should do wonders, I’d think.
please have your comment form redirect to the comment you just posted instead of to the front page?
Care to explain why? Seeing what you just wrote always seemed like a strange idea to me.
It’s common practice on both web forums and blogs to show the comment after it’s posted. Not sure why, but it makes sense to me at least. I like seeing my comment in context after it’s posted, to verify that it is indeed posted and to see it “in place”. It’s just a nice verification.
Also, since I don’t ever visit your front page (I subscribe to your Atom Feed instead), directing me to your front page doesn’t bring me “home” either. I enter your blog from an Atom Entry and the only natural exit would be the same Atom Entry. Since that’s not possible to achieve, I’d be more comfortable seeing my posted comment afterwards, mark the discussion as “tracked” in coComment and then closing the window.
Speaking about coComment, could you please take a look at the Tools Page and perhaps integrate it into your website? It would make the discussions a lot easier to follow (for me, at least). And for those who haven’t tried out coComment yet, I can warmly recommend it. It lets you track discussions across blogs in a very easy way, all through one RSS feed and a bookmarklet or Firefox extension.
I’d be more comfortable seeing my posted comment afterwards, mark the discussion as “tracked” in coComment and then closing the window.
OK, I’ll take a look into it. No forms changes will be required, just some minor server side work. With the current implementation, it is quite possible to visit the original page to which you posted before it get decached and regenerated.
it is quite possible to visit the original page to which you posted before it get decached
Yes, that has always bothered me. Like Asbjørn, I prefer to see my comment in context to ensure that it came out OK (especially if I submit a second draft of a comment without re-previewing), and to see if anyone else has commented while I was drafting. The current system is a double whammy — I have to re-navigate to the entry page, and I have to force-refresh to see my comment. I’ve never complained, but since someone brought it up, there’s my 2 cents.
Count me in with the “I’d like to land back on the entry page with my comment showing on it” crowd.
I’m in quite a different mental state when composing than when reading, which greatly affects how my writing appears to me. I see (and more importantly, miss) different things while editing, even when I preview and re-preview. Actually, the more I preview, the more I tend to get caught up in my train of thought, so it becomes ever more likely that I’ll fail to make all the assumptions explicit that would be necessary to understand what I’m saying. After posting heavily edited stuff and coming back to it as a reader rather than editor, I often find it was actually barely coherent. (Sometimes I leave the finished post/comment/mail unposted/-submitted/-sent and going off to do something else for a while, in order to deal with the problem.)
I don’t know if this experience is as pronounced for others as it is for me, but I know I have heard many remarks from other people which suggest that some extent of it is not uncommon.
That is one possible explanation for why the request that you make this change to your software is common.
Another one is confidence.
The CMSish app I currently work on has several kinds of records that are only ever used in the context of the main type of document held in the system, so they didn’t have display pages, just entry/update forms. Originally, when you’d submit such a form it would just send you right back to the same form showing the changed data. Users found this highly confusing – they were unsure whether anything had actually happened. So I changed it to redirect to the record list page instead. This was better, but now they felt were unsure whether their changes had gone through, so they’d pull up the update form again to check. So in the end I created display pages for these kinds of records, and now when you submit a form you get sent to the corresponding record display page showing the changed data. That finally worked. The editing process is more complex but users feel confident: after clicking the submit button, something visibly happens and the right thing visibly happens.
They’re happy now even though editing takes twice as much clicking and time.
It turns out that the openid validated identity and non validated identity are two separate code paths, so the people who make use of OpenID get to be the guinea pigs this time — I’ve put that part of the change online, and if it isn’t too obnoxious, I’ll subject the rest of the commenters to it.
Hmm, still needs a refresh. The culprit (in Firefox) seems to be browser.cache.check_doc_frequency; I am guessing that with any setting other than 1, Firefox will skip sending any request at all for as long as the cached version appears acceptable.
I wonder if it’s possible to add cache-invalidating headers for the redirect target to the redirect; probably not.
A gross hack-around to avoid the problem is to stick some equivalent of the ETag in a meaningless part of the query string…
Nope, it won’t comply. With browser.cache.check_doc_frequency set to 1 it works as you’d expect; with the default value of 3, it just shows the cached version.
Ah, I should have followed your link before spamming your comments; sorry. Yes, the bug MNot filed remains open and remains a problem. I guess there’s nothing you can do on the server side to fix the problem. (Unless one is so desperate that faked query string tricks become acceptable…)
Let’s see how this works now, then. While I’m posting: Did you have a look at that coComment script, Sam? It would do wonders for tracking discussions on your blog. For me, at least. :-)