Macromedia Coldfusion MX 7 Web Application Construction Kit

2017-07-07 02:10:07

This chapter concentrates on issues regarding the overall user experience and ways to it improve it. The term user experience is vague and hard to measure, and different people define it differently. For our purposes, think of the quality of the user experience as being affected mainly by the combination of an application's performance, usability, and friendliness.

In other words, do people have a pleasant experience when they use your application?

Put yourself in the User's Shoes

One of the best ways to ensure that your application is pleasant for your users is just to keep them in mind as you do your development work. When you are deep into a development project, perhaps rushing to meet a deadline, it's easy to produce code that works well enough for you to move on to the next task, without asking yourself whether it's really good enough for the user.

Even if you aren't responsible for the design or navigation, you still should keep the user in mind as you put together each data-entry screen, or code each query. If users are happy, your application will probably be successful. If they spend too much time waiting, or get confused, your application probably won't be successful. In most situations, especially applications aimed at the general public, it's as simple as that.

Think About Navigation

Entire books have been written on great ways to set up navigation elements for Web sites. Navigation elements should not only look good, but also be clear and easy to use. They shouldn't offer too many choices, especially on your application's first page. At the same time, most Web sites try to put the most important content no deeper than three levels (clicks) into the navigation structure. The most important or most commonly used items should appear before the less important ones, even if this makes the sequence less predictable.

Studying the navigation elements used by your favorite Web sitesthe ones you use oftencan help. What do these sites have in common? What's the theory behind the navigation on each page? For instance, does it adapt itself to context, or does it remain consistent from page to page? Why do some elements appear on the home page, but others on a second-level page? Try to come up with rules that explain which items appear on which pages, and where. For instance, some sites tend to put "verbs" (actions) in a toolbar at the top of each page and "nouns" (articles, accounts) in the left margin; other sites do the reverse. Try to come up with similar rules for what goes where within your own application.

TIP

Discussions on navigation and other design elements can be found on a number of developer-related Web sites. One good place to start is the Dimitry's Design Lab section at the WebReference Web site (www.webreference.com/dlab).

Why it's good to be Predictable

When describing a book or a movie, the word "predictable" isn't much of a compliment. But when describing a Web application, predictability is to be pursued and cherished. As users move from page to page, they will feel most comfortable if they can predict or guess what's going to appear next.

Anticipating the User's Next Move

As you put together a page, don't think only about what the user is going to do on that page; try to imagine what they're likely to do next. If the user is filling out a registration form, they might want to know your company's privacy policy. If they're reading a press release, they might appreciate links to the company's corporate information and facts about its management team.

In general, on any page, try to put yourself in the user's shoes and ask yourself whether it's clear how to get to the next step or the next piece of information.

Scripting, Rollovers, and Widgets

JavaScript and Dynamic HTML can help make your applications more exciting to your users, but they also can cause problems. For instance, image rollovers are great when used judiciously but can really slow a page down if you go overboard.

In particular, Dynamic HTML functionality is notorious for behaving differently from browser to browser, version to version, and platform to platform. If you use Dynamic HTML, try to find cross-browser scripts you can adapt until you understand the specific limitations. As a start, www.webreference.com and www.builder.com are good places to look for scripts that work reasonably well in a variety of browsers.

You may want to consider using Flash instead of Dynamic HTML, since a Flash movie almost always behaves the same way no matter what browser or platform it is viewed with. For more information about using Flash in your ColdFusion applications, see Chapter 26, "Integrating with Macromedia Flash."

Dealing with Problems Gracefully

Even the best-crafted application can encounter problems or error conditions, so make your error messages friendly and encouraging to the user, so they don't lose trust in your Web site.

For instance, consider customizing all error messages so they match the site's look and feel. For instructions, see the section "Customizing the Look of Error Messages" in Chapter 19, "Introducing the Web Application Framework." See also Chapter 32, "Error Handling."

Easing the Browser's Burden

If an application isn't running as fast as you want, look for a source of trouble on the server side, such a <cfquery> tag that is taking too long to execute. Also, think about how much work the browser is doing to display your pages.

If you're having performance troubles, turn on the debugging options in the ColdFusion Administrator so you can see the execution time for the page. This shows you how long the server is taking to complete your CFML template(s). If the server execution time is nice and short (under a couple of hundred milliseconds, say) but pages still seem to come up slowly for some users, the problem is probably something like image size, the overuse of tables, or some other topic discussed in this section. If, on the other hand, the server execution time is long, then you need to work on the code in your CFML templates themselves.

Dealing with Image Size

No matter how ardently you strive to make your application generate sensible HTML, and no matter how hard you work to ensure that all your queries and other server-side code runs quickly, a lot of large images can slow your pages. Not only can such images take a long time to download, they also take up room in the browser machine's memory. This can affect the user's computer, depending on how much RAM and virtual memory are available.

Here are some suggestions to keep image size in check:

Create or resave your images using a program that can compress or optimize images for use on the Web. You give up a bit of image quality for a smaller file size, but the trade-off is generally worth it. Macromedia's Fireworks product also does a great job of compressing image files and generally optimizing them for display on the Web. Adobe Photoshop CS includes a terrific Save for Web option on the File menu, which lets you preview how your images will look after they are optimized. Other tools, some of them free or shareware, can provide similar results. One place to look for such programs is www.shareware.com.

Create or resave JPEGs using a progressive JPEG option, so the images can be displayed in increasingly finer detail as they are downloaded. This is more pleasant for the user because they don't have to wait for the whole file to download before they can get a sense of the image. Most graphic-manipulation packages let you save progressive JPEGs.

