Mistakes made when developing with Ajax .


Using Ajax for the sake of Ajax.

Sure Ajax is cool, and developers love to play with cool technology, but Ajax is a tool, not a toy. A lot of Ajax isn’t seriously needed to improve usability but rather experiments in what Ajax can do or trying to fit Ajax somewhere where it isn’t needed.

Breaking the back button

The back button is a great feature of the standard web site user interface. Unfortunately, the back button doesn’t mesh very well with Javascript. Keeping back button functionality is one reason not to go with a pure Javascript web app.

Keep in mind however that good web design provides the user with everything they would need to successfully navigate your site, and never relies on web browser controls.

Not giving immediate visual cues for clicking widgets

If something I’m clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on. An example of this is GMail loading button that is in the top right. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading, to make up for the fact that Ajax doesn’t trigger the normal web UI for new page loading.

Leaving offline people behind

As web applications push the boundaries further and further, it becomes more and more compelling to move all applications to the web. The provisioning is better, the world-wide access model is great, the maintenance and configuration is really cool, the user interface learning curve is short.

However, with this new breed of Ajax applications, people who have spotty internet connections or people who just don’t want to switch to the web need to be accomodated as well. Just because technology ‘advances’ doesn’t mean that people are ready and willing to go with it. Web application design should at least consider offline access. With GMail it’s POP, Backpackit has SMS integration. In the Enterprise, it’s web-services.
Don’t make me wait

With Firefox tabs, I can manage various waits at websites, and typically I only have to wait for a page navigation. With AJAX apps combined with poor network connectivity/bandwidth/latency I can have a really terrible time managing an interface, because every time I do something I have to wait for the server to return a response. However, remember that the ‘A’ in AJAX stands for ‘Asynchronous’, and the interaction can be designed so that the user is not prevented from continuing to work on the page while the earlier request is processed.

Sending sensitive information in the clear

The security of AJAX applications is subject to the same rules as any web application, except that once you can talk asynchronously to the server, you may tend to write code that is very chatty in a potentially insecure way. All traffic must be vetted to make sure security is not compromised.

Assuming AJAX development is single platform development.

Ajax development is multi-platform development. Ajax code will run on IE’s javascript engine, Spidermonkey (Mozilla’s js engine), Rhino (a Java js implementation, also from Mozilla), or other minor engines that may grow into major engines. So it’s not enough just to code to JavaScript standards, there needs to be real-world thorough testing as well. A major obstacle in any serious Javascript development is IE’s buggy JS implementation, although there are tools to help with IE JS development.

Forgetting that multiple people might be using the same application at the same time

In the case of developing an Intranet type web application, you have to remember that you might have more than one person using the application at once. If the data that is being displayed is dynamically stored in a database, make sure it doesn’t go “stale” on you.

Too much code makes the browser slow

Ajax introduces a way to make much more interesting javascript applications, unfortunately interesting often means more code running. More code running means more work for the browser, which means that for some javascript intensive websites, especially inefficiently coded ones, you need to have a powerful CPU to keep the functionality zippy. The CPU problem has actually been a limit on javascript functionality in the past, and just because computers have gotten faster doesn’t mean the problem has disappeared.

Not having a plan for those who do not enable or have JavaScript.

According to the W3 schools browser usage statistics, which if anything are skewed towards advanced browsers, 11% of all visitors don’t have JavaScript. So if your web application is wholly dependent on JavaScript, it would seem that you have potentially cut a tenth of your audience.

Blinking and changing parts of the page unexpectedly

The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they pop in unexpectedly. Asynchronous page changes should only ever occur in narrowly defined places and should be used judiciously, flashing and blinking in messages in areas I don’t want to concentrate on harkens back to days of the html blink tag. “Yellow Fade”, “One Second Spotlight” and other similar techniques are used to indicate page changes unobtrusively.

Not using links I can pass to friends or bookmark

Another great feature of websites is that I can pass URLs to other people and they can see the same thing that I’m seeing. I can also bookmark an index into my site navigation and come back to it later. Javascript, and thus Ajax applications, can cause huge problems for this model of use. Since the Javascript is dynamically generating the page instead of the server, the URL is cut out of the loop and can no longer be used as an index into navigation. This is a very unfortunate feature to lose, many Ajax webapps thoughtfully include specially constructed permalinks for this exact reason.

