Ajax Talk: Washington DC February 09, 2006
I am doing an Ajax talk on February 09, 2006 from 6:30pm to 9:00pm for the Washington DC BEA User Group. If you are in the area you should come check it out and learn how Ajax can help your web application.
You can register for the event and get more details by visiting: http://dev2dev.bea.com/pub/e/845 .
If you need another reason to come: I will be giving free books away! Hope to see you there.
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
Developers need to step back and think.
I have been doing a lot of consulting lately looking at people's ideas for Ajax applications. Whole idea behind it is to tell them if it will work or not. I have seen some cool ideas, ideas I would have never thought of, but I have seen a lot of bad ones too. Now it really seems that people think "flashy" is good. If I add tons of crap people will love it. It may make your application top of the line, but you have to draw a line somewhere. Developers have to remember don’t change things that are normal by default and users can not read your mind on how things work! Do not override functionality!!!! I can not stress that point enough.
First let’s peep at some bad design choices with applications:
One application had panels that opened and closed to perform actions. Well this seemed cool until you realize that this was meant to enter in orders. So a fancy picture showed up. You clicked on different portions, sort of like a JavaScript controlled image map. Now if I am a person that had to click on the one picture to enter an order 100 times a day I would be pissed off. That is 100 clicks I really did not need to do. All just so the menu is not visible all of the time. Concept looked nice to the eyes of the executives, but it would not work for the person using it 40 hours a week. Think of the time wasted to click on an image, wait for this drawer to open up and show a form that could have been sitting there in the first place.
Another was using Ajax to save entered data. Now this makes sense people were entering data to make orders. They were using Ajax to send back information. Problem was they were sending an Ajax request for each form element in the form. Now the form had 10 fields. Therefore they were making 10 requests to send information for each item entered. The reason for implementing this was to keep a user from having to click a single button to save the information.
You are creating more bandwidth than needed and also more problems. I suggested sending information only when the button is clicked. Plus another thing was they were not using an OO based request so a fast typer would be killing the requests for each element. Now look at all of the extra work these people were creating. So you save each field, what if the user stops entering data. Now you have incomplete data in the database which you would have to mine out. What if the user figured they spelt something wrong? You would have to code checks to see if data was there. All of this was extra work on developers. So this one click savings was going to relate in multiple man hours to solve all of the new issues brought into the mix. Not every economical!
Now there is a good use for Ajax on a single element. One example is a product number. You can validate to make sure that number is correct. I would prefer a type ahead functionality to do this, but you can check to see if usernames are in use when a person is signing up or that an area code matches the city and state. Keep it to basic checks before a large form is submitted to the server. Not every field should be validated this way! Keep validation that needs no server side knowledge on the client. PLUS validate your data on the server when submitted! A fatal flaw I see all of the time!
Another flaw (or annoyance) I se is using way too many special effects. Thanks to those wonderful libraries people are fading in things more than I like. I do not want to see my page fading in and out when I scroll! I know an action is happening since I am scrolling; you do not have to emphasize it! I do not want to see text flash or change colors unless we are talking about errors. But you do not need to have it on a setInterval until I fix it. I see it, stop harassing me. I started to code those wonderful status bar scrollers 9 years ago. Just because I could do it does not mean I would use it in a professional application. Think how this stuff will effect your user's eye movements as they look at the screen. If stuff is popping in and out, flipping around, you can drive someone crazy. Keep everything in a normal eye flow and keep it in my view.
Do not randomly add text into a portion of a page without some notification. One application was reading error logs, I reading it and a new one pops up. Now that is annoying. I lost my space and I had to scroll to find it. Appended it to the bottom, add checks to see if I am reading, keep my spot please!
Everyone should follow KISS. Keep It Simple Stupid. Just because you programmed it and know how it works, does not mean that your user knows that they have to click the picture, spin their mouse 360 degrees, click three times, and yell at the screen to make the link appear. When you get requirements just ask yourself one thing: "Would I want to come back to this site after using it once." If I have to go through loops to do basic actions, I would not want to come back.
A real world example:
The forums at ASP.NET implemented a feature that I can not stand. If you double click anywhere on the page, the page fades out and a reply box appears. Now who would think that I use my mouse to double click on a word to perform the action of copy and paste? So now when I try to copy a keyword to add in a reply, I can't do it because someone changed my basic functionality of the browser! It is really really really^1000000 annoying. Hence my post count there does not increase since I really hate it! One feature that sounds cool to one person can really screw others over. If you want this to be a feature, let someone enable or disable it!
So please as a developer, remember not to change functionality, do not screw with right clicks, shift keys, ctrl keys, function keys, etc. They are meant to do things by default, by changing them you make people uncomfortable. Keep the user interface simple. Do not overuse effects. Just because fading in stuff can be one line of code, does not mean that everything on the page has to do it.
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
Ajax Article
Well I was asked by many Ranchers here at JavaRanch to write a low level article on Ajax so that is what I did for the January Newsletter. You can find the article here:
http://www.javaranch.com/journal/200601/Journal200601.jsp#a2
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
Anyone seen this problem with Safari XHR request?
Yesterday was the big day for testing my Ajax functionality in my application at work. All went well on all of the main browsers until Safari was brought into the mix. The browser just ended up going to the site error page saying I was sending an invalid Guid.
Well I checked my variables on the client and everything was fine. Traced the server code and that is when I saw that Safari was appending a null terminator ("\0") to the end of my Guid. There was my problem as the log showed. I ran some other tests with this post and whatever my last parameter had on it, a \0 was appended to the end. I have never seen this on any other safari browser before, wondering if anyone has any clue why this happens.
My solution for this bug is to append an additional request parameter to the post so it is the last one in the list and gets the terminator appended to it. I saw this to be easier then checking all of my request parameters and making sure they did not contain a \0.
Hopefully someone can shine some light into this!
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
JavaScript Quick Tip: Logging ClientSide Errors
As a developer you know how things work and always do the same actions, you say hey look error free. Get a user that has a happy click finger and watch your
application die right before your eyes. Wait it will not be before your eyes since you have no clue where this user is sitting using your application. Since
it is a clientside error will not even know that this is happening! One thing people seem to forget is that these wonderful clientside applications may be
full of errors and destroy your application. Bug free code is a dream, but with browser quirks and such, you can never test everything. So we probably need
to do something about this.
The easiest solution is to use the wonderful onerror event handler and get the error message to handle. The onerror event fires when a problem occurs. A lot
of people do not know this, but the onerror event does allow us to do more than keep browsers from freaking out. We can actually catch the Error Message, the
Line Number and the file the error fired in. Now this is a good starting point. So let’s build a simple code that allows us to log some errors.
All I am going to do is make a global array and stuff errors into it. Nothing too advanced for this example:
var arrErrors = new Array();
window.onerror = function ( strErr, strURL, strLineNumber ) {
strMess = "URL: " + strURL + "\nline number: " +
strLineNumber + "\nError Message: " + strErr;
arrErrors.push(strMess);
alert(arrErrors.join("\n__________\n\n"));
}
To see it in action click the following buttons to create errors, Button 1 calls a function with an error in it and button2 calls a function that does not exist.
Now I know what you may be saying, so what, I just alerted the errors, I still can not log them! Well this is where a simple error page comes into the mix. Instead of an alert message, redirect the user to the error page with the parameters in a query string. Or you can post the values obtained to a hidden iframe or even use a wonderful Ajax request to the server. The server side code on this error page that we are going to or posting too can add it to the server's error log. Now your error log will contain errors that you had no clue ever existed!
Hopefully this little tip can keep your application error free. Just remember that this onerror may cause some bad side effects to a page, especially if you forget to tell the user there was a problem. If you do it silently, they will click those buttons until their face turns red and leave since nothing would happen!
Also make sure to check out the JavaRanch journal a little later this month for an article I wrote on Ajax. It is great for anyone that is just starting to learn Ajax.
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
VS Tip: Setting the Default Browser
Here is a quick tip for people using Visual Studio. When you run the project or view the page in the browser, it is possible to do this in any browser installed on your computer and not just IE. Yes you can run the debugger in Mozilla, Firefox, Opera, etc. All you need to do is tell the browser what the default browser is and here is a quick way to do it.
Right click on one of your .aspx pages in your Solution Explorer window to bring up the menu and select "Browse With..." as shown below.
Now with that selected a window pops up with all of the available browsers on your computer. Select the one you want and make it the default. Therefore when you run the project, this browser will open up rather than Internet Explorer.
As you can see I prefer to use Mozilla as my default browser since it has better JavaScript debugging features built into it. Hopefully this will help you out and eliminate the need to keep copy and pasting URLS into multiple browsers to test code. The screenshots are from 2003, but you can find the same exact menus in 2005.
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages
Ask me a question!
Well I am looking for ideas for future articles on Ajax and JavaScript so I thought I would ask you the readers to ask me questions. I know people have questions because I get plenty at my talks and forums I frequent. So if you have some buring question about Ajax, JavaScript, my books Ajax In Action or JavaScript: your visual blueprint for dynamic Web pages (2nd ed), my life/job (to a point!), and whatever else you can come up with I am game. Hopefully you will find a few minutes to ask a question.
You can submit questions as a comment here on this blog entry or to askEric@pascarello.com!
I will be waiting!
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Dynamic Web Pages