The width and height attributes you supply to an img tag don't have to reflect the actual width and height of the image file. You could, for instance, create an image file that is 50 by 50 pixels, yet provide width and height attributes of 100 each. The image's file size would be much smaller, but it would take up the same amount of space on the page. Of course, it would appear pixelated, but depending on the nature of the artwork, that might not matter.

If you don't know an image's width and height, you can determine them by reading the dimensions dynamically using a custom tag or CFX tag. This occurs in situations such as dealing with images that have been uploaded from users (see Chapter 34, "Interacting with the Operating System"). A number of such tags are available from the ColdFusion Developers Exchange Web site. See Chapter 23, "Building Reusable Components," for details about the Developers Exchange.

Always try to provide a sensible alt attribute for each <img> tag to describe the image. Most browsers display any text you provide in an alt tag while the image is loading or as a tool tip when the mouse pointer hovers over the image. This lets the user anticipate what each image is before it is actually displayed.

Consider using the lowsrc attribute for your larger <img> tags. With the lowsrc attribute, a small version of the image to be displayed while the full-size one is being downloaded. Consult the HTML Reference section of the Dreamweaver or HomeSite+ online help for details.

Finally, ask yourself if big images are really necessary. Can they be eliminated, or at least be made a bit smaller? Look at the Web sites you use on a daily basis. How many images do you see? Most likely, not that many. Popular sites often use other techniques (especially type size and background colors) to give a page visual impact, and they use images sparingly.

NOTE

Always provide width and heigt attributes for each <img> tag. This lets the browser display the rest of the page correctly before it has loaded the images. Without width and height, the browser might have to wait until all the images have loaded to display anything, or it might have to reflow the document several times as each image loads. The exact behavior varies from browser to browser.

Use Tables Wisely

HTML tables are a great way to display information in any type of rows-and-columns format, such as the next-n examples shown later in this chapter. These tips will help you make the most of them without placing an undue burden on the browser:

Whenever possible, provide width attributes for each <th> or <td> cell in the table. This usually speeds up the display of the table.

Specify the width attribute for an entire table as a percentage. For instance, width="100%" tells the browser to make the table take up the entire available width of the page. You can also use percentages for the widths of each <th> and <td> cell. For instance, if three <td> cells were in a table row, you could use width="50%" for the first one and width="25%" for the second two. This is helpful when you want content to spread itself evenly across the page regardless of screen resolution. If the user resizes the page, the table automatically resizes as well.

Use tables instead of solid images to add color, style, and callout sections to a page. If you want to fill a section of the screen with a light blue color, why send a light blue image to the browser when you can just include a light blue table cell instead, by seeing the cell's bgcolor to blue? The result will be smaller file size and faster speed.

Try not to use tables to control an entire page's layout. Because tables usually can't be displayed incrementally, a table often won't be displayed until the closing </table> tag is encountered. If your whole page is laid out using a single, large table, the page might not be displayed at all until the whole page has been received (regardless of what you do with the <cfflush> tag discussed below). Sometimes, however, a table can be displayed incrementally. The exact behavior varies from browser to browser. See the cols attribute for the <table> tag in an HTML reference for details.

Use Frames Wisely

Frames are a nice way to separate sections of a page. A frame-based page usually takes a tiny bit longer to appear at first because the browser must fetch each frame by submitting a separate page request to the server. However, after the frameset is loaded, subsequent page requests can be pretty quick (assuming that only one frame needs to be replaced, rather than the whole page).

NOTE

However, some users find frames confusingespecially if a lot of them are used on a page, each with its own scroll bar. If you use frames in your application, try to create a layout in which the content of each frame doesn't need to scroll.

Using External Script and Style Files

We don't discuss the use of JavaScript and Cascading Style Sheets (CSS) in this book, but they often become important parts of ColdFusion applications. CSS and JavaScript code usually are included as part of the HTML document itself, generally in the <head> section. If use the same JavaScript functions or CSS classes over and over again on a number of pages, consider moving the script or CSS code into separate files.

This way, the browser must download the file only once, at the beginning of each session (depending on how the user has set up the browser's caching preferences), rather than as a part of each page. This can make your pages display more quickly, especially for modem usersand especially if your script or CSS code is rather long.

To move frequently used JavaScript functions into a separate file, save the JavaScript code to a file with a .js extension. The file should not include opening and closing <script> tags; it should contain only the JavaScript code. Next, in place of the original <script> block, include a reference to the .js file using the src attribute of the <script> tag, like this (the closing </script> tag is required):

Similarly, to move frequently used CSS code into a separate file, save it to a file with a .css extension. The file shouldn't include any <style> tags, just the CSS code. Now, in place of the original <style> block, include a reference to the .css file using the <link> tag:

Browser Compatibility Issues

Not all browsers support all HTML tags. For instance, neither Internet Explorer nor Netscape 6 (or later) supports the <layer> tag that was introduced in Netscape Communicator 4.0. Netscape browsers don't support the <marquee> tag introduced by IE. Support for various tags also differs across browser versionsfor instance, the <iframe> tag wasn't supported in Netscape browsers until version 6.0. Support for more advanced technologies, such as JavaScript and Dynamic HTML, varies even more widely.

You can use the automatic CGI.http_user_agent variable to determine which browser is being used to access the currently executing template. The http_user_agent value is a string provided by the browser for identification purposes. You can look at the string with ColdFusion's string functions to determine the browser and version number. For instance, the following line of code can be placed in Application.cfc to determine whether the Microsoft Internet Explorer browser is being used:

You then could use the REQUEST.isIE variable in any of your application's pages (including custom tags or modules) to display Internet Explorerspecific content when appropriate: