Planning and Managing a Web Site
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.
){kind=link}
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: ( _ ).
Consistent case—Do not switch case while naming files. Choose uppercase or lowercase names and stick with them.
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.