Apart from scheduled downtime, we expect that this system to be available 99.9% of the time. It is permissible that it be taken down late at night for up to 1 hour a week. We do not expect that this will require the use of redundant servers, but it this would be a nice feature if not too expensive.

We expect that most pages be returned in 1 second or less to users for whom bandwidth isn't an issue. We will attempt to keep pages to a reasonable size, however, in order to ensure that users with slow connections (e.g. 56K) do not experience a delay of more than 3 seconds for most pages. One way to do this is to limit queries so they do not return more than 20 events per page. For larger pages, or pages that return search results from the database, we expect page returns of 3 seconds for users with fast connections and 5 seconds for users with slower connections to be reasonable.

Although there will be some private Events in certain calendars, all Event data will be displayed on a public web-based calendar somewhere, so we do not believe extreme measures need to be taken to make sure that unauthorized users do not view the data. However, we will keep the system secure in terms of entering data by requiring that all Event submitters log to the Calendar & Event Management Application using a CalNet ID in order to minimize tampering with Event or calendar information. We will also require that anyone submitting an Event to a calendar log on from the live calendar using a CalNet ID. Event submitters will clearly see that their information is linked to any Events they submit, and we expect policies which punish users that spam the system or submit events containing profanity or hate speech to be put into place. We will allow users to submit HTML in the description field of an Event, but will only allow certain tags in order to prevent a malicious user from attempting to execute a script.

We will ensure that the web server is up to date with the latest patches and as secure as possible to minimize the possibility of the machine being hacked. This will include turning off all services that aren't needed, such as ordinary FTP & telnet. We will only use encrypted connections, such as SFTP or SSH, to access the server.

The application code will also be written to minimize the possibility of someone hacking into the server. We will avoid using system calls that might trick the shell into executing arbitrary shell commands and validate all user input. Additionally, we will store all files that we can outside the publicly accessible folder (e.g. "htdocs" for Apache). If PHP is used, the precautions in the "PHP and the OWASP Top Ten Security Vulnerabilities" article should be followed.

We recommend that the system be configured to allow the addition of web or database servers as the user base grows.

The application will be designed using a model-view-controller type of architecture to ensure that it is easy for developers with different skill sets to manage the application code. This means the presentation, business logic, and database layers will be separated using either the Free Energy methodology, Pear:DB modules, or another effective methodology. The coding style guidelines in this document should also be followed to encourage the development of maintainable code.

If possible, another round of usability testing of the final prototype application and calendar should be held before development begins. After the initial roll-out, the final application should also be evaluated by several users to provide ideas for the next round of development.

Both the Calendar & Event Management Application and the Live Calendar should be ADA compliant. This means that recommendations on the WebAIM Section 508 Checklist should be followed. We also recommend following the Priority 1 and as many of the Priority 2 & 3 guidelines in the W3C's Web Content Accessibility Guidelines 1.0. Other suggested reading includes the W3C's "Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0", and the Web Accessibility Initiative's "WAI Quick Tips Reference Card" and "Making a Web Site Accessible" article.