Here are several suggestions to consider when looking to speed up your application:

1. Reduce the total number of server calls that you need to make from your application by using FQL queries over standard Facebook API calls.

2. When you need to make several API calls at one time, use the batch.run method to combine up to 20 calls into a single request to the Facebook server.

3. Use FBML canvas pages rather than iframe pages. According to Facebook, FBML pages are faster.

4. Move JavaScript and CSS code to external files and then import them into your pages. Facebook caches these files the first time they are accessed and stores them indefinitely.

5. Use the fb:ref element to store FBML content, particularly when you need to publish to multiple profile boxes. Facebook caches fb:ref references, making them quickly accessible on future usage.

6. Most Facebook applications call friends.get at some point during their operation, consider making this call during your initial app load to minimize server requests.

7. As in any Web application, keep your canvas pages manageable in length. If you are displaying multiple rows of data, divide your content over a series of pages. Consider, for example, how the Photos app handles this when viewing an album.

8. Use AJAX when refreshing page content, limiting the page refresh to part of a page rather than the entire page.

Relative addressing means the link paths are set up to be relative to the directory where the current page resides. For instance, “images/gif/btn.gif” exhibits relative addressing, in which the file is in the subdirectory “gif,” which is under the “images” subdirectory, which is in turn under the directory in which the current HTML document resides.

Furthermore, using “../” at the beginning of the reference sends the browser up a level, so that “../../gif/btn.gif” sends the browser up two levels from the location of the current page, and then down to the “gif” directory where the file is located.

Absolute addressing, conversely, means that each page is accessed independently, via the full URL. The absolute address for the aforementioned image might be “http://www.whatever.com/root/someSubCategory/images/gif/btn.gif.”

The problem with absolute addressing is that if you move the site, either from your local machine to the web server or to an entirely new web server, all the links break. Such moves necessitate updating every absolute address to point to the new location, often a time-consuming and error-prone task. On the other hand, relative addressing should work flawlessly regardless of where the site happens to be located, as long as the site’s directory and link structure remain unchanged.

Although you have no choice but to use absolute addressing for links to pages outside of your site, make sure to use relative addressing for all links to pages within your own site.

The exception to this trend would be for sites like online e-mail accounts (Gmail, for example) and search engine results listings, where extensibility is important because it allows those sites to display more content when the browser is maximized.

For everyone else, the shift away from fluid designs likely has more to do with page readability and printability than with accessibility (the ease with which visitors with disabilities and nonhuman devices can access and navigate through a site).

Think about your own preferences. Wouldn’t you rather read a long, narrow page than a wide, short one? And how important is it to you that a site’s design extends the full width of your browser window at any monitor resolution?

It probably doesn’t matter that much to you, which means that the average Internet visitor for any one site never considers the difference between a site with an expanding layout versus one that has a fixed width.

If you and your client choose the fixed-width design size, the next aesthetic design issue that you need to decide upon is the orientation of the page relative to the browser window. Will the design begin fixed to the upper-left corner of the browser window, leaving empty space to the right of the design, or will it be anchored to the top of the page but aligned to the center of the browser window with empty space to both the left and right of the fixed-width design?

Neither solution is better than the other, so choosing the right one is simply a matter of taste. In recent years, the prevailing trend has been to create fixed-width designs that are center aligned to the browser. As you know, however, trends change. Ultimately, you should choose a design layout that will suit the client’s needs and the Web site’s content and, above all, cater directly to the target audience‘s preferences.

Simple—invite the management to sit in on the testing. Let them hear for themselves the complaints and responses of their potential customers.

For instance, we have created a web site with blue buttons for navigation and green buttons for submitting forms. If we name the buttons “btnBlue” and “btnGreen” and then later the color scheme of the web site changes, our button names become meaningless.

On the other hand, if we name the buttons “btnSave” and “btnSubmit,” then the sudden order from management to change the color scheme of the site will not fill us with dread and will in fact be relatively painless.

Use this navigation and jump directly to content :

