Eliyahu Goldin wrote:
Quote:
Damien,
>
In what sense do you call an application with bad user experience useful?
>
I still remember the time when developers where forced to program for MS-DOS
since not everyone had/wanted Windows. And in MS-DOS one could always
achieve the same functionality.
>
--
Well, lets see.
For a long running process, if the user has javascript, they get a
stable page which uses ajax to check for progress and updates the page
apropriately. No javascript, they get a page that does a refresh every
five seconds - it looks jerky, but it works.
For a text box where the user has to provide the name of a company - we
have a drop-down list which pulls in possible names (based on what the
user has typed) from a list of ~200 most likely names to be typing. If
they don't have javascript, they don't get the list, but they can still
type in the company names (and anyone is allowed to enter a name not on
the list anyway)
For validation - if the client has javascript, they get client side
validation which saves round trips to the server if they've got errors
on the page. No javascript, they have to wait until they submit the
form to get the same kind of feedback.
So, if the user has *chosen* to disable javascript (and you'd hope
they'd be aware that doing so limits their user experience
possibilities), we still allow them to use our system.
Now, how do the penalties for developing like this work out? Well, you
have to have server side validation anyway, to protect yourself from
malicious people. The text box with the "predictive" text just renders
as a text box anyway - no development effort whatsoever for the
non-javascript approach. And the progress page? There are about twelve
additional lines of code to support the non-ajax functionality.
Damien