Web Site Development and Maintenance Standards

1. Introduction

This document serves to define the principles and standards by which the Web Services group in Office of Administrative Systems (OAS) develops and supports construction and maintenance of web sites for the University's Financial Administration (FAD) and the Office of Human Resources (OHR). The intended audience for this document comprises Harvard web developers in these organizations, consulting developers hired by FAD and OHR business units to work on departmental sub-sites, managers within FAD, OHR, and OAS, and content managers within the business units.

These standards compliment and support the Central Administration Information Technology (CAIT) Web Application Development Standards and Guidelines (Word).Whereas the target of CAIT standards is the development of online applications, the focus here is on processes for web site development and support, tools, technologies, and methodologies. User Interface (UI) issues are a primary concern. Synergies exist between the two documents particularly in compatibility with a Java applications framework, in development best practices, and in the Future Directions section of the CAIT document. Inconsistency or apparent conflict with CAIT standards is unintended.

Objectives for this document include

• Ensuring that sites are developed and maintained with standard tools and technologies that are consistent with the web platform, and that support performance and facilitate maintenance
• Encouraging consistency of approach that increases opportunities for knowledge sharing and support within the OAS service area and CAIT
• Improving the quantity and quality of documentation that is developed as an integral component of new sites and significant enhancement
• Supporting user-centered design that leverages current research and understanding on ways that users approach information organized for web-based delivery
• Building a framework within which sites are built to comply with Priority One accessibility standards
• Encouraging consistency with an eye toward CAIT's Java framework

Web developers and project teams can also request an associated Technical Requirements & Turnover Package Quick Reference.

OAS Web Services is also creating separate documents entitled Web Development Guidelines and Web Maintenance Process to support its customers. These provide best-practice information, documentation and resource links, and clarify and document processes that keep its production web sites current and up and running.

2. Terminology

Throughout this document, we make use of a variety of words and phrases that require some introduction.

API- Abbreviation for Application Programming Interface. These are routines, tools, and protocols, that serve as the building blocks developers use to develop more efficient and consistent applications.

CSS- Short for Cascading Style Sheets, a relatively new HTML feature that gives both Web site developers and users more control over how pages are displayed. With CSS, designers and users can create style sheets that define how different elements, such as headings and links, appear. These style sheets can then be applied to any Web page.

External Links- Links constructed to help end users navigate from a primary site or one of its sub-sites to another primary site. The link on the Budget and Financial Planning home page that leads users to the Harvard University Home page represents an external link.

Internal Links- Links constructed to help end users navigate from a sub-site, to a primary site (back to the home page, for instance), or from one sub-site to another within the same primary site.

J2EE- Short for Java 2 Platform Enterprise Edition. J2EE is a platform-independent, Java-centric environment from Sun for developing, building and deploying Web-based enterprise applications online. The J2EE platform consists of a set of services, APIs, and protocols that provide the functionality for developing multi-tiered, web applications.

Javadoc- Javadoc allows developers, in an automated way, to generate API documentation in the HTML format from doc comments in source code. The tool from Sun Microsystems lets developers document more efficiently, and ensures that code is more maintainable.

Primary Site- The top-level, main, organizational, central transactional page, or project web site. These generally have a separate domain and URL, e.g., http://vpf-web.harvard.edu, http://atwork.harvard.edu, or http://oas.harvard.edu.

QA- Abbreviation for Quality Assurance. This is an essential part of the various cycles within the web-development process. Testing for consistency, performance, and whether requirements are addressed improves quality, and makes sites and web applications more maintainable.

SSI- Short for Server-Side Include. A type of HTML comment that directs the Web server to dynamically generate data for the Web page whenever it is requested. A type of include often used for navigational components.

Sub-site- Second-level business unit, category content area, or reference content area that organizes and provides a navigation path to more detailed, categorized information. These generally have a URL that relates to the Primary Site URL, e.g., http://vpf-web.harvard.edu/budget, http://harvie.harvard.edu/perks.

Turnover Package- Information to accompany new sites, redeveloped sites, and sites that have been significantly modified when presented to OAS Web Services for placement in the managed environment and in production. The Documentation section below outlines specific components of the package, but contents range from files and directories to code-level and web-based (print) documentation.

3. Scope

The standards outlined in this document apply to any web site developed, re-developed, or modified in a significant way by Harvard web developers within FAD or OHR, or by consultants and third-party developers contracted by these organizations, when OAS will house, manage technically and support the resulting sites. The standards fall within five categories that include

