University Libraries Web Style Guide

Introduction

This document pulls together information to be used by those responsible for creating, maintaining, updating, and revising official UCF Libraries Web pages, hereafter referred to as Web Editors. The University of Central Florida Web Development Resources (WDR) has created an extensive set of pages filled with information pertinent to university Web pages. Web Editors are responsible for familiarizing themselves with this information. This document puts forth the philosophy and practices specific to Libraries Web pages. Questions should be addressed to the Libraries' Web working Group (WWG).

Look for links throughout this guide for tutorials created primarily by Athena Hoeppner, Electronic Resources librarian. Microsoft FrontPage is the software used by the Libraries to create and maintain Web pages. If a Web Editor prefers to use another program or method the results must interface successfully with FrontPage. For help in getting started in FrontPage and with the basics begin with the Tutorial Introduction. All documents should be in compliance with HTML 4.01 standards. Web Editors are strongly encouraged to familiarize themselves with basic HTML tags to be able to edit FrontPage in HTML mode.

Web Editors should also familiarize themselves with the Web Editors Duties (pdf/4.51K).

Accessibility

Web Editors are responsible for familiarizing themselves with and complying to all University of Central Florida (UCF) Web standards and policies as described in the Web Development Resources' (WDR) Web policies. Of particular note for accessibility see WebAIM Section 508 Checklist and the GSA Section 508 sites. If a Web Editor chooses to include elements that do not meet the accessibility requirements, a link to an alternative text-version page must be included. New pages should be compliant as they are created. Existing pages should be made compliant as part of the regular maintenance schedule.

Back to Top

Page Components

• CSS Style Sheet
• Header
• Local Menu
• Updated Date
• Page Owner
• Titles

The UCF Libraries seeks to maintain a consistent, recognizable look and feel to all official pages on its Web site. All official UCF Libraries Web pages should adhere to the following stylistic, design, and navigational elements. When deviation from these elements is necessary, it should be approved by WAC.

Standard.css Style-Sheet

The standard CSS style-sheet is included automatically in the header (see below). It sets the following and much more for each Web page:

