Jump to Content
  The Ohio State University
. www.osu.edu
Help • Campus Map • Find People • Webmail • Search Ohio State •

Humanities Information Systems

Humanities Information Systems Home Page

Web Services

Get started building a Department Web site

Information about building your Department Web sites on the College of Humanities (COH) servers.

(a k a The Web Toolkit)

The purpose of this Web Toolkit is to provide a guide for you to develop a Web site from concept to production. We first start out with a brief discussion to help you determine the goals of your Web site. Next we help to define the 'roles' of the people who participate in the site's development. Finally we get into the more technical aspects of organizing the site and locating it on our servers. We end up with a listing of the minimum production requirments we expect to find in every department Web site. Please notice that none of the requirements are content oriented - each department is responsible for its own content. We are here however, to aid in your Web site development and help to make its operation efficient and functional.

So Let's Get Started !

  1. Why are you building a Web site?
  2. What roles do people play in the development of a Web site (and who is going to play what role)?
    Content Owner(s)
    Web Editor(s)
    Web Publisher(s)
    Web Manager(s) (formerly Webmaster)
  3. How and where do you build the site?
    Servers
    Staging server
    Production server
    Domain Names
    Directory Structure - On the server
    Web site directory structure for the department Web site.
    Web site sub-directory structure for the department Web site.
  4. What is the best way to name files?
  5. Mininum Requirements - What must department Web sites do to be current?
    ADA Recommendations
  1. Why are you building a Web site?
    (or Designing a Web site to be useful for the end users as well as the designers.)
    To help get started, ask yourself the following questions:
    1. Who are all of the potential users of the Web site?
    2. What are our goals for the site?
    3. How do we prioritize goals and then prioritize users based on goals?
    4. For our first priority users, what types of tasks do we want them to undertake on our Web site?
    5. Define a minimum of five (5) tasks &/or scenarios.
    6. Define content needed to accomplish each task.
    Return to beginning of this Web Toolkit.
  2. What roles do people play in the development of a Web site (and who is going to play what role)?
    To get organized, review the roles that need to be filled by people in your department to insure the development of an active and accurate Web site. These roles, defined below, may each be filled by different individuals or sometimes one person may fill them all. But before anyone takes on the responsibilites, they need to understand all that is expected of them. So take a look!
    Roles:(See Web / Internet Related Definitions for additional definitions of these roles.
    Content Owner(s):
    The content owners consist of the people who actually provide the information that is to go out on the Web. Their names (and phone numbers and/or email addresses) should be published at the bottom of every page for which they are responsible. (See sample owner message at the bottom of this page.)
    Web Editor(s):
    Web editors format the content owner's materials for use on the Web site. They do this work on the staging server. They must have their work approved for content, by the content owners and for Web compatibility by the Web Manager.
    Web Publisher(s) (This role is usually combined with that of the Web Manager.):
    The Web publisher takes the finished (and approved) Web documents and uses an FTP utility to upload the documents to their proper locations on the production server.
    Web Manager(s) (formerly Webmaster):
    The Web Manager is a person or persons designated by the department chair to approve the final design of the Web site, assign roles to others as needed, approve access rights for these others within the department according to their roles, approve final or finished Web pages, check the Web site regularly for continuity and 'freshness,' arrange or perform archival and cleanup functions for their Web site and finally for work with Humanities Information Systems as the department liaison for their Web site.
    Return to beginning of this Web Toolkit
  3. How and where do you build the site?
    Servers
    There are basically two (2) servers for all college and department Web sites. The first is the staging server and the second is the production server. The staging server is the working location where all Web site creation and refinement for any college or department Web pages is to be developed. Once the work is completed and meets the approval of the department Web Manager, the files will then be uploaded to the production server.
    Staging Server
    The staging server is, by definition, the location in which we develop or 'stage' our Web sites. We have set up the staging server for a variety of reasons.
    ONE: You have a development area, for creation of content, images, pages, etc that will keep your work together and not clutter up your hard drive.
    TWO: We keep all the development work in a location where the development is not viewed by the world outside until we are ready for them to view it.
    THREE: By putting the Web work in one, easily accessed network drive, the Web Manager can designate more than one person to work on the development, thus allowing for easier coordination of what is current and what is not.
    FOUR: The network staging server is backed up nightly, insuring less loss of work.
    FIVE: By maintaining almost duplicate Web sites on the staging and production servers, we have a complete backup of our entire system of Web sites.
    SIX: Keeping the Web pages on the staging server allows the Humanities Information Systems department to better be able to aid, when called upon, in your Web site development.
    Access to the staging server will be given, when requested, to the department Web Publisher. Only the department's Web Publisher will automatically be given access to the entire department Web site. They then are responsible for requesting access to either the entire Web site or to a particular directory for anyone else doing work that will be a part of the Web site.

    Access to the staging server will be Direct Drive Access. This means that when you log on to the Novell Network on your computer, the staging server will appear on your PC as your W: drive or on your MAC as another accessible Volume.

    Drive access to the staging server for the Web Publisher and their designees may be requested from H I S Service & Support at: http://his.osu.edu/service/forms/servicerequestform.cfm.

    Production Server
    The production server is the final location in which our Web sites reside. After completing our Web development and making sure that our pages work, the graphics appear properly and the links are accurate, we copy the pages from the staging server to the production server using the ftp protocol.
    Access to the production server for a departments Web site will be given, when requested, to the department Web Publisher. This access will be FTP access only. Access will typically only be given to other persons in the department when requested by that departments Web Publisher/Manager. At that time, those persons will only be given access to the location within the department Web site that is indicated by the request. The purpose of this is to create a process by which all changes on the department Web site are first created on the staging server and then reviewed by the Web Publisher/Manager before being placed into production.

    FTP access for the Web Publisher to the production server may be requested through HIS by sending an email to our COH Web Manager at: croley.1@osu.edu

    Domain Names
    Departments are to have their own domain names in the following format:
    http://DeptWebName.osu.edu/
    The Department Chair and Web Manager should determine the department Web name. The Domain is to be requested from and setup by H I S (College of Humanities Information Systems).
    Directory StructureLine drawing for a hierarchial directory structure
    A Directory structure is a way to organize files into a hierarchical structure. Directories contain bookkeeping information about files that are, figuratively speaking, beneath them. You can think of a directory as a folder or cabinet that contains files and perhaps other folders. In fact, many graphical user interfaces use the term folder instead of directory.

    Computer manuals often describe directories and file structures in terms of an inverted tree. The files and directories at any level are contained in the directory above them. To access a file, you may need to specify the names of all the directories above it. You do this by specifying a path.

    The topmost directory in any file is called the root directory. A directory that is below another directory is called a subdirectory. A directory above a subdirectory is called the parent directory.

    Web Site Directory Structure
    To both maintain a working consistency and to be better able to provide accurate Web statistics to departments, all departments Web sites is to have their Main Directory located off of the servers root directory.

    For example:
    root://
    aaas (Department of African American and African Studies)
    cfs (Center for Folklore Studies)
    coh (College of Humanities)
    english (Department of English)
    history (Department of History)
    nelc (Department of Near Eastern Languages and Cultures)
    etc..

    Web Site Sub-Directory Structure
    Department Web sites also need to maintain consistency with their sub-directory layout and naming conventions. This will allow for ease of transition from one Web editor (student helper, administrative assistant, etc.) to the next as well as making it easier for the Humanities Information Systems to aid Web managers. Finally, it will allow more future integration of information between the College Web site and the department Web sites.
    (Bold black denotes directory names. Red denotes file names)
    Main Directory (root directory for department Web site)
    default.htm
    (see File Naming below for naming of files.)
    images
    Contains all images for Main Directory pages and common images for the next directory level down.
    news
    default.htm
    images
    yr2000 (ie)
    yr3001
    default.htm
    jan.htm
    feb.cfm
    etc.. OtherMajorSection
    default.htm
    images
    If you have any questions about additional directory breakdown, please contact the COH Web Services Manager Jody Croley Jones at croley.1@osu.edu.
    Directory structure must be IDENTICAL on staging and production servers.
    4. Return to beginning of this Web Toolkit.
  4. What is the best way to name files?
    Frequently people do not give alot of thought to the naming of their files. However, by following a few conventions, you can make your Web site much more usable for your viewers. Here are the conventions that we advocate:
    • File names within a Web site consist of a name and an extension. i.e. FileName.ext. Because some servers are case (lowercase = j, uppercase = J) sensitive, it is suggested that all file names and file extensions be lowercase. This will solve the problem of trying to remember which files contain uppercase characters and why.

      Also because some servers are more 'picky' than other servers, it is wise not to use any spaces within a file name. Acceptable special characters should be limited to: - and _.

    • A file extension is the two to four character extension following the dot (.) in a file name. It is typically three characters. The extension is used by software programs to help 'recognize' a file. It indicates, to the program what type of information is stored in the file. For example, on PC's the extension .com or .exe indicates a program. A .doc file is typically a Microsoft Word document. And a .htm or .html file is a file that is recognized by a Web server as a file that has the correct structure to be delivered to and read by a Web browser.

      There are other file extension besides .htm that are recognized on the Internet. Some of these are .cfm - ColdFusion file, .asp - Active Server Page file, .php - Hypertext Processor, .pl - perl language file, .shtm - Server-site htm directive file, etc... We primarily use .htm and .cfm files on our Web sites. HTML files are of course standard Web files. The .cfm (ColdFusion) files are files that we use to interpret and display database information on the Web.

    • Within each and every directory you may create one file that is accessed whenever someone connects with that directory without specifying a file name. This file must be named - on our servers (in order of precedence) default.htm, index.htm or default.cfm. This file gains importance because, on the production server, directory listing is turned OFF. This means that if someone tries to access a particular directory - and there is no 'default' page, then they will receive a 404 - File not found error. Not a pleasant experience for your users.
    5. Return to beginning of this Web Toolkit.
  5. Mininum Requirements - What must department Web sites do to be current?
    Following is a list of required attributes for ALL College of Humanities department Web sites. If you have any questions about any of them - how to comply, why they are requirements, etc. please feel free to contact the COH Web Manager at: croley.1@osu.edu.
    • All department Web sites are to follow the directory structure as described at: Directory Structure
    • In addition, if there exists a department newsletter, then the News directory is to contain a news.htm (or cfm) file that contains the most current copy of the department news. The College Web site can then systematically 'pick up' and link to this newsletter from the College news page.
    • All pages on the department Web site are to identify and contain a link to the College of Humanities. It is easiest and best to do this through the use of the COH standard footer (see example at base of this page).
    • The front or home page of every department Web site is to use the COH version of the Ohio State University masthead. To view it, look at the top of this page.
    • It is recommended that a link to the department's own home page be made available on every page within the Web site.
    • Department Web sites are to be ADA compatible according to OSU policy and HIS guidelines.
    • Every page within the Web site that contains content identifiable with an owner must name the owner along with content last revised and next revision due information.
    • Departments must coordinate with H I S and use databases and tools developed by H I S for the common good of the College of Humanities. (i.e. People database, calendar database, etc.)
Return to beginning of this Web Toolkit.