Skip over navigation

keyword search: ITC

For:

• Students
• Instructors
• Researchers
• Staff
• IT Professionals

Web Site Building Hazards

Prerequisites

Experience creating Web Pages using HTML

Format:	Discussion and hands-on
Length:	2 hours
Materials:	3.5" diskette

Course Objectives: What you will learn

1. Cross-Platform File Naming Conventions
2. Directory Infrastructure and Hyperlinks
3. Managing a Team-Based Web Project
4. WebSite Building Tools
5. Resources Available at UVa

Course Content

1. Overview
2. File Naming Conventions
3. Directory Infrastructure
4. Team Management
5. WebSite Tools
6. Conclusion

Overview

Anyone who has "surfed the 'Net" for any length of time has experienced the frustration of becoming lost within a large and confusing site. The Microsoft site has an incredible amount of information that is constantly changing, making it sometimes difficult to navigate or find a specific piece of information. Likewise, there are sites such as Dell and Byte, which organize their information carefully, making the task of navigation easy for the user.

Although end-user navigation is a large issue, there are other hazards that face the web site designer:

• file maintenance & organization
• file naming
• maintaining links

These issues are even more pronounced when there are several people working on the same web project. Team-members may accidentally overwrite each others' material, file names may be too similar or incoherent, and files may be duplicated several times throughout different directories. As a result, planning and good team management are crucial to the success of medium- to large-sized web sites.

File Naming Conventions

Of particular concern is how each operating system handles filenaming issues: what extensions are used and which characters are or are not allowed. It is best to use UNIX filenaming conventions whenever possible: never use spaces, slashes, tildes (~), colons, semi-colons, asterisks, question marks, exclamation marks, plus signs or any other non-alphanumeric characters in your filenames. These are considered command characters to UNIX and will not be interpreted correctly by the server. Likewise, do not use spaces or dashes as word separators. Instead, use underscores to separate words. Finally, always use lowercase characters in your filenames. Like non-alphanumeric characters, capital letters have different meanings in UNIX and the server will not be able to read your files correctly. For example, the files TEST, test, Test, and teSt are each distinct and valid filenames to UNIX. This attribute of case-sensitivity can wreak havoc on web servers.

You should make sure that you keep your file extensions consistent throughout your ebsite (i.e., .jpg vs. jpeg). This is particularly important with the .html vs. .htm extensions. For example, PCs tend to default to the .htm extension, whereas UNIX servers support .html extensions. It doesn't really matter whether you use the .htm or .html extension as long as you are consistent. Choose one extension to use and stick with it throughout your website

How do you organize your images when you have an image-intensive site? If there are many images to be put on your site, you might want to use an algorithm to assign names to your images. Otherwise, it may be very difficult to differentiate one image from the other. An example in use comes from the Drama Department's Costume Archive. The drama department used the following formula to name the many images for its site:
      Year, type of clothing, color, xx
Thus, a white evening gown from the year 1932 would be named: "1932egwh". However, the drama department has 16 white evening gowns from 1932. Assuming that this particular gown is the 7th of the 16 gowns, we could give it the following name: "1932egwh07.jpg".

The key to this naming convention is to find the two or three variables that are most important to describe your images. Then, derive an easy-to-understand formula with which to create the name of the image.

The advantage of using such an algorithm is that one you have the formula in place, you will not need to spend a lot of time figuring out what name to give the image. This will prevent you from using the same name twice and possibly overwriting your original image, which is exceptionally important, when there are several people working on the site at one time. Additionally, such an algorithm makes it easier to locate a group of files. Files are listed in alphabetic order on the UNIX server. Using the algorithm described above, all images of clothing from 1932 would be grouped together. Within the 1932 group, all of the evening gowns would be grouped together. This is much preferable than scrolling back and forth through large lists of images to find a particular file.

Directory Infrastructure

An operating system consists of files and directories (a.k.a. folders) and each operating system manages its files and directories differently. Although the terminology and pictures below are PC-based, they hold true for Macs, as well.

Electronic folders are used to organize your electronic data in the same way that paper folders and file cabinets are used to organize your paper documents.

Folder icons look like actual paper folders.
It is possible to nest folders inside of other folders In the example below, when you open the folder "Spring 97" you find that it contains three other folders and two documents.

