The new CS Web Site

Version 1.0 -- 10/19/96

This document sketches out the requirements in designing and building the new CS Web site. It includes comments from David Gries, Lynette Millet, Rosen Sharma, Linda Wu, and Li-dong Zhou. Additional comments are solicited

1. Introduction

Web site design involves numerous architectural and artistic challenges because it serves three conflicting purposes:

1. Perhaps the most important characteristic of a good site design is ease of access to information. First impressions of prospective students, faculty, and funding agencies are often based on how hard (or easy) it is to get to some information stored in our department's virtual home. Unfortunately, as described in Section 2, the nature of information sought by remote users is inherently different from that sought by the local users. Moreover, in most web sites, the flood of incoming information quickly becomes unmanageable. Keeping it consistent and current are challenging tasks. Categorizaton and search engines help to some degree, as does intuitive and uniform page layout.

1. The second goal of the department web site is to allow users to share experiences. For example, such a feature would allow a fresh student joining a group not only to read papers published by group members, but also learn about the evolution of the ideas described in them. Other examples are to allow students who did a summer internship to share comments on their experience, and bulletin boards where UG and grad students can swap notes, comments, and learnings.

1. Finally, it should be easy for content creators, particularly support staff, to publish it. Separating the content creator from the content publisher delays access to information. Moreover, the easier it is for content creators to create and update content, the more of it there will be.

These three goals set up a tension that a good site should gracefully resolve. For example, making it easy to publish information often works against making it easy to access information. Tools such as automatic cross-indexing and keyword generation would allow us to rapidly publish information, yet make it easy to access. We should incorporate such tools into the web site architecture.

2. Audience

As mentioned above, the site has two rather different audiences: internal and external

2.1 Internal audience

The three components of the internal audience are:

• Faculty and staff
• Grad students
• Undergraduate students

Members from these three group would normally be looking for information about department operations and events such as talk announcements, information about computing and other resources, news bulletins etc. The site should make it easy to add information about these events, as also to track down resources. A regular maintenance schedule to update information is critical.

2.2 External audience

These include:

• Prospective undergraduate and graduate students
• Prospective faculty
• Faculty members from other departments
• People in industry
• External researchers
• Members of funding organizations

Members from these groups are either looking for a specific piece of information, or want to get a sense of what is going on in the department. The site should have a look and feel that impresses first-time visitors, and also has a search capability to allow rapid access to information. On-line demos and descriptions of ongoing projects are particularly important to showcase for an external audience. It might also help to have papers online (though this might involve negotiations with IEEE and ACM)

3. Requirements

We believe that the site architecture should support these requirements:

• Each piece of information should be stored in only one place, to keep things consistent
• Pages should be searchable, including searches on postscript files
• Pages should be fast to download (so most pictures should be thumbnails)
• All department pages (excluding personal and project pages) should have the same look and feel
• The site should be accessible to any browser (we may have separate pages with and without frames, and with and without Java)
• Should be easy to find one's way around (intuitive layout), perhaps using a global map
• The site should be complete
• It should be easy to create and update information
• A page should contain only a few key pieces of information (low information density)
• We should support distributed control - people should have more freedom to put scripts or applets on their own pages
• We should support cross-indexing tools so that files are only generated once and can be cross-indexed automatically to generate web pages.
• We should aim on making the firewall as transparent as possible
• We should make it possible to restrict access to some pages to individuals, research groups, or the department

4. Features and things that should be online

4.1 Mostly for an external audience

• Personal home pages of faculty, staff, and students
• Project home pages and research project profiles, in text or postscript.
• Demos of cool projects
• Talk announcements, past and present
• Links to other departments and CS related resources (ACM, IEEE, NSF/CS etc.)
• Alumni page(s)
• What's new
• Compact top level to make navigation easier
• Reminders of talks and other deadlines updated regularly
• Virtual department tour
• History
• Admissions
• Publications
• Technical Report Server (there is already one at Cornell)
• Access to older databases
• People finder
• Links to organizations like CIT
• Comprehensive faculty profile, in text

4.3 Primarily for an internal audience

• Departmental information (resources, directory, mailing lists, who is in charge of what-see the Appendix)
• Course home pages, present and past
• News bulletins and status reports
• Policies regarding various things (chain mail etc.)
• Documentation of procedures
• A list of companies where students spent summers, and their opinion of them
• Online tutorials about local resources and locally generated software
• A way to register interest in updates on parts of the site
• Templates (perhaps using forms or applets) to allow rapid creation of pages with uniform look and feel. Standard libraries of images, logos, and html for email-response, access counters etc
• Interfaces to ease updates of the site: for example, filling in a form to automatically generate mail and news posting when a talk is announced on the site
• Counters to track hits
• Freshman/UG/Meng/PhD corner (a threaded Co-notes like interface), linked to archives of newsgroups
• Job postings
• Some sort of connection to the Xerox liveboard
• Automatic archiving of email sent to a server, with a searchable web-based front end
• Slide to html tools and help for html-based presentations
• Links to Internet wizards to convert various document formats to HTML
• Templates for courses - for example student-lists, imporant events, etc, more like a checklist. Creating content so that it can be cross-indexed automatically

5. Steps in site design and timetable

1. Recruit the CS Web Site Committee consisting of a staff person (Denise Moore?), and three students to refine requirements and do a first cut at design (by 10/15)
2. Distribute the first draft for comments to faculty, staff and students (10/23)
3. Do a second iteration of the design and circulate to a smaller group for review (by 10/30)
4. Recruit a professional web designer to hammer out details of design (by 10/30)
5. Review first cut of designer's work and iterate on design till it satisfies requirements above (11/15 - 11/30)
6. Assign one or more students for periodic maintenance, creating appropriate processes to make this as automated as possible (by 11/30)

Appendix: Questionnaire for administrative staff

1. What information do you usually maintain?
2. How does this information originate (comes from other electronic formats like mail etc. or is typed)?
3. How often is this information updated?
4. Does it need special privileges to update/access?
5. Is the same information sent out periodically?

These questions probably need to be refined to be more precise and get meaningful answers.