Blocking Spidering

Ajax applications that load large amounts of text without a reload can cause a big problem for search engines. This goes back to the URL problem. If users can come in through search engines, the text of the application needs to be somewhat static so that the spiders can read it.

Asynchronously performing batch operations

Sure with Ajax you can make edits to a lot of form fields happen immediately, but that can cause a lot of problems. For example if I check off a lot of check boxes that are each sent asynchronously to the server, I lose my ability to keep track of the overall state of checkbox changes and the flood of checkbox change indications will be annoying and disconcerting.

Scrolling the page and making me lose my place

Another problem with popping text into a running page is that it can effect the page scroll. I may be happily reading an article or paging through a long list, and an asynchronous javascript request will decide to cut out a paragraph way above where I’m reading, cutting my reading flow off. This is obviously annoying and it wastes my time trying to figure out my place. But then again, that would be a very stupid way to program a page, with or without AJAX.

Inventing new UI conventions

A major mistake that is easy to make with Ajax is: ‘click on this non obvious thing to drive this other non obvious result’. Sure, users who use an application for a while may learn that if you click and hold down the mouse on this div that you can then drag it and permanently move it to this other place, but since that’s it’s not in the common user experience, you increase the time and difficulty of learning the application, which is a major negative for any application. On the plus side, intuitiveness is a function of learning, and AJAX is popularising many new conventions which will become intuitive as time goes by. The net result will be greater productivity once the industry gets over the intuitiveness hump.

Character Sets

One big problem with using AJAX is the lack of support for character sets. You should always set the content character set on the server-side as well as encoding any data sent by Javascript. Use ISO-8859-1 if you use plain english, or UTF-8 if you use special characters, like æ, ø and å (danish special characters) Note: it is usually a good idea to go with utf-8 nowadays as it supports many languages).

Changing state with links (GET requests)

The majority of Ajax applications tend to just use the GET method when working with AJAX. However, the W3C standards state that GET should only be used for retrieving data, and POST should only be used for setting data. Although there might be no noticable difference to the end user, these standards should still be followed to avoid problems with robots or programs such as Google Web Accelerator.

Not cascading local changes to other parts of the page

Since Ajax/Javascript gives you such specific control over page content, it’s easy to get too focused on a single area of content and miss the overall integrated picture. An example of this is the Backpackit title. If you change a Backpackit page title, they immediately replace the title, they even remember to replace the title on the right, but they don’t replace the head title tag with the new page title. With Ajax you have to think about the whole picture even with localized changes.

Problem reporting

In a traditional server-side application, you have visibility into every exception, you can log all interesting events and benchmarks, and you can even record and view (if you wish) the actual HTML that the browser is rendering. With client-side applications, you may have no idea that something has gone wrong if you don’t know how to code correctly and log exceptions from the remotely called pages to your database.

Return on Investment

Sometimes AJAX can impressively improve the usability of an application (a great example is the star-rating feedback on Netflix), but more often you see examples of expensive rich-client applications that were no better than the plain HTML versions.

Mimicing browser page navigation behavior imperfectly

One example of this is blinklist Ajax paging mechanism on the front page. As you click to see another page of links, ajax fills in the next page. Except that if you are used to a browser experience, you probably expect to go to the top of the page when you hit next page, something JavaScript driven page navigation doesn’t do. BlinkList actually anticipates this and tries to counteract by manipulating your scrolling to scroll upwards until you hit the top. Except this can be slow and if you try scrolling down you will fight the upwards scrolling JavaScript and it won’t let you scroll down. But then again, that is very stupid way to program a page, with or without AJAX.

Another Tool

It seems everyone has forgotten that Ajax is just another tool in the toolbox for Web Design. You can use it or not and misuse it or not. The old 80/20 rule always applies to applications (if you cover 80% of what all users want/need then you have a viable app) and if you lose 11% of your audience because they don’t switch on their javascript then you have to ask yourself if changing your app is worth capturing that 11% or stick with 89% that are currently using it and move on to something else. Also web apps should take advantage of all tricks to enable them to function quickly and efficiently. If that means using javascript for some part, Ajax for another and ASP callbacks for a third, so be it.

Ashko

Ajax Tutorials for Beginners