{Usability} {Instructions} {Visitor Support} {Accessibility} {Help} {Feedback} {Error Handling} {Form Submission} {Text Input Controls} {Selection Controls}

Usability—Did you:

1. Do everything possible to reduce visitor effort—visually, cognitively, and physically?

2. Minimize visitor clicks, keystrokes, mouse movements, and scrolling?

3. Avoid asking for any data until after visitors are aware of the benefits?

4. Avoid asking for unnecessary or redundant data?

5. Indicate which elements are required and which are optional?

6. Present input controls in the expected order?

7. Use wizards and control panels appropriately?

8. If employing control panels, chunk the input elements by category?

9. Specify an appropriate tab order and initial focus, when appropriate?

Instructions—Did you:

1. Provide adequate instructions so that separate help is rarely needed?

2. Accurately label each form control, and place each in close proximity and visual connection to the fields it explains?

3. Make documentation apparent but unobtrusive?

4. Use a consistent vocabulary?

5. Include the title attribute on form elements to provide concise instructions on rollover?

Visitor Support—Did you:

1. Practice defensive design, so that the form is so intuitive and easy to use that little additional support is necessary?

2. Try to be brief and salient, telling visitors only what they absolutely need to know to accomplish their tasks?

3. Provide obvious documentation for probabilities, not possibilities?

Accessibility—Did you:

1. Whenever possible, place labels to the left of controls, or associate the label and its control with the <label> tag?

2. Surround related form elements with <fieldset> tags and include the <legend> tag for labeling?

3. Avoid populating controls with instructional text as the default value?

4. Avoid using list boxes when multiple choices are possible (i.e., using the multiple attribute)?

5. Avoid setting the default value for a single yes/no checkbox to “yes”?

6. Use the title attribute to provide tooltips on rollover?

Help—Did you:

1. Use contextual help whenever possible?

2. Provide a hot-linked table of contents or site map, and a search function for larger Help systems?

Feedback—Did you:

1. Provide feedback, particularly for long waits and errors?

2. Use modeless, rather than modal, feedback whenever possible?

Error Handling—Did you:

1. Provide error messages that are helpful, clear, non-technical, concise, polite, tactful, non-accusatory, apologetic, and visible?

2. When a server-side error is encountered, either redisplay the entire form or just the subset of controls that are in error?

3. Display an error message on the same page as the field that needs to be corrected?

4. Remember that successful resolution of a problem builds stronger customer loyalty than delivering a product that performs flawlessly?

Form Submission—Did you:

1. Use the appropriate control to submit a form?

2. Avoid telling visitors not to click a Submit button twice?

3. Avoid using Reset buttons?

4. If you do use a Reset button, verify that the user intended to click it?

5. Position buttons in close proximity and visually connected to their form elements?

6. Position the safer or more positive action button on the left, and the riskier or more negative action button on the right, making sure that default focus lands on the safer of the two actions?

7. Confirm risky actions?

8. After submission, reassure a visitor with a response page that re-displays the entered information?

9. Verify completeness and format of all entries as much as possible before submitting the form to the server?

Text Input Controls—Did you:

1. Use <input type="text" /> for one-line text input, or <input type="password" /> for a one-line text input with the entered characters hidden by asterisks?

2. Specify a size and maxlength that roughly correspond?

3. Display relevant field formatting and punctuation, such as dashes within dates?

4. Use the value attribute to specify a default value if 80% or more of the audience can use the default?

5. Avoid using the value attribute to display instructions for the field?

6. Use the <textarea> tag for multiple-line text input?

7. Use wrap="soft", "hard", or "off" to determine whether carriage returns are used and whether they’re saved with the <textarea> field?

8. Use <textarea> to display informational text that needs to scroll?

Selection Controls—Did you:

1. Use <input type="radio" />, <input type="checkbox" />, or <select> for a limited number of choices?

2. Filter out those options that become irrelevant because of earlier choices?

3. Use <input type="radio" /> for a short list of mutually exclusive choices?

