We have just launched our new Tribute Application for creating customized cards for donations in honour or memory of someone you love.We used Microsoft .NET and the new AJAX library for development of our forms. Our developer teams became enthusiastic supporters of using AJAX styled controls for creating a sense of immediacy in the interface.
However, what was interesting was the new set of bugs that cropped up simply because of now using AJAX controls. Here is an example: the above form has two controls for postal code and zip code and based on which state or province is picked, we flip between them so that you can have client side validation, proper field lengths, etc. Sounds simple enough, but we went through quite a bit of work and bug fixing to make this work.
Here are a few bugs that we found in the process as examples:
1. When you click the back button the right control isn't always displayed.
2. We had styling/layout issues in Mozilla.
3. When you picked a state and then switched to province the value would disappear.
4. The switching of state was generally quite slow on some clients.
In the "old days", the interface would have been really simple - a text box submitted to a server side script. Very few presentation layer bugs because there wasn't really anything going on in the presentation.
So the question becomes - is it really worth it? For Yahoo Mail it might be, but for an average data entry form is it really that crucial?
Now that we're planning phase 2 on our project, I would be much more cautious about going gung-ho on AJAX simply because it dramatically increases the testing/bug fixing time for what amounts to a simple user interface convenience.
4 comments:
I don't mean to be "rude" but your assumptions about "using AJAX controls made a whole new slew of bugs" should have been; "using ASP.NET AJAX controls made a whole..."
E.g. Gaia Ajax Widgets (where I work) would probably have given you way less pain than ASP.NET AJAX...
It sounds like a lot of what you are trying to do doesn't need Ajax at all. At least in the example you gave you can download HTML with both field elements and display only one via simple client side JavaScript. There really isn't any need to create an HTTP connection just to pull down what shouldn't be more than 100 bytes. Now if you wanted to do some kind of server side ZIP code validation ASP.net might make that easier, but even that would most likely be overkill. A simple servlet (or even ASP page) that takes a zipcode as a parameter and returns the City and State (by performing some DB lookup on your server) could be parsed in 8 lines of JavaScript. Maybe 40 if you wanted to present a pull down for multiple cities in the event that more than one comes up in your query. As for your back button issue onUnload() is your friend. The plus side of doing this manually is you get a code base that you have a deeper understanding of and a much greater likelihood that cross browser issues can be worked out.
I've found that most AJAX frameworks simply tie your hands behind your back.
A very small amount of javascript can handle that situation elegantly.
My guess, is that you used an UpdatePanel and Partial Page Postbacks to change that box on the server side, hence the frustration.
I think the reason it became so hard to create your form is the presentation engine you're using. I used WebForms for a long while, but got seriously fed up with them because of their buggy nature and crap state-model that complicate something that's simpler, in trying to impose a state model on one that is not, without succeeding.
In fact, when I opened my eyes to this, I also realized that I was rubbish at writing REAL javascript, i.e. non-autogenerated by MS... I'm a lot better now though. You guys should try something like MonoRail instead, together with Ext JS/prototype or something.
Post a Comment