<p>APPENDIX E</p><p>Web Task Force: Design and Standards Group Final Recommendations (DRAFT) </p><p>Findings:</p><p>The Web at Princeton is a vast domain: over 2 million individual web pages, serving a wide range of audiences, with a broad array of administrative and academic content. The Design and Standards Group met on a number of occasions to try to fashion recommendations regarding the design and coding standards which might be applied to this vast domain. We have concluded that a single set of standards will not be useful. Instead, we recommend the creation of a mechanism whereby specific standards can be created for an appropriate subset of the Princeton web domain, and also a process whereby those standards can evolve and adapt to changing circumstances. We believe the mechanism and process proposed will also help accomplish the broader goals of the task force.</p><p>Primary Recommendation: Create a Web Page Registry</p><p>We recommend the creation of a Princeton web page registry. This will not simply be an inventory of existing pages. Rather, it will be the authoritative index of all “official” Princeton University pages. What will make a web page “official” will be its inclusion in the registry. This will not be an automatic process; rather, pages will only be included once they have met certain standards and guidelines. </p><p>Initially, such a registry can be implemented as a database; ultimately, a content management system might be used. Each entry in the registry will identify a web page along with associated “meta” data, such as:</p><p>1. The URL of the web page. 2. A unique numeric identifier for the page (pageid). 3. The “official” function/designation of the page (e.g., “Computing Home Page”, or “Dining Services Home Page”). This will often correspond to the web page “title”. This is referred to as a “pseudo-URL” below. 4. The “type”, or classification, of the page (see below). 5. The “owner” of the page, for customer contact purposes. 6. The “owner” of the page, for problem/error/update purposes. 7. The “owner” of the page, for copyright purposes. 8. The date of last update/change. 9. An “alternate” page, in case the current page is being worked on. 10. The “status” of the page (being worked on, disabled, enabled, etc.).</p><p>It is intended that this list will grow over time; new fields can be added to the database as needed, without disturbing any existing fields, or any existing pages. Note the multiple “owner” fields; we do not think that a single, global page “owner” can always be identified; multiple fields allow for breaking apart global “ownership” into individual elements, which can be assigned to the same, or different, groups. Along with the registry will come a program that translates “pseudo-URLs” into actual URLs. The idea here is that “official” web pages (those in the registry) will not point directly to other “official” web pages via a URL; rather, they will point to a page using it’s function/designation (field 2 above), and a process will translate that into a URL. This will allow the University to change which page serves a given function in one place, the registry, and have that change instantly take effect on all “official” Princeton pages.</p><p>The registry also provides a mechanism whereby policy can be implemented, and, with the appropriate process, whereby that policy can evolve to meet changing needs. And there many other potential uses.</p><p>How will pages get into the registry? We envision that the registry will be “owned” by a University group which oversees access to the registry. Clearly many of the “standard” University pages will be registered (home page, second-level pages. etc.). Beyond that, we think that inclusion in the registry should be done via a simple (web-based) application process, whereby the applicant provides information on all of the registry fields (including typology), and agrees to abide by the corresponding standards. A key standard, for ALL pages, regardless of type, will be that pages do not point directly to each other; they point to a “pseudo-URL” that designates the “functional” page they are linking (e.g., “computing-home-page”). </p><p>Secondary Recommendation: Create a Web Page Typology</p><p>Along with the registry, we recommend that a typology (taxonomy) of web pages be created, which will allow for flexibility in the application of policy and design standards. We believe this typology should be based on a combination of factors, such as the perceived target audience, authoring department, and other factors. For example:</p><p>1. Type A: Web pages for the world. Princeton Home Page. 2. Type B: Web pages for internal administrative use. PeopleSoft pages. 3. Type C: Course web pages for students. 4. Type D: Departmental web pages 5. Etc.</p><p>The specifics of the typology can be worked out over time; we might start with a simple set, and add types as we go along. One possibility is a hierarchical typology (types and subtypes). Each page’s type classification would be recorded in the registry. Associated with a type would be a set of design and coding standards, and possibly support standards as well.</p><p>Specific Recommendations: </p><p>All Pages (Global Recommendations)</p><p>We discussed what set of design and coding standards might be applicable to all pages. By “all”, we mean any “official” page, which is synonymous with a registered page. Because of the potential size of this domain, there are very few standards that would apply globally, but the following list represents what we regard as a minimum set. 1. To make the registry effective, all pages in the registry will include a “meta” tag as part of their HTML header information. This Princeton-unique “meta” tag will contain the registry “pageid” (see above), thereby linking the page to the registry. Using this pageid, scripts can be written that refer back to the registry to extract a variety of meta-information about the page. The pageid will, in essence, stamp the page as being “official”. Adherence to conformance level A of the WAI accessibility standards. 2. If the Princeton University name, shield, or other trademark is used, it will be selected from a fixed set of images or text elements maintained by a central group. We do not think the inclusion of a Princeton identifier should be required for all pages, but if an identifier is used, it should be a standard one. 3. Use of photographs of the University from a “standard” set maintained by a central group. 4. Inclusion of a visible contact and date field at the bottom of the page. If required by the DMCA act, inclusion of a visible copyright field that hot-linked to the University’s DMCA page (as is currently the case for the Princeton home page). The contact should be a “mailto” link. Note that these fields should correspond to the registry. One possibility would be to have the fields generated by a call to a registry application which returns the appropriate data (e.g., copyright data for type “A” pages, no copyright data for others). Once again, the goal is to allow for policy to be implemented via the registry, and to be tied to the typology. 5. Links to any other “official” ( = registered) page be done via a registry “Pseudo- URL”, rather than through an actual URL. 6. We may want to require some kind of copyright “sign-off” by the page’s “copyright owner” group. On the other hand, the University may not want to be viewed as “policing” the web space, so the specifics here need to be worked out by the counsel’s office.</p><p>Type A Pages</p><p>We discussed what set of design and coding standards might be applicable to “type A” pages (in addition to the global standards listed above); things like the Princeton Home Page. These pages must be viewable and decipherable by almost anyone with any kind of web access and just about any browser. Given these constraints, we recommend the following:</p><p>1. Compliance with conformance level A of the WAI standards. 2. Coding in HTML 4.0. 3. No use of plugins or any other objects requiring separate downloads. 4. Some kind of server specifications … e.g., that the server which hosts the page be on a UPS.</p><p>Additional standards can be added, or these can be amended, as we refine the typology.</p><p>Resources:</p><p>We may want to obtain funding to purchase a content management system that can facilitate the creation and management of the registry. We believe existing staff can provide the manpower resources to populate the registry, to develop the typology, and to refine the design and coding standards. Where we see a potential need for additional resources, in people, software and hardware, is in helping departments implement whatever standards we develop. We may need to provide incentives for people to play by our rules, because the domain is too vast to be policed effectively (carrot, rather than stick, approach). We believe the best possible incentives come in the way of people who can help departments design and code their pages. While existing staff, in Web Services and Communication, can handle the registry and provide basic support for departmental web pages, additional staff resources in these groups will make it possible to implement the typology in a reasonable time frame.</p><p>Outstanding Issues and Questions:</p><p>If our recommendations for the creation of a web page registry and typology are accepted, then most of the outstanding issues and questions come down to deciding the specifics of the typology and the registry fields. Indeed, that is one clear benefit of this approach; it provides a framework within which additional questions can be asked and answered.</p><p>If the registry is not implemented, but the typology is, then there will have to be a mechanism created whereby we can decided to which pages any given standards should, or should not, apply. If the registry is implemented, but not the typology, then the design and coding standards will have to be very, very general.</p>