1. Technical Requirements
2. Quality Assurance
3. Required Documentation
4. Site Organization & Planning
5. Future Directions

The approach, platform, and tools and technologies will evolve over time and, where possible, will leverage CAIT standards and applicable portions of the web applications development approach. For an overview of possible enhancements to this document, see the "Future Directions" section.

4. Technical Requirements

4.1 Acceptable Download Time

Web sites should be optimized so that every page loads in the browser in less than 5 seconds (threshold of frustration). Determining page budget and sticking to it will achieve this. Page budget should not exceed 35KB for the general public and 100KB for the Harvard audience.

Note: Exceptions to this rule will be considered on a case-by-case basis. In such cases, include a written explanation in the site's documentation when submitted to OAS Web Services.

4.2 Browser Standards

All sites open to public will have to be displayed properly with

1. Netscape 7 and above
2. Internet Explorer 5.0 and above
3. Mac equivalents of the above

Browser standard for intranets developed for users within Central Administration is Internet Explorer 6.0.

4.3 Cascading Style Sheets Govern Presentation

Cascading Style Sheets (CSS), level 2 (see at http://www.w3.org/TR/CSS2/), should be used to define the style of a web site. All style definitions should be saved in one CSS file, unless customization for multiple browsers/platforms is necessary. Page styles can be modified by including <style></style> on the top of the page, but inline style definitions should not be used (for example <table style="..."> ).

Note: All font sizes should be made relative (either defined in 'em' or %).

4.4 Directory Organization

Content files of a web site should be logically organized by following content categories. Directories common to most sites include

• /images/ - This directory should be created at the root of the site, but also at other levels if the need be
• /styles/ - CSS files, and other style definition files should be placed in this directory (in the future there could be XSL files)
• /scripts/ - This directory should be a container for all client-side scripts (JavaScript)
• /includes/ - This directory should contain all included components (SSI or other) which by itself do not make a page as a whole, but rather contribute in page composition by adding repetitive parts (a good example of repetitive components are navigational links)

Note: Directories above should be created at the root of the site unless alternative approaches have been discussed and agreed to by OAS Web Services.

4.5 Document Conversion Methods & Tools

Those preparing content for integration into managed sites should not use the Microsoft Office converter, and built-in utilities for HTML conversion (includes Office 97 and 2000). In addition, do not use Microsoft FrontPage, or other HTML editors that incorporate proprietary code into the resulting source.

Rationale: Microsoft converters and FrontPage incorporate large volumes of proprietary code, a nearly unique blend of HTML and XML, and unnecessary files and folders that support a web page and site. This adds unnecessary complexity to maintenance, and can affect the performance of the site.

4.6 Document Headings

Follow these rules regarding document headings

• The HTML heading scheme should be used to convey the relative importance of elements in a document (h1, h2, h3... )
• Every document should have only one h1 element and as many of the other elements as needed
• Authors should not choose a heading level based on the font size commonly used by visual browsers; he heading level should be chosen based on the heading's importance and placement in the document
• <font></font> tag should never be used for headings (e.g. <font size="20"> instead of h1), as it does not convey the structure of the document
  

4.7 File Naming Conventions

Filenames underlying the site should be <= 25 characters, should include no spaces, and should always be lowercase. Do not use mixed case for naming web documents. In naming standard web documents, .html, rather than .htm is the appropriate file extension. It is recommended that words in file names are separated with a dash, not an underscore.

Example: good-content.html, new-content.html; or goodcontent.html, newcontent.html

Duplicate file names with different file extensions should not be placed in the same directory.

Example: index.html, index shtml (every directory should have only one file named index).

4.8 Frames Should Not be Used for General Navigation

Frames should not be used for cross-site navigation. Although effective for small-scale and target applications, the disadvantages of frames outweigh the advantages. Issues with frames include

• Search engines have trouble with frames, as they do not know what frame components to include as navigational units in their index; if a user reaches a destination page outside of the frameset by following the link resulting from the search, orientation and navigational tools are lost
• In some cases, frames obscure or render useless valuable information about usage that is recorded in web server logs; in the best case, with frames, this task becomes much more difficult
• Users may bookmark individual pages nested within a framed document, thus losing context and navigation
• Framed documents are usually not printed properly; the "Print" command results in the printing of a single frame, rather than the whole screen
• Older browsers do not support frames

Exceptions to this rule will be considered on a case-by-case basis. Present a written justification prior to development. In cases where frames are used a <NOFRAMES> version should be created for the pages in question. For detailed information about frames see What's Wrong With Frames.

4.9 Inktomi Search Engine

Every effort should be made to utilize the Inktomi search tool (Inktomi Search Software) when appropriate. Inktomi has for several years been the standard search engine within the Harvard web community, and has been a reliable performer. The Harvard Webmaster manages the Harvard central implementation. Search engine software and collections are situated at University Information Systems. When site requirements call for features not provided in Inktomi, alternative approaches should be discussed with OAS Web Services.

4.10 Internal Site Links

When constructing links to assets within the primary site or sub-site, relative rather than absolute linking approach should be taken. Absolute links should be used only to point to resources resident within other domains.

Rationale: Absolute links complicate site deployment and migration between development, staging, and production environments.

4.11 META Information Required

Every document in the web site must have a unique title. Use of <meta name="keywords" content="keyword, keyword, keyword"> is also mandatory.

Rationale: META tag information enables search engine optimization. When Inktomi (and other search engines) works efficiently it provides a powerful, secondary navigation tool for end users. Including META information also provides a "container" for frequently used query strings that can be gathered from search log files.

4.12 Modular Design

Modular design means segmenting out content and navigation to avoid repetition. We support Server Side Includes. Apache SSI extensions support basic conditional logic (for example to display a different image for current vs. all other pages).

Similar functionality built into Java Servlet/JSP approaches should be utilized among other techniques to promote modular design.

Example: Copyright statement should be placed in a separate file (.shtml or .gif) and referenced from all appropriate pages. If the statement needs to be modified the change will occur in only one file and propagate through multiple pages.

4.13 Page Layout Standard

Whenever possible, style sheets should be used to control page layout, and to define the style of a web site, although cross-browser limitations to this approach exist. This is particularly desirable for an audience internal to Harvard. Use of tables as a page-formatting device is common and acceptable; however, web project teams should be aware of the issues and limitations of this approach (see image note in Use of Images section).

The style sheet specification is available at http://www.w3.org/TR/CSS2/.

Known issues with table layouts include

• Trouble for users with narrow window settings
• Large fonts preferred by some users can cause problems
• Issues when tables are fed into non-visual browsers
• Complex nested tables may result in slow download
  

4.14 Printable Content

Before a site is built all content should be reviewed and categorized, among other criteria, into PRINTABLE and NON-PRINTABLE categories. At the same time components of printable pages should be determined (logo, copyright statement, etc.)

Printability of content can be achieved in many different ways, depending on whether content is static or dynamically generated from a database. Converting content into PDF files, utilizing includes, or formatting dynamically generated content specifically for printing are all acceptable approaches. In case printability is achieved through includes, all content files should be in separate directories to prevent them from indexing by directory exclusion in robots.txt.

Note: OAS Web Services can provide a .gif "Printer friendly" image upon request.

4.15 Screen Resolution

Web sites open to public should be optimized 800 x 600 for screen resolution.

4.16 Standard HTML Version

HTML 4.01 Strict is the standard HTML version for supported sites. Deprecated, non-STRICT elements and attributes should not be used unless it is critical to reach an audience outside the University dependent upon older (3.x) browsers. Proprietary HTML elements of any HTML editing tool must be avoided. All HTML templates must be validated as HTML 4.01 Strict documents, and proof needs to be included in the turnover package.

For detailed information on standard HTML, see http://www.w3.org/TR/html401/.

Example: To see the difference between STRICT and non-STRICT, see the W3C FORM element specifications, at http://www.htmlhelp.com/reference/html40/forms/form.html and toggle between the strict- and non-strict buttons.

4.17 Standard Page Elements

Include the following in each sub-site web page

• Harvard University logo or link that leads to the University home page
• Link to the home page of the sub-site, and the home page of the primary site that houses the sub-site
• Content and technical contact links and telephone numbers
• Copyright information where appropriate - Copyright 2004 President and Fellows of Harvard College

Note: OAS Web Services, upon request, can provide the .txt/.gif file containing the required copyright statement, with accompanying text relating to Copyright, a Legal Notice, and our Privacy Policy.

4.18 Supported Databases

Oracle 9i is the supported database and should be used when site functionality requires a foundational database.

Depending on requirements/scope of application, OAS Web Services will consider lighter-weight database alternatives on a case-by-case basis.

4.19 Supported Programming Languages and Frameworks

Server-side web development should be done in supported scripting/programming language

• Java (we recommend Jakarta Struts as web development framework, and Jakarta Taglib project if any tag libraries are to be used)
• Perl
  

4.19 Turnover Package

Web developers and consultants should prepare a Turnover Package for delivery along with new and redesigned sites. The package should supplement the required process-related documentation and should include:

Technical Components

• Final HTML code
• Cascading Style Sheet for the entire site
• Perl/Java code (un-compiled source code if Java is used)
• SQL files for all database tables (DDL and DML)
• Production image files (.gif, .jpg, .png) and source image files (.tiff, .psd)
• Templates that will aide in site maintenance
• Bobby testing report indicating accessibility scores
  

4.20 Use of Images

Follow these rules regarding use of graphics/images on the web

• Graphics/images that convey meaning and enhance the message communicated to audience are important features of a good web site
• Use of graphics/images to encapsulate text for navigation should be avoided unless that approach will improve clarity and usability
• Optimize graphics/images for the web
• Include alt, height, and width attributes for every image on your site
• Keep all site-wide graphics in /images/ folder at root, keep other graphics in /images/ folder at content level(s)
• Deliver all graphics together with source files (.psd file if Photoshop is used)
• Use appropriate compression format (.gif, .png, or .jpg)
• When using tables for page layout, DO NOT split images for distribution in adjacent cells, this makes maintenance more difficult
  

4.21 Use of JavaScript

JavaScript should not be used for critical functions like form validation. JavaScript introduces complexity to the page and increases testing and maintenance overhead. The web site should provide the same functionality if JavaScript is disabled on a browser.

If JavaScript is used for extendible menus or to display hidden content as a mouseover event, caution should be exercised. The same navigation and content has to be made accessible to browsers that do not support JavaScript and to users who disable JavaScript. (There are also usability issues associated with the use of JavaScript devices like menus for exclusive navigation within a site.)

JavaScript should not be used for web page components that involve highly variable content and require frequent updates. E.g. using JavaScript to provide a mouseover visual cue in a departmental organizational chart would be a maintenance mistake. (Doubly so if on/off state images were involved.)

JavaScript mouseovers should be replaced with CSS mouseover effects whenever feasible.

Rationale: Because JavaScript has not been implemented consistently across most popular browsers, cross-browser compatibility issues and inconsistencies have resulted.

4.22 Use of the Development Environment

Business unit content managers should work within the development environment when creating, maintaining, and updating files. (Work can be done locally and copied to development.) OAS Web Services will provide a process orientation to the designated Content Manager. Once development has been completed, the Content Manager or his designee will conduct Quality Assurance (QA) in the Staging environment, and give approval for final promotion to the Production or "live" web site.

As a deliverable, external development firms will work with OAS Web Services at turnover (preferably at Harvard) to implement their sites and sub-sites in the Harvard development environment.

4.23 Web Folders and URL Aliases

All content should be attainable within a maximum of three nested folders in the site structure because the Inktomi spider does not index any content deeper in a folder/site hierarchy. In cases when this is not possible to achieve due to complex information architecture of a (sub)site OAS Web Services will be notified for approval. In such cases, URL aliases will be created and communicated to the content owner because they will appear as the URL for that particular content.

The deepest content that will be indexed by the spider would reside at: http://sitename.harvard.edu/directory1/directory2/directory3/document.html

Note: URL aliases may be applied in cases when content is attainable within three folders if they will improve the clarity of URL.

5. Quality Assurance

5.1 Accessibility

All new sites should comply with Level One accessibility standards (see W3C Priority One Checkpoints) and tested using the Bobby tool. Non-compliance in legacy sites will be addressed during re-development. Every effort will be taken to make old sites compliant as soon as possible.

5.2 Notification Of Filename Changes

Prior to any file- or page-name changes, the web team or content owner should notify OAS Web Services by e-mail of the intended change. As part of this communication, the requestor should provide a map from the old filename to the new filename. Given file inter-dependencies that are an everyday part of every web site, the importance of this should be clear. We will work with you to ensure that changes are made without affecting incoming links from other sites.

5.3 Quality Assurance

Rigorous Quality Assurance (QA) is also a key part of the development process and ongoing maintenance and ensures proper site operations and quality. At a minimum, prior to turnover, we require

1. Links within the site are evaluated both with an automated link-checking utility, and by hands-on navigation
2. The site is evaluated by an accessibility validator (see Accessibility section)
3. An HTML validator is used to evaluate code and navigation
4. The site is tested in conjunction with multiple browsers; to the greatest extent possible, a site should be cross-browser compatible
5. All site programming code (Perl, Java, etc.) should meet written specifications, be thoroughly tested both at the module level and within its site context

QA is an ongoing process, and makes the difference between professional sites that generate return visits, and those that frustrate end users. We strongly suggest weekly checks by content and technical managers, and that time and resources are planned for this maintenance.

5.4 Usability Testing Requirement

Usability testing is an integral part of the web-development process. Web developers and those undertaking development or major modifications to a site should conduct usability testing. A results matrix including original tasks/queries provided to test subjects and an outline of any completed mitigation tasks should be included in the turnover package.

Usability testing involves

• Developing test scenarios
• Actual end users navigate the site in search of content
• Unbiased observation of user behavior, reaction, and level of navigational success
• Recording observations, mouse clicks, time to content, results, user comments, common issues among test subjects
• Different people should fill the roles of facilitator, time and navigation tracker, and recorder

6. Required Documentation

6.1 Content Area Relationships

Web developers and those working on sub-sites should define major content areas, map relationships between content areas, and indicate in writing how users are expected to navigate between areas. Maps such as this typically result from a dialogue between content and technical managers. This map provides a foundation for development, and is a key component of the Turnover Package.

6.2 Content Inventory

Content management is one of the significant challenges in web site development and maintenance. Web-development teams should prepare a content inventory (including page count) to be delivered in writing. This is essential to the success of a web-development effort. We strongly recommend, where possible, that all content be completed before web development starts. During projects and rollouts, very careful planning should take place and approximately 80 percent of content should be completed, with the remaining 20 percent carefully slotted and planned for. As part of maintenance, an updated Content Inventory is an invaluable tool.

6.3 Documentation

Code-level and web-based (print) documentation are an elemental part of the development process. All code written in support of production web sites should be richly documented in a manner consistent with best software-development practices. Documentation outside the code is required for all sub-sites that are being developed or changed to any significant degree. Documentation should, among other things, include

• Technical specifications and/or design document
• Maintenance/turnover document
• Self-contained, zipped directory containing web-ready documentation (preferred)

Required supporting documentation is outlined in the Turnover Package section. Developers should use the Checklist when constructing new sub-sites and when significantly modifying existing web site areas.

• An Entity-Relationship Diagram (ERD) for any supporting databases
• A data dictionary describing the tables which are components of any supporting databases; each field in every database table should be described with a minimum of name, data type, size; comments must be provided for those fields whose function and contents are not obvious from its field name
• JavaDoc APIs in a zipped format for all Java code in the application
• A flow chart outlining program logic
• Site map
• A content inventory
• Navigation schema or flow chart
  

6.4 Site Functionality

Web project teams should clearly outline and document core site functionality as part of the development process and for inclusion in the Turnover Package. At a high level, the question "will business be transacted on the site?" needs to be answered. When the answer is "yes", implementation typically involves functionality like data collection forms, discussion forums, and any sort of personalization. Documentation should explain purpose, approach, architecture, and platform of a particular solution.

6.5 Site Goals & Objectives

Site Goals & Objectives are another integral part of site development and the required Turnover Package. This short (<= 1 page), bulleted list or narrative should highlight the Harvard business that will be conducted when this site is (re)launched. Measures by which the site's effectiveness can be evaluated should be built into these.

6.6 Site Map

A site map should be prepared and included in the turnover package when new sub-sites are developed, or when there are significant changes within existing content areas. Site maps facilitate content management, and good site organization, aide in maintenance, and provide an opportunity for supplemental navigation when published on the site. The best Site Maps convey the organization and location of content on the site, as well as the relationships among content areas, in the most simple, and easily maintained format.

6.7 Site Mission Statement

A Site Mission Statement is required for all new and redeveloped web sites that will be integrated into primary sites.

The Site Mission Statement should answer the fundamental question: "What Harvard business purpose does the site serve?"

Example: "The purpose of this site is to provide customers with web-based, site-maintenance forms, access to up-to-date Standards, Guidelines, and Maintenance Procedures, and the latest news."

7. Site Organization and Planning

7.1 Process Components

• Site mission statement
• Site goals & objectives
• Site functionality
• Audience profile
• Content area relationships diagram
• Content update frequency and strategy
• Site map
• Document count and categorization
• Designation of a content manage

7.2 Audience Analysis and Profile

Audience should be defined at the very beginning of the web development project, and it should be classified into primary and secondary groups. Every audience group should be accompanied with a general user profile. We highly recommend building a few detailed, individual profiles.

Primary audience: Audience that is critical to the web site's success.

Secondary audience: Audience that is important, but not critical to the web site's success.

Typical user descriptions include: Typical user demographic description includes occupation, age, gender, online frequency, connection speed, and online habits (how web savvy they are). The description also includes their type of computer, and their browser.

General user profile example: "A typical user is a Financial Administration employee at Harvard, between the ages of 35 and 45, who accesses the web on a daily basis. She is moderately web savvy, and often uses web to look for information that helps with day-to-day job responsibilities. She uses Oracle financial applications during about half of the business day. She often uses web pages that link to these applications (example http://vpf-web.harvard.edu/applications/) as an entry point. She uses a PC with Widows 95 operating system. She has high-speed internet access in her office, and her standard browser is Internet Explorer 6.0."

7.3 Content Updates

The frequency and nature of content updates is critical information. This informs development and helps plan for and carry out maintenance on production web sites. Web project managers, as part of the Turnover Package, should provide their best estimates on updates. Among other things, evaluating and categorizing content by frequency of update helps with site organization and informs user navigation decisions. Possible content categories could include:

• Daily
• Weekly
• Monthly
• Occasionally
• Other categories that could be mutually agreed upon
  

7.4 Designation of a Content Manager

All production web sites require a designated Content Manager. This is a critical success factor for the site. As part of the Turnover Package, web developers should include the manager's name, office location, e-mail address, telephone and FAX numbers. Content managers should possess basic HTML skills, and familiarity with standard HTML editing tools.

7.5 Writing for the Web

When web sites are turned over for integration on managed file servers, it is expected that content will have been authored specifically for web publication. Material originally produced for printed publication should be shortened by approximately 50 percent, according to a widely acknowledged principle. Research indicates that web content is generally scanned rather than read. The web demands strong organization, and a terse writing style. Look for unifying characteristics and opportunities for distillation. If your site's objective is to make content easily accessible to readers, this is key. (If the end user is expected to print content, that content should be authored in a suitable file format like .pdf, or a format associated with typical office productivity applications.)

Example:

Following this approach makes the paragraph above more "web ready".

Web content should be created (or rewritten) specifically for that purpose.

• Shorten content originally prepared for print distribution by 50%
• Present vital information without adornment
  

8. Future Directions

These standards exist within a "living" document that will be updated and extended, as our customers' business needs change, and in relation to CAIT future directions and technological change. The following list includes possible areas of focus for the short- and long-term that could result in additions and changes to these standards. These fall into two categories

1. Relevant material from Section 7. Future Directions, from the CAIT Web Development Standard (Word)
2. Near- and longer-term changes in approach and platform resulting from technical and future planning

All would require significant discussion. They are not listed in order of priority.

8.1 CAIT Standards & Guidelines, Section 7. Future Directions

Items numbered 6, and 10 through 13 in the CAIT document (see above link) relate directly to work that OAS Web Services performs routinely and could factor into future extensions of this document.

8.2 OAS Web Services Technical and Future Planning

1. Continue to rely on the CAIT Java Standard, as appropriate, for all significant development. Along with this, the group will continue to seek consistency, look for efficiencies, and leverage CAIT code libraries whenever possible, and help business partners and our customers take advantage of these powerful approaches and technologies.
2. FAD and OHR business partners continue to transact more business through their web sites. To facilitate this, and meet requirements for rule-specific authorization, we will continue to work with our CAIT partners in the web security space. Work completed as part of the OHR HARVie intranet implementation, allows us to offer to our business partners ways to protect dynamic and static content at the subdirectory (departmental subsite) level.
3. With the continued objective of enabling non-technical business users to manage their own web content, OAS Web Services will continue to play a role in CAIT discussions on a content management standard. Simultaneously, the group will focus on "points of pain" these systems are expected to address developing creative, extendable, and targeted solutions.
4. The group will continue use and promote approaches like Includes, Style Sheets, and XML, to encourage separation of presentation-layer code from content and logic driving sites and small-scale applications.
5. Continue support for web partners seeking to benefit from usability testing and log-analysis data.
6. Work with CAIT partners toward a common, secure approach to web-based credit card transitions. Outings & Innings on-line ordering, implemented with HARVie, set the foundation for this work in our area.
7. Identify, isolate, and refine components of core business functionality within web sites that can be inventoried and offered to other developers and business units within CAIT, and possibly across the University.

Back to Top