The AJAX commenting on my site is a plugin. I can’t figure any real reason why a person would want to do this, though. It’s still a page load, and people expect that their comment is going to be submitted somewhere, so why waste the energy on coding the AJAX?
Owen, it’s more of a cognitive thing than a technical one… also, if I understand correctly, that ajax commenting demo doesn’t reload the comments per se, just sends yours off and independently plugs it onto the bottom of the ones that’re on the page (so if someone commented after you loaded the page you wouldn’t see it on submit.) I could be wrong though.
Well, cognitively, visual feedback is a bear on AJAX forms. When you submit a normal form, your browser behaves in a familiar way that you attribute to the web site processing your data. All sites behave the same way. Enter AJAX, and who knows what is going on. Is this canary yellow background fading thing the standard way to show things are happening? Since there is no browser-provided UI for AJAX submissions, it’s hard to tell what’s going on.
If anything, the AJAX is *less* functional than submitting the form normally, because others could have replied while you were writing your comment, and you wouldn’t see those without the full page reload that submitting a form would normally incur.
AJAX would be more useful for inline editing of comments. Say you wanted to delete a certain comment for some reason. Click a button next to that comment to delete it, and it vanishes. Click a different button to change the static text into a textarea, submit it, and see the results again as static text.
The prototype for this comment plugin actually allowed you to swap any static text that ran through a WordPress filter (the_content, the_title, etc.) with editing boxes and then repost them all via AJAX without reloading the whole page. That seems like more of a benefit — What isn’t clear to me is the line over which a feature must cross before applying AJAX as the solution yields a worthwhile return.
Kind of Owen. From a “I’m used to the web” point of view it is different. From a general application and software point of view it’s the norm. We’re so used to broken web interfaces now that broken is the norm 😉
I’m working on having AJAX comment support in my new theme I’ll be releasing. Plus some other nice gubbins.
I’m testing Ajax Commenting — however this is not a plugin but included in the theme. In my eyes this makes more sense because you never know how the templates’ element ids are called in different themes…
Opera 7 seems to have problems with this and is not falling back to form submission. Bad. Will see how the Ruby on Rails people handle this…
Hum, nifty! And works well with accented characters, unlike some AJAX-driven Wp plugins out there… 😉
If they do, they should make sure to use FAT. 😉
I believe that Owen was working on something like that. See: http://asymptomatic.net/wp/2005/05/12/1576/canary-comment-testing/
Ah cool, Owen is using “the fat” too… good man.
Here’s another neat demonstration:
http://beautifulpixel.textdriven.com/
The AJAX commenting on my site is a plugin. I can’t figure any real reason why a person would want to do this, though. It’s still a page load, and people expect that their comment is going to be submitted somewhere, so why waste the energy on coding the AJAX?
You can download the plugin here: http://asymptomatic.net/wp-hacks
Hmm, I did it… but it’s not on a live site anywhere. It took me all of about 20 minutes, honestly. Just plug in prototype and add a few effects.
Owen, it’s more of a cognitive thing than a technical one… also, if I understand correctly, that ajax commenting demo doesn’t reload the comments per se, just sends yours off and independently plugs it onto the bottom of the ones that’re on the page (so if someone commented after you loaded the page you wouldn’t see it on submit.) I could be wrong though.
Well, cognitively, visual feedback is a bear on AJAX forms. When you submit a normal form, your browser behaves in a familiar way that you attribute to the web site processing your data. All sites behave the same way. Enter AJAX, and who knows what is going on. Is this canary yellow background fading thing the standard way to show things are happening? Since there is no browser-provided UI for AJAX submissions, it’s hard to tell what’s going on.
If anything, the AJAX is *less* functional than submitting the form normally, because others could have replied while you were writing your comment, and you wouldn’t see those without the full page reload that submitting a form would normally incur.
AJAX would be more useful for inline editing of comments. Say you wanted to delete a certain comment for some reason. Click a button next to that comment to delete it, and it vanishes. Click a different button to change the static text into a textarea, submit it, and see the results again as static text.
The prototype for this comment plugin actually allowed you to swap any static text that ran through a WordPress filter (the_content, the_title, etc.) with editing boxes and then repost them all via AJAX without reloading the whole page. That seems like more of a benefit — What isn’t clear to me is the line over which a feature must cross before applying AJAX as the solution yields a worthwhile return.
Kind of Owen. From a “I’m used to the web” point of view it is different. From a general application and software point of view it’s the norm. We’re so used to broken web interfaces now that broken is the norm 😉
I’m working on having AJAX comment support in my new theme I’ll be releasing. Plus some other nice gubbins.
I’m testing Ajax Commenting — however this is not a plugin but included in the theme. In my eyes this makes more sense because you never know how the templates’ element ids are called in different themes…
Opera 7 seems to have problems with this and is not falling back to form submission. Bad. Will see how the Ruby on Rails people handle this…