This is the first in a three-part series of the top Ajax tutorials from around the web. Part one is for beginners, how to build your first ajax application, and understanding how it works. Part two will be for novices who have experience with ajax, but would like to take their skills to the next level. And part three will be for experts who want to... build their own gmail application? Why not. So we'll get started from the very beginning.

What is Ajax? Ajax stands for Asynchronous JavaScript and XML. In a nutshell, it is the use of the nonstandard XMLHttpRequest() object to communicate with server-side scripts. It can send as well as receive information in a variety of formats, including XML, HTML, and even text files. Ajax’s most appealing characteristic, however, is its “asynchronous” nature, which means it can do all of this without having to refresh the page. This allows you to update portions of a page based upon user events. You can: Make requests to the server without reloading the page and Parse and work with XML documents.

Our first tutorial is from the Mozilla development page. This is the number one example because it provides you will all the information you need to make a basic "hello world" ajax app. By the end of this article you will be able to make simple ajax application on your own.

Our next tutorial is from W3schools. Here we take what you learned in the previous article and we incorporate it into forms. So you can put together a log-in or registration form, and check for valid credentials without navigating away from the current page. Very convenient. The overall trick is not to put your input variables into a form tag. and your submit button should contain an onSubmit="javascript:function()"> so instead of directing the user to a new page, the javascript call will check the credentials in real time.

Now let's migrate into XML a little bit. Web Reference has a great tutorial on the basics of using XML with Ajax. The method they use for parsing XML files is very similar to the method's used in the above two examples, so make sure you totally understand how XMLHttpRequest works.

function ajaxRead(file){
var xmlObj = null;
if(window.XMLHttpRequest){
xmlObj = new XMLHttpRequest();
} else if(window.ActiveXObject){
xmlObj = new ActiveXObject("Microsoft.XMLHTTP");
} else {
return;
}
xmlObj.onreadystatechange = function(){
if(xmlObj.readyState == 4){
updateObj('xmlObj', xmlObj.responseXML.getElementsByTagName('data')[0].firstChild.data);
}
}
xmlObj.open ('GET', file, true);
xmlObj.send ('');
}
function updateObj(obj, data){
document.getElementById(obj).firstChild.data = data;
}

Although javascript is required to complete the Ajax request, you don't have to know a lot of javascript to make good use of Ajax. For example you can make a form, and onSubmit use javascript (document.getElementById()) to get the content of the input id's, and send them to a php file. Let PHP parse all the data, and return the result to javascript to display. Very minimal javascript is required, but if you know javascript is can be extremely helpful when you get into novice and advanced tutorials. Developer.com has a great article called "Ajax from Scratch" that shows different methods than the above ones, for making ajax requests. They also have a lot of more advanced javascript helping them do this, so if you are a fan of (or at least understand) javascript, check it out.

