If you've worked in the field of Web development for a while, you've probably come across situations where you had to build a Web site fast. Maybe there's a new design that needs to be mocked up for usability testing; maybe you've got a client with an immovable deadline; or maybe you just work with procrastinators. The bottom line is that you need to be able to crank out Web pages quickly, and you need to do it in a way that provides flexibility for the future.

This article demonstrates some techniques that can be used to develop large numbers of pages quickly. The examples illustrate methods that can be used with almost any development system. You should be able to adapt these ideas to the platform and tools that you use for development and deployment.

Prerequisites: What you need to get started

Rapid Web development means building sites efficiently. This starts with making sure that it is clear what needs to be built. To do this, you need to know what the functional requirements for the site are, and you need to have a design and flowcharts that show how the site should work.

Functional requirements specify clearly what your finished site should do. Knowing the requirements and scope of a project helps you avoid delays and headaches later. Functional requirements answer questions like these:

• What does the Web site/page need to do?
• How fast does it need to be?
• What browsers does it need to be compatible with?
• What services does it need to provide?
• What systems does it need to tie into?

These types of questions should be answered as specifically as possible.

In addition to knowing what the Web site should do, you need to know how it should look and work for users. This requires that you have a design for the Web user interface. In addition, it's often helpful to have flowcharts or storyboards that show how users will progress from one screen to another.

The rapid Web development process

While each Web project is unique, there are several steps common to most projects:

• Review the design and functional requirements for potential problems.
• Break the design down into modular page building blocks, or panes.
• Create a model for capturing the data as either XML or database records.
• Use XHTML for page result/presentation.
• Move as much of the presentation styling to a central standard style sheet as possible.
• Use automated procedures to build content elements.

Back to top

Review interface designs for potential problems

Once you know what the Web pages need to do and have the interface design, you need to look for potential problems. Look for technical problems that will make the design difficult to implement or use. Identifying these problems up front, before pages and applications are built, can save a huge amount of time in the long run.

Review printouts of the interface design against common user expectations. This is a quick exercise that can help you avoid wasting project time on rework and last minute changes. Have the designers provide a set of 8.5" x11" printouts of the page designs, printed at full size. Here's a list of items to look for:

• Are all important interface elements visible and legible on the printouts?
  • Your company logo or identifier
  • Site-wide navigation
  • Persistent tools (such as, help, about us, search, site map, and privacy)
  • Page content area
  • Links related to the current page's content
• Are any key navigation elements partially obscured, or implemented using drop-downs, mouse-overs, etc.?
  • Elements that are cut off on 8.5" x 11" printouts are likely to be off-screen on typical users' computer screens.
  • Drop-downs and mouse-overs have known usability drawbacks; if they are used, they may require special attention.
• Are graphics used effectively for the Web?
  • Regardless of the aesthetics of the interface design, it's important that the site meets the speed expectations of users.
  • Watch out for any large areas of continuous-tone images and gradations, as well as any unnecessary images.
• Are important elements located where users expect them to be?
  • Logo and "Home" button in the upper left of the page
  • Main site category links at the top of the page or on the left side
  • Persistent tools at the top of the page
  • Internal links on the left side of the page
  • External links on the right side of the page
  • Advertising at the top or on the right side of the page
  • The main page content in the center of the page
• Does the hierarchy of navigation elements follow users' expectations? Research suggests that users will look for links first in the content, then the left of the page, then at the top of the page (see Resources). This is because it's common for broad category navigation to be at the top of a page, related links to be at the left of the page, and action items and contextual links to be in the content area. Amazon.com provides a typical example of this approach. If your design doesn't follow this hierarchy, or if any of these elements is not visible on your printout, it may be a problem.

If the designs contain potential problems, try to address them before building anything. There may be reasons specific to the site and its goals that the design uses an unconventional approach. On the other hand, you may identify and avoid potential development, usability, or performance problems before anything has been coded.

Back to top

Break down design into modular elements

Next, you should evaluate the layouts and break them down into modular elements. This can be done with printouts of the designs.

Most Web layouts can be divided into a set of commonly found sections:

• Top branding area
• Top navigation
• Left column
• Center (main content) column
• Right column
• Footer

