Here is where the first issues arise: which script is responsible for the validation of the form data and what happens should this validation fail? How can we return the user back to where they started, with the original form re-filled with their data even if they just click the “Back” button in their browser? More importantly, what do we do if the result of the data has multiple potential destinations?

As programmers we are also, whether we like it or not, responsible for creating user friendly applications. This means not relying on browser specifics to achieve tasks and hand-holding the user through our systems as much as possible. A good example of a badly designed user experience follows:

Joe Bloggs enters his username and password into a web site login page and submits the form.

The script checks his data and sees that something doesn’t quite match, so it sends him to an error page that simply says “Username/Password invalid” and urges him to click “Back” in his browser and try again.

This is more common than you might think and several high-profile web sites adopt this principal of “let the user fend for themselves”. But poor Joe is sat there thinking “Well which was it? My username or my password that failed?” and when he clicks “Back” in his browser he finds the form is now blank and he has to try again.

This might not sound like such a big deal, but what if the form had been part of a registration process or a shopping cart purchase page? Often the forms in use are both far more complex than our example and have multiple outcomes based on the user data. As we all know, the more data you loose for someone, the bigger their frustration factor. Using an XT (Transfer) script is one way to allow you to keep track of this information flow and to separate the logic of your site from the display and core functions.

So what is an XT script and how does it work?