One of my colleagues Josh Evnin recently did a User Centered Design study for the application we are building at a client.
We were trying to build a web application where the user interacts with the system using the well known html forms.
We were doing the traditional form validation where the user is required to enter information/select the required fields.
When the user clicks submit the application does a validation routine and displays errors next to the error fields.
This is one way to make sure that no erratic information enters the application. I would call this method as 'trial and error'.
With the new UCD that Josh came up with - he gave a new direction of thought to error handling and error perception to the user.
The philosophy was why let the user make an error and submit in the first place.
Why not just stop the user from submitting ? - (by being more proactive) - that way the user already knows something is missing and he needsto fill out/select the required fields or else he will not be able to proceed.
Essentially what my UCD expert wants to tell me is why let the user get into error conditions at all.
I as a developer think -Let's do preventive design and minimise the number of round trips to the server and make sure only valid data gets to the server in the first place.
This saves me not only the time to build code for all the errors that the server gets and also adds confusion to my user. (Also I should mention that all the analysts on the project had their own opinions about the error text that should go on the page - but that is a funnier discussion in its own right)
The new design of the above page would look and behave as shown below.
Notice the difference.
As a developer I don't have to use server side validation - which at most times is desired - also with the different types of validation required today the number/string validation that comes standard with frameworks is hardly of any use. So I write my own regex based validation in javascript anyway.
As a user - this is what is more pleasing because I know that I have not completed this page correctly till the submit button is clickable.
Some sugar around training/informative messages on the screen make the screen more friendly to the user.
Get your Agile UI/UCD/Human Computer Interaction earlier in the game... and make friends with him/her..- It can save u a lot of code and make the application look slick....
Subscribe to:
Post Comments (Atom)
Welcome
- Agile (1)
- ant (1)
- automation (2)
- batch files (1)
- commandline (1)
- continuous integration (1)
- cruisecontrol (1)
- cruisecontrol java monitor Big visible charts agile ramaze ruby (1)
- env (1)
- errors (1)
- github pages blog jekyll accordion.js accordion prototype1.6 javascript opensource (1)
- java (1)
- java5 (1)
- jruby Mac OSX install Windows CLASSPATH (1)
- Junit (1)
- junit4 (1)
- launchy (1)
- maven build tools (1)
- mocking (1)
- PATH (1)
- process (1)
- procexp (1)
- rails (1)
- ruby (1)
- save (1)
- selenium (2)
- sysinternals (1)
- testing (1)
- testing "random numbers" ruby (1)
- thoughtworks (1)
- top (1)
- UCD (1)
- User Centered Design (1)
- webrick (1)
4 comments:
This kind of preventitive design is certainly better, but:
"as a developer I don't have to user server-side validation"
But what happens if the user doesn't have javascript available or enabled?
You always have to do server side validation. Client side javascript validation certainly improves the user experience and should be included.
The concern is not one of User Experience, but rather one of security. If you don't do validation at the server you open yourself up to all sorts of attacks including SQL Injection ans Cross Site Scripting. Basically, you can't trust any server input because you have no assurance that the client validation ran. A malicious user could bypass the validation by running through a proxy or simply by disabling javascript in their browser.
Although it may lead to duplicate code, if you want client validation you need to have the validation done both in the client and on the server.
Remember, NEVER trust user input. Client side validation is a nice UI improvement, but it doesn't remove the need for server side validation.
Thanks for the shout-out, Sudhindra. It's always interesting to see UCD techniques from the developers' side of work. It's interesting that this sort of user-based improvement *might* make your job a little easier...I'd like that to be the case all the time, but more often than not it's probably the other way around.
Still, the user's experience is vital, especially with respect to whether they will accept and use the tool after it is built. I think the point of helping a user out before an impending error is important, and we should all look out for areas where this idea can be applied throughout the software we design and build.
Sorry if I misrepresented that. You guys are right about server side validation. But I am not talking about getting rid of all the server side validation. Most of the server side validation that is done to just show errors gets to be a drag. This perspective I presented above helps a lot in the way you think about the app you are writing.
Post a Comment