Review the printouts and identify these areas within the designs. Your site design may not contain all of these elements, or it may have additional ones not mentioned here. The main goal of this step is to determine what people or processes are responsible for each area of the page. An easy way to do this is to mark out the areas on printouts, and to make sure that areas of responsibility don't overlap.

The resulting breakdown into sections can be used to analyze how the page will be built. When you are done, you will have identified the logical subsets of the page. These sub-sections can be used to determine what goes into server includes or dynamic processes, and the logic associated with each.

Here is an example of the type of breakdown you need to make:

Back to top

Create a model for capturing data consistently

Before you work with actual content, you need to have a strategy for capturing it in a consistent fashion. This process is similar to defining a schema for a database. Capturing content consistently makes it possible to manipulate it with applications, and also to separate the presentation from the content itself.

Define how your content should be captured:

• Review sample pages and determine what elements make various pages unique.
• Identify common page elements such as title, headline, images, and body copy.
• Determine what additional information should be captured, such as standard Web meta keywords and descriptions. Each page may also have information that you need to capture that doesn't end up in the presentation, such as page taxonomy, or whether the page should be published to wireless devices.

The result of this process is a master list of discrete content elements that make up the pages. Here's a simple example:

• Page title
• Meta keywords
• Meta description
• Site category
• Publish to wireless flag
• Page summary
• Headline
• Dateline
• Author
• Body content
• Footer type

Use the list you create to define how content will be captured. For example, this list can be translated into a database or XML schema. If you were using a content management system, like Interwoven's Teamsite, you would use the list to define your data capture records.

Back to top

Use XHTML for page presentation

Once you've defined how your content will be captured, you can create page presentation templates. Though this process can vary widely depending on your infrastructure, there are some techniques for speeding up your development process that will work with any system.

One technique is to use XHTML to create your Web interface. XHTML has many benefits. It works with current Web browsers, and is valid XML, so it can be intelligently transformed to and from other XML applications. To maximize the benefits of using XHTML, you will want to separate out presentation styling from your XHTML as much as possible.

There are a few important things to remember when creating pages with XHTML, instead of HTML:

• Include a doctype declaration.
• Make sure elements are well-formed.
• Quote all attributes.
• Use lowercase identifiers.
• Close empty elements.

Next, determine what page styling can be implemented as a CSS. Doing this requires balancing the benefits of moving presentation styling to style sheets against the need to maintain compatibility with users' browsers. Ideally, all styling would be moved out of the XHTML document. Unfortunately, most interface designs cannot be accurately implemented using CSS because of Web browser incompatibilities. The main effects that can't be replaced with style sheets will be table elements used to define page layout.

Break the XHTML into discrete sections that match the layout sections determined earlier. Divide it according to the people and processes that supply that content. This will help you determine what the final presentation XHTML needs to be for each section of the page.

The result should be XHTML content with a minimum of presentation coding, broken into logical sections (see Listing 1).

<!DOCTYPE html 
        PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "DTD/xhtml1-transitional.dtd">
<html>
<head>
  <meta http-equiv="Content-Language" content="en-us" />
  <title>Title</title>
</head>
<body>
  <table border="0" width="100%">
    <tbody>
      <tr>
        <td width="100%">Branding</td>
      </tr>
    </tbody>
</table>
<table border="0" width="100%">
  <tbody>
    <tr>
      <td width="100%" height="16">Navigation</td>
    </tr>
  </tbody>
</table>
<table border="0" width="100%">
  <tbody>
    <tr>
      <td width="120">Left column</td>
      <td width="100%">Center</td>
      <td width="120">Right column</td>
    </tr>
  </tbody>
</table>
<table border="0" width="100%">
  <tbody>
    <tr>
    <td width="100%">Footer</td>
    </tr>
</tbody>
</table>
</body>
</html>

Once you have a bare bones template, check your work! Validate your XHTML with the W3 validator (See Resources).

Back to top

Create a global style sheet

The final step in creating the presentation is to create a global CSS. This style sheet should contain all site-wide styling. Use style sheets to separate the presentation styling from the XHTML content markup as much as possible.

Wherever possible, apply styles to standard XHTML elements. This minimizes the size of your Web page, while also keeping the complexity of the code to a minimum. It also reduces the likelihood that distributed developers will code page styling elements differently.

