Main Navigation

Home » Site Information

Standards for University System of Georgia Web Environments

Introduction

As the scope of the University System of Georgia (USG) web presence broadens, it is necessary to have in place a framework to guide and accommodate the development and growth of the USG web site. The USG web site should strive to be a dynamic, informative site that provides the visitor with reliable information and is easily navigable. To assist in accomplishing this goal, Information and Web Services (IWS) encourages all divisions, offices, and departments of the Board of Regents to adopt the following guidelines.

Development and Design

The following guidelines are listed to provide a general framework for developing and designing web pages for the USG web server. They are not meant to be restrictive, but to encourage web developers and designers to be attentive to a web site's structure and content so that visitors to the USG web site can quickly locate information.

Development and Design Guidelines

  1. The home page should be limited to broad areas not subject to frequent change, excluding news and announcements. It should not be a list of specific topics that ends up getting lengthy and unorganized. Visitors to the home page should feel comfortable when they browse the USG web site, knowing that they can easily navigate to the information they desire from one visit to the next.
  2. All pages should reflect a visual and organizational consistency respective to their level, location and purpose. The branding established on the home page should set the standard for the rest of the images used throughout the web site. A small, appropriate logo should be used on the two levels below the home page to identify the page as being a part of the USG web site. The idea is to give the visitor a sense of visual and organizational consistency from page to page and level to level throughout the site.
  3. USG Web site refers to the University System of Georgia Web site as a whole. The home page and subpages share a navigational structure and visual design. Levels are defined as the following:
    1. The first-level is the USG homepage.
    2. The second-level is any main section linked from the homepage (e.g., Colleges and Universities).
    3. Third-level pages are any other sub-pages of the USG Web site. These pages are linked from second-level pages.
  4. The top-level pages should have content appropriate for the page and implement persistent navigation schema. Content should be reasonable in length (no more than 750 words). Longer documents should be placed as a lower level page or linked to as a document for downloading.
  5. Before any higher level web pages (the first three levels) are posted, they must first be reviewed by Information and Web Services staff to ensure the following:
    1. textual accuracy;
    2. adherence to IWS coding specifications and BOR Visual Identity Program guidelines;
    3. no broken links, regardless of level;
    4. and proper placement within the web structure.
  6. All documents must be approved by a divisional director or by IWS before being placed on the USG web site. Each division will have some flexibility with lower level pages so that approved and edited documents ready for web placement may be quickly and easily linked.
  7. Before a lower level page is added, the developer should check for correct spelling, grammar, and organization and proper HTML. All items should be proofed before they are placed on the web. The author of a web document should have someone edit the document or submit the document to web administration for editing. Any time a page is added, it should be immediately checked to ensure that it displays properly, contains no broken links or grammatical mistakes, and conforms to HTML specifications and USG standards as outlined here and in the Page Content Guidelines section of this document.
  8. IWS discourages the use of animated GIFs.
  9. Meta tags should be employed on all pages to ensure ease of location by search engines. The following tags should be placed between the <head></head> tags of each HTML document:

    Examples

    <meta name="author" content="division/department name">
    <meta name="keywords" content="descriptive keywords separated by commas">
    <meta name="description" content="short paragraph that describes web site's purpose and/or content">

Page Content Guidelines

  1. All pages must be approved by a division director or IWS before being placed on the USG web site.
  2. Remember, your page will be accessible to anyone on the Internet. Your page represents not only you and your division, but the entire BOR and USG as well, and should be professional and consistent with the rest of the USG web site.
  3. The Web audience is literally worldwide; be careful to ensure that posting the information on the USG web site will not violate any copyrights, restrictions, or agreements. For example, do not post information that would violate a non-disclosure agreement.
  4. All documents must contain a "Last Updated" date and must be checked regularly and updated as needed by the creator of the page or web administration if so arranged.
  5. All documents must be "signed" by the creator by using the author meta tag (see #9 in the Design and Development Guidelines section in this document). (Note: This signature is visible only in the source code; it is not viewable by a web browser.) No page on the USG web site may be removed or altered by anyone other than the author of that page without the consent of the author except in the case of administrative changes performed by IWS staff.
  6. Within the USG web site, each page of level three and above must be written in a uniform format. Each page should contain the standard navigational features, including the "Leave a Comment" option. The comments will be sent by default to IWS. If desired, the comments for pages can be directed to a different individual. (Note: It is highly recommended that all pages on the USG web site follow this format.)
  7. To reduce spam, "mailto" links to individuals should not be used unless specifically requested.
  8. No unimplemented links and links to pages that inform the visitor that "this area is not developed yet" or "under construction" are allowed. Every page should contain useful information before being linked within the web structure.
  9. The use of excessively large graphic files is discouraged.
  10. Links to commercial entities are not allowed. It is the general policy of the BOR to avoid linking to commercial web sites and thereby making implicit endorsements; however, links to companies that provide goods or services specifically of interest to the BOR, OIIT, and USG institutions are not prohibited.
  11. No copyrighted material in any form can be used unless permission from the original copyright owner is explicitly granted.
  12. No information pertaining to other individuals who object to the information being placed on the Web is allowed.
  13. No material that might be reasonably considered abusive, profane, harassing, or sexually offensive is allowed.

Coding Guidelines

  1. Web developers and designers must follow W3C Accessibility Guidelines, Priority 1, to comply with the ADA (Americans with Disabilities Act). The recommendations made by W3C represent a best practice not only for accessibility, but also for web coding in general.
  2. Web environments be developed and coded to function in browsers that comply with the W3C standards for CSS, XHTML, and the DOM. Browsers that implement most of these standards are IE6, NS7, Safari, Mozilla, Opera7, FireFox, etc.
  3. Directory and file names are case sensitive (files and links to files must match in case). IWS recommends using all lower case for file names.
  4. Directory and file names must not have spaces. If you need a separator, use _ (underscore) or - (dash).
  5. Directory and file names shall be meaningful but concise (recommended 15 characters or less).
  6. Pages shall use the site's standard header and footer. Many web sites have their own look and feel and common headers and footers can be easily revised to reflect the visual identity and navigation of a site. Please consult with IWS for different methods available for creating common headers and footers.
  7. All links in a site should be relative, unless linking to a web site located on a different server.
  8. External cascading style sheets (CSS) should be used to format web pages. All pages that use style sheets should be viewable without style sheets enabled in the browser:

    Example

    <link rel="stylesheet" type="text/css" href="/path/to/stylesheet.css">
  9. If scripting languages are used such as JavaScript, a text equivalent must be provided for each page using <noscript></noscript> tags. Pages that use JavaScript should also use external scripts, using the following tags:

    Example

    <script language="JavaScript" type="text/javascript" src="/path/to/javascript.js">


    Some scripts must be embedded within the page in order to work properly, such as scripts that print the date at the bottom of the page. In this case, a NOSCRIPT equivalent would provide a text equivalent for the script-generated date.
  10. Often frames are used to separate content from navigation elements. When using frames, be sure to use no-frame (<noframe></noframe>) tags with explanatory text. Also, name the frame pages within the title (<title></title>) tags to reflect their function or relationship to other frames (e.g., a navigation frame on the left should be named "Left Navigation" or an equivalent description). Due to usability issues, IWS recommends not using frames for public sites.
  11. When using tables, provide a table summary that describes the content or purpose of the table. Tables used for page layout should include a table summary describing the function as a visual layout/organization for graphic elements. If the table is used for displaying data, include caption tags (<caption></caption>) after the beginning <table> tag. Try to avoid using nested tables.
  12. Always provide a descriptive text equivalent for all images by using the ALT element of the image <img> tag. If the image is a photograph or chart, be sure to describe the content of the image and not simply label it as "photograph" or "chart."
  13. For comprehensive information about accessibility coding practices, go to the USG guidelines or see the W3C Accessibility Initiative (http://www.w3.org/WAI).

E-Mail Addresses

Developers may wish to link e-mail addresses of staff on their web site. If so, please remember that doing so may result in spam and abusive e-mail messages. The web administrator's office has no control over e-mail received by persons listed on the USG web site.

Third Party Web Developers

In some cases, a division may wish to contract a third party to develop and design a web site for a particular project. The USG web administrator requests notification of third party development/design contracts in order to ensure a general awareness of ongoing projects, a collaborative atmosphere for all parties involved, and the proper loading and testing of the web site. In addition to the items listed above, third party developers/designers must use the text "© 200x Board of Regents of the University System of Georgia" as link on the web site's home page and lower level pages. The link may appear in the page footer.

In addition to the items listed above, we encourage that all developers follow W3C Accessibility guidelines (see the coding guidelines above for a brief overview of coding practices).

Page Administration

All pages on the USG WWW that are level three and higher will be administered by web administration, unless otherwise arranged. A division wishing to administer a level three page must assign a contact person for all issues concerning the page. In order to administer a page, an individual must have an understanding of HTML; adequate UNIX skills, such as creating directories and editing and moving files; be willing to maintain and update the page as needed; be approved by his or her supervisor; and notify web administration of the desired administrative change.

  • have an understanding of HTML;
  • possess adequate UNIX skills, such as creating directories and editing and moving files;
  • be willing to maintain and update the page as needed;
  • be approved by his or her supervisor; and
  • notify Planning staff of the desired administrative change.

In order to maintain visual and organizational consistency, all level-three pages must follow the same structural pattern.

The administrator of a level-three page must "sign" the page in the manner outlined in the Page Content Guidelines section. This signature is visible only in the source code--not by the browser--and will provide an easy way of determining the author of a document. No page on the USG web site may be removed or altered by anyone other than the author of that page without the consent of the author except in the case of administrative changes performed by web administration.

Subdomain and Domain Names

Offices, departments, and divisions that initiate special projects that go beyond the purview of their web site may request a subdomain name to reflect a project's profile. The following guidelines are proposed as general framework for evaluating the merits of subdomain and domain name requests.

Subdomain Name Guidelines

  1. All projects using subdomain names must have a high profile and extend beyond the purview of originating division, office, or department.
  2. All subdomain names must include "usg.edu" at the end of the URL. No exceptions are allowed.
  3. All web sites with subdomain names must have a link to the USG web site.
  4. All requests for subdomain names should be forwarded to OIIT Customer Services (http://www.usg.edu/customer_services). Systems Support Services and IWS evaluate requests.

Domain Name Guidelines

  1. All projects using domain names must have a high profile and extend beyond the purview of originating office, department, or division.
  2. No "com" domains are allowed.
  3. All requests for top-level domain names are subject to guidelines established by InterNIC. Currently, requests for "edu" domain names are limited to four-year colleges and universities.
  4. All requests for domain names to be hosted on the USG server will be submitted to OIIT Customer Services (http://www.usg.edu/customer_services). Systems Support Services and IWS evaluate requests.

Security

Security is considered of the highest importance in web development. Because web sites are the most visible components of an organization's network, they can become targets of attack.

The USG web site is hosted on a UNIX machine using Apache web server. The server provides a robust environment for web sites and applications, and includes support for a variety scripting and programming languages including PHP, PERL, Java, and JSP. IWS uses a three-tier server environment for design, development and publishing of web-based content: a development server for experimental and proof-of-concept environments; a test server to preview revisions, test scripts, and review web sites and applications prior to implementation in production; and a production server for web sites and applications available for public view and use. It is very important that the development of web content and coding use the following guidelines:

  1. Shell accounts with usernames and passwords are assigned by Systems Support Services to qualified staff to access and revise files on the web server.
  2. Staff who have accounts are encouraged to become familiar with the Information and Web Services Web Design and Development Guidelines before creating, revising or deleting pages on the web server.
  3. It is recommended to change your password every 180 days (8 characters, alphanumeric with one non-alphanumeric character).
  4. All directories must have an index file (use either index.html or index.phtml) including image directories. Directories that normally do not use index files (e.g., image directories) should use the directory redirect script provided by IWS.
  5. Image files should be placed in an "images" directory, PHP and JavaScript scripts in an "includes" directory, and CSS files in a "css" directory.
  6. HTML files with embedded PHP should use ".phtml" as the file name suffix. Otherwise, use the suffix ".html."
  7. No world-writeable files or directories are allowed.
  8. All forms should use validation scripts to ensure the proper submission of data.
  9. All user input data must be cleaned according to standard security practice before being passed to the web server or system for use. IWS will review all scripts used for data transfer before they are moved to production server.
  10. All collected data will be stored securely. Information gathered from web applications such as surveys is stored in a restricted access area on the server. IWS will provide the path and storage area for the data file.
  11. All password-protected areas are to use the following table to determine when usernames, passwords, and content/data are to be encrypted:

    Content/Data Example Username / Password Required Username / Password Encrypted Content / Data Encrypted
    Confidential SSN, payroll information Yes Yes Yes
    Protected Content administration tool for public web site Yes Yes No
    Restricted Test web sites, non-proprietary screenshots Yes No No
    Public Public web site No No No
  12. Before revising a page on the web server, the page should be first copied from the production server. All pages in production are considered the latest and most accurate version.
  13. All new or revised content should be reviewed on the test server before placing content into production.
  14. Accounts are assigned to individuals to ensure a secure server environment. Your account is intended for your use only. DO NOT ALLOW others to use your account.