AJAX Angst (part 1 of 2)

So someone at your company decided that you need to jazz up your web site with “Web 2.0” technology.  You need a Rich Internet Application (RIA), which might involve using this new AJAX technology.    What is AJAX? (And no, it is not a household cleanser).How does it change the customer experience? How can you measure it? 

AJAX stands for Asynchronous JavaScript and XML, but it’s really a combination of multiple technologies including Dynamic HTML, JavaScript, and dynamically created requests for data from a web server.  The result is a web page that behaves more like an application installed on your PC (like the word processor that I am writing this with).  This means that instead of the page, page, page interaction typical of most web sites, you just operate one web page, which changes as you interact.  This can greatly improve the user experience by avoiding the sometimes jarring experience of each page unload/reload where the entire window changes appearance.

If you use the web regularly, you have probably used AJAX applications, even without knowing.  Address books are a current popular use of the technology,  the page might include a search field where you can type in search terms to find in your address book, which is located on a web server far, far away.  Under the search field is a list of names and addresses, maybe the first 10 contained in the address book.

When you type “John” into the Search field and hit the enter key, the JavaScript program running in the web page formats a search request and tells your web browser to send the request to the web server, just like you tell the web browser to go to google.com.  The web server receives the request and responds with a list of names and addresses containing the word “John”, formatted using the XML standard (eXtensible Markup Language, aren’t acronyms fun?).  The browser provides this data to the calling JavaScript which creates Dynamic HTML that the browser formats and displays to you.  If you change the search term, the process repeats.

Compared to a “regular” web page, the screen did not refresh with a new version of the page showing the list of “John”s, only that part of the screen listing the first 10 addresses changed.

At this point, it is interesting to consider how the back button would work, or more importantly, how it would affect the user’s experience?

• If they hit the back button now, would they expect to see the original list of addresses?
• Will they be surprised when they return to the page preceding the address book?
• Will they hit the back button, lose focus and leave the site?

This simple example is just one of the considerations developers and designers face when integrating AJAX to make web pages more application-like.  Within the customer experience, the user interface metaphors start to get mixed up.  The end user can become confused as paradigms change and the effort to enhance the experience, could actually lower conversion and cause users to abandon..

In addition to changing the user interface paradigm, AJAX has also added complexity to the development team. Before, if there was an error on the page, say the server returned a blank list instead of the first 10 “Johns”, the programmer would look at the code on the server to troubleshoot.  With AJAX  the programmer needs to look at both the code on the server and the JavaScript running in the web page, then consider what user variables could be in play and attempt to recreate the error.  This takes us back to a core QA issue, with yet another set of variables.

• How can I accurately monitor and measure the user’s experience?
• How can I troubleshoot off averaged analytical website data?
• Is this new feature helping or hurting the overall customer experience?

To address the challenges within development and testing (as well as measuring the impact of the AJAX initiative against marketing goals), you really need to have the entire user’s experience and that starts with data capture.

I’m often asked, “How does it work, can you really track AJAX?”

With a regular web page, Tealeaf CX captures the data stream between the web server and the browser.  But for AJAX, the user interactions are within the web page, so no data is being transmitted, therefore how can Tealeaf see what is happening?

To capture this interaction, the web page programmer adds a line of code to the web page (usually near the top) that tells the browser to include Tealeaf-supplied JavaScript code from the server.  This code “instruments” the regular JavaScript application.  It can collect information about the user environment - what is the current screen size set to?  Is it big enough to show the entire page?, etc. 

The code also makes sure that all the objects on the page (e.g., that “nice” tabbed look across the top of the address book that lets you show different fields) have a unique ID.  And most importantly, the JavaScript captures every character typed, every button pushed,and (if desired) every movement of the mouse. 

Within AJAX applications,  we have extended the insight available, and our customers now have the data they need to create actions.

However, sometimes even the best intentions can go awry.  In part II, I’ll address an interesting  “real-world” scenario.

If you have an AJAX challenge or want to  determine if your RIA is adding value, I encourage comments...

-Mark Neumann, VP of Engineering