• Font: Arial, 100% (roughly 14pt size)
• Background Color: White (#fff)
• Text Color: Black (#000)
• Headers: H1=160%; H2=140%; H3=120%; H4=110%
• Link Colors: unselected and visited=blue; active=gold

Back to Page Components

Back to Top

Header/Footer

Always use the Libraries' header and footer on each page. The header must be the first component on any Web page and may not be placed inside tables, paragraphs, divisions, or other HTML segment tags. Not only will this promote consistency, but the header provides our basic navigation and the footer also contains the contact information for the Libraries. The header and footer files are kept in the /Web/HeaderFooter/ folder. Any variations must be approved by the webmaster.

Back to Page Components

Back to Top

Local Menu

In addition to the header, each page in the official Web site will have a side menu. The default menu will be the same as the menu on the home page. Customized menus are possible and recommended. Exceptions to this policy should be granted by WAC. The "local menu" is the preferred mode of navigation for all pages.

Back to Page Components

Back to Top

Updated Date

• The date a page is updated should appear at the bottom of the file/page.
• Format for dates on UCF Libraries Web pages should be: “day” (numerical) “month” (spelled out) “year” (four digits), e.g., 15 July 2004. The standard.css style-sheet sets the appropriate font and placement for update dates.

Back to Page Components

Back to Top

Page Owner or Content Provider:

The Libraries side menu provides necessary contact information. When the content of a page might benefit by providing specific contact information in addition to that provided in the menu, an exception is permissible, when absolutely necessary to provide individual contact information.

Back to Page Components

Back to Top

Titles

• Each page must have a TITLE tag. Whenever possible the text in the TITLE tag and the "page title" (i.e., header) should be the same. The information in the TITLE tag appears in the title bar at the top of browsers, bookmark entry for the site, search engine results and browsers' "Back"/"Forward"/"Go"/"History" lists.
• Try to match the wording of the title with the text within a document, especially when linking to this page from other pages, If that is not possible, use Link Titles to provide this information.
• Make titles concise and meaningful for the user. Keep in mind that visitors may locate the page using either a Web search tool or the search feature within the UCF Library site. Try to make the title understandable out of context of the library site.
• Do not start your titles with UCF Libraries. WWG recommends including UCF Libraries at the end of each TITLE tag.
• Each title within the Web site should be unique.

Back to Page Components

Back to Top

Aesthetics

• CSS Style-Sheet
• Layout
• Colors
• Fonts
• Links
• Page Length
• Page Width
• Tables
• Things to Avoid
• Graphics & Images
• Video & Sound
• PDFs

Page Layout:

• Consistency: The most important quality of a well-laid out page is consistency. If one title in a section on your page is centered – then center all section titles. Use the same font and size for each element of each section so that the page has a planned look rather than a haphazard, thrown together look.
• Scanability: Organize Web pages so that users can quickly scan the pages.
• White Space: Give serious consideration to the generous use of white space. This adds emphasis and legibility and does not add to the file size.

Back to Aesthetics

Back to Top

Page Colors:

• Basic background color: white (#fff).
• Other acceptable colors, e.g., fill-in for tables, include: gray (e.g., #AAAAAA or #DDDDDD), gold (#CC9900 or #FFCC00), and black (#000000). Whenever possible the official Libraries color scheme (white, black, gray, gold) should be used. Exceptions should be petitioned to WAC via the chair.
• See the table below for acceptable Libraries Web page colors.

Color Table
Black #000000	Dark Gray #666666	Gray #AAAAAA	Light Gray #DDDDDD	Lightest Gray #F4F4F4
Preferred Gold #CC9900	Light Gold #FFCC00	Pale Gold #FFEEA8	Off-White #FFF7DD	White #FFFFFF

 

Back to Aesthetics

Back to Top

Fonts:

The use of the proper font is essential to the consistent and professional look of a Web page. Use the default font size for the main content of the page. Use headers (H1-H6) for section headings, instead of setting a different font size. Use smaller font sizes for unobtrusive information or navigation, e.g., dates, Top links, etc.

• Choose a font available with the standard operation systems. The preferred fonts for official UCF Libraries Web pages are: Arial (sans serif), Times New Roman (serif), and Monotype Corsiva (script).
• Use sans serif fonts, e.g., Arial, which are easier to read from a computer monitor. The default font for Libraries pages is Arial.
• Weigh the use of elaborate or specialty fonts carefully as not all fonts display as expected and therefore may not be approved by WAC. Always designate alternate fonts for specialty fonts - or consider importing the specialized text as a graphic.
• Use multiple fonts on the same page sparingly for emphasis.
• Avoid underlining text, which can easily be confused with links.
• Use black (#000000) for text on official UCF Libraries Web pages. Other colors may be used sparingly for emphasis. Other colors (see Color Table above) used on the Libraries Web site include gold and white (on a dark, i.e., distinguishable, background).
• Use relative, i.e., percentage, font sizes rather than (pts) sizes. This allows the reader to use his or her browser's increase or decrease text feature. Comparison table of point sizes vs. percentages. Test the page with the increase/decrease text feature in different browsers (Netscape, Internet Explorer, etc.) to be sure it handles this feature. Consider redesigning the page if not.

Back to Aesthetics

Back to Top

Links:

• Use the following link colors:

Link Colors
Unselected Link Color #0000FFd	Active Link Color (#CC9900)	Visited Link Color #0000FF

• Use non-clickable characters to separate lists of links to help screen readers differentiate the links. The | ("pipe" or vertical bar) character is often used for this purpose.

Back to Aesthetics

Back to Top

Page Length:

• Avoid lengthy pages.
• Keep a page to three or fewer screens.
• Consider breaking one long page into several shorter pages with links.
• Place a table of contents or menu buttons at the top of the page to assist the reader to move quickly through the page without scrolling if using a long page.
• Use navigation buttons throughout the pages to allow the reader to move quickly back to the table of contents or menu.

Back to Aesthetics

Back to Top

Page Width:

• Try to design your pages to be any width available, larger or smaller than your browser window. Not everyone will have the same screen size and it's important to not alienate our visitors because of their settings.
• If you must design for a specific width, plan for a window size of 1024 pixels by 768 pixels.
• Avoid horizontal scrolling.
• Pages should also be designed with very small screens in mind; in the case of mobile devices. These devices are gaining in popularity and it's important that our pages work well and look right on them too.

Back to Aesthetics

Back to Top

Tables:

• Tables should not cause the page to exceed 1024 pixels in width. Use the SharePoint Designer "Preview in Browser" function, with a Window size of 1024 x 768 to visually confirm that your tables do not extend off the right side of a window.
• Border: Keep the border relatively small, or set the border size to "0" to create the effect of columns.
• Colors: Use high-contrast text and background colors, consistent with the standard Libraries colors.
• Alignment: Align the table and the table cell contents for the best readability.
• Cell Spacing: Use sufficient cell spacing to visually separate the contents of one cell from another.
• Sizing - Percentages: Use percentages to control your table and table cell size. The table will size itself according to the browser window. This method is the most certain way to ensure that a table does not extend to the right of the window's display area. However, percentages do not allow for strict control of the size and shape of a table.
• Sizing - Number of Pixels: Avoid using pixel dimensions. Specifying an exact number of pixels for a table and table cells allows for control of the exact dimensions of the table, but it may extend past the right side of the window if the browser is not set to full size, or if the screen resolution is set smaller than 1024 x 768.
• Include the "summary" attribute in tables. This is free text describing a table's content. Many talking browsers can speak this text.
  Example:
  <table summary="Policy information for other libraries. Columns/rows in this table include...">
  Enter this information in the <table> tag in "Code" view mode in SharePoint Designer.

Back to Aesthetics

Back to Top

Things to Avoid (Unless Absolutely Necessary):

• Blinking text
• Simplistic animated graphics
• Pixel based dimensions
• Font settings (changes to the font size, font family)
• <font> tags. (Use span with style instead.)
• Embedded applets - use only with webmaster's permission
• Frames. Web Editors wishing to use frames must obtain permission from WWG.
• Too many links next to each other
• Links made up of too many words

Back to Aesthetics

Back to Top

Graphics & Images

The key to using images and graphics is simplicity.

• Consider page size and loading time when using graphics on any page.
• If the image is critical to understanding the information on a page, use the "LONGDESC" tag that is a longer free-text description for images. Many talking browsers can speak this text. Avoid describing the picture; convey the information the image is there to present.
• Keep images under 40K (@ 72 dpi) so that the graphics do not take too long to download. Provide a thumbnail of larger images. Give the size of the full image. The larger image should still be no larger than 72dpi. The resolution of images may be changed by using various programs including Microsoft Photo Editor or Image Composer.
• Include an "ALT" tag that provides alternative text describing an image's function for all images, including navigational bullets or buttons.
• Include image "HEIGHT" and "WIDTH" tags (in pixels). These tags permit page text to load before the images. FrontPage automatically includes these tags. To change the image size, right click on the image. Select "Picture Properties" and make your changes.
• Save all images, especially photos, as JPEG. Simpler images (i.e., drawings, logos) may be saved as GIF.
• Save all images in the Images folder, creating a subdirectory only if necessary.
• NOTE: Bullets, Icons, Photos, and other images are available in the Images folder.
• Use the color bullets in the style drop down menu instead of inserting an image in list displays. If the bullet you are looking for doesn't exist contact the webmaster, who will add what you want to the CSS style-sheet.

Back to Aesthetics

Back to Top

Video & Sound Files

Like images and graphics, the use of video or sound files should be done judiciously and only when integral to the message.

• Provide a text transcript if using important video or sound files

Back to Aesthetics

Back to Top

PDFs

• PDFs are a great way to electronically distribute hand-outs or fliers that have exacting sizing or printing requirements.
• Provide the size of the PDF file where you link to it. Also provide the information in a format accessible to all users, preferably HTML. PDF should not be a replacement for HTML. PDF is not fully accessible to people with visual disabilities.
• Include a link to a reader when using PDF files.

Back to Aesthetics

Back to Top

Functionality

• Navigation
• Loadability
• Printability
• Frames

Navigation & Links:

Consistent navigation buttons and/or links are critical to a well-designed Web page. Create a common navigational look to ensure that users can use the Web site navigation effectively.

• Use the localmenu.htm to provide consistent navigation for Libraries' Web pages.
• Make navigational icons unobtrusive but easily recognizable.
• Provide links on each page to the “parent” home page.
• Use descriptive text or the page title for links rather than using "previous" to refer back to a specific page.
• Avoid "click here" links. Incorporate links into the text of the document, e.g., rather than "for more information about UCF, click here." type "information about UCF." (NOTE: Neither of these are active links, just samples of what the links might look like.)
• Use non-clickable characters to separate lists of links to help screen readers read the links. The | ("pipe" or vertical bar above the "\" key) character is often used for this purpose.
• Space navigational tools and icons far enough apart and make them large enough so that those who have difficulty using a mouse can more easily select them.
• Let visitors know if clicking on a link will open a separate window (e.g., clicking on this link will open a new window in your browser.)
• Provide links to all Web sites referenced on the page, whether internal (i.e., UCF Libraries) or external.
• Use relative paths and links when linking to other internal Libraries Web pages. Use absolute paths and links when linking to all external pages. For example, document relative: WebStyle/TechnicalIssues.htm; server relative: /Web/standard.css; and absolute: http://www.w3.org/TR/REC-html40/). (Tutorial)
• Consider including warnings when:
  • Linking to a page outside the UCF Libraries site, e.g., use a graphic icon.
  • Linking to a page will open a separate window
  • Linking to a non-HTML file. Provide a link to any free software needed to read the file.)
  • Linking to large files (i.e., large image files where a thumbnail is provided on the referring page); indicate the size of the file.

Back to Functionality

Back to Top

Frames

The WWG highly discourages the use of frames. Web Editors wishing to use frames must obtain permission from the WWG.

Back to Functionality

Back to Top

Loadability

This refers to the how easily a reader can open and view a Web page. It is an important consideration, since many Internet users will ignore pages that take too long to open. Pages that take 30 seconds or longer to open are considered slow. Among the things a designer can do to facilitate ease of opening are:

• File Size: Keep document size down - with images under 40K; without images around 20K.
• Graphics: Avoid the use of large images. Consider using thumbnail images with links to the full-sized image. Specify height & width of graphics in pixels to speed downloading.

Back to Functionality

Back to Top

Printability

Another important consideration for the Internet user is how the page prints. Closely related to page length, width, and loadability, other considerations of printability include the contrast in colors between the background color and the text color; the use of "busy," textured, or watermarked backgrounds, which can interfere both with readability and printability. The CSS embedded in the header will automatically format most pages for optimal printing. It is recommended, however, that the Web page be printed to evaluate how effectively the page has been designed.

Back to Functionality

Back to Top

Procedures

• Content
• File Structure & Naming
• Backup Files
• New Folders
• Approval Process
• Maintaining Pages

Content

• Anyone may suggest ideas for new content by contacting the WWG.
• WAC members implement new content as needed with the help of content providers.
• WAC members or content providers create mock-up examples for WAC's consideration.
• WAC members are encouraged to collaborate on page creation by checking each other's pages for grammar, punctuation, readability, layout, and blocking (e.g., organizing information on a page).

Back to Procedures

Back to Top

File Structure/Naming

• Minimize the number of levels within your pages. Navigating too many layers can be frustrating for users. Try to keep navigation simple and clear and the paths short. Remember that the department's pages are already one level down from the Libraries home page.
• File names should end in .asp.
• Each directory should have a default page with the name default.asp.
• File names must not contain spaces or underscores. Use upper and lowercase (WordCase) as the naming convention (e.g., "CreationAndMaintenance" rather than "creationandmaintenance", "creation and maintenance" or "creation_and_maintenance").
• Abbreviations are permissible as long as they are interpretable and consistent.
• Store all images in the Images folder. Do not duplicate images that may already exist. Create individual subfolders within the Images, e.g., images/ill, images/ask, images/bullets, etc., only when necessary. Check the appropriate folder for images before creating your own.

Back to Procedures

Back to Top

Request to Create a New Folder

• WAC members may create subfolders within their content area.
• To create a new "root level" folder, WWG members should discuss the folder with the WWG and get the Webmaster's approval.

Back to Procedures

Back to Top

Backup Files

It is strongly recommended that Web Editors maintain backup copies (either on the LAN, their hard drive, zip disk or floppy disk) of the most current version of their Web pages. Failure to keep a backup may mean permanent loss of data.

Back to Procedures

Back to Top

Approval Process

• Timing
• Before Update Request
• Updating Pages
• After Update Request
• Creating New Folders

WAC members and other web editors do not work directly in the Library server (library.ucf.edu). They must, therefore, request that changes made on the working Development server be replicated on Library, e.g., updates, additions, deletions, moves, etc. Departmental web editors should notify their WAC representative when they feel their pages are ready for the Library server. The WAC member will check the page(s) for compliance to the Libraries specifications as described below, and when ready will submit the page(s) for updating by sending them to the Webmaster. Once a request is received, one of the Coordinators of Computer Applications (as of October 2005, Blake Stephens, Greg McCoy or Joel Lavoie) will duplicate the changes from Development onto Library.

Timing

Requests take at least one full business day to process. Sometimes they happen in minutes, sometimes in days. It depends on current workloads and scheduling. You will be notified immediately via email when the web-updating process for your request has been completed. Do not plan to use the new or changed page(s) within the same business day of sending the request. Note: No Web updates take place on weekends or after 5:00 P.M. weekdays.

Before Sending a Web Update Request

1. Check the look.
   • Preview the page in a 1024 X 768 browser window. (This option can be found in the File menu of SharePoint Designer.) Preview the page in both Internet Explorer 6 or 7 and FireFox. Note: It's also advisable but not required to test the following browsers: Opera, Safari, Internet Explorer 5. These however are unnecessary if the site-wide CSS classes have been correctly used throughout your document, as they have been tested in all major browsers.
   • Does the page fit the screen? Do the tables, images, and other content extend past the right side of the window. All the content should display without any horizontal scrolling.
   • Do all the images display in the expected location?
   • Does the text align the properly?
   • Are the colors what they should be? Do the text and background colors create an easy-to-read combination?
2. Check the links.
   • Preview the page as described above. Click on all the external links. Are the pages still active?
   • Check all internal links. In FrontPage, click on View in the toolbar, choose "Hyperlinks" and wait for the report to come up. Scan the list. There should be NO links to:
     • Local drives (i.e. C:\, G:\, F:\, etc.)
     • The Development Server
     • The /Testing/ folder
     • Absolute links to the server that the file is hosted from (i.e. http://library.ucf.edu)
   • Links containing any of the above will break our Web site. Convert these to relative links. See the Tutorial for instructions, or contact Athena Hoeppner with questions.
3. Check the images.
4. Check loadability.
5. Check printability.

Back to Approval Process

Back to Procedures

Back to Top

Request for Updating Page(s)

1. Send an e-mail to the departmental WWG representative. [NOTE: These same rules apply to the WWG representative when submitting the final update request to the webmaster.]
   • SUBJECT: Must start with "Web Update". The subject may include more specific information after the phrase, e.g., Web Update – ILL pages.
   • CONTENT: Be sure to specify ALL changes. If a file is renamed on Develop, it must be renamed on Library. If a file is moved or deleted, the same must happen on Library. Be especially aware of any new images or other files that must be included in the update request. Unless these changes are included in the Add request, they will not display on the updated page on Library.
   • FORMAT: The format of the update request significantly affects the ease and efficiency with which updates are made. Overly complex, long Web Update e-mails can be difficult to read and follow up on. Here are some guidelines to keep requests clear and easy to process:
     • Keep requests short (i.e., fewer than 20 changes per e-mail)
     • Alphabetize the files and folders within each request.
     • Organize the requests by type, using the following order:
       • Please Move / Rename:
       • Please Add / Update:
       • Please Delete:
   • Use a consistent format to refer to files and folders. Leave off the development server name/domain, but ALWAYS include the complete path, specifying every folder and subfolder.
   • Specify any files and folders on the root (not contained in another folder). For example: Please update root libindex.htm.

     Sample Request

     To: Blake Stephens <stephens@mail.ucf.edu>
     Subject: Web Update

     Please Move / Rename:
     /Instruct/Images/image1.jpg to Instruct/Images/BookIcon.jpg
     /Instruct/trunc.htm to LUIS/trunc.htm
     /Instruct/LI/LIFacutlyEval.htm to Instruct/LIFacultyEval.htm
     /Instruct/LI/LIStudentEval.htm to Instruct/LIStudentEval.htm
     /Instruct/LI/LIThankYou.htm to Instruct/LIThankYou.htm

     Please Add / Update:
     /Instruct/Staff.htm
     /Images/Library/FlameLibraryFront.jpg
     /libindex.htm
     /Instruct/Default.htm

     Please Delete:
     /Instruct/sprintsoft.htm
     The folder Instruct/LI/and all its contents

2. The e-mail goes into a GroupWise folder, Web Updates, shared by Stephens and McCoy.
3. Stephens or McCoy copies the files, etc. to Library.
4. Stephens or McCoy moves the e-mail from the Web Updates folder to the Completed folder in GroupWise.

Back to Approval Process

Back to Procedures

Back to Top

After Sending a Web Update Request

The Web Editor submitting the request will receive an automated message when the update has been processed. Upon receiving the message, the Web Editor should check the pertinent pages on as they now appear live on the http://library.ucf.edu server, repeating the steps taken "Before Sending a Web Update Request."

Back to Approval Process

Back to Procedures

Back to Top

Maintaining Pages

Web Editors and content providers should:

• Devise a routine schedule for:
  • Reviewing the information content on pages
  • Checking links
  • Removing or repairing dead links
  • Upgrading pages for compliance to all policies & standards as discussed in the Introduction
  • Deleting no longer needed pages

• Document:
  • The maintenance schedule and
  • The person(s) responsible for the page content.
• Respond quickly when users report dead links or other problems with specific Web pages.

Back to Procedures

Back to Top

04 April 2008