4. Use <input type="checkbox" /> for a short list that allows multiple choices?

5. Align checkboxes and radio buttons vertically?

6. Visually chunk related radio buttons and checkboxes?

7. Use <select> for a longer list that would cover too much screen real estate if all the choices were displayed at once?

8. Decide whether or not to place the most common choices at the top of the list?

9. Use size="1" for a drop-down list, and a size with a value greater than 1 for a scrollable list?

10. Use <optgroup> to chunk related options within a select box?

Don’t forget to look at “All In One Design Checklist” after this article.

Consequently, the best way to support an organization’s goals is to consider how best to support our visitors’ goals. How do we go about sustaining a business goal, such as to sell lots of products, while at the same time supporting visitor’s goals to buy something? What works for both of us? Well, of course we need to demonstrate to visitors that our site is reliable and provides the best value, or the best quality, or the best service. Then we allow the visitors to make purchases easily and quickly. Anything that interferes with visitors’ goals is ultimately counterproductive to a site’s goals as well, because visitors will be disinclined to use the site.

We define or identify our visitors’ goals by getting feedback from current customers, interviewing potential visitors, and analyzing competing web sites. Visitor goals might include:

1. Purchasing products or services online, as economically and efficiently as possible.

2. Researching products or services for future purchase, either online or at a retail store.

3. Obtaining service for a product that he or she already owns.

4. Obtaining information about a topic of interest.

A use case is a step-by-step documentation of a sequence of interactions that must be completed for a visitor to accomplish a task, presented from that visitor’s point of view. Normally, there is one main scenario for successful completion of the basic task, plus additional scenarios for alternate paths when things go wrong or for when the task has an unusual component.

Put all the scenarios together, and you have a complete use case for a typical user interaction. See the below for simple an example of a use case that includes two alternate scenarios.

Use Case For Purchasing A Product

1. The customer browses the on-line catalog and adds desired items to the shopping cart.

2. When done shopping, the customer clicks the “checkout” button.

3. The customer enters the shipping information.

4. The system presents full order details, including shipping costs.

5. The customer enters credit card data and clicks “place order.”

6. The system verifies the credit card.

   Alternative: Authorization Failure

   1. The system fails to authorize the credit card.

   2. The system allows the customer to re-enter credit card information up to two more times.

   3. Upon third failure, the transaction is terminated with an error message.

7. The system confirms the sale immediately.

8. The system sends a follow-up email to the customer.

Alternative: Repeat Customer

1. The system displays the full order details, including the customer’s standard shipping option and the last four digits of the credit card.

2. The customer may accept or reject the standard shipping and credit card information.

3. The customer clicks “place order.”

4. See Steps VI and VIII in the primary scenario.

We also need to analyze how often a visitor might perform each task. Those that are performed often should take priority and have the most visibility on the site.

Design Patterns

One way of analyzing any task is to see how it might fit into a design pattern, a common, recurring problem that can make use of a standard solution. This technique relies on the belief that almost anything that anyone might want to do has been done already.

Only rarely does a site do something radically different from that recognizable metaphor. When it does happen, it’s usually an unpleasant surprise. The point is that we can re-use the patterns of the web pages that we have been visiting ourselves—patterns that have already been proven to work. We need not reinvent the wheel with every site. In fact, it’s not just a waste of time, it’s likely to be a failure!

Design patterns can include not only a sequence of visitor interactions but also a recommended layout for the necessary pages and specific guidelines for designing those pages. Such design patterns proliferate on the web.

Last Words

By identifying target audience goals, we can support visitors’ decisions and actions, not only the best-case scenarios (the user completes his or her intended task) but also the worst-case scenarios (the user doesn’t complete a task or encounters an error). We are always searching for ways to expedite the entire process.

Accordingly, we now must ask, who are the people most likely to frequent the site? Identifying a target audience isn’t necessarily easy in the worldwide, heterogeneous universe of the web. Sometimes it’s hard to ascertain even the country our audience resides in, much less more specific data. Still, it can be done, as any marketing guru would be happy to tell you. Sometimes it’s just common sense, while at other times it requires extensive research.