1 function Mutex( cmdObject, methodName ) {
2 // define static variable and method
3 if (!Mutex.Wait) Mutex.Wait = new Map();
4 Mutex.SLICE = function( cmdID, startID ) {
5 Mutex.Wait.get(cmdID).attempt( Mutex.Wait.get(startID) );
6 }
7 // define instance method
8 this.attempt = function( start ) {
9 for (var j=start; j; j=Mutex.Wait.next(j.c.id)) {
10 if (j.enter || (j.number (j.number < number ="=" number =" 0;" c =" cmdObject;" methodid =" methodName;" enter =" true;" number =" (new" enter =" false;">


Now the question is, what are you going to use for the back end of the ajax requests? The two most popular methods are ASP.NET and PHP. Personally I prefer PHP whether I'm using ajax or not, but that doesn't mean asp.net doesn't have it's advantages. Ajax Projects has a nice "hello world" example using ASP.NET with your new ajax requests. Before moving on to the PHP back end of things, you should also check out "Ajax and PHP without XmlHttpRequest object" from PHPit, it outlines a nice alternative to using the traditional ajax method.

url = document.location.href;
xend = url.lastIndexOf("/") + 1;
var base_url = url.substring(0, xend);

function ajax_do (url) {
if (url.substring(0, 4) != 'http') {
url = base_url + url;
}
var jsel = document.createElement('SCRIPT');
jsel.type = 'text/javascript';
jsel.src = url;
document.body.appendChild (jsel);
}

Now on to some "good stuff". Lets put what you just learned to work with something useful. First we'll look at creating a comment system for your website. Comments are a great way for users to interact with a website, and often times it's easier to let them add a comment without leaving the page they're on. To do this we'll take a look at the Ajax Feedback Mechanism from iBegin. Although it's pre-written code you can still use and learn from it. There are a lot of advanced effects in this library (fading in and out when adding / removing comments) you will understand the basic concept of taking data from a from, sending it to a backend PHP script, and showing the user the new information (e.g. "Successful log in" or "Failed log in") without leaving the web page. Web Pasties has a similar walk-thru (except no download is required) that goes through form creation and how to store, check and display data from the current page. Both of these articles are great resources to get you going on your first ajax project.

Ajax isn't limited to just input boxes either. For example, phpRiot has a walk-thru that shows you out to create real-time sortable lists. You can click and drag items into a new order (much like you can in Netvibes or Google IG). This is very nifty for sites with lots of content in one area. This way users can decide what they want to see first. The Tool Man takes the last example a few steps further by adding the ability to add multiple lists to one sorting method, add multi-row and column support and more.

That wraps it up for part one of this three-part series. From this article you should know how to create an XMLHttpRequest object, how to grab data from inside text boxes (and other input areas), and how to display that information for the user in real-time without leaving your web page. In part two we will pick up where we left off here, and go into more advanced options, so be sure you know all the information here before reading on!

Ashko

Open Source Law

Columbia University Law Professor Eben Moglen today announced the formation of the Software Freedom Law Center, whose mission is to provide pro-bono legal services globally to eligible non-profit open source software projects and developers.

"As the popularity and use of free and open source software increases and proprietary software development models are threatened, providing necessary legal services to open source developers is becoming increasingly important to prevent liability and other legal issues from interfering with its success," Moglen said. "The Law Center is being established to provide legal services to protect the legitimate rights and interests of free and open source software projects and developers, who often do not have the means to secure the legal services they need."

OSDL has raised more than $4 million for a newly-established IP fund that will provide the seed money for the new and independent legal center based in New York. Last year, OSDL announced a separate $10 million Linux Legal Defense Fund to provide legal support for Linus Torvalds and end user companies subjected to Linux-related litigation by the SCO Group. The new Law Center announced today will be an independent organization not affiliated with OSDL.

"OSDL is committed to supporting initiatives such as the Law Center to help protect the legitimate development and use of Linux and open source software," said Stuart Cohen, CEO of OSDL. "We encourage other companies and organizations like OSDL who are dedicated to securing the future of open source software to contribute to the Law Center and participate in its good works."

Overseeing the Law Center will be a distinguished board of directors comprised of Moglen; Diane Peters, General Counsel at OSDL; Daniel Weitzner, Principal Research Scientist at MIT's Computer Science and Artificial Intelligence Laboratory; and Lawrence Lessig, Stanford Law Professor and author.

"Both free and open source software face many emerging legal threats," said Lessig. "We should be skeptical of legal mechanisms that enable those most threatened by the success of open source and free software to resist its advance. The Law Center will serve as important support for the free and open source communities and for those that benefit from free and open source software."

Moglen, regarded as one of the world's leading experts on copyright law as applied to software, will run the new Law Center from its headquarters in New York City. The Law Center will initially have two full-time intellectual property attorneys on staff and expects to expand to four attorneys later this year. Initial clients for the Law Center include the Free Software Foundation and the Samba Project.

"Free software projects often face legal issues that need expert advice, but it can sometimes be difficult or prohibitively costly to obtain that advice through traditional legal channels," said Andrew Tridgell, head of the Samba project. "We are delighted that the Free Software Law Center is being setup under Eben Mogeln's excellent guidance. I think this is an important milestone in the maturity of the free software community."

Legal services provided to eligible individuals and projects include asset stewardship, licensing, license defense and litigation support, and legal consulting and lawyer training. The Law Center will be software license neutral and intends to participate directly in work currently underway around revisions to the GNU General Public License (GPL) with the Free Software Foundation. The Law Center will also work on issues around the proliferation of open source licenses.

The Law Centeris dedicated to assisting non-profit open source developers and projects who do not otherwise have access to necessary legal services.

OSDL is dedicated to accelerating the growth and adoption of Linux in the enterprise.