(This document lives at http://www.gnosis.cx/docs/communication_spec.html)
If you have received a printed version, consult the URL for the most current version
Users of Ariadne products will, if required by client needs, be presented with an area in which they may examine all the messages sent to them individually, or to whatever groups they belong to. Users will have the opportunity to perform basic management (deletion, email forwarding) of their message lists.
An authorized subset of users - such as supervisors or trainers - will have the capability to configure group lists, and to send messages to individuals or groups.
The specific technological implementation of the Communication Functions have not been finalized as of Fri 05-07-1999. The purpose of the current document is to specify requirements, not to detail specific implementations and programming interfaces.
Although technical implementation details have not been finally determined, we expect that the basic message forwarding layer of the Communication Functions will utilize a POP3 protocol. POP3 user and password details will be directly based on HTTPd authentication details; the server/environment variables REMOTE_USER and REMOTE_PASSWORD will be fed to a POP3 server using CGI technologies.
When each user logs in to an Ariadne-based system, she will be presented with a prominant top-level link that will bring her to the "My Messages" area of the system. It is expected, but not per se required, that this link will be consistent with the overall frame-navigation structure and look-and-feel of the overall system in question.
Within the "My Messages" area, a user will be presented with a list
of short descriptions of available messages (probably based on the
in a standard POP3 message). Upon clicking on a message description
and/or an identifying icon, a user will be presented with the full text
of a message. This full text might be presented within a subframe, or
it might occupy the entire "My Messages" frame, depending on
implementation decisions. In any case, some recognizable navigation
element will exist to return to the standard message description list.
At a minimum, the user will be presented with options to Delete a selected message, and to forward a message to an internet email address.
It is likely to be desirable to present the user with additional options for sorting messages by sender, date, and recipient group.
According to current understanding, there will not be a need for fine-grained control of which administrators will be able to send messages to which groups. Rather, a set of users is given general permission to send messages. Such users will the presented with a top-level link to the "Send Messages" area of the system.
Within the "Send Messages" area, a user will be presented with a list of groups and individuals, and will be able to generate a message to be sent to a set of users and/or groups. The list of groups and users must be up-to-date with the user and group configuration of the system as a whole. However, daily rather than instantaneous transfer of user/group update information would be acceptable if technical concerns suggest a difficulty in accessing the same data directly.
In its simplest form, something like the below example covers the functionality needed in the "Send Messages" area. A final version will, of course, incorporate the look-and-feel of a specific client product, and also pay more attention to attractiveness of layout.
When a message is sent, it will be the responsibility of the back-end script to attach appropriate date and sender information automatically, as well as to de-alias any groups so that they forward to correct collections of users. Further, the "Send Messages" function should present actual phrases or names for users/groups, rather than the true underlying POP3 email address that is used by the server.
As with the message sending function, the granularity of configuring user control of group memberships will be at the broad level of allowing certain users such permission. Any user authorized to modify group lists will have unlimited power to do so. It is anticipated that only a very small number of user will have this permission level.
Those users who do have group configuration permission will the presented with a top-level link to the "Manage Groups" area of the system.
No specification has been made of the specific interface or look-and-feel of the group configuration function. If technically warranted, even a LISTSERV/Majordomo type batch interface would be workable. However, ideally another web-page would allow this configuration, and would share the interface and look-and-feel conventions of the rest of a client's system.
The following capabilities must exist within the "Manage Groups" area:
The management of groups should use the ordinary words or phrases used to identify users and groups, rather than their underlying email addresses. For example, configuration should be able to refer to "John Smith" or "Sales Workshop".