What are the demographics of the target audience, in terms of income, age, education, family status, and health conditions? What problems do they have? What appeals to them? What do they need? Unless you have a very clear definition of the audience, you cannot design a site to appeal to that audience.

Here are the characteristics to define during the process of nailing down your target audience:

Physical Demographics

Gender, age range, health status. Females and males tend to prefer a different look for a web site. If you need to satisfy both, you will need to create a design that appeals to both. Age and health status have implications for issues like vision impairment and mobility. Additionally, older folks might well be less computer-literate because they didn’t grow up with computers as younger generations have.

Cultural Demographics

Economic status, employment, education level, social group, nationality, language, values. Economic status and employment might dictate whether a visitor accesses the web from a high-end home computer, an intranet at the office, or a low-end computer at the public library. Education level, social group, nationality, and language dictate the level of writing you can use.

Values can dictate everything from the language that won’t offend the audience to the products that are appropriate to sell on the site.

Computer Experience

Knowledge of technology, usage patterns, favorite sites, web surfing patterns and frequency. Computer experience is an important factor in determining the characteristics of such elements as navigation and search methods.

Findability

Will your visitors find your site from a search engine, a banner ad, a link on another site, printed promotional materials, or from a friend’s referral?

Computer Equipment Profile

Operating system, system speed and power, connection speed. You will be making design decisions based upon this knowledge. For instance, bandwidth (speed of the connection) is less of a concern if most of your visitors are on high-end systems within a corporate intranet, but a major concern if some of your visitors are on low-speed, dial-up lines.

Frequency Of Visits

Repeatedly or infrequently? Infrequent visitors in particular need sites that are exceedingly easy to use, because they will have to re-learn how to use the site each time they visit.

Location Of Access

From home, a business, a public-access location. For instance, an office worker who might enjoy background sound at home will be more than mildly irritated if your site blares “noise” when he’s surfing the web from his cubicle at work. After all, that sound tells everyone in the surrounding cubicles that someone is goofing off.

Competing Sites

What other sites do your visitors patronize? When you know what these are, you can assess the bar that has been set for the visitor experience.

Internal Or External

Are they internal (for example, doing back-end data entry using a BUI application) or external (as they would be for most public access web sites)? Security issues can be important in either case. For instance, not all employees are typically granted access to every page on the company intranet. Another site might need to protect the security of credit card numbers from both internal and external visitors.

Design Expectations

What do visitors expect your site to look like? This information will be critical when you progress to the visual design of the site.

When characterizing one or more target audiences for your site, the more specific and vivid you can be, the better. Create a persona (an imaginary person or character) to symbolize each of the main types of people you expect to use the site), and give each one a name, a personality, and a brief biography. You might even associate a picture with the persona, to make him or her more memorable. As you work through the design of your site, call up the persona in your mind and ask yourself, “What would this person like to see on the site? How can I make this person’s task easier to accomplish?”

The target audience and their needs must be the central focus in every decision you make. If you understand your target audience, you can determine what they want, design for them, and test with them. Satisfy their needs, and you have earned repeat visitors.

Keep in mind that the importance of your site to the target audience has great bearing on what that audience will tolerate. Fans of a popular rock band might be more than willing to wait for an interminably long download just to get their hands on a short MP3 clip of the band’s newly-released single. In contrast, a visitor who is only mildly interested will have little tolerance for such a long wait.

Self Evidence

The site must be easy to use. Viewers will quickly leave a web site that is too complicated or that requires extensive onscreen explanations. In either case, the designers have not put enough thought into the design. We need to do the thinking so that users don’t have to. A consistent and predictable organization, presentation, and interaction style promotes a faster learning curve and a resulting increase in visitor efficiency, and therefore, of course, user presence and loyalty.

Speed

