Article
Dreamweaver 8 Does Standards!
Chapter 2. Site Planning and Setting up for Development
Before we dive in and start developing our site, we need to make some decisions about how the site will look, how it will be hosted, and how it will be structured. The Website we'll build through the course of this book will be called Code Spark; it will be a Web design resource site much like sitepoint.com. I have chosen this as the subject matter for the site not because I assume that every reader wants to build a Web design resource site, but because the concepts that we'll explore while creating this site are common to many other types of Website. The decisions we'll need to make during this project will parallel the kinds of options you'll have to consider around most of the sites you'll build. Whether you follow this book, creating the Code Spark resource site using the example graphics provided, or using the techniques described here to develop your own project, is entirely up to you.
The Code Spark Site Design
Features of the Code Spark Website
Before we can begin to design the layout of the site, we need to consider the site's features, so that we know exactly what we need to include in the layout. Code Spark is a Web design and development tutorial site, so we'll have to handle tutorials that explore design and development techniques, and articles that discuss interesting developments in the area of Web design.
Tutorial Pages
The tutorials will comprise the majority of the site's content, so we obviously need a design that facilitates the formatting of this type of content. Tutorials tend to include a number of screenshots—which might be quite wide—and code samples, which need to be formatted so that the tutorial author's line breaks are preserved. We want to ensure that our article page allows for the display of such page elements.
We'll also want to make sure that, if readers like the tutorial they're reading, they'll be able to find similar tutorials on the Code Spark site. Perhaps the easiest way to do this is to add to the tutorial page a list of other articles written by that author.
The Homepage
We'll want to make the focus of Code Spark—Web design and development tutorials—obvious from the get-go, so we'll present a number of regularly updated feature tutorials on the homepage of the Website. This way, new visitors can quickly and easily ascertain what the site's about, and returning visitors can see what's new at a glance.
Site Navigation
Once we've prepared and published our tutorial content, we're going to need to give visitors various ways to find it. The subject of "Web design and development" is fairly broad, so our content will need to be sensibly categorized. This way, visitors can quickly access all the articles that discuss Dreamweaver, CSS, or PHP development, for example. A tutorials index page, which displays the categories list, along with a couple of sample tutorials, will give the user an immediate understanding of the information contained in the categories. Making a list of these categories available on every page of the site helps to reinforce the content categories in the minds of users, and gives them quick, easy access to the latest tutorials on the topics in which they're most interested.
A list of the most popular and highly rated tutorials is a good way to allow the cream of your Website to rise to the top. By making it easy for users to find your site's best content from the homepage, your visitors will be more likely to read those tutorials and come away with a good impression of Code Spark—perhaps even telling their friends about it. A sitemap is also very useful to visitors: it's a well-known tool that allows users to quickly get a feel for the way the Code Spark content is organized, and gives them a direct pathway to the tutorials that interest them.
Now, navigating the site by browsing its carefully thought-out categories might be good for users who are looking to improve their CSS skills, for example. But if a user needs a tutorial on a specific topic—such as building a CSS-based three-column page layout—that person's going to want a faster way to locate it. By providing a search field, you make it very easy for users to quickly find specific tutorials, a task that—as you'd know if you've ever had to visit a huge site like Microsoft's Developer Network (MSDN)—can otherwise be very difficult indeed.
As we're concerned with accessibility, we want to add features that will help visitors use the site, such as a style sheet switcher that allows users to increase and decrease the font size, and a list of keyboard shortcuts that they can use to navigate the site. We'll also need to provide a page that explains what the Website's all about, and a way for visitors to get in touch with the people who run the site.
Bearing all of the above in mind, we can make a list of the important features that our site requires. It needs:
- Navigation to the main parts of the site: the tutorial index, information about the site and the people who run it, the contact page, and the sitemap
- A list of the tutorial categories
- A search facility
- A featured tutorials display on the homepage
- A large area for the presentation of article content on individual tutorial pages
Designing the Site
Once you've created a list of key elements, you can come up with a page layout either on paper or in a graphics application. To begin the Code Spark project site, let's take a look at a design created in Fireworks by SitePoint's Alex Walker, and pictured in Figure 2.1, "Alex's homepage design, incorporating our requirements", so we can discuss the implementation of a layout that makes use of graphics, while still adhering to Web standards.
Figure 2.1. Alex's homepage design, incorporating our requirements.

This design incorporates each of the elements we identified as being required on the homepage:
- Our main navigation displays along the top.
- Category links and a "reader favorites" section appear down the right-hand side.
- The search field is also on the right.
- Our accessibility controls appear in the top-right corner.
- The featured tutorials make up the main content area.
This process of thinking through the elements that you want to include before you come up with a layout will save you struggling find space later for extra elements that you hadn't expected to use.
The site's tutorial page layout shown in Figure 2.2, "The tutorial page layout, showing the content area." includes a large content area, allowing us to easily publish articles that contain images and blocks of example code.
Figure 2.2. The tutorial page layout, showing the content area.

Whether you're at the homepage, an article page, or any other location on the site, a number of consistent page elements are present: the header, which includes the Code Spark logo, the top navigation, and accessibility features that we'll discuss later; and the bar to the right of the page, which contains the search box, along with elements that change depending on where you are located within the site. This sidebar provides quick, easy access to tutorial topics.
The content area on the homepage will contain two columns in which we'll highlight the latest articles and tutorials posted on the site. When users click through from this display to an article page, the article content fills the complete width of this main content area. Ours will be a liquid layout: one that stretches to fill the users' browser windows, regardless of their screen resolutions.
Note: Liquid or Fixed Width?
A fixed width layout (one that doesn't grow and shrink with the size of the browser window) needs to be narrow enough to ensure that users with low screen resolutions don't have to scroll sideways to read the site's content. In practice, this fact means that we really need to design for users operating at a resolution of 800 x 600 pixels, unless we know that the majority of our target users will have a resolution of at least 1024 x 768 pixels. Designers often use fixed width layouts because they find it easier to position graphically intense designs within a known page width.
For a content rich site, however, using a liquid layout (one that expands and shrinks with the browser window's size) can be a good design choice. Of course, you should always check your work at a resolution of 800 x 600 pixels to ensure that a horizontal scrollbar doesn't appear at this resolution, and that the columns are not ridiculously narrow, but users with higher screen resolutions will have greater flexibility in the ways they view the site.
Structuring the Site
Now that we have a site design, we can begin to think about how we'll put the site together, and the technologies we'll use to do so. Once again, some time spent planning will help to make the site's development more streamlined once we begin.
Dealing with Common Elements
We've already identified some common page elements in our design; some of these elements are present on every page, while other elements are present on some—but not all—pages. We can use the fact that we have these common elements in the site design to make development easier.
The "Copy, Paste, Copy, Paste" Technique
In developing a site, you might work by creating a new document, writing the XHTML code, applying your CSS, and then, when you're ready to create a new page, simply copying and pasting into the new document all of the common elements that appeared in the last document. In this way, all of your site's files contain potentially large amounts of markup—and possibly images—that are duplicated on each page.
This isn't too much of a problem, until you decide to change a graphic in the header, and have to open up every page of the site to copy and paste in the new logo markup. The use of CSS does reduce the need to copy and paste common elements between files—much of this information can be found in the CSS file that controls the site's pages—however, there are still many elements that need to appear in the individual page document. As such, when you create pages in this way, some copying and pasting is inevitable. Finally, you must upload all of the altered pages to the Website in order to have the revised logo display.
Dreamweaver Templates
If you have any experience in Dreamweaver, you may be aware of Dreamweaver Templates. A template is basically a normal HTML page that Dreamweaver can use as a basis from which to create new pages. You mark one or more regions of the template as being editable, optional, or repeating. These will be the only areas that Dreamweaver will allow you to update in pages based on that template; the rest are locked by Dreamweaver, as shown in Figure 2.3, "A page based on a Dreamweaver template with a single editable region."
Figure 2.3. A page based on a Dreamweaver template with a single editable region.

Dreamweaver locks parts of the page by placing special HTML comments in your markup. These comments indicate which areas are locked, and which are editable, as shown below.
<h1>Code Spark Notice</h1>
<!-- TemplateBeginEditable name="EditRegion3" -->
<p>This is where the text of the notice will appear. </p>
<!-- TemplateEndEditable -->
<p>© 2005 Code Spark</p>
The really useful aspect of using Dreamweaver Templates is that if you change any part of the main template, Dreamweaver will ask whether or not you want it to update all other pages based on this template, saving you the time and hassle of copying and pasting the changes across your site.
Templates help us avoid copying and pasting common elements, which is great. However, it can't help us overcome the task of having to re-upload all the changed Website files, which we have to do whether we use Dreamweaver Templates or some other design approach. And of course, Dreamweaver Templates don't benefit designers who don't use Dreamweaver: it's the only program that knows how to handle these templates.
Server Side Includes (SSI)
Our third option for the management of repeated sections of markup is to make use of use Server Side Includes (SSI). SSI allows you to merge two or more files before your page is presented to the browser. The include file, or include, is simply a file into which the repeated section of code has been copied. It isn't a complete XHTML document in itself: it's just a part of your complete document.
To create an include, simply copy the repeated content from the original file, and save it as a new file. Then, include that file in the main document using the following line:
<!--#include file="newfile.html" -->
As an example, you might have an XHTML document that looks like this:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1" />
<title>Code Spark Notice</title>
</head>
<body>
<h1>Code Spark Notice</h1>
<p>This is where the text of the notice will appear.</p>
<p>© 2005 Code Spark</p>
</body>
</html>
The content from the top of this document all the way down to the <h1> heading is common to all pages of the Website, as is the content from the copyright notice onwards. We could divide this page into three parts: the top, the bottom and the middle—the middle being the only part that will change.
By copying the top and bottom parts of the document into top.html and bottom.html, respectively, we can replace them in the original document with the include information.
<!--#include file="top.html" -->
<p>This is where the text of the notice will appear.</p>
<!--#include file="bottom.html" -->
Once this file has been uploaded to a Web server (we'll set one up later in this chapter), anyone who views the page with a Web browser will see the file exactly as it was before you employed SSI. The Web server intercepts the #include file code in our HTML, and replaces it with the specified file, as shown in Figure 2.4, "Creating a complete document from three files using Server Side Includes."
Figure 2.4. Creating a complete document from three files using Server Side Includes.

To create new files that contain the same top section, we simply add the appropriate include line to each page on which we want the top section to display. Then, if we want to change the logo, we simply edit it within the top.html file, and re-upload that file. All of the pages that include top.html will automatically show the new logo.
Server Side Includes are an incredibly useful way to create documents that are easy to maintain, and, given that our tutorial site is likely to become quite large as we add new tutorials, SSI represents a good choice for us. After all, we don't want to have to copy and paste our changes, then re-upload all our files every time we make a change to a section; nor do we want to lock anyone who works on the site into using Dreamweaver. If the site was a brochure site that had only a few pages and wasn't expected to develop any further than that, you might decide against using SSI. However, having maintained a number of large sites over the years, I know that—in the case of Code Spark, at least—SSI will save us a lot of time and energy later on.
Dreamweaver understands includes: when you load a page that contains an include directive, it will display the part of the document that's contained in the SSI. However, you need to open the include file directly in order to make any changes to it. We'll look at how we can work with Dreamweaver and SSI when we move on to build our site.
Note: Using Built-In Functions to Include Files
If you're building a site using PHP, ASP.NET, or some other server-side language, you may be able to use that language's built-in functions to include files. These methods tend to offer better error handling features, but you're unlikely to need these features if your content is static.
In PHP, you can make use of include, require, include_once or require_once. See the relevant discussion in the PHP manual for more information. In ASP, Server.Execute is similar, but not quite the same.
Setting up a Web Server
Since we're building what could potentially become a large static content site, we'll employ SSI to reuse the code for the common parts of each page. If we want to test and view the site complete with all the included portions of each page, we'll need to run a local Web server. In this instance, "Web server" refers to the software that responds to browser requests by sending back Web pages. This software is responsible for the heavy lifting involved in SSI: intercepting #include commands in HTML files, and replacing them with the specified files. The term "Web Server" can also be used to refer to the computer that hosts a Website.
You may already have Apache or IIS installed if you perform any server-side Web development in languages such as PHP, Perl, or ASP. If you're unsure whether or not you have a Web server installed, try typing http://localhost/ into your Web browser: this will request the default page from your local Web server, if one is running. Both Apache and IIS install a test page; if you see such a page, it will be pretty obvious which Web server you're running. If you see only an error message complaining that localhost could not be found, you may need to install a Web server.
If you're running Apache, you may want to skip to the section called "Testing SSI " below; if you're using IIS, skip straight to the section called "Using IIS as your Local Web Server". If you're not already running a local Web server, we can set up the Apache Web server in order to process our includes. Apache is available for all major platforms, and is free to download and use.
Installing Apache
Apache is used on almost 70% of the Web servers that run sites on the Internet (according to netcraft.com). If you've ever used shared hosting on a Linux server, it's likely that your site was running on Apache. The Apache Web server is an Open Source project that's free to download and install, with installers provided for most operating systems.
Windows
Figure 2.5. Downloading the Apache installer.

To install Apache on Windows, go to http://httpd.apache.org/, click on Download, and grab the "Win32 Binary (Self Extracting)" version, as shown in Figure 2.5, "Downloading the Apache installer.". I'll be using Apache 1.3 throughout this discussion, but the instructions are more or less the same for Apache 2, if you wish to use that instead.
Locate and run the downloaded executable file, and progress through the setup questions by clicking Next. Don't worry if you don't understand the options presented; they're not important in the case of our simple testing server.