body { font-family: Verdana, Arial, Helvetica, sans-serif }
h1 { margin-left: 14px; margin-bottom: 5px; margin-right:14px }
h2 { margin: 14px; font-size: 1em; font-style: italic; }
h3 { color: #FFFFFF; margin-left: 5px; margin-top: 2px; margin-bottom: 2px }
h4 { font-size: .8em; margin-left: 5px; margin-top: 2px; 
margin-bottom: 2px; color:#FFFFFF }
h5 { font-size: .6em; margin-left: 5px; margin-top: 2px; margin-bottom: 2px }
p { margin: 14px; font-size: .9em; }
.Offer { color: #FF0000; font-size: .6em; font-weight: bold }
.OfferCopy { font-size: .6em }
.OfferHead { font-size: .6em; font-weight: bold; margin-top: 5px}

Centralizing the styling for your site improves consistency and it makes your site easier to maintain. Moving styling to a separate linked file can also dramatically reduce the size of your pages.

Back to top

Use automated processes to build content elements, wherever possible

Once you have stored your content in a consistent way, it becomes easy to generate page elements programmatically. For example, indexes, taxonomies, and links of related information can be generated automatically.

SELECT key, dateline, headline, summary FROM Articles ORDER BY Date DESC

Listing 3 demonstrates using a query to extract information that's a subset of the stored content. The dateline, headline, and summary information that is extracted can be inserted into a page template to generate the index. Formatted, this would give you a result looking like this:

A query by category name and date can be used to generate index pages for major sections of your site. Similarly, queries against the content database can be used to generate indexes of related articles, or a list sorted by author. These elements will update themselves as the content changes, minimizing the amount of effort required to build and maintain the site's content.

Back to top

Making changes

It seems that no Web development project is complete without last minute changes. Following a rapid Web development process makes late changes much easier.

• Changes that affect any content section can easily be made, because the change only involves the people or process responsible for that section.
• Look and feel changes can be made by modifying centrally managed includes.
• Changes to overall look and feel can be made by modifying the CSS.
• Each of these changes will update all affected pages within the site.

Here are two samples that demonstrate how site-wide changes can be made by making small changes to centrally managed files

Example 1 - Text formatting in central style sheet
Example 2 - Result after the header include is changed and style sheet updated

Much more dramatic changes can be made very easily with larger changes to the page templates.

Back to top

Summary

Using a rapid Web development process has many benefits. First, it gives you a way to break a large project into manageable chunks. It also helps you create many Web pages in a short period of time. This approach is flexible enough to work with any development environment. The biggest benefit is that when changes need to be made quickly, it is easier to do because elements are broken into logical, centrally managed chunks.

Resources

• Web Review's An XHTML Roadmap for Designers is a concise introduction to XHTML.
  
  
• Web Review also maintains a useful Web browser compatibility chart.
  
  
• Details on XHTML can be found at the W3 Web site. They also have an online XHTML validator.
  
  
• Apache Week discusses using server side includes with Apache.
  
  
• Webmonkey provides a good introduction to cascading style sheets.
  
  
• The Society for Technical Communication has a great heuristic evaluation checklist that can be used to locate potential problems with interface designs.
  
  
• For more depth on cascading style sheets and their use of type, take a look at our own CSS tutorial here on developerWorks.
  
  
• Planning for growth, from IBM's High Volume Web Site Team, can show you how your Web site can satisfy future demands and evaluate potential workload and infrastructure changes.
  
  
• IBM's Patterns for e-business site features a number of reusable assets that can help speed the process of developing applications.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Prerequisites: What you need to get started
• Review interface designs for potential problems
• Break down design into modular elements
• Create a model for capturing data consistently
• Use XHTML for page presentation
• Create a global style sheet
• Use automated processes to build content elements, wherever possible
• Making changes
• Summary
• Resources
• About the author
• Comments

Next steps from IBM

WebSphere Application Server can take you to the next step in the evolution of Web Development that lends itself to the creation of rich Web 2.0 user interfaces.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby..
• Article: This article introduces you to the web development with WebSphere Application Server Feature Pack for Web 2.0. Its a good look at solutions for creating Ajax-based web apps and mashups.
• Tutorial: This tutorial takes you through the PHP and Java steps to master Facebook application Web development with the no-charge WebSphere Application Server Community Edition Web server.
• Demo: This demo showcases the WebSphere Application Server Community Edition administrative console feature set and walks you through deployment of a Web application.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Web development on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers