Too much AJAX

In my role as a customer experience consultant (with Tealeaf), I get to research many types of web sites built by a variety of organizations. Focusing on usability issues, I get to analyze web site implementations where the use of AJAX is a big factor today. Alas, too many sites have gone wild and crazy and deliver too much AJAX.

Back in the old Web 1.0 world of ten years ago, developers broke business processes into nice, consumable chunks called pages. It was easy to break down a business form into nice logical pieces that were easy to implement and easy for customers to understand. For example:

• A loan application. You filled out your personal information on one page, next your financial, next your employment, and finally a confirmation page.

• Buying a product. A search page, product description, shopping cart, and purchase pages.
• Booking a hotel. Enter your travel dates, desired location, search, select, and purchase.

All nice and logical, right? The greatest part is that the sites are easy to support as well as functional. If a form needed fixing or page need tweaking, you only had to troubleshoot that page in the process. Making changes and rolling them out was not that complex or earth-shattering. Life cycle management of Web 1.0 sites was reasonable, easy, and cost-effective.

But the introduction of too much AJAX now replaces this easy life cycle with complex, insupportable models. The worst is the insurance industry. They seem infatuated with taking very complex, ten page processes and slamming them into one page AJAX nightmares. In order to debug a problem on the eighth end user page, the developer has to start at the first page, enter in pages of test data just to get to the eight page. What used to take 10 seconds to test now takes minutes. Over and over again. And we haven't gotten this into the user's hand yet! Ouch!

Now try compound all this client-side AJAX in all the tablets, phones, and laptops coming out. Yikes! To me it seems like a plot by the consulting and design firms to keep fat support contracts to support all this spaghetti code. Yuck. Too much AJAX.

Thank goodness some sanity is out there. Retail sites seem to get it and avoid too much AJAX. Also, the new design models based on HTML5 and Responsive Design appear to lead the next generation back into supportable design models, with simpler code implementation and avoiding the too much AJAX applications that have 80 JavaScript files to build a business process in the browser.

Best Practices

In my travels with my customers, I've come to understand where AJAX in a page makes sense. Here are just a few:

• Vehicle look-up. When I pull down a menu, an AJAX call fills it with only the cars I need.
  
• Search terms as I type. As I type "laptop", the search bar autofills other searches to save me time.
  
• Content display as I navigate. As I interact on the page, content appears or pops up that is relevant to me. AJAX calls make this possible, improving my customer experience.
  
• Inventory checks. On the same product page, knowing it is really in stock is very helpful. Ditto for shipping charges and taxes.
  
• Filtering choices. As I select certain dates, only the Hotels with openings are listed, as I filter on brands, the page refreshes with content.
  

Using AJAX, just the right amount, makes for a wonderful site experience. Hopefully the mobile and tablet evolution will return us to the middle, blending the best of web 1.0 and web 2.0, giving us sites that are:

• Sexy interfaces that are fun to use
• Easy for developer's to troubleshoot and support
• Leveraging the devices that I want to use
  
• Keeping support costs down
  

Performance Challenge: The Misconfiguration

There are a number of performance challenges that many websites find themselves, but nothing worse than the Misconfiguration. Last week, a customer noted that "my site seems very slow." So I fired up Gomez and started testing. The page was very heavy at over 1.5 Mbytes, but still, 70 seconds on average was terrible! I drilled into the data on behalf of the customer and saw swings of excessively long Content Download times, which usually indicates something is misconfigured with the web server. Note the graph showing the oscillation up and down. Not only are things slow, but swinging wildly, totally inconsistent.

So how did things get fixed?

The engineers looked at the switch ports and found this:

#sho int g2/370
GigabitEthernet2/370 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 001f.ca6f.8424 (bia 001f.ca6f.8424)
Description: serverwww:eth0
MTU 1500 bytes, BW 100000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100/1000BaseT
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 40w2d, output hang never
Last clearing of "show interface" counters 00:21:11
Input queue: 0/2000/389/0 (size/max/drops/flushes);
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
4114 packets input, 4232945 bytes, 0 no buffer
Received 21 broadcasts (0 multicasts)
2 runts, 0 giants, 0 throttles
389 input errors, 108 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
4400 packets output, 1192528 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 PAUSE output
0 output buffer failures, 0 output buffers swapped out

So basically, the silly ports on the switch and the server were in a mismatch. Packets were getting dropped or munged between the switch and the server. After manually checking both sides and making sure everything was set, the performance impact was HUGE! Think of over 55 seconds on average. WOW!

So ... checking all the silly details gives us huge wins for the customer. Another misconfiguration win!

Performance Dashboards

Back the early Internet age, I was a consultant helping build marketing data warehouses. There were a number of great spokes-persons of our niche industry, notably Ralph Kimball and Bill Inmon. Both published a lot of books and both educated many of us on critical data management issues. A rising star from those days was Wayne Eckerson, who became the Business Intelligence guru. Wayne published a great book, Peformance Dashboards, which really leverage the 1990's wave in data warehousing with the web analytics of this decade, blending the metrics to deploy business performance dashboards.
The key summary of this book is that dashboards, scorecards, metrics, monitoring, and analytics all get munged into one screen of information. Keeping the key things simple to understand makes it easier for the entire company to focus their efforts and work to making things better for the customer. The dashboard translates strategy into objectives, metrics, and initatives for each team to achieve.

My favorite dashboard that combines the world of the web, data warehouse, and basic business systems is that from the Indiana Musuem of Art.

They have combined all the great metrics to run their business on published it on the web. Just think how you could transform your web site infrastructure and make this your Intranet. All the employees (and even customers!) can see what is important to the company. Clicking on a KPI gives you the trends over time and they even have "cross-selling" references on the left of the page. Totally a wonderful example.