Re: user comments of the future

I too feel compelled to participate in this thread... On Apr 1, 2009, at 9:06 AM, Richard Quadling wrote:

2009/3/31 Philip Olson <philip@roshambo.org>:

As far as using a "fancy" looking comment system, I would vote for it. Everything is going "web 2.0" with the "ooohhh" and "ahhh"s (gmail is a prime example, there are tons of libraries and sample code for Javascript effects). Almost every site I visit uses some sort of Javascript or AJAX in background (even vBulletin has gone AJAX to some extent).

Yeah, people almost expect such features these days.

Personally I think there is a usability case to be made for some Ajax-style features as well. My clients find "edit in place" to be a very easy feature to understand. So, for me, it's not just about being fancy or following the latest trend. After all, if it *were* about that, we'd all be using RoR by now... ;-)

[snip snip]

You don't need 2 versions. Even with the most complex of sites, it should be developed without JS initially. You then use unobtrusive JavaScript inclusion to modify the page as appropriate. This technique allows the widest range of clients with the least amount of effort. It is pretty much a given that the user-agent string is useless for anything other than truly rudimentary browser analysis. The browscap.ini file from Gary Keith (http://browsers.garykeith.com/stream.asp?PHP_BrowsCapINI) is fine and dandy but is updated pretty much every week. New user-agent strings are constantly being created. And, having said that, the agent string doesn't actually tell you if JS is supported or enabled. That can only be done on the client. So, "they" say don't bother. Assume it isn't. That way you site works with no special effects, AJAX, etc. Add JS to the mix and its a few form actions overridden, some observers and voila, Web 2.0 in all its glory.

[snip snip]

I use Prototype/Scriptaculous (both served by Google API, so the more sites that use the Google API cache the better for all). When using AJAX I supply a JS callback (using the JSONP concept) to let server side know the style of call being made. Essentially this means 1 set of HTML/CSS (with or without JS) and 1 set of server side scripts which are told to generate HTML or JSONP output. All the server side logic should be identical and it is just the output that is tuned.

This is totally the way to do it and there are a few frameworks out there that lend themselves to just such an approach. If you think of it as an MVC approach, in the View stage you analyze the format of output requested and respond accordingly. Richard really does understand how it should be done. Also, it should be noted that for people who aren't able to render the JS (such as screen readers), accessibility is maintained. 1+ for using this approach... ---- G. T. Stresen-Reuter Web: http://tedmasterweb.com Blog: http://tecnotertulia.com Twitter: http://twitter.com/tedmasterweb