In UNIX and DOS the word "directory" is used in place of the word "folder."

If the "Projects" folder above contained a file named Target you could write a pathname to Target as follows: /Spring97/Projects/Target. This text description is read: A document named Target is located within a folder (directory) named Projects which is contained within a folder named Spring97.

Directory structures and Web addresses are closely related. In fact, the directory structure becomes the Web address.

When a web page is on a Web server that is different from the workstation where it is viewed, it is necessary to specify the server as well as the pathname. Thus, the Web address for the required texts for a course EDES 775 at the Curry School of Education would be as follows: http://curry.edschool.Virginia.EDU/curry/class/edes/775/Texts.html. In this address "curry.edschool.virginia.edu" is the name of the server. The remainder of the pathname to the right of the server name is the directory structure.

Paths to Web Directories

There are two types of links found in a web document:

1.    Absolute link         (Example: "http://www.newschool.edu/academic/mannes/jazz.html")
2.     Relative link         (Example: "jazz.html")

Absolute links have paths that are prefaced by http:// and contain the full web address. An absolute web address must be used for links to Web pages on other servers.

A relative address should be used for links to other Web documents on the same server, especially when the files are all part of a larger project you are developing. Using relative addresses will also make your Web document more portable and easier to maintain.

For example, a wildlife habitat project developed in the Spring of 1997 might include a graphic named "lion.gif" residing in a folder named "Habitat" placed within another folder named "Projects" contained within a third folder named "Spring97" which resides on a floppy disk on the a:\ drive.

Spring97
      Projects
             Habitat
                    Lion.gif

The full path name to this image on the Zip disk would be as follows:
      <IMG SRC = "///a:/spring97/projects/habitat/lion.gif">

However, it is unlikely that the directory structure on the UNIX server would be exactly the same as the structure of nested folders on the microcomputer. Using the absolute address in this instance would make it necessary to re-write all of the addresses when the project is transferred from the microcomputer to the Web server. Using the following relative address would be far more efficient:
      <IMG SRC = "lion.gif">
The relative form of the address is less complex, and it will not have to be re-written if the project is moved to another computer.

Pathnames to Files

The code to link a picture of a lion to a web page would be as following: <IMG SRC = "lion.gif">
However, if images were stored in a subdirectory named "images", the path to the image would be altered to read:
<IMG SRC = "images/lion.gif" >

When creating a web site you could put all of your files and images into your main directory. However, it is easy for your directory to become cluttered with various images and HTML documents. A better alternative is to create additional subdirectories within your main directory to help you to organize your web projects. It is recommended that you to create the following subdirectories:

docs:	To contain all html documents, except for the splash page ( home.html or index.html) which should be placed in the root directory
images:	To contain all .GIF, .JPG, and .PNG files
sounds:	To contain any .wav or .midi files
trash:	To contain those files you are not currently using on your site but do not yet want to delete

It may be helpful to remember that the first page (also called the "splash page") is often called "home.html" or "index.html" by default on the UNIX platform. At UVa, the default is "home.html". Your "home.html" page should be placed in the root of your directory (a.k.a. "public_html" directory for most people at UVa). All other .html files can be housed in the docs directory. The images directory can store general images such as bullets, horizontal rules, and buttons, which are used throughout the web site as well as all other images. It is easy to link to images this way. The advantage to this file system is that if you have a certain image that is used consistently throughout your site, you can change that image just once in the "../images" directory as opposed to wasting valuable time changing that image on each and every page.

Thus, your folders might look like the following:

• Animals Project folder
  
  • home.html
    
  • docs folder
    
    • amphibians.html
      
    • reptiles.html
      
  • images folder
    
    • arrow.gif
      
    • banner.gif
      

In the above example, a Web developer might need to include a link to the graphic arrow.gif in the Web document "reptiles.html." Two dots ".." can be used to indicate the previous directory. A relative reference could therefore be written in the following way:
      <IMG SRC =" ../images/arrow.gif">
This would be the equivalent of saying, "Go back to the previous directory, and then go down a level to the directory named "images" to access the file named "arrow.gif."

File Structure

A structured system is the most common system of links. In the simplest terms, a structured system is a hierarchy. It gives the viewer a idea of where their position is within your site and makes it easier for them to navigate successfully. It is best to keep your hierarchies two to three levels deep, otherwise viewers will become frustrated.

