![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Ajax is not about technology. Most developers will try to convince you that it is, using languages like XML and JavaScript to prove their points. However, that's a very limited view. More than that, it ignores the person who pays your bills: your customer, whether that's a consulting client or a boss (who, in turn, only gets paid if you have a satisfied user base).
Customers don't care about technology; they care about how the application feels, how it works underneath their hands via a mouse and keyboard. You can have all the technology in the world built into an application that fails. Likewise, you can have a simple HTML application that works great. The goal is to marry technology and usability, and this is particularly true in the case of Ajax applications.
It's important to understand what Ajax offers, both to you as a developer and to your users. Whether you brand your applications as Ajax or not, there's a new level of expectation for Web apps, and you better know what those expectations are if you plan on delivering satisfaction to your customers.
First of all, Ajax is about usability. This may surprise some developers, as Ajax brings to mind thoughts of blazing-fast response times, widgets and visual toys, and all sorts of other flashy GUI elements. Those are definitely part of the Ajax experience, but most users — not developers — simply find Ajax applications more usable. They respond like users expect them to, and elements of the application — fields, buttons, images — are where they're expected to be.
The result is an application that is comfortable to use. There's not a lot of looking around, trying to find where the zip code field is or how to zoom in on a map. If you're designing an Ajax application (and really, even if you're not), you should strive for this same degree of usability. User testing and common sense are the best guides, and we'll talk about some of the easy ways you can ensure your applications are usable and intuitive in this article.
Once you've tackled usability, you've got to deal with the responsiveness facet of Ajax applications. At first glance, this seems to be about speed. Ajax applications don't have to submit to a server-side program and refresh the page every time something happens, and that means less waiting (at least in theory). However, that part of the Ajax promise is a bit contrived. In a DSL world, there's not a whole lot of waiting going on. Your mother and grandmother probably have cable modems, rather than dial-up, and if you're reading this at work, you're very likely on a T1 or T3. The idea that Ajax apps are inherently faster is a tough case to make (and if they are, how much? 10 ms? 100 ms? Do you realize how little time that is?).
However, Ajax apps should be more responsive than traditional apps. That's not just about speed, it's also about how the application feels (and part of this is wrapped up in usability and the interface, make no mistake). When you enter your name, for example, and start to select the colors of Crocs that you like, a program has lots of time while you're doing something else. So the application might go and fetch your address, a saved credit card, maybe what people you've marked as your friends bought when they visited the store. All of that may take a lot of time, but if you're busy doing something else and then the information appears ready to use, the application feels responsive.
Where things get really tricky — and we'll talk about this in some detail — is when you start manufacturing this responsiveness. By ordering fields on your application in a particular way, you know the flow your user will work through. Therefore, you can write your Ajax interactions to take advantage of that flow. Hang on to that thought, let it roll around a bit, and we'll come back to it later with specific examples.
This is the most recognizable and at the same time most difficult distinction of Ajax applications. They "feel" like desktop applications, sure, but many times, that means that they "look" like desktop applications. My company uses the Zimbra mail suite, and it is modeled to look like Microsoft Outlook, with (I suppose) the impetus that looking like a desktop app will make it feel like one.
There's a lot of debate here, and we're going to sidestep the issue a bit. Some say that the purpose of the Web is to become the new desktop. You'll work with all your same applications — or analogues of them — but they'll be online. Everything else will look and feel the same. Others (and I admit, I lean more toward this camp) think that the Web is a unique place and does some things better than desktop apps and some things much worse. The Web is its own medium, and apps that are on the Web should be designed differently, rather than just as desktop application clones.
In either case, it is clear that an Ajax app can look like more than a 1997 HTML form, with big gray Submit Form buttons and clunky "border=1" decorations. So part of the Ajax paradigm demands a richer experience, even though most people disagree on how to get there.
Enough technique and theory. Let's dig into a sample application and get our hands dirty. To get started quickly, I've chosen to use Nathan Smith's Hoverbox (see the Resources section for links) as a starting point. Hoverbox is a simple CSS-based Web layout that lets you move over an image in a gallery and get a larger view of that image. Figure 1 shows the default Hoverbox demo:
Figure 1. Hoverbox running as a demo
For our sample, we want to modify this a good bit for usability purposes, and then we'll add some cool Ajaxian behavior to tell us a little bit about an image as it hovers or is clicked on.
Before we get into JavaScript, let's talk a bit about what we're aiming for. You're going to take the image gallery idea — using the Hoverbox CSS — and in addition to popping up a larger view of an image, you're going to bring up a set of comments about that image using Ajax. So the first thing you need to do is provide some space on the page for your comments.
Download the sample files for this article and find hoverbox.css. This is the CSS for the image gallery. You're going to make some significant changes to this file, so edit yours to match Listing 1 (or just replace the contents wholesale with Listing 1):
Listing 1. The modified CSS for our image gallery
*
{
border: 0;
margin: 0;
padding: 0;
}
/* =Basic HTML, Non-essential
----------------------------------------------------------------------*/
a
{
text-decoration: none;
}
body
{
background: #fff;
color: #777;
padding: 50px;
}
#page {
position: relative;
}
#images {
float: left;
width: 400px;
}
#details {
color: #000;
}
h1
{
background: inherit;
border-bottom: 1px dashed #ccc;
color: #933;
font: 17px Georgia, serif;
margin: 0 0 10px;
padding: 0 0 5px;
text-align: center;
}
p#footer
{
clear: both;
font: 10px Verdana, sans-serif;
padding: 10px 0;
text-align: center;
}
p a
{
background: inherit;
color: #777;
}
p a:hover
{
background: inherit;
color: #000;
}
/* =Hoverbox Code
----------------------------------------------------------------------*/
.hoverbox
{
width: 375px;
cursor: default;
list-style: none;
}
.hoverbox a
{
cursor: default;
}
.hoverbox a .preview
{
display: none;
}
.hoverbox a:hover .preview
{
display: block;
position: absolute;
top: -33px;
left: -45px;
z-index: 1;
}
.hoverbox img
{
background: #fff;
border-color: #aaa #ccc #ddd #bbb;
border-style: solid;
border-width: 1px;
color: inherit;
padding: 2px;
vertical-align: top;
width: 100px;
height: 75px;
}
.hoverbox li
{
background: #eee;
border-color: #ddd #bbb #aaa #ccc;
border-style: solid;
border-width: 1px;
color: inherit;
display: inline;
float: left;
margin: 3px;
padding: 5px;
position: relative;
}
.hoverbox .preview
{
border-color: #000;
width: 200px;
height: 150px;
}
/* Info details -----------------------------*/
.info-title {
color: #933;
}
.info-date {
font-size: 14px;
color: #777;
}
.info-text {
font: 10px Verdana, sans-serif;
padding: 10px 0;
}
|
Listing 1 adds some div elements, mostly so you can deal
with the image gallery as one unit, and details about the image (which you'll add soon) as the other major element. Most of the rest of the changes are cosmetic and support a two-column layout.
Now you need to add in a few div elements to your HTML, as
shown in Listing 2:
Listing 2. The modified HTML for our image gallery
Save and load your page and it should look like Figure 2:
Figure 2. Modified Hoverbox demo
Note: Some of this CSS is hackery. Rather than spend hours tweaking it, though, I tried to make the most direct changes possible so it was clear what I did. If you want to tidy it up, feel free!
User Interface 101: Reading from left to right
You may not have noticed, but you made a very important decision in this change: you've decided to leave the gallery on the left and add detail about each image on the right of the page. You had several choices:
- Put the gallery on the left and the information about the image on the right (like you did).
- Put the gallery on the right and information about each image on the left (the opposite of what you did).
- Come up with some new, clever arrangement that is neither of the first two options.
The most obvious no-no is the second option, and here's why: Westerners read from left to right (see Figure 3). It's built into our heads from the time we're babies and a parent or grandparent reads a book while pointing out the words. Our eyes are conditioned to move from left to right. (There's a larger science here, called z-tracking, that goes beyond the scope of this article.) Anytime you go against this trend, you're fighting decades of any particular human's experience. In your gallery, you see an image on the left, click or hover over it, and then move your eyes to the right to read about that image. It's a very natural feeling, and your users will immediately feel comfortable and at home, even if they're not very Internet-savvy.
Figure 3. A standard z-tracking pattern, left-to-right and then down
If you flip this paradigm, you create an unnatural right-to-left movement (see Figure 4). Images are on the right, and then you move your head back to the left to read about the image. A big deal? It wouldn't seem so, and users will never tell you, "Wow, I hated moving my head from right to left." However, studies show that over time, subtle discomfort will emerge with the unnatural flow. Better to go with the feeling of a book here.
Figure 4. Forcing the eye to go from right-to-left
The third option — coming up with a new and clever approach, perhaps popping up information below the gallery or shuffling the images around to insert the information about the image in the middle of the gallery — is dangerous. For users comfortable with computers and next-generation applications, it's probably not going to be a big deal. But for less experienced users (especially for those in-laws who just logged on to see your photos or to pay their electric bill) all that cleverness is confusing or annoying. Less-experienced users don't want things moving around, or flashing, or acting in unexpected ways. They want their online experience to be simple and straightforward, like reading a book or newspaper! So stick with the left-to-right approach in your own user interfaces; it will pay off.
At this point, most developers would jump right into the JavaScript event handlers on their page. Hold off on that, though. Instead, we need to take a look at how the rest of the data on the page will look.
The most important reason to do a little mockup work at this stage is because dealing with HTML — in the best case — is a pain. It's fickle and full of angle brackets. But, we've learned to work with it. However, throw that HTML into JavaScript and the DOM, and it's even easier to misplace a p element or id attribute. By mocking up your data, you can be sure it looks like you want it to look without all that hassle.
Then, once you've got the data looking just right, it's trivial to drop it into whatever code you need. It's also easy to strip out the data and focus on just structure, which is what you'll need to do when working with the DOM.
Let's add a little HTML to our page, simulating a title, date, and a journal-type entry for each photo. Add in the "details" div after the images div, right before the page footer:
Listing 3. HTML for the page
<a href="#"><img src="img/photo20.jpg" alt="description" />
<img src="img/photo20.jpg" alt="description" class="preview" /></a>
</li>
</ul>
</div>
<div id="details">
<h2 class="info-title">Sunrise over the bay</h2>
<h3 class="info-date">27 October, 2006</h3>
<p class="info-text">Here is what I experienced when
I took this photo.</p>
</div>
<p id="footer"><a href="http://validator.w3.org/check/referer">XHTML</a>
<a href="http://jigsaw.w3.org/css-validator/check/referer">CSS</a>
<a href="http://www.contentquality.com/mynewtester/cynthia.exe?Url1=
http://host.sonspring.com/hoverbox/">508</a> |
Hoverbox by <a href="http://sonspring.com/">Nathan Smith</a>. |
Read the
<a href="http://sonspring.com/journal/hoverbox-image-gallery">Tutorial</a>.</p>
</div>
</body>
|
The CSS for these classes is in Listing 1. Load this page in your browser to make sure it looks right (refer to Figure 5):
Figure 5. An entry for each photo
This may look simple, but there are some important things going on. First and foremost, the text gets smaller as it moves down the page. While this may seem like a small detail, it has a great effect on Web page perception (remember the discussion on usability at the beginning of this article?) as moving from left to right. Figure 6 shows the ideal progression of text down a page:
Figure 6. Text should get smaller moving down the page
This probably seems like a trivial point, not that big of a deal. But it turns out to strongly affect the perception of your application by users. In fact, let's make the image gallery at the top of the entire page a bit bigger and see what that does to the page. Change your CSS for the h1:
h1
{
background: inherit;
border-bottom: 1px dashed #ccc;
color: #933;
font: 32px Georgia, serif;
font-weight: bold;
margin: 0 0 10px;
padding: 0 0 5px;
text-align: center;
}
|
It's a small change, but if you look at Figure 7, the page looks quite different:
Figure 7. Increasing the size of the page heading
The biggest problem with the page now is the lack of font consistency. The heading is Georgia, but the photo details, title, and date are not. It produces a messy look, so you can make a few quick changes to take care of that, also to your CSS, near the bottom:
/* Info details -----------------------------*/
.info-title {
font: Georgia;
color: #933;
}
.info-date {
font: 14px Georgia;
color: #777;
}
.info-text {
font: 10px Verdana, sans-serif;
padding: 10px 0;
}
|
We've just changed the font to Georgia to be consistent with the heading font (yes, there are more generic ways to do this in CSS, but again, I'm choosing the most obvious approach here).
You may have noticed that the body text — the portion of text about the photo — is not consistent with the rest of the page. That's because body text gets to break the consistency rule, especially if your heading fonts are serif fonts (serif fonts have the little squiggles, like at the end of the downstroke of the "y").
Serif fonts look cool but create a lot of eye fatigue in large blocks of text. Most books are printed in sans-serif fonts (despite the popularity of Times New Roman, a serif font). In fact, if you submitted a manuscript to most publishing houses, you'd be required to submit your manuscript in a sans-serif font. So for small or lengthy text, go with a sans-serif font. The result of making all these font changes is shown in Figure 8:
Figure 8. The current image gallery
The last thing that stood out to me was how cramped the top title looked with the images and the details. This is trivial to fix, by just increasing the margin a bit between the heading and the images:
h1
{
background: inherit;
border-bottom: 1px dashed #ccc;
color: #933;
font: 32px Georgia, serif;
font-weight: bold;
margin: 0 0 20px;
padding: 0 0 15px;
text-align: center;
}
|
This gets us to the look shown in Figure 9:
Figure 9. Adding a little space to the top
These are tiny changes and may seem silly or even inconsequential to you. However, you have to keep in mind what I talked about at the beginning of this article: your applications are for real people. They're not about showing off your technical chops. So tweaking fonts, making sure everything is consistent, ensuring spacing is right... these all result in a very professional and usable application.
I imagine some of you are looking frantically for all the Ajax code: the XMLHttpRequest objects and send() calls. Don't worry, they're coming in the next article. This article has been focused on crafting a usable front-end setup, and that involves a lot more than JavaScript. In fact, it's mostly about fonts, look-and-feel, and spacing.
As boring as it may seem to you (especially if you're a heavily analytical type of person) you've got to work on these aesthetic issues. Otherwise, you'll have a technically superior, completely ugly, and unusable application. Believe me, the Internet is littered with these sorts of applications.
So take a little time to make things look right. Focus on moving your users' eyes from left to right and keeping fonts consistent and moving from large to small as their eyes run down the page. Work on spacing and a clean look. Your users will love you for it, and you'll be ready for the challenges in the next article (which will involve a lot more programming!).
| Description | Name | Size | Download method |
|---|---|---|---|
| Source code for this article | wa-aj-frontend-startSamples.zip | 279KB | HTTP |
| Source code for this article | wa-aj-frontend-completeSamples.zip | 280KB | HTTP |
Information about download methods
Learn
- Check out the Hoverbox documentation used as the basis for this article's examples.
- Hoverbox has an online demo if you want to see where we started.
- Take the techniques in this article and apply them to Lightbox, an even cooler JavaScript toolkit.
-
Find more Ajax resources on Wikipedia.
-
The developerWorks Web development
zone is packed with tools and information for Web 2.0 development.
-
The developerWorks Ajax resource
center contains a growing library of Ajax content as well as useful resources to get
you started developing Ajax applications today.
Get products and technologies
-
Head Rush Ajax
(Brett McLaughlin, O'Reilly Media, Inc.): Takes the ideas in this article and loads them into your brain, Head First style.
-
Java™ and XML, Second Edition
(Brett McLaughlin, O'Reilly Media, Inc.): Includes Brett's discussion of XHTML and XML transformations.
-
JavaScript: The Definitive Guide
(David Flanagan, O'Reilly Media, Inc.): Includes extensive instruction on working with JavaScript, dynamic Web pages, and the upcoming edition adds two chapters on Ajax.
-
Head First HTML with CSS & XHTML
(Elizabeth and Eric Freeman, O'Reilly Media, Inc.): Learn more about standardized HTML and XHTML, and how CSS can be applied to HTML.
Discuss
-
developerWorks
blogs: Get involved in the developerWorks community.
- Participate in the
discussion forum.
Brett McLaughlin has worked in computers since the Logo days. (Remember the little triangle?) In recent years, he's become one of the most well-known authors and programmers in the Java™ and XML communities. He's worked for Nextel Communications, implementing complex enterprise systems; at Lutris Technologies, actually writing application servers; and most recently at O'Reilly Media, Inc., where he continues to write and edit books that matter. Brett's upcoming book, Head Rush Ajax, brings the award-winning and innovative Head First approach to Ajax. His last book, Java 1.5 Tiger: A Developer's Notebook, was the first book available on the newest version of Java technology. And his classic Java and XML remains one of the definitive works on using XML technologies in the Java language.
Table of contents
Next steps from IBM
Create rich Internet applications using WebSphere Portal Express Web 2.0 technologies.
- Try: WebSphere Portal Express
- Article: Get started using Ajax and WebSphere Portal Express
- Tutorial: Quickly build a an Ajax-enabled WebSphere Portal Express Web application
- Demo: Architecture, design, and construction using the IBM Rational Software Delivery Platform: AJAX
- Buy: WebSphere Portal Express