Visitors have no patience for slow. Unfortunately, some visitors are still on dial-up lines with slow modems. Consequently, we should limit the sizes of our files. We also shouldn’t require excessive clicks from visitors, because every new page requires a page load. We must establish clear and concise navigation so that visitors don’t take wrong turns, again slowing them down. Ideally, we would like to deliver a visitor to his or her target within three clicks.

Feedback

If the visitor must wait for something, we should warn her of that fact. For instance, a small animation that visually illustrates progress can indicate that the system is indeed doing something and hasn’t just locked up. It’s much like background music on a telephone call when you have been put on hold—you might not like the music, but at least it confirms that the connection isn’t broken.

Accuracy

Professional web pages shouldn’t have broken links, missing images, JavaScript errors, or anything else that obviously doesn’t work. You must make absolutely certain that none of these flubs turn up on your pages. Moreover, you should test the site in multiple browsers and browser versions. You can use this useful website for checking different browsers compatibility.

Last Words

Keep in mind that all of the aesthetic and interaction factors we are going to examine determine the usability of a site. For instance, a poor layout or irritating color scheme will, of course, degrade usability. After all, what is usability if not the result of effective design choices?

Feasibility

1. Purpose

   Deciding whether a web site is needed, or whether an existing web as interviewing the organization’s site needs modification. If “yes” determining rough costs and benefits.

2. Principal Tools

   Fact-gathering techniques such as interviewing the organization’s management and proposed visitors.

   Cost-benefit analysis that ascertains whether the benefits are worth the associated costs.

Analysis

1. Purpose

   Determining the purpose, target audience, and proposed content and functionality for the entire site. In short, deciding what is needed.

2. Principal Tools

   Fact-gathering techniques.

   Cost-benefit analysis.

   Preliminary site architecture models.

Design

1. Purpose

   Designing a site (both organizationally and visually) that fulfills the requirements determined in the analysis phase. In short, creating a “how” that provides the “what” from the analysis phase.

2. Principal Tools

   Site architecture models.

   HTML, CSS, JavaScript, and integrated web development environments (such as Adobe Dreamweaver) for site prototyping.

   Image editors such as Adobe Photoshop or Fireworks for creating site graphics.

Construction and Testing

1. Purpose

   Building and testing the web site. (Note that construction and testing can’t be separated into independent phases, since testing should begin as soon as the first few lines of code are written. That way, problems are identified early in the process, rather than at the end when the entire site might end up needing major modifications to correct those problems.)

2. Principal Tools

   HTML, CSS, JavaScript, and integrated web development environments (such as Adobe Dreamweaver) for site prototyping.

   Image editors such as Adobe Photoshop or Fireworks for creating site graphics.

   Accessibility validators.

   Live testing with prospective visitors.

Launch

1. Purpose

   Uploading the site to the server, performing final site-wide tests, and bringing the site live.

2. Principal Tools

   FTP or its equivalent.

Maintenance

1. Purpose

   Repairing, upgrading, and overhauling the system as necessary.

2. Principal Tools

   All of the tools mentioned in the prior phases.

Yes, we do still follow the waterfall model for the high-level process of web design; most of the overall site analysis and design is indeed done before much construction begins. But the construction and testing phase also includes tasks normally included in the independent analysis and design phases. This is because much of the analysis and design for individual pages is deferred until the construction and testing phase for those pages, since every page has unique requirements that often can’t be ascertained until it’s under construction.

The result is that each page requires its own miniature life cycle.

Each page is represented by a concentric circle, and each page progresses through its own analysis, design, and construction and testing phases. Now, all of the phases are tightly coupled with all of the other phases. Thus, to put a fine technical sheen on it, building a web site is iterative and recursive instead of rigidly sequential.

The iterative nature of web site construction also means that sometimes we need to revisit a page that we thought we had already completed. As a result, we often move backward, not just forward. For instance, several pages might be so closely related that none of them can be finalized until all of them are finalized, as would be the case with the multiple pages of a shopping-cart application. All in all, creating a web site is indeed a spiraling, reiterative process.