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 <phi...@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
