Level: Introductory James Lewin (jim@lewingroup.com), President, The Lewin Group
01 Sep 2001 What do you do when you need to have a Web site done "yesterday"? This article answers that question, showing you how to create sites quickly and flexibly using Web standards like cascading style sheets (CSS), structural HTML, and server-side includes. It contains examples that demonstrate how rapid Web development not only streamlines the process, but also makes updating easier. 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.
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.
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
Figure 1. Standard Web layout
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: | Section | Responsibility | Properties | | Top branding area | Corporately controlled | Static for entire site | | Top navigation | Corporately controlled | Static, but different category highlighted
in each site area | | Left column | Multiple versions, some corporately controlled,
some by business units | Static, versions for each area of site | | Center content column | Controlled by each business unit | Unique, defines page unit | | Right column | Corporately controlled | Updated daily | | Footer | Corporately controlled | Static, custom version for different
areas of the site |
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.
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).
Listing 1. Bare bones XHTML document
<!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).
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.
Listing 2. CSS example
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.
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.
Listing 3. Using SQL queries to create content elements
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:
| | 7/6/2001
Measuring
Your Site's Success
How do you know if your Web site is successful? Finding the
answer to this question is becoming central to the role of enterprise Web
builders. We list the four top ways to measure the success of your site.
6/9/2001
Personalizing
the Web
Personalization means knowing your customers and demonstrating
that you care about them. It's easy to get bogged down discussing
methodologies, such as rule-based decision-making and collaborative filtering,
and lose site of this idea. Find out how to use personalization to make your
customers feel like you know who they are, and that you care.
6/9/2001
Are you ready
for wireless Internet?
If your company is like most, you have tech-savvy employees
bringing wireless Internet devices, such as PDA's and cell phones, in to work.
They're using these devices to carry around their contacts, calendars, and
more. Find out if you're ready for your employees to go wireless.
|
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.
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.
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
About the author  | | | James Lewin has been working with the Internet since 1995. He is the president and owner of The Lewin Group a Networking and Internet Solutions provider. He is an MCSE who also works with Microsoft and open source Internet development tools. |
Rate this page
| 
