|
|
Organization is one of the (by now you've noticed many) keys to building an effective Web site. This organization takes place on several levels—page structure, site structure, directories, and even the way in which you organize your tools. We're
not saying that you must be a completely detail-oriented person to build effective Web sites. In fact it often seems that the goal-oriented person who can see the big picture has the type of personality best suited to developing commercial systems. Getting
stuck in the details can be counter-productive and often the result is Web sites that are never quite finished.
This chapter deals with two areas of organization. The first has to do with how you organize your tools, and the second confronts the issue of directory structure on WWW servers—you've already dealt with site and page organization. While it may
seem that this chapter is out of order, and should actually have been addressed earlier on, we assure you that there is a method to our madness. Up to this point, we hope that you have been thinking about what you want to create, and now we begin
discussing how you're going to create it.
The next chapter, "Taking Advantage of HTML," is the first step in diving into the blood-and-guts of WWW design, in that you will be taking your ideas and applying them to a real, working system. Before you do this, we want you to get
everything organized so that the immense and confusing job of organizing your entire system won't overwhelm you. HTML can be confusing at its best, and making some simple preparations now can save you headaches in the future.
You'll be using several tools to design your pages, many of which you can find on the CD-ROM. You really only need a few tools to design, test, and place HTML documents, and you may find that you will prefer applications other than those we are
supplying—which is fine. Four tools you will absolutely need are
Once you've decided on your tools, try to put them into a directory/folder where you can quickly access them. If you are able to keep them on your desktop, do so. You'll be jumping back and forth between them constantly as you design your pages, and
the less time it takes to do this, the less likely you are to lose your train of thought. The same thing applies to any reference files you may wish to use—keep them at hand so that you can remember what it was you were looking for.
If you are converting files from print editing applications (MS WORD, Aldus PageMaker, for example), you may need to get that software, though with many "viewers" ( applications that are generally available for free, and enable you to read
but not write the files) you can select text for cutting and pasting.
If you decide to use a WYSIWYG editor, you will still need a text editor to check the code and a browser to test the pages. While WYSIWYG editors are becoming better and better, there's no substitute for crunching the code yourself. This gives you complete control over the content of your code and enables you to eliminate the odd formatting many WYSIWYG editors incorporate to make things easier for the author. To tell the truth, we never use this type of editor, and we advise you against it.
Note
Most print editing applications use representative links (OLE, EPS, CGM, and WMF headers, and so on) to signify graphic placement. The true graphic is only represented on the screen and isn't presented in full detail until the file goes to print. If you are using print layout files as your design basis, you will want to get and convert the original image files for use on your WWW pages. Cutting and pasting the graphic elements of a print layout document usually results in poor quality graphics.
If you're at all familiar with DOS, you'll have a good overall picture of UNIX directory structure. Like DOS, UNIX uses a hierarchical tree structure for organizing directories and files. Where DOS uses drive
name:\directory1\directory2\directory3\file (C:\programs\graphics\tools\psp.exe), the WWW and UNIX use machine name/directory1/directory2/file
(www.domain.com/photos/animals/hoppy.gif). As you can see, the most obvious difference is simply which way the slash goes—DOS uses a backslash [\], while UNIX uses a forward slash [/].
Whether you use a virtual host or have your own Web server, you will use a directory structure to organize your Web system. If you are using a virtual host, you may access your virtual server directories by many means. A common way this is done is that
your files will be accessed via FTP as a substructure of your host's main system. This means that although your WWW system is accessed as www.yourname.com, you will actually be placing your files somewhere that looks like hostname.com/users/you/WWW. Your
host server is set up so that files placed within the WWW subdirectory of your FTP account are aliased to your domain name and virtual server. This can be set up in different ways and is something on which your provider will have to instruct you.
Unless your WWW system is quite large, you will probably opt to place all of your files in one directory—at least initially. A good argument for doing this is that many FTP clients do not upload subdirectories; therefore, you must upload files one
directory at a time. If your WWW system is in one directory, you can simply upload or download everything at once. This works well when you redesign your system because you can easily keep track of uploads by moving the entire directory at once, thus
updating all of the files in one big chunk.
After your system becomes larger, as it inevitably will, you will want to start making use of directories to keep things organized. This way you won't have to search through dozens and dozens of files to find the one you'd like to replace, and you'll
also have more control over different sections of the system when and if there comes a time that you will allow other authors to update the system.
For instance, say that you plan on allowing the sales force to upload an up-to-date chart graphic each month. You can allow them access to a single directory without giving them access to the core of the Web system. In a case like this, the page
containing the graphic might reside in the main directory, while the graphic resides on a subdirectory—the one you have allowed the sales team to access. The image tag on the page may look like this: <IMG SRC="sales/chart.jpg">, which
refers to a subdirectory called sales. If you've allowed the sales team access to only that directory, that's all that they can screw up.
Now, say that the sales team is responsible for several pages on the system and that you want them to have control over sections of the pages, but still want to keep continuity throughout the system. This will be like the reverse of the above example,
in that the pages will reside on the sales directory and the graphic elements will reside in another, secure directory. So, the page address may look like this: www.yourname.com/sales/page1.htm, and the image tags might look something like this: <IMG
SRC="/graphics/header.gif">.
If a directory name has a slash in front of it, as in …SRC="/graphics, this means that the directory is a root—higher up the hierarchical structure than the page accessing it. If a directory has no slash in front, as in …SRC="sales/ , this means that the directory is a subdirectory of the one containing the page. This is very important in testing your pages on a local system because many browsers and operating systems will not discern between the two—/graphics/ and graphics/ will both be treated as subdirectories on a DOS PC, for example. Thus, things that run great on your PC may not work on a server if the directory structure isn't correctly assigned within the HTML code. For testing on a system such as this, you will need to make all directories subdirectories and sort them out when you upload.
If you're planning on having multiple authors updating the system (and this will also be addressed in Chapter 25, "Maintaining Your System"), and you want to have page continuity throughout the system (matching
headers, footers, background, and so on), you should set up a root directory that contains the elements common to the entire system. For instance, as in the preceding examples, say you have a header that you want included in each page. To make things more
confusing, say that the sales department wants to have a subdirectory for placing graphic images, so that they are not included within the same directory as their HTML files. Therefore, a section of one of their pages might look something like this:
<HTML> <HEAD> <TITLE> Winning with Widget #1234 </TITLE> </HEAD> <!-- Begin corporate header --> <BODY BACKGROUND="/graphics/bground.jpg"> <A HREF="/header.map"> <IMG SRC="/graphics/header.gif" BORDER=0 ISMAP ALT="[Navigation Header]"> </A> <!-- end corporate header --> <IMG SRC="graphics/1234.jpg" ALIGN=RIGHT> <H1> Winning with Widget #1234 </H1>
This page would load a navigation graphic (ISMAP) from a root directory called graphics, as well as a picture from a subdirectory also called graphics (see preceding Note). Obviously, it would be better to call the subdirectory by a different name to
avoid confusion, but this illustrates that you don't have to.
Even if you will be the only author and don't have to worry about others accessing the system, you may still want to use a directory structure to keep things straight—this is a matter of choice. In either case, it's best to design a basic page
that includes all of the common elements in the system and to use this page as the starting point for each subsequent page you or any other authors design. This is called a template.
When you design a template, it's best that you keep the code in a line-by-line structure that's clear and concise, labeling exactly what must be changed on each page and clumping things together that will remain standard. Here is an example of a basic
template, based on the previous example code:
<HTML> <HEAD> <TITLE> PUT THE TITLE HERE </TITLE> <!-- Page design by webmaster --> </HEAD> <!-- Begin corporate header --> <BODY BACKGROUND="/graphics/bground.jpg"> <A HREF="/header.map"> <IMG SRC="/graphics/header.gif" BORDER=0 ISMAP ALT="[Navigation Header]"> </A> <!-- end corporate header --> <IMG SRC=" PLACE MAIN PAGE GRAPHIC HERE " ALIGN=RIGHT> <H1> REPEAT PAGE TITLE HERE </H1> <HR> BEGIN TEXT HERE <!-- Begin corporate footer --> <A HREF="/footer.map"> <IMG SRC="/graphics/footer.gif" BORDER=0 ISMAP ALT="[Navigation footer]"> </A> <HR> © Copyright 1996, My Company, All Rights Reserved<P> Problems viewing this page? Contact the <A HREF="mailto:webmaster@yourdomain.com"> Webmaster </A>. </BODY> </HTML>
In the interest of time, you may wish to make more specific templates based on your main template. For instance: you may want to make product page templates, business information templates, forms templates, and so on. Templates can be as specific as
you'd like and can be laid out in any way that makes you (and your other authors, if any) comfortable and efficient.
To get you up and running, we've included some basic templates on the CD-ROM, which you can use to develop your own system. (See Chapter 10, "Taking Advantage of HTML.")
By now, you should have some idea of what you want to say, and how you'll go about preparing yourself to leap into page design. Roll up your sleeves, clear your desk, and get ready. The next chapter is about raw HTML code.
