In this chapter from Sams Teach Yourself Dreamweaver UltraDev 4 in 21 Days, author John Ray discusses the necessary steps you must take before starting to work on your Web site. Learn what UltraDev tools are available to help streamline and simplify the design process, how to work with existing Web sites from within the outlived interface, and techniques to keep your site online and working within a distributed working environment.

From the author of

From the author of

Although Day 2, "Using the UltraDev WYSIWYG Layout Tools," exposed
the UltraDev design tools, you will need a bit of background before you can
fully develop a Web site. Creating an entire site consists of more than sitting
down and typing/designing HTML. You must carefully plan how the end user will
interact with the site. Today, you will learn

The necessary steps you must take before starting to work on your Web site.

The UltraDev tools that are available to help streamline and simplify the
design process.

How to work with existing Web sites from within the outlived interface.

Techniques to keep your site online and working within a distributed working
environment.

Site Planning

Site planning is one of the most important phases in the design of a Web site.
Much like "painting yourself into a corner," designing a Web site
opens the possibility of creating "dead ends" for the user in terms
of navigation. If a site is being designed by multiple people, it becomes more
critical to carefully plan its construction to avoid any chance of differing
styles in layout and navigation.

As I'm sure you've all experienced, it's too easy to get lost
on a Web site. Navigation bars switch sides, links disappear and reappear, and
the design of the pages itself might vary from section to section. As I mentioned
in yesterday's lesson, one of the drawbacks to frames is that it is easy
to get lost in the site if there are multiple pages in multiple frames. Many
Web sites actually feature someone else's content, contained within a frame
on their pages. These sites are the most confusing of all because it's
next to impossible to tell where the information you're viewing is coming
from or is going to appear.

Proper planning can eliminate these problems and more. Spend a few hours before
you start programming and save yourself days of reworking later.

Site Maps

So, what is a site map? It's exactly what it sounds like—a map of
the site that you are creating. It provides a visual means of showing how a
user can navigate between the different available pages. If you map your site
out, only to find that there is one way to reach the most important content—through
a single link on an About Our Pets page—you're probably going to be
in trouble.

Take a look at a site map for a small computer store. Figure
3.1 shows a potential site map that can be used in the construction of the
Web pages.

Figure 3.1
A site map can ease the process of designing and linking pages in a Web site.

In this site map, pages are grouped by category, and links between these categories
are shown with lines. By laying out your site visually before it's built,
you can determine the best way for the user to navigate. You can also avoid
the problem of having orphan pages that are not linked to directly from the
rest of the site.

Note - Orphan pages occur when someone designs content for an area
of a Web site. It gets built, but is never linked into the bulk of the pages.

I've experienced this firsthand on several occasions when a site has
been created without a proper site map. I recently constructed a site following
the guidelines that the client had prepared, only to find that it was impossible
to reach the About This Company portion of the Web site from any of the other
pages. Taking the time to create a simple site map would have solved this
problem.

File Layout

Site maps also aid in the actual directory structure that you use while building
the site. It is all too common to take over the maintenance of a site and find
that every single page is located in the same directory, regardless of its position
on the site. The process of creating a site map involves defining the relationships
between the pages on the site. Later, when you create the site itself, the related
pages can be grouped under a common directory. This makes finding and manipulating
them much easier.

Typically, sites are created with HTML directories for each of the major categories
on the site, and an image directory for the images on the pages within that
category. You might find that a different layout works better for you. I've
had many occasions in which the number of images on an individual page warranted
creating a separate image directory for that document. The most important thing
to keep in mind is that the structure you're creating will probably have
to be maintained by someone else someday. Do a good job now, and you'll
make someone very happy down the road.

Naming Conventions

When you've determined how your site is going to be built and where the
files are going to be located, the next big decision is how you're going
to name them. Depending on the size of a Web site, there are typically several
people involved in getting it put together—the HTML programmer, graphic
designers, and a system administrator. Each of these people should have input
into the naming conventions that are used on the files.

The Programmer and Graphic Artist

In order for a smooth transition to take place between concept graphics and
the final product, the HTML programmer must be able to anticipate how the graphic
artist intends files to be used.

For example, there are often instances in which large graphic files are broken
down into smaller images that must be placed together in a table. If the graphic
files are handed off to the programmer as art1.jpg, art2.jpg,
and so on, the programmer has to open each image individually and essentially
piece together a puzzle (or spend a great deal of time bugging the graphic designer).
A better solution would be to set a standard for labeling images by their position
within the table based on rows and columns. A file named flowerr1c1.jpg
could tell the HTML programmer to insert the image in row 1 and column 1 of
the page's table.

Of course, this is just an example of a naming convention. You might have a
better idea that works well within your organization. I highly recommend coming
up with a system and sticking to it, even if you are the only person working
on a site. Receiving a hand-me-down site with images labeled 13123a13.jpg will
quickly convince you just how important this is.

The Programmer and the System Administrator

If you're lucky, you fall under both of these categories. If not, pay
close attention here before creating any more pages.

Whatever naming convention you've decided on must work within the naming
system of the server software that is being used to run your Web site. If you're
deploying on a Macintosh Web server running on anything less than Mac OS X,
you're going to run into trouble with filenames that are greater than 32
characters long. Likewise, on a Unix server, you need to make sure that you
are providing links to pages using case-sensitive conventions. On most Windows-based
Web servers, the file HELLO.HTM is the same as hello.htm and
can be retrieved by referencing either version of the filename. Unix machines,
however, are case sensitive, and must reference the exact filename.

All the little quirks about the platform you're deploying on should be
well documented before you start naming files. Here are some rules of thumb
that work well:

No punctuation—Remove any punctuation from filenames. The only
allowable characters should be alphanumeric.

No spaces—Spaces are valid for filenames, but they can be difficult
to link to because they must be translated to %20 within the HTML.
Most people replace the spaces in their documents with underscore characters:
( _ ).

Short and Simple—Keep the names of your files short and simple.
This keeps the Web site portable to other platforms without long filenames
and makes the HTML more readable.

Following these guidelines does not guarantee that your files will work on
all systems, but it is very likely. Be sure to check with your system administrator
for any other information that you should know about your deployment platform.