Too many menu pages results in "voice-mail syndrome". After having to choose from too many menus you forget what it was you originally wanted, and you're too annoyed to care.
ñ Laura Lemay, Teach yourself Web Publishing with HTML 3.2 in 14 Days. Sams.net Publishing, 1996.

Structured links are links to other documents within your website. Most often, these will be relative links. You should use relative links whenever possible within your website (ex. <a href="/docs/02_intro.html>) Structured links should be represented by headers & footers or by frames, whereas unstructured, or absolute, links should be placed in the body of the page. Finally, make sure there is a link back to home on every page.

Team Management

Managing the production of a WebSite requires a great deal of planning and organization. In addition to possible confusion regarding file-naming issues which was addressed earlier, other difficulties the website manager may encounter may be a result of many people working on one project. In this case the website manager should be concerned with the possible duplication or deletion of work. With a little organization, the old adage, "Too many cooks spoil the pot" will not apply to your website.

StoryBoarding

Before you begin your first HTML document, you should storyboard your site. Storyboarding is comparative to charting your course on a map before undertaking a cross-country trip by car. It is a rough outline of the finished product and shows the overall structure of your website. Your storyboard should include which topics go on which pages, the primary links, and a conceptual idea of more prominent images. This allows several people to develop certain portions of web site at same time, which minimizes the duplication of work.

Team Coordination

One aspect of site development that the web site manager may overlook regards access rights to the server: Who will upload the final documents to the account on the web server? Should every member of the development team have access rights to the account on the server? Who is responsible for the content of each page on the web site? What if a document or image is overwritten? These are very important questions which, if ignored, may determine whether a project meets or falls short of the completion deadline.

The three most likely scenarios available to the web site manager are open access, closed access, and partial access to the account on the web server.

Under the Open Access scenario, each team member has unrestricted access to the web server. This model, obviously, provides very little system security. Although content may be updated immediately by each project member, this advantage is overshadowed by the likely possibility that one member may unwittingly overwrite another person's file, thus saving an older version of the particular document to the server. Another disadvantage to the open access scenario hinges upon accountability; Improper content may be uploaded, and viewed by the public, at any time by any team member without the site manager's prior approval or knowledge. The site manager, however, is ultimately responsible for the content that is uploaded to the server whether or not he has knowledge of that content. The Closed Access scenario attempts to prevent this type of occurrence.

The Partial Access scenario attempts to balance security issues with the demand for immediate information publishing. This model restricts team members' access rights to specific areas of the account on the server. Before partial access can be implemented, the web site manager must determine who may have access to which areas, or folders, of the account. Allowing each team member to upload only to his specific area permits updates and changes to be uploaded immediately without the possibility of accidentally overwriting, deleting, or duplicating someone else's work. Additionally, this scenario makes it easier for the web site manager to control the overall development of the site and determine the author of any improper content while allowing greater access privileges to the project members.

It is important to note that many issues may be resolved by following this rule of thumb throughout the development process: each page should include the author's name and the date on which it was created. Inserting the creation date or modification date on a document may clear up any confusion if there exists two copies of the same page. Knowing the author of a page encourages accountability for errors or improper content of a page from each team member.

WebSite Tools

There are many tools that are available to site builders today. New software packages such as Microsoft FrontPage and NetObject's Cold Fusion are not difficult to use and provide many features that are attractive to both novice and advanced website builders alike.

The New Media Center officially supports Claris Home Page, a powerful yet simple wysiwyg (what-you-see-is-what-you-get) HTML editor. Claris Home Page, among its many features, supports forms, tables, and client-side image maps.

Conclusion

In summary, the website manager needs to be organized to avoid the production of the actual website from going out of control. The manager needs to have the following items already done before any HTML coding is produced:

1. Storyboard the site: know who your target market is and what information you want to present to them; map out the basic structure of your webpage.
2. Define your file-naming algorithm
3. Determine which type of team coordination you plan to use -- open access, closed access, or partial access ñ and how you intend to implement it.

Once you have done these three things, as the website manager, you will be in a better position to determine what resources you will need in order to complete your website.

Resources available at UVa

Digital Media Lab
The Faculty Instructional Toolkit
ITC Public Labs
Instructional Technology Resources
UVa Suggested Guidelines for WebDesign