Calendar and Scheduling Requirements

Return to C&S Discovery Team Home Page



Would Be Nice:


Client/ServerArchitecture: Return to Index
For a high visibility Group product such as Calendar & Scheduling (C&S) to work, requires user data to be available to it constantly. Using a Peer-to-Peer architecture would greatly diminish its usefulness. Client/Server design where the Server or Servers house users C&S data is the chosen design.

Communications Protocol: Return to Index
TCP/IP is a requirement at MIT.
See 'Transport Mechanism' in A Glossary of Calendaring and Scheduling Terms

Multiplatform Servers: Return to Index
Solaris support is an operational requirement for an institute wide system.
SunOS and HPUX support are also desired.

Multiplatform Clients: Return to Index
For a C&S product to be considered a possible solution, it would need to provide Clients for the following platforms:

  UNIX - Solaris and IRIX are requirements for use in the Athena environment.
         The following versions of Unix are also widely used at MIT:
         HPUX, SunOS, Linux and NetBSD (SCO support will meet this need.),
         Ultrix, AIX, and OSF/1 support are also desired.
  MacOS  7.0x or above - on 68K and PowerPC hardware

System Exits: Return to Index
To allow local system level customization, 'Exit' points should be provided in both the Server and Client code. Included here would be ability to execute AppleScripts, UNIX shell commands etc. on the Client side. An example of where exit points should be provided would be: Initialization, Authentication, Notification, e-mail, access level processing, Directory Access (People Database).

Adequate Security: Return to Index
To accommodate authentication and verification, Client code needs to be Kerberos compliant or provide an Exit point for local customization.

Proxy Capable: Return to Index
Grants another person access to your calendar. Needed by people who have an assistant/secretary/coordinator tracking their appointments. Proxy will require the use of 'Access Controls'. Users must be able to set security levels of access for other users to their personal Calendar. Users must also be able to set privacy levels on calendar entries in their personal calendar. See 'Proxy Agents' in A Glossary of Calendaring and Scheduling Terms

Find Free Time: Return to Index
Automatically finds a time when all attendees and resources are available for an event or meeting.

Report Customization: Return to Index
In addition to standard reports/views, i.e. daily, weekly, monthly etc. users should be able to create their own and/or customize the standard ones.

Proactive Notification: Return to Index
The system should be capable of real time notification of upcoming and imminent events. Notification to be either visual or sound or both.

Ease of Use: Return to Index
To make the application more appealing to users and to aid in the acceptance of and to promote the use of an institute wide C&S application, the Client interface must be easy to use and intuitive. 'Easy to use' is meant to mean, a computer literate person should be able to navigate through the system with little or no training. The interface should 'lead' the user around the application and have easy access to a help facility.

Compliance with GUI standards for client platforms: Return to Index
The user interface should be consistent with the standards for the operating system being used.

System Management: Return to Index
The C&S system performance should be manageable. System administrators should have monitoring tools available to check on the health of the system. i.e. how well is it performing, how busy is the system, how big and how fast is the database growing (might indicate a projected need to split servers), discover bottle necks, query statistics on user usage (how many active user in the last x time period). Tools to aid in fixing performance problems, should be available.
It should also provide plain text backup and restore utilities for the back end database, whether proprietary or not. The vendor should provide a robust environment, it should be fault tolerant. (Does it provide data replication or is RAID compliant hardware required.)

Manual Conflict Resolution: Return to Index
Client code needs to be able to automatically detect appointment/schedule conflicts, display the conflicts and allow the user to manually reschedule items.

E-Mail Support: Return to Index
The system should have the ability to let non C&S users participate or at least be notified about meetings and agendas via email. If this capability is not provided by the server then it is desired that the client be able to interact via more than one email application. (e.g., Windows applications may support OLE and or MAPI, Mac clients may support Applescript or OpenDoc, Unix client may support shell scripts, each providing the ability to send message through a variety of email applications.) If the product has its own built in SMTP support then it at least needs to provide some configuration of the From, X-Sender, and Reply-To fields. Mail originating from "user@host" is not acceptable.

Reasonable License: Return to Index
The application must not be licensed and administered on a node locked basis. Our environment is too large and dynamic for MIT to afford this administrative overhead.
The application should not require connectivity to manage the licenses. A mobile user must not be required to initiate a PPP connection just to verify the license if they are using the application in a disconnected mode, using their to-do list, or just checking the current meeting list.
Restricting the use of the application based on IP address is very bad. It would preclude users that may work at home and access the MIT network via third party carriers. It would also preclude the use by some travelers who may be given connectivity privileges at other sites while visiting or away on business. It may also preclude the use by MIT members at the Whitehead Institute, WHOI, LL, and AI Lab.

Import/Export Functionality: Return to Index
There are operational reasons why we want data import and export features. If we use a system which requires a proprietary database we wish to be able to dump the data in ASCII form and reload this into the database. This serves two purposes. It provides us with the ability to perform some data validation tests independent of the vendor provided tools. It also provides us with the ability to migrate to another system if we so choose.
Additionally this ability is required for initial acceptance of a C&S system. Many users and departments are currently using a diverse set of C&S tools, a means to migrate these users to the new system is strongly desired. The ability to easily re-export this data into older systems is also strongly desired. Some departments may have a need to run parallel systems for some undefined period of time.

Support for Disconnected or Mobile Users: Return to Index
If the network is down or a user is going on a business trip and may not be able to connect from wherever they are going. They need a way to take a copy of their schedule with them (Export), and be allowed to alter their schedule off-line. Upon return of the net connectivity or from the trip, the user needs to be able to upload(Import) their changes to the Server.


TTY Support: Return to Index
The MIT environment consists of a very diverse set of operating systems and needs. We do not believe that any one product will possibly be able to provide native GUI interfaces for all necessary platforms. Strong preference will be given to vendors which also provide an interface for users limited to simple TTY or telnet access. We feel this would be an acceptable interface for current VM and VMS users as well as users that use the present Athena dialup machines.
Because some users will be accessing the system via PPP links the application should continue to perform well over a 14.4kbps connection. This includes native GUI clients as well.
It is understood that TTY versions of the Client may lack some functionality when compared with GUI Clients.

Extensive Proactive Notification: Return to Index
User selectable notification methods and order of preference. The user should be able to choose methods of notification and should also be able to set a priority for the methods chosen. See 'Notification' in A Glossary of Calendaring and Scheduling Terms

Notification via... Real time message window
                    Real time sound/voice
                    Phone call
                    Set message on Voice Mail/Pager etc.

Resource Scheduling: Return to Index
Access to an inventory of resources and equipment.

Automatic Conflict Resolution: Return to Index
A system that could, after detecting a conflict, 'automatically' present the user with a list of non-conflicting alternatives would be desirable.

Would Be Nice:

Choice of back-end Database: Return to Index
Expertise on a number of databases already installed at MIT is currently available within IS. It would be nice to be able to choose one we already know or one we might consider to excel in functionality and performance.

Extensive Import/Export: Return to Index
If the vendors involved are willing to cooperate, Client code could have a utility to read the users favorite calendar data and upload(Import) it to the C&S Server. The reverse should also be true.
This would require limiting the support of local calendars to a predetermined list of calendars. The most popular calendars used by the MIT community would be nice, however vendor cooperation would be the determining factor.

Contact Database: Return to Index
Address Book and Directory Services Support would be nice.

Support for XAPIA: Return to Index

World Wide Web Interface: Return to Index
A World Wide Web user interface would be nice. Privacy and security issues are a concern to MIT. It is mentioned here for completeness.

Return to C&S Discovery Team Home Page