Logo

One of the more innovative web development interfaces that has come along in recent years is AJAX (Asynchronous JavaScript and XML). The use of AJAX allows web developers to dynamically change content on a web page without having to refresh the entire page in a web browser. There are divisions in the the web developer community on the downsides of using AJAX from a usability standpoint. So with that in mind, let's talk about a big issue associated with the use of AJAX as it may impact web sites: usability and data presentation.

This discussion will focus on two web sites: si.com and our web site. These two sites are related in that both sites use AJAX to present basketball information. SI.com uses it to choose and display scores on a page. Our site uses it to present the television broadcast schedule databases.

The first issue is usability and data presentation. Two years ago, I made the conscious decision to go with an AJAX-based presentation of the the TV schedules. The reason was two-fold.

The first was as a proof of concept demonstrating how information stored and managed in IBM Lotus Notes and Domino could be easily integrated into other web sites at a fraction of the cost that some organizations are spending to do something similar. In this case, it was the NCAA. They had spent considerable sums of money on an IBM WebSphere Portal solution that was/is woefully inadequate in their data presentation. Instead of going into deep discussion of that here, you can read "When Bad Portals Happen to Good Organizations" over on the Business Controls Caddy.

The second was to make the access to the information as user-friendly as possible. By using AJAX, I was able to allow people to see data on a single screen without scrolling and/or without having to go through multiple page loads. In my use of AJAX, I only have to worry about the "redraw" of one section (i.e. div tag"). However, last year I made a subtle change on the basketball schedule presentation (not done this year yet). This change was not only to refresh the schedule information, but to display the school/conference logo and name when a specific school or conference was selected for display. This meant that if the presentation was to be accurate, I had to redraw two sections of the screen to match.

This is where the si.com web site comes into play. When I opened the story on FIU's loss to North Carolina last night, there was a "FanNation Game Flash" score banner at the top of the page displaying the Top 25 scores:

If you change the drop down to show you America East scores from last night, you get the Albany - Syracuse score as expected:


But what happens when you pick a conference that had no games that night? You might expect it to display "No games scheduled." But this is not the case, as you the header changes to reflect the conference selected, but the scores are not removed:


Is this by design, or a coding oversight? If the former, you need to ask why that approach was taken. If the latter, you have to ask if they did not think through this particular use case, or they just did not do thorough testing.

This is not to say this type thing does not happen a lot. It happens to all developers, including me. You might think you have every angle covered, but your end users will always find something you did not think of in your design, development, and testing.

So What Does This Mean To You?

If your organization is developing a web site for internal (Intranet) or external (Extranet and or Intranet), you need to bring in actual users from the stakeholder communities to give you guidance, feedback, and usability testing. There are a number of questions that need to be addressed, including:

• You need to look at performance issues for the users. A web site my look all cool, jazzy, and hip on your desktop, but what happens with the users at the end of the pipe?
  
  
• What if they have disabled JavaScript? Is your design deprecated enough to handle that scenario?
  
  
• What if they are still on dial-up for Internet access? How will the site perform in that case?
  
  
• If you are using AJAX and they have to use a screen reader, will they still have access to the data? If not, will they abandon your site in favor of one that meets their needs?

We wrestle with those issues every day for this site, and that is why we do a lot of test-bed/sandbox type initiatives on here. But there is one down-side to that, which applies to all web sites in general:

If users are having problems using your web site, they will almost NEVER tell you. They will just leave, tell their friends how bad their experience was, and never come back.

This happened to CBSSports.com last year. During severe weather all up and down the East Cost and Central states, there were huge performance hits on their Fantasy Football site during the Sunday Night Football game. The message boards and Twitter was abuzz with users complaining and dissing the site/brand. But did anyone think that the problem was not internal to CBS Sports, and that it had to do with the Internet infrastructure as a whole? Did any of them contact CBS Sports to ask them about the problem. The answer is no on both counts (as we verified with the CBSSports,com later).

You see, users do not care about issues with the wiring and plumbing. They just care that the site/tool they are using is behaving poorly. And that is what/who they blame.

Is your brand worth that risk?

Interested in learning more?

If you would like to talk to us about how we can work with you on these and other business process issues, both technical and non-technical, you can email us at infoATthecayugagroupDOT.com (replacing the AT and DOT of course) or call us at 706-363-0299.