Now, I know that many of you may not have a website up and running yet, and you're thinking that maintaining a site is the farthest thing from your mind. However, one of tricky things about web design is how closely every aspect is related to every other aspect. Because although maintenance may seem far down the road, how you design and create your site can dramatically impact your ability to take care of it later. This is also why I've made it clear that even if you haven't "kept pace" with the lectures, that's OK, because all the lectures affect each step of design and construction. What I'm trying to say is that you should read this lecture even though you may not feel you're anywhere close to maintaining an actual website.
Once you have a site in hand, and you've set up a hosting account and obtained a URL, it's time to post your site to the web. This introduces one of those tricky, wonderful problems of information - you're about to duplicate your site. This can cause no end of confusion; you've probably experienced similar problems when editing a large document within a company. Which one is the original? Which changes are the right changes? Which version is the latest version? Who can edit and change the information, and which version should one work on?
In a corporate setting, there is typically a document server, or repository (e.g. Lotus Notes) that serves as the information clearing house, and provides access rights, versioning information, and more. There are similar management systems available for web content (Frontpage can do some of these things, as can CVS and many others), but you're unlikely to use such tools for your personal web projects. My rule therefore is that the actual website, the one on the web with a live URL that everyone can see, is the official and final version. The version on your computer then becomes a backup copy. Of course, if no one but you ever works on your site, this is less of an issue, but still a good rule to follow. Once you post your site to the web and verify that it's correct, it should become the master copy.
So, how do you post a site to the web? I mentioned two articles in lecture 4, which you should now read in detail. Even if you're not using Dreamweaver, the article points out a number of important issues.
The basic idea is that you simply copy the files that comprise your website onto another computer, one that's set up to be a web server. Copying the files is actually the easy part. The hard part is insuring that the files you copy actually comprise a website, and work the way you want them to. You can in fact preview your website by opening your home page (which should be named "index.htm" or "index.html") in a web browser, and you should then be able to see your website. Simply choose File / Open / index.htm from your browser.
There are two problems that are likely to crop up when you copy your site to another server. The first is that you've simply failed to copy all the appropriate files. When using Microsoft word for instance, it creates a whole folder full of files that it expects to be part of the web site (usually called "site files" or something like) - you must copy this folder to your web hosting account. Other programs will often create special files and images that appear correctly on your local machine, but disappear on your website if you fail to copy them.
The other problem that often crops up is due to relative vs. absolute addressing. I have a pretty thorough explanation of this issue as a part of my other lecture series, you can find the specific topic here:
absolute vs. relative indexing
Again, the basic idea is that a web page is comprised of many independent files, including at least HTML document, and typically some images. Each file must have an address, a place that the server and thus your browser can find all the appropriate document or file. The address of a given file can be relative (starting from this document, go up one directory, then into the images folder, then get this image) or web-absolute (starting from my root web folder, look in folder A, then folder B, then get this image), or finally, locally-absolute (starting from the C drive, look in folder X, then folder Y, etc.). Here are some examples:
../images/imageX.gif
/http-docs/images/imageX.gif
C:\windows\my documents\web project\site\images\imageX.gif
The problem you can encounter is when creating the site, if you're not careful, you'll use the wrong "address" for a document or file, and it will work fine on your computer, but not on the website. Relative addressing (the first example) is the best thing to use. Again, this is why I say that even if you haven't created a single page, it's still important to understand this lecture, because it's possible to create a site incorrectly, and then not be able to view it on the web.
Finally, and I mention this in the above article on FTP, moving files from one computer to another is a little different than moving files around on your own computer, and there's one particular hitch of which you should be aware. If you copy a file from a floppy onto your hard drive, and that file is already on your hard drive, your computer will ask you: do you want to replace this file? Many FTP programs (and site creation software such as Dreamweaver and Frontpage have FTP software built in) *will not* ask you "do you want to replace this file?" - they'll just do it. So, when moving files from one computer to another over the internent, especially web files which you know are duplicated on your computer and the web server, be certain which file is the master copy, and which is the duplicate, and which one you want where. I've wiped out important files more than once in this way, so be cautious before you copy!
In the third example above, Windows-specific addressing has been been used, and there are three problems with it. The first is the "C:" - this tells windows where to start its search for a file, but your web server likely won't be windows, and definitely won't have a C: drive. Also, Windows uses "\" and not "/" (particularly older versions of windows), and "\" won't work for web addresses. Finally, and *most importantly*, Windows (and Macintosh) happily allow spaces in folders and file names, but this is unacceptable on the web!!! This is again why I say that maintenance issues affect site creation - you may be able to see your site on your computer, but in order for the world to see it, and you to be able to maintain it, there are some basic good practices to follow, and one of them is not using spaces in any of your web folders or web file names.
I think it's important to note here that over time, you should receive feedback about your site from your users. Since you're building a site for other people to use, even though *you* may think it's done, you'll probably find otherwise down the road. This is one particularly important reason for establishing good maintenance habits now.
As you may recall, I suggested that you create a separate folder for your web project, and move everything into it, and that you further have a site folder that contains only HTML and images, and that ideally, you create yet another subfolder for the images. This structure 1) helps eliminate some of the above addressing issues - you know that moving the contents of your site folder onto the web will reproduce your entire site; and 2) helps provide an organization that you can more readily maintain.
Over time, websites tend to grow. They accrue content, images, pages, documents, and become more complex - they're organic. This is precisely why we spent so much time early on thinking about structure and organization - to provide a roadmap and allow room for growth. One reason you want to keep the number of major choices or categories on a page to a minimum to provide room for new ones. And a good reason for thinking in terms of categories is to provide a space for you to insert new content down the road (and to also provide a ready means for a web user to understand how specific content fits into the whole).
It's when sites grow that good maintenance practices and site design merge - it should be *easy* to add another web page, not bewildering and complicated. Here are a few more issues that relate to good maintenance and easy growth:
Naming conventions - it's a good idea to strike some naming conventions early on. Since you can't use spaces in your file and folder names, the conventional approach is to use capitalization (e.g. BuildingAWebsite vs. buildingawebsite). To provide further categorization, use pre- or post-fixed names with dashes and underscores, such as btn_About1.gif; hdr_ABout.jpg; tmp_About.htm. In the first example, I've identified the image as a button, vs a header image that sits at the top of a page. When you look at files listed in your image folder, this will help you identify which images are what (in case you want to change them). "tmp_" might mean the HTML page is a template for the About section of your site.
One mistake I've made (sadly, more than once) is to finish a site, but throw away or more likely lose track of documents and files I used to create the site. When it comes time to maintain and modify a website, it's very helpful to keep the original files around. That's why I suggest creating your content in text files, which are easy to read in any program, easy to spell check, and easy to transfer from one person to another (if you're not the only one working on the content). For the same reason, I typically keep all my Photoshop and other design files around, so that I can easily modify images, site maps, etc. instead of having to recreate them from scratch.
Includes - A web page is, or can be a whole set of separate files that are linked together within the HTML to create the page a user sees. For instance, to put an image on a web page, you don't actually store the image on the page itself, but rather link to the image using the IMG tag in HTML. The image gets "included" on the page when it's shown to the user. Two other common types of "include" are headers/footers, and style sheets. A footer is what it sounds like - information you want at the bottom of every page. You can simply insert this content over and over again, but as soon as you want to change it, you'll quickly become annoyed. There are two ways to include a footer on a web page - Server Side Includes, and Client Side Includes. In the first case, you would actually create an SHTML file, and put an Include tag on the web page, and the web server software will insert your footer into the page before showing it to the user. This is how copyright notices, page numbers, counters and the time of day are usually handled on a web page. This is a bit technical, so the second way to handle an include is to use your site creation software (Dreamweaver and Frontpage will handle this). You can tell Dreamweaver to use a template for all the pages on your site (or all the pages in a section, etc.), and Dreamweaver will build the final HTML when you export the site to its final destination.
This may seem like a bit much to bite off at this point, particularly if you've never created a site. But it will make changing and maintaining your site much much easier down the road, and is worth the trouble to understand. Obviously, different programs handle this in different ways, so you'll have to delve into the help section of your software to learn more. Look for topics on "includes," "templates," and "projects." This last category is important - rather than creating a series of independent pages and keeping mental track of where everything is, what belongs and what doesn't, Dreamweaver and others can keep track of what's part of your site project. Again, setting up projects for the first time can be a little daunting, but well worth the effort when you see how easy it is to change an entire site with the click of a button instead of laboriously editing each individual page.
Page templates - most site creation software provides a facility for using templates. Of course, using a template will allow you to create many similar pages quickly. But more importantly, it will allow you to *change* many pages quickly - by changing a page template, you can modify your entire site (or subsection of a site). Also, if you want to "include" things like a footer on your web page, and you don't want to learn how to create Server Side Includes (which involves learning a little HTML), templates can help you programatically build your web pages right on your own computer.
Cascading style sheets - I've mentioned style sheets before, they're an extremely powerful tool in site creation. As I mentioned, you can use style sheets to accomplish all sorts of complex effects on a web page, if you want to take the time to learn them thoroughly. However, I suggest at a minimum that you use a style sheet to set the color of your page, as well as the color and style of your primary font usages (text, headers, bolds, paragraphs, etc). Again, it may seem like a lot to learn to do something that you can already do with your web creation software *without* style sheets. But the advantage again is this: if you use a single style sheet to control the color of your page headers and your page text, and decide you subsequently want to change these aspects of your site, you can do so by editing a single file (rather than the entire site). And again, Dreamweaver and most site creation software will allow you to easily create, edit and use style sheets. If you include a style sheet on your page template, then you can modify many things about the look and feel of your website by editing two files.
Again, I'd like to stress that most people ignore issues of content management and site creation when they are getting started, and many designers never learn to pay attention to it. Learning good habits now will help you create and maintain even your first site, and will serve you well down the road.