Enlarged version: challenges to comprehension
Home/Search
Documents >>
Themes >>
Visuals >>
Context >>
FAQ/Contact >>

Joy in the Present
      

February 1979

Computer-enhanced Communication Environment
for an International Conference Centre

- / -

Report prepared at the request of : International Congress Centre (Berlin)

Summary: This report describes a computer-based system for message exchange, directory production, participant  feedback, programme arrangement, and topic mapping in support of one or more confe- rences. As such it introduces a completely new approach to par- ticipant communication in conferences. The report gives a detailed general account of the types of computer input, processing and output problems which need to be faced in any further discussion of systems design, hardware requirements, costs and any phased development of the system over time.

0verview Annex 1 : Input formats : general approach Annex 2 : Input form layout : general considerations Annex 3 : Messaging input sheet contents Annex 4 : Directory input format Annex 5 : Directory code table creation Annex 6 : Processing Annex 7 : Feedback input, processing and output Annex 8 : Arrangements input, processing and output Annex 9 : Mapping input, processing and output. Annex 10: Output formats : general approach Annex 11: Directory output formats Annex 12: Modularization and systems possibilities Annex 13: Reproduction and addressing Annex 14: Delivery of output Annex 15: Confidentiality Annex 16: Exhibitions. Reference texts ( by the author) *  Meeting failure and participant frustration *  Meeting types old and new * Facilitative techniques for participative meetings *  Utilisation d'un programme d'ordinateur

* Enhancing conmunication at a large conference/festival
* Conference facilitation by computer-aided sharing
* Interrelating viewpoints in complex meetings.


Overview

The concept for this communication environment arises from an aware- ness that, despite the considerable increase in the number of meeting held  there is an undercurrent of concern that meetings are not as fruitful as participants are often led to suspect. There is a ten dency to treat participants as passive "consumers" of contributions. The dynamics of meetings of over 15 people are still largely based on procedures current at the beginning of the century although the techniques available permit much more flexible meetings if that is considered desirable.

Very briefly, some of the principles on which this new approach are based may be indicated as follows :

  • participants should feel confident that they mill quickly be able to locate the people with whom they need to talk
  • participants should feel confident that they are making best use of their time
  • organizers should feel confident that they are helping to make best use of the human resources assembled for the meeting
  • participants should feel confident that it is a meeting for their benefit rather than for the benefit of the organizers or speakers.
  • fluid, responsive meeting dynamics enable issues to emerge and crys- tallize much more rapidly ; there is a need to be able to re-sche dule, re-orientate and re-conceptualize rapidly (rather than wait for the following meeting)
  • small group and coalition formation around emerging issues needs to be matched by a new level of integration within the conference, par ticularly where interdisciplinary issues are concerned.

These and related principles are implicit in the design of the different options discussed below.

Design

This report deliberately avoids discussion of details (e.g. field lengths) except in so far as they affect the basic concept. However the many aspects of the application have been extensively described where relevant.

1. Input : The input philosophy may best be understood from :

Annex 1 : Input formats : general approach Annex 2 : Input form layout : general considerations. The main form of input is associated with the message exchange concept : Annex 3: Messaging input sheet contents. Another main form of input is associated with directory production : Annex 4 : Directory input format.

Both this and the massaging depend on codes described in :
Annex 5 : Directory code table creation.

The special kinds of input for feedback, arrangements and mapping are discussed below.

2. Processing : A general view of the processing problem is given in :

Annex 6: Processing. Some special processing requirements are discussed in : Annex 7 : Feedback input, processing and output Annex 8 : Arrangements input, processing and output Annex 9 : Mapping input, processing and output.

3. Output : The general output philosophy may best be understood from :

Annex 10 : Output formats : general approach The question of directory output may be found in : Annex 11 : Directory output formats. The special kinds of output for feedback (Annex 7), arrangements (Annex 8) and mapping are discussed as indicated.

4. Modularization and systems possibilities : These questions are discussed in :

Annex 12: Modularization and systems possibilities. This includes the question of phased development and possible use of on-line terminals.

5. Non-computer portions of the system : These matters, and their relationship to computer operations, are discussed in :

Annex 13 : Reproduction and addressing
Annex 14: Delivery of output.

6. Confidentiality : This important issue is discussed in :

Annex 15 : Confidentiality.

7.Exhibitions : The special case of exhibitions as an extension of conferences is discussed in :

Annex 16 : Exhibitions.

Next steps

On the basis of this report further discussion is required to clarify whether the concept as described reflects ICC interest in this matter. At the same time the systems and hardware implications need to be studied to determine how programs might be modularized, and how module and hardware development might be phased in the light of the cost implications.


Annex 1: Input formats : general approach

1. From a computer viewpoint it may well be useful to conceive most, input fields, if not all, as forming one group of fields (each appropriately identified  for key-punching and program purposes). It mould then be up to the organizer to decide before the conference which fields he wished to appear on what input forms. In this may the input fields could be located on one or more of the following forms depending on what combination was chosen and what fields were omitted as unwanted options :

  • messaging input form
  • directory input form
  • feedback input form
  • arrangements input form
  • directory update form
  • arrangements update form
  • mapping input form
  • mapping update form

2. Clearly there may be some constraints on this degree of freedom, if only in terms of :

  • the need for certain kinds of information on a form intended for a particular purpose
  • physical handling problems
  • the design of the input form layout to render it acceptable and comprehensible (This is discussed separately)

3. Note that from a computer viewpoint, input for the directory may be viewed as a "message" addressed to the computer rather than to another participant.


Annex 2: Input form layout : general considerations

1.- The design of the physical input document is of the utmost importance, independently of all computer considerations. If the document is not comprehensible to the organizer, the participants, the messaging service, and the key-punch staff, then the whole basis for this service is destroyed.

2.-As noted elsewhere, it is better to be able to propose a variety of standard input forms to the organizer and even  to allow him to specify his own. The conference centre is however duty bound to draw his attention to considerations such as the following :

(a) the value of minimizing the number of input forms offered to participants. (b) the number available may be high to cover the need for labelling fields in different languages (if this is required). In other words, the participant can be given the form corresponding to his preferred language. (c) a single form may be used with numbered fields ; the field labels would then be given on separate sheets by language. These could be incorporated into the participant directory. (d) forms of different levels of complexity can be selected by participants according to their level of tolerance. For example, a "simple" form for someone who only intends to engage in simple message exchange and who will go to a message desk for assistance in order to submit anything more complex. Whereas a sophisticated communicator would select the most complex form with all the options. Participants may move on from the simple to the complex as they learn to use the system. (e) forms may be laid out with the "simple" fields on one side of the sheet and the complex ones on the reverse side. (f) the fields may be positioned on the form with colouring or shading to guide the user towards the simple or essential fields (no shading) and away from the more complex options (heavier shading). This is also important for fields which need to be physically checked by the messaging service (e.g. "no typing required, deliver in handwritten form"). (g) forms of different colours may of course be used for different purposes or languages. (h) forms may be supplied in pad form if this is appropriate. (i) a highly generalized form may be used with just a column for key-punch field identifiers to be chosen and inserted by the user according to the options he wishes to use. This possibility would require careful thought.

Annex 3: Messaging : Input sheet contents (annotated)

The following list of items should be considered for use on a standard pre-printed message input sheet. As listed here in an arbitrary order, no attempt is made to consider the actual layout of such a sheet which may vary from conference to conference. Whether or not a particular item is included on the message form of a specific conference, the computer message file should make provision for the complete range by allocating field codes to each item. Such codes would also be important for any keypunching and those used would therefore appear in small print at appropriate positions on the actual message form.

The layout of the form is of course of the greatest importance. It must take into account :

(a) language (multi-lingual forms or forms by language ?)

(b) visual prominance of essential items, as opposed to secondary prominance of optional information (in order not to confuse and discourage the user)

(c) processing instructions (translations, urgency, etc.)

01 - Message addressed to

011 - Addressee code in directory :

1. This field is used, if preferred, to identify the addressee in terms of a code specified in the participant directory (e.g. like a cable address). It is also particularly useful for identifying (a) secretariat services (travel , audio- visual services, feedback officer, accommodation, etc), (b) groups of participants ("commission 3 - session 2" partici- pants, coalition 14 members, all participants, conference officers, etc.). These codes would also be identified in the directory, in directory updates, or on the conference programme  (e.g. against each meeting session).

2. Since the message may go to several code groups (e.g. members of coalition 14 and 15) or individuals, provision should be made for several codes in this field.

3. The person preparing the message may not wish to find or use the appropriate code. This may therefore be added to the form by the "messaging service officer" before the form is sent for key-punching.

4. The computer program uses this code to locate the "conference address" (a) of the person from its directory file, or (b) of the persons in a group (if the message cannot be delivered to a person in an ongoing session). It will determine how many copies of the message are to be prepared. Clearly there is an advantage in grouping messages to be sent to one person or group. But a compromise must be sought between grouping messages for an individual and grouping messages for a group of individuals (e.g. the 75 members of "topic coalition 9" ; in this case the computer output original can be more economically reproduced by offset or photocopy). If messages can be consulted on a television screen linked on demand to the data base, hard copy may be unnecessary.

5. Confidential addresse  codes (e.g. analogous to ex-directory telephone numbers) may be allocated to participants, whether systematically or on request, in addition to the code which is printed in the directory. Such codes may be :

(a) exchanged between "high profile" colleagues mho are likely to be receiving many "junk  messages" they will not read under their "public" addressee code. (b) used as pseudonyms to preserve anonymity in message exchange and yet still be able to receive a reply. (c) used to authenticate the sender (see 045) .

6. It may not be necessary, from a computer viewpoint, to specify the code design.  For one conference a numeric 3-digit identifier might be adequate, for another a 4-digit identifier. In another "numeric" identifiers may be viewed as disagreeably impersonal so that alphabetic codes could be used (e.g. XPQ, ABZ). Or again codes may be assigned as unique computer abridgements of the surname (e.g. BRWN for Brown). Confidential codes could either be individually assigned or based on a computer manipulation of the public code. Note that there is considerable psychological merit in allowing people to design their own identifier codes, especially when they are to be used as pseudonyms.

012 - Addressee code in meeting room ; meeting codes

1. Message exchange during a session, or from others to people in a session, depends mainly on the following factors :

(a) need to identify specific participants seated in a meeting room to deliver personalized messages. This would only be practical where desk identifiers are used or whe re a desk/seat number directory can be quickly prepared and distributed. This would provide a meeting room address for each participant. Participants who have to leave the session could have messages delivered to their conference address. (b) delays if a translation in required (c) delays if the message has to be typed for reproduction or incorporation into the computer system, as opposed to acceptability of the handwritten message (whether as a single copy or reproduced) (d) delays if messages (a) to all participants or (b) which can be grouped with (a), even though addressed to some participants, are cumulated before being distributed on a reproduced sheet.

2. As mentioned in 011, there is a case for employing a standard coding system for :

(a) the conference as a whole, to avoid confusion for a messaging service handling several conferences in the same building complex. (b) any series of sessions on a given topic where the same participants will be grouped on a number of occasions and communication continuity isrequired. (c) any session at a particular time and place. (d) the room number in which the session is held.

013 - Addressee exclusion code

This is used, if required, to specify who should not receive the message. It is therefore a qualifier on codes in 011 (e.g. all participants except coalition 14). Again provision should be made for a number of codes in this position. This may be very important to facilitate coalition dynamics where coalition, need to conceal their strategies from each other.

014 - Addressee name

As discussed under 011 and 012, the name of a person or of a group (e.g. "Resolution 14 coalition") may be inserted here if the 011 code number is not used, or as confirmation of that code number or in the case of additional names for which codes are not available. Again it is preferable to be able to specify several names (as discussed in 011) . The "messaging service officer" should complete ill-defined names such as "Secretary, Topic group 4", where possible.

015 - Addressee excluded names

This corresponds to 0133, except that the names are given in full as in 014.

016 - Addressee address (specially temporary location)

Where delivery of the message should first be attempted at an address different from that specified in the directory (or possibly where the meeting room address (see 012) can only be expressed verbally or imprecisely, this should be placed here. Note such an address may usefully have a time frame attached to it (e.g. Room 411, 1500-1750 ; or Foyer table 14, 1000-1030)

02 - Message from

021 - Sender identifier code indirectory 1 . As for 011

2. As for 011

3. Approach of 011, not relevant

4. Approach of 011, not relevant

5. As for 011. However, if no reply is required and the message is anonymous, no code need be used

6. As for 011

022 - Address ofsender in meeting room

1. As for 012

2. As for 012


023 - Sender exclusion code

Not relevant (although see 025)

024 - Sender name As for 014

025 - Sender excluded names

Not relevant except possibly where a dissident minority must be indicated (e.g. Recommendations Committee except J.Brown and R.Schmidt)

026 - Sender address (specially temporary locations)

As for 016 ; namely where any immediate reply should be addressed.

3 - Message references

031 - Date/time

Preferably in standard numeric form to avoid language problems (e.g. 1979/04/23 1503). Note that provision should be made for several date/time figures :

(a) Time prepared by sender as noted by sender (b) Time received for processing as inserted by messaging service officer (c) Time inserted by computer on output message when the latter is available.

These different date/time figures may prove useful when there are complaints about delays. Consideration should be given to which ones should appear on the output message.

032 - Sender's message reference number

This field may be used by a person or group sending many messages and using a personal filing system to maintain order. It may be cited by the addressee when replying (see 034). The simplest code mould be numerical but, since it is not of relevance to the computer, other user-designed codes could be permissable.

033 - Message reference number

This is a unique number inserted and used by the computer in order to handle messages. This number should be printed as an identifier on all messages processed by the computer. Note it may replace the need for 032 and may be cited in 034.

034 - Addressee's message reference number

As for 032. In general 033 would be used in preference to 032. Note that any such reference could be made in the message text if required (e.g. "In response to your 1030 message to coalition 4 .....") rather than in this field.


035 - Topic/subject codes in directory

1. This field is used, if desired, to identify the subject matter of the message in terms of codes in the participant directory. Such codes would be used to identify such "subjects" as :

  • specific substantive topics (e.g. "water pollution")
  • topics grouped in/relation to a meeting session (e.g. "session 3 topics")
  • agenda item (e.g. "agenda item 14")

Since the message may be about organizational matters, the codes used in the directory to identify any of the following can also be considered as "subject" codes :

  • panel 14
  • coalition 10
  • topic group 9.

2. The advantage of using such codes, for messages processed by computer, is that it allows the computer to take note, if required (see  052), of the person's interest in the topic. This means that the person mill automatically re- ceive any messages addressed to "all those interested in a topic X" (by insertion of an appropriate code from the directory in 011).

3. Another advantage is that it facilitates the task of automatic translation if translation is likely to be required (see 053).

4. The messaging service officer may add the appropriate code on the basis of information in 039 before the form is sent for key-punching (as for 011.3)

5. Since a combination of topics may be required, provision should be made for several codes in this field (as for 011.2,

6. If possible,consideration should be given to logical combinations of topic codes : A and B, A or C, or more complex groupings (see also 037). Such combinations should be registered, if required (see 052) as new topic codes in the directory in order to facilitate subsequent communications.

036 - Topic/subject names

The name of a topic or subject may be inserted here, if codes are not used in 035, or in addition to such codes. As discussed in 035, it is preferable to be able to include several topics.

037 - Topic/subject codes excluded

This field is used to clarify the scope or intention of the message as/defined by 035. (See also 035.6)

038 - Topic/subject names excluded

As for 036 , such exclusions (as for 037) may be necessary to clarify topics in terms of which interaction can usefully take place (e.g. "water pollution except oil pollution").


04 - Message processing indications : I.

041 - Message type

Aside From use of codes to specify the addressee(s), it may be useful to distinguish here the type of message, particularly if special handling is necessary :

(a) general message, basically to all participants and therefore to be cumulated for reproduction with other such messages . (b) message to a specified group of participants (e.g. identified by a group code in the directory). Again such messages may be cumulated for reproduction and distribution. (c) message to an amorphous, ill-defined group (e.g. specified by a combination of codes in the directory). This can be treated either for inclusion in the (a) message sheet, recognizing that it will not be of interest to many, or else as in (d) (d) message of type (c) but to be treated as many separate individual messages which can be cumulated with others for distribution to each individual. Depending on economic and quantity considerations, such non-confidential personal messages may simply be listed on a different colour message sheet (from type a) with the messages listed in participant number order. (e) messaga to an individual to be considered as confiden - tial. This can be combined with type (d), unless that is handled as for type (a).

042 - Message forms

As discussed in 012 , it may not be necessary, possible, or even desirable, to process all messages by computer. The following forms can be distinguished

(a) handwritten message, not to be reproduced but delivered as such. (b) handwritten message (e.g. non-roman characters), for reproduction as such (c) typed message, or message to be typed for reproduction (d) message to be computer processed.

043 - Message timing

The time factor may be very important in relation to a message. The following may be distinguished

(a) urgent, namely personal handling (b) must be delivered before a stated time or else consider as undeliverable (c) process normally with other messages (d) retain in computer for automatic transfer to any person subsequently indicating an interest in the topic.

044 - Message validation

The accuracy of a message may be a very important consideration (e.g. in the case of draft resolutions). The following may b.e distinguished :

(a) normal processing (b) messaging service to double check against handwritten original (c) copy prior to reproduction to be checked by sender, possibly also for cost implications (see 055.6). 045 - Sender authentication

Confirmation that the sender is who he claims to be in the message may be important. Otherwise the messages may be sent deliberately, or accidentally, to misrepresent someone's position. A good system of authentication is for the individual (or group) to supply their confidential (ex-directory) code in this position (see 011.5) and have it matched by the computer (or messaging service officer) against the directory code. If there in a mismatch  the message should be returned to the sender. Clearly the problem does not arise in the case of anonymous messages, but it does in the case of the use of the pseudonym (confidential) codes. In such cases, it is the directory code in this position which should be used for matching.

This technique is only necessary when possible abuse is suspected and in such cases the output message Form can bear some "identity authenticated" phrase.

Where abuse is deliberate and the sender's confidential code becomes known, he should be able to disown that "identity" and request another. (This could create a problem if the relation between the confidential and public codes are fixed by program rather than by table look-up).

Where the message is a feedback vote or comment, it is clearly important that each person only vote once (even if a second vote is allowed to modify or replace the first). Use  of the confidential code can be used to prevent multiple voting.

Where the post of the message must be borne in whole or in part by the sender,it is clearly important that a confidential authentication code be used.

046 - Error and delivery failure procedures

A variety of failures (other than 044 or 045) may arise and simple procedures may be required to indicate action to be taken :

(a) in case of failure to deliver, return to sender (b) in case of erroneous addressee identity, return to sender.

05 - Message processing indicators : II.

051 - Directory augmentation: addressees

1. As mentioned above (see 011/4), use of addressee codes or names can permit the computer to take automatic note of :

  • new addressee names as yet uncoded (e.g. "womens coalition", which therefore require a code.
  • use of existing addressee codes, so that an indication can be maintained of the sender's interest (e.g. in the coalition in question).

2. Whilst this would arguably not be relevant for individual (as opposed to collective) addressees, there may be a case for being able to supply the participant at the end of the conference with a list of the names/addresses of all those with whom he had exchanged messages.

3. Directory augmentation should not be automatic however but optional either in the form

(a) if a code  input in this field augmentation will be done, or (b) if you do not put a code in this field augmentation will be done.

The choice between (a) and (b) should be a system-level decision based on the organizers conference communication policy .

052 - Directory augmentation : topics/subjects

1. As mentioned above (see 035), use of topic/subject codes or names can permit the computer to take automatic note of :

  • new topic/subject names as yet uncoded (e.g. "water pollution"), which therefore require a code.
  • use of existing topic/subject codes, so that an indication can be maintained of the sender's interest in the topic in question

2 . Maintenance of a list of who is interested in which topic enables :

  • messages to be sent at any time to such a group
  • permits a list of names to be supplied at any time (e.g. as a checklist of possible attendance at a proposed session) and particularly at the end of the meeting (e.g. in preparation for future meetings, for mailing session reports, or exchange of papers between those in the interest group).

3. As for 051.3

053 - Translation requirement : for addressee 's

1. A sender may express the desire that the message be translated into other languages for appropriate distribution. This would be arranged by the messaging service offices. Note that in a sophisticated system, the original mould be entered into the computer system and transferred to the terminal screen of appropriate translators who would enter the translation directly by terminal.

2. Note that terms in the directory would be available in several languages so that some degree of automatic translation would be possible.

054 - Translation requirement : For replies

A sender may specify here in which languages he is able to receive a reply to any message sent.

055 - Messaging fees

1. The messaging facilities offered by this system constitute a service with fairly well-defined costs. Such costs can be :

  • accumulated in an overall invoice to the organizers for the service, so that participants use it as a a free service
  • absorbed by the conference centre into general services offered to the conference organizer, so that both organizer and participants use it as a free ervice
  • messaging costs can be transferred to participants : (a) as a fixed fee (optional) at registration time entitling any use of the facility by the participant. (b) as a credit at reqistration time against which any use of the facility will be offset until the participant's credit is exhausted and further payment is required (c) as a service to be billed to the participant at the end of the conference according to use.

2. It should be noted that the computer is ideally suited to keep detailed track of costs incurred by each participant (including special services like translation, special checks, etc)

3. Costs can be partially subsidized by interested parties to facilitate selectively the communication within the conference :

(a) use by any participants can be subsidized, effectively reducing the message rate. This might be done by the conference centre, the organizer, or well-endowed participants (b) use by selected participant groups may be partially subsidized as in (a). (e. g. " deve1oping country participants", "members of coalition 14", etc). (c) use by participants communicating about a specified topic (e.g. "water pollution in developing countries"), provided there was some control against abuse. For example, messages could be transferred to the subsidizing body to verify the content corresponded to the topic codes, failing which the sender could be billed at a normal (or penalty) rate. (d) use by specific individuals whose messages would constitute a stimulus to the conference communication process . (e) use by individuals communicating with the subsidizing individual about a specific topic. This may be used by a participant as a way of eliciting information and interest in a topic of special interest, or of initiating coalition formation.

4. Mote that the degree of subsidy of messages may be publicized or not. In any case it may vary during the course of the conference.

5. If the number of messages a participant receives is likely to be unacceptable to him, it is possible to envisage a system whereby the participant's account would be credited if he agreed to receive the message. This would be one way for a participant to impose a "barrier" to unwanted communications .

6. Note that a sender may need to know how much it will cost to send a message to a category of participants. This information may usefully be printed in the directory (as an approximation) against each addressee code. Alternatively the sender may request confirmation of the cost before dispatch (see 044 (c)).

7. This field may therefore be used by the sender to indicate how much he is prepared to subsidize any reply. Several formulas can be considered :

  • 50 % of standard rate for all replies up to N words
  • 100 % of standard rate for first 10 replies up to N words
  • 25 % of standard rate for all replies, up to Nwords, before 1978/04/23  1700.

8. Note that provision should be made for "outsiders" not in the directory (e.g. people wishing to make contact with participants) to pay for a message they wish to send to a participant.

06 - Short cut messaging procedures

Clearly the number of options which can be offered to the sender may discourage him from filling out a complex form for a simple message. Most of the fields are optional however, and much depends on the layout of the form (discussed elsewhere). Two procedures using this field may be adopted to avoid unnecessary form filling :

  • the directory may list a number of "short cut" codes to specify standard message types.
  • short cut procedures may be modified by the sender by including information in particular fields which will then substitute for that specified in the procedure.

Such procedures may be specially useful in the case of feedback votes on a particular issue.

07 - Message text

1. This raises no major problem

2. Mote that computer processed messages may have to be listed in capitals. Even when upper/lower case is available, accents may not.


3. Note that excessive message length is a problem in the following ways :

  • delays to message handling (and translation) service
  • nuisance to receiver
  • cost to sender or system.

Consideration should be given to increasing the message cost for long messages not reproduced separately.

4. Note that the messaging service officer may find it necessary to use discretion (or a simple word list) to prevent reproduction of messages which may be construed as insulting  blasphemous, etc. The rules may of course be changed from conference to conference.


Annex 4: Directory input format

1 . The question of the code table creation for the directory is considered separately. This note is primarily concerned with how information about "identities" (individuals, groups, etc) is prepared for the computer.

2. It is not possible to specify in advance with certainty what items of information the organizers would like to appear in their conference directory either during or after the conference (since there may be a difference). For this reason a flexible approach is required.

3. It is appropriate to distinguish several categories of information :

(a) information basic to messaging
  • name and identity codes
  • conference address (or pickup location
(b) information basic to participant directory
  • name and public identity code
  • mailing address (including institution) and jab title,if necessary.
(c) additional information important to messaging and directory, specially as sort or selection keys
  • nationality, language(s)
  • conference functions (Panel 2 chairman, etc)
  • special interest topics
  • observer or other status
(d) additional confidential messaging information
  • procedure codes
  • contact preferences
  • availability
(e) additional directory information
  • items to be positioned on the directory page but requiring no other processing or use as a sort key.

4. As with the messaging input form, the actual form design is important to avoid discouraging the participant. Clearly 3 (a) and (b) must figure prominently as well-defined fields. Whereas 3 (c) and (d) depend on which of the options the organizer plans to have used. Only those used are required and the field lengths will be defined. The fields of 3 (a) to (d) will all be identified by codes to facilitate key-punching. This may pernit the fields to be in any order desired. In the case of 3 (e), a number of fields of different lengths can be used by the organizer to carry any special items of information. Clearly these need not be used. If they are their identities mill be given by a key-punch number.

5. Note that some of the information in 3 may be available from a separate conference registration/administration program. The type of link between the two data bases needs to be studied. They would probably need to be separate to avoid confusion. A simple program could be used to extract information from the one for input to the other.

6. Note thatsome participants may not wish to provide more than a minimum of information, such as in 3 (a) or (b). They may have no desire or need to use a messaging system.


Annex 5: Directory code table creation

1. For anything more than the simplest name/address directory, a directory code table must be set up before the conference. Some elements of this table may be provided by the conference centre (e.g. codes for meeting rooms, conference services, etc) but the details must obviously be supplied by the organizers (e.g. topic codes, etc) on the basis of a format supplied by the conference centre. The codes mould be printed in/the directory to facilitate messaging. Note the distinction between the directory as published for certain purposes and the directory information held in the computer for a wider variety of purposes.

2. Code design : Whilst the conference centre may be able to recommend one or more approaches to code design, it is obviously preferable to involve the organizers in the conception of a code system which will suit them. This should not be a problem on the computer side, or any constraints should be minor.

Note the possible desirability, in some cases, of a code with a check-digit to avoid problems from illegible handwriting - specially in the case of the sender and receiver identifier codes.

3. Types of code required : Again it should be emphasized that any distinctions to be made between codes should be decided by the organizers. The fallowing list merely suggests a range of types which might be present, absent or regrouped according to the needs of the organizer :

3.1 Individual participant : These are codes which enable the computer to locate the individual's name and conference address. They would be allocated as the participants were registered unless the participants were known in advance so that a preliminary participant directory was available prior to actual registration.

Note the desirability of a confidential code as well as a code for any printed directory. (see  )

3.2 Participant group : The organizers may want to indicate a range of groups with which participants may be associated during the conference. These may be considered distinct from topic code groups (see 3.11 below). They may be special interest groups, coalitions, "resolution 14 group", workshop members, "those who attended the 1st Congress in 1950", etc. The organizers may wish to submit a list of such groups to participants before the conference so/that they can indicate with which they wish to be associated. During the conference other groups may be added as the directory is updated. A distinction may be made between "approved/official" groups and "spontaneous" groups arising from individual initiative.

Note the desirability of a confidential code for any group and the possibility of not publishing the group name and contact code in any directory. It is part of conference dynamics, in some cases, not to publicize the existence of a coalition even through members need to exchange messages. Further more, even if publicized with a public code enabling them to receive messages from anyone, group members may only wish to send messages to those who have been linked to the confidential code for the group. Otherwise the group may be infiltrated and will refuse to use the messaging system.

3.3 Conference officers : These are people identified by function rather than by name (which may change or not be known in advance), such as "Chairman of Panel 4", "Secretary of coalition 2".

3.4 .Secretariat services : These are all the conference secretariat services (e.g. audio-visuals, room allocation/scheduling, interpreters, etc)

3.5 A_s s o c i a t e d services : These are the services which may be available in the conference centre (e.g. travel, tourism, accommodation, flowers, bus service)

3.6 Hotels : Codes may be used to identify the different hotels around the conference centre, particularly if messages are to be delivered to participants in hotels.

3.7 Meeting location codes : rooms, foyer tables, pigeonholes, message pickup points, etc.

3.8 Meeting sessions

3.9 Nationality : These would be used to facilitate messaging to all people of one nationality, (e.g. invitations to a cocktail party for Canadian participants)

3.10 Language : These would be used to facilitate translation and messaging (e.g. invitations to a cocktail party for all German speaking participants)

3.11 Topic/subject codes : As with participant groups (3.2 above), the organizers may want to indicate the range of topics with which participants can be associated during the conference. They may be considered distinct from the participant group, depending on how formalized is the group  (e.g. an interest in "flood control" does not necessarily imply a desire for membership of the "flood control group"). The organizers may wish to submit a list of such topics to participants before the conference (on the basis of the previous conference,- so that they can indicate with which they wish to be associated. Other topics can be added during the conference as the directory is updated. Again a distinction may be made between "official/approved" topics and others added on individual initiative.

Since the latter may emerge from the messaging procedure in which topic combinations are defined, such combinations may each be given special codes (e.g. "water and air pollution excluding oil pollution").

3.12 Agenda items : These may be considered distinct from topic/ subject codes (3.11)

3.13 Resolution number : These may be considered distinct from 3.11 and 3.12.

3.14 Emerging issues : These would be codes for guestions on which feedback was specifically requested in the Form of a vote or other comment (e.g. cancellation of plenary session 3, suppression of "marine pollution" from directory topic codes,etc).

3.15 0perational codes : Certain codes may be printed in the directory to facilitate messaging (e.g. shortcut procedure codes, requests to the computer). These are discussed e 1sewhere .

4. Directory code update : This is discussed elsewhere. Of particular importance is the automatic augmentation of the directory on the basis of groups and topics implicitly defined in messaging. Unless this is done, there mill always be inconvenient delays before a new topic is "approved". This would be highly detrimental to communication dynamics.

5. Editing the directory codes : If the freedom of the previous

paragraph is allowed, some attention needs to be given periodically to "tidying up" the code table. For example if "marine pollution" suddenly appears in topic list in which "water pollution" is already present, it should be possible to insert remarks in the directory like

  • use instead : water pollution
  • see also : water pollution
  • clarification requested ; see also : water pollution.

This could be the responsibility of an individual or a committee (see 3,14, above ).

Similarly, if "Convenor, Resolution 14 task force" suddenly appeared in the directory, an individual's code could be inserted with a "use instead" mention, once the identity was known. Or if the task force required all messages be sent to the "secretary" and "convenor", two codes could be indicated.

Processing

Several processing categories are envisaged below.

There is a special systems/programming problem which is not discussed here, namely at what stage, and how best, to perform (or distinguish)

  • noncumulated and cumulated messages
  • messages for a limited number and for a group (where the text is reproduced either after being output by the computer or in parallel with computer processing of addresses).
  • the extent to which all input and output should be treated as "messages".

A. Input processing

A basic run may be used for processing "messages" of different types :

1. Locate and decode any addressee information to generate an adequate delivery address.

2. Update sender directory profile, if relevant

3. Update addresse  directory profile, if relevant

4. Update any fields (e.g. topic codes) linked to the message.

B . 0utput  processing

1. Output priority messages immediately (with any lower priority cumulated messages), if relevant.

2 . Output periodically (according to work load) cumulated messages

C. Unsorted extractions

This option would be activated in response to a participant request to the computer for any of the following :

1. List of participants having certain characteristics specified by codes, e.g. - nationality

  • language
  • topic interest
  • group membership.

2. Full directory profile of the participant making the request, so that he can check for any misrepresentation.

3. Partial directory profile of any participant, namely information which could appear in the participant directory (if and when published). This would exclude confidential codes.

4. Current feedback response on any issue. This would exclude confidential information.

5. List of people (with addresses ?) who have contacted the participant, with message number and message keyword. (This may be considered as part of the full directory profile)

6. List of people (with addresses ?) who have been contacted by the participant (as for 5)

The output would normally take the form of a message from the computer to the participant placing the request. It might well be cumulated with other messages to him.


Annex 6: Processing

Several processing categories are envisaged below.

There is a special systems/programming problem which is not discussed here, namely at what stage, and how best, to perform (or distinguish)

  • noncumulated and cumulated messages
  • messages for a limited number and for a group (where the text is reproduced either after being output by the computer or in parallel with computer processing of addresses).
  • the extent to which all input and output should be treated as "messages " .

A. Input processing

A basic run may be used for processing "messages" of different types :

1. Locate and decode any addressee information to generate an adequate delivery address.

2. Update sender directory profile, if relevant

3 . Update addresse  directory profile, if relevant

4. Update any fields (e.g. topic codes) linked to the message.

B. Output  processing

1. Output priority messages immediately (with any lower priority cumulated messages), if relevant.

2 . Output periodically (according to work load) cumulated messages.

C . Unsorted extractions

This option would be activated in response to a participant request to the computer for any of the following :

1. List of participants having certain characteristics specified by codes, e.g. - nationality

  • language
  • topic interest
  • group membership.

2. Full directory profile of the participant making the request, so that he can check for any misrepresentation.

3. Partial directory profile of any participant, namely information which could appear in the participant directory (if and when published). This would exclude confidential codes.

4. Current feedback response on any issue. This would exclude confidential information.

5. List of people (with addresses ?) who have contacted the participant, with message number and message keyword. (This may be considered as part of the full directory profile)

6. List of people (with addresses ?) who have been contacted by the participant (as for 5)

In some cases (e.g. 1 or 4), the response might be reproduced for wider distribution.

D. Sorted selection

This option would normally be used by the organizer to obtain any of the following :

1. Participants in code number order

2. Sorted lists of participants (with or without additional information, but usually with the identifier code) in terms of such codes as, for example :

  • nationality
  • language
  • topic interest
  • group membership.

3. Non-confidential feedback comments on any issue, although sorting would effectively destroy any confidentiality.

The output of 2 (above) would take any of the following forms :

  • sort groups (e.g. the French language participants) would be treated as messages  to be reproduced (if appropriate) for distribution to all the participants in the group.
  • the complete document (including 1, above) would be available for consultation at a message desk or as a wall display.
  • the complete document (including 1 , above) would be photoreduced or otherwise prepared for distribution to all participants as part of the participant directory.

E. Sort and comparison

This  option would normally be used by the organizer to obtain an  indication for each participant with which other participants he had interests in common (see Arrangements processing) and which might usefully be followed up.

Note that once the run had beendone, whether or not the results were distributed, it should be possible for individuals to request of the computer that part of the file which concerned them.


Annex 7: Feedback input, processing and output

1. The feedback concept is really a special application of the messaging concept which is discussed separately. Feedback from participants is required in order to determine participant sentiment or decisions on particular issues.  Feedback on a particular issue (e.g. Issue 79) would be requested by verbal announcement or a message to participants.

2. Input :

2.1 . Two types of feedback can be envisaged :

(a) Verbal comment : This is self-explanatory. It would be very similar to a message (b) Vote : This could be of the yes, no, don't know/abstain variety. Or also it could be expressed as a degree of preference (e.g. on a scale 1 to 9). Such information would have to be in well-defined fields.

Clearly, particularly in the case of voting, there may be several questions on which separate feedback is required. In which case, several sets of fields would be required.

2.2. As discussed elsewhere, there is need for a control on the identity of the participant in terms of (a) right to vote and (b)no voting twice, although perhaps his second vote may be allowed to replace his first.

2.3. A special problem of identity and authentication arises when voting is only possible by delegation or by country rather than by participant. The implications of this for file organization should be considered.

2.4. There is also a question of whether it is desired by the organizers or individual participant that the feedback should be considered confidential in a particular case. Clearly there will be times when :

(a) it is desirable that everyone should know how everyone else voted (b) some people do not mind everyone knowing how they voted (c) although no list is available of how individual participants voted, nevertheless messages can be sent to "all those who voted noon issue 24".

2.5. To the extent that the feedback issue concerns a particular arrangement (see arrangements processing), namely a proposal made by the computer for a contact or a meeting event, attention should be given to how the two are to be related. A special problem arises in the case of feedback expressed as a degree of preference (e.g. on a 1 to 9 scale).

2.6. It is possible that special input would be required to "set up" an issue on which feedback is required. This could either be the responsibility of the organizer or simply a special zone on a message form useable by any participant. A date/time dead1ine for feedback should be supplied at the same time, although open to modification.

3. Processing :

3.1. Verbal comment : Feedback in this form should simply be cumulated as a series of messages for the "issue officer", organizer, or whoever introduced the issue for feedback (e.g. coalition 14 or a participant). The results may of course be reproduced as a general message to all participants. A special problem arises when the comment constitutes a reservation or qualification on a vote.

3.2. Vote : In this case totals are required on the yes, no, and other fields. Clearly the processing of this information can be made quite sophisticated by combining it with other information to produce a statistical analysis (e.g. votes by nationality, language group, etc). The program  routine (like that for part of the arrangements processing) should be designed to be replaced at a later stage if it becomes possible to introduce a better routine.

3.3. Deadlines : In principle when the date/time deadline for the issue is reached, the computer should be able to process the feedback for the issue without further instruction.

4. Output :

4.1. Verbal comment : As with messages.

4.2. Votes : A suitable tabular presentation is required. Where many issues are currently under consideration, it would be convenient to have the output presented in issue number order (with the issue topic keyword), vote results, and an indication of the deadline and whether it has been passed thus closing the issue to further voting. Note that there may be a requirement that the current state of the vote not be announced prior to the deadline.


Annex 8: Arrangements : input (including feedback) processing and output

1.1. The purpose of this option is to offer the participant the possibility of being supplied with suggestions of contacts he should make with other participants. Not all participants may wish to use this option or they may wish to use it to varying extents.

1.2. For those wishing to place greater dependence on this facility, it may be used (a) to propose a schedule of appointments at particular locations for mutually free time periods, and (b) to confirm the appointments if the proposals are mutually agreeable.

1.3. For those wishing to use the facility to restructure their conference program, an even greater degree of involvement is possible. The degree of restructuring permissable will of course depend on the policy of the organizer who may not allow this option to be made available (except possibly on certain days), because of the nature of the conference. However, when it is available, it does permit the participant to "design  his own conference experience" depending upon how much effort he wishes to put into it.

1.4. Much of the acceptability of this facility depends on the layout or presentation of the input form. This problem is discussed separately.

1.5. Note that this facility may be used prior to the conference by the organizer in interacting with potential participants who will only come if they can be certain of confirmed meetings with certain other participants (irrespective of the official programme). It can also be used by the organizer as a negotiating tool with potential panelists, moderators and speakers to design the official programme.

2. Input

2.1. The input, as mentioned elsewhere, may be considered as a particular kind of message from the participant to the computer. Alternatively a separate input format can be envisaged. In either case the information would be used to/update the directory profile of the participant.

2.2. Aside from the necessary introduction of the participant identifier or other standard information, the input may be conceived as made up of a group of fields described below. Note that these may be considered as linked or separate.  If they are linked, several such groups of fields may need to be input. In the simpler versions of this facility not all fields will need to be used, and in other versions absence of information can be construed as absence of constraint.

2.3. The fields are :

(a) topic/subject : This may be indicated in code form or as text. In text form either a code must be found (if available) or generated (if not available), whether or not this is done by the messaging service or by computer. Note that text raises the question of language.  As for messaging, several topics and topic combinations should be permissable including exclusions (e.g. topic A and B but not C). (b) participant : Again this may be indicated in code form or as text. Several participant combinations should be perraissable including exclusions (e.g.person A and B but not C). (c) number of persons : This is used to indicate the number of persons acceptable, in terms of maximum and minimum. This covers the complete range from tete-a-tete to a large lecture. (d) style : This is used to indicate the kind of dynamics, e.g. structured - brainstorming - informal - experiential (e) own role : This is used to indicate what role one is pre- pared to adopt, e.g. - chairman - moderator - lecturer - panelist - participant - group leader. (f) role of others : This is used to indicate what role the others named in (b) are expected to adopt, e.g. - panelist - lecturer. (g) duration : This is used to indicate the time period which is acceptable, in terms of maximum and minimum. This co- vers the complete range from a 5 minute exchange to a many-hour session. (h) location preference : This is used to indicate where the meeting could take place, e.g. - meeting room - bar - foyer table - breakfast table. (i) time preference : This is used to indicate when the meeting could take place in terms of date and time. (j) language : This is used to indicate the languages acceptable for the interaction. (k) invitor : Where relevant, this is used to indicate who is inviting or paying any costs, whether a meeting room or a meal. This field may also be used by those prepared to sponsor an event financially.

2.4. It should be possible to use the above fields to specify such preferences as :

  • no contact with person X
  • no contact involving topic Y
  • any meeting at a particular time period
  • a tourist visit to a down-town museaum.

2.5. In addition the participant should be able to specify, for the more involved options, the following :

(a) time periods available : This is used to indicate which periods of each day the participant is prepared to allow the computer to consider as "open" for any possible arrangements. (b) time period not available : Depending on the number of appointments, it may be more convenient to use this field rather than the previous one. (c) location : Clearly it is important for the participant to be able to specify where he will be at his "available" times (e.g. there is no point in proposing a meeting in a hotel bar when the other person is in the conference centre at that time)

2.6. Irrespective of the information given by the participant (in 2.5.), the organizer and/or conference centre should be able to specify the following :

(a) meeting room size : Namely the physical constraints on a meeting in a particular location (b) meetino room availability : Namely the time periods within which it is available. (c) other factors : Namely the possible need for other information such as cost (if it must be separately negotiated with the conference centre or hotel), audio-visual and other facilities.

3. Feedback

3.1. As a result of participant inspection of the output (discussed below), it is to be expected that participants will wish to modify or confirm arrangements proposed to them by the computer.

3.2. Feedback is therefore an extended form of input (which may be associated with feedback vote processing discussed separately). It may take the form of :

(a) rejecting a proposal (b) modifying the profile so that the computer will not in future make proposals like that rejected. (c) amplifying the profile in the light of unforeseen possibilities .

3.3. To facilitate feedback and processing the computer should allocate a reference number to each proposal identified on any output.

4. Processing

4.1. Passive arrangements : In this simple use of the facility the processing involves a double sort to identify those who have common interest or expressed a unilateral preference to meet with other named persons. This information can then be presented in a sorted list to each person, possibly as a form of message.

4.2. Proposed arrangements : Those using the facility at this level would be sent, in addition to the information in 4.1, an  indication of the time/place for the meeting as proposed by the computer. Note that if one participant has specified the time/ place, the computer's proposal is merely a repetition of this. Practical considerations suggest that thought be given to such problems as :

  • indicating of date/time by which feedback should be supplied accepting the proposal
  • indicating the status of the proposal
  • proposed
  • acceptance by self, in anticipation of acceptance by other
  • acceptance by other, in anticipation of acceptance by self
  • confirmation.

Note that in practice "self" may or may not want "other" to know of his own acceptance before "other" has accepted.

4.3. Conference programme design : This is basically the same as 4.2 except that it would normally be expected that the proposals mould be considered confirmed, unless the participant supplies a feedback message rejecting one or more of them. The normal procedure would be for the computer to supply a complete conference programme for a future period (e.g. for the following morning onward). This would be split into (a) a public programme usually of group and other conventional meetings, for general distribution, and (b) the many private or non-publicized individual or group meetings distributed as messages to the parties concerned. On the basis of feedback one (or more) revised versions of the conference programme would be supplied.

4.4. Allocation routine : The computer program which decides on the best match of people/interests/locations can be made very sophisticated by the use of certain operations research techniques. It Is therefore advisable to treat this routine as a separate unit which may be progressively improved. In the absence of sophisticated techniques, greater reliance must be placed on participant tolerance of less satisfactory proposals. The ultimate challenge with this routine may be expressed by the following :

(a) participant confidence, by interacting with computer proposals, that the computer will be able to design/schedule a more beneficial series of events (given the constraints and possibilities) than is the case with conventional procedures . (b) participant confidence that he will not meet by chance for 5 minutes on the last conference day someone he should have had lenghty discussions with from the first day. (c) interaction and grouping possibilities will be explored and proposed by the computer in order to achieve the optimum number, taking into account any need to extend a  given interaction (There is a certain parallel with scheduling a pattern of elimination matches between many sports teams such that the "capacity" for each to continue to play is exhausted. In a conference it is a question of exhausting the communication capacity or potential such that each has a sense of fulfillment).

4.5. Simultaneous use of facility at different levels :

As noted in 1.1. (above), it may well prove possible for the three levels of the facility (4.1, 4.2, and 4.3) to be used simultaneously, whether by the same participant or by different

Participants. In addition the organizer may specify to what extent 4.2 and 4.3 are allowed to modify any pre-planned program, whether at all or over a given time period.

5. Output

5.1. Participant messages : Processing of 4.1 and 4.2 leads only to message type output (discussed separately). This may take a standard form as a listing of proposals and confirmations.' Or else individual proposals may be converted into standard messages describing the nature of the meeting proposed (e.g. analogous to a formal invitation card but with the zones for handwriting completed by computer).

5.2. Conference programme : Processing of 4.3, to the extent that it affects the formal conference and room allocation, may require a special output format, particularly to indicate sessions in parallel.

Associated with this should be checklists for the organizer and conference secretariat to indicate requirements for : seating, audio-visuals, interpreters, etc.

Such documents should clearly indicate changes made from previous drafts to avoid time-consuming checks to work out "what has been changed".

Annex 9: Mapping input (including feedback), processing and output.

1.1. The purpose of the mapping facility is to provide participants with a graphic presentation of the relationships between the issues under discussion in the conference. The reason for this is that :

(a) the relationships seldom conform to the linear or hierarchical pattern implied by the conventional agenda structure. (b) participants unfamiliar with the topic under discussion at a particular moment or in a particular session need to be able to see how it relates to other issues with which they are more familiar (positioned elsewhere on the same map). This is specially necessary for participants from another culture mho are unfamiliar with the jargon or mind-set of the majority present. (c) in the absence of such a map, the quality of discussion tends to deteriorate or become unfocussed. Speakers and debates effectively "wander" all over the territory so crudely mapped by the unidimensional agenda. A significant portion of the debate in meetings on complex issues is in effect about the nature of the map, although no attempt is made to express it visually. A map can help to stabilize a debate and prevent it becoming polarized, "spastic" or subject to primitive dynamics . (d) frequently a map can make evident "hidden" issues of which the majority of participants are not aware, particularly in terms of their relationship to issues which are under discussion. (e) research has already shown that participants at meetings tend to group themselves in terms of the "mental maps" which they share (see document accompanying this annex). Where several participant groups each have different maps of the same issue territory, communication is clearly impeded. By making such maps explicit, discrepancies can be discussed more objectively.

1.2. As with the arrangements processing, the operation of this facility may be envisaged at different levels. Here however the problem constituted by the more sophisticated levels is mainly one of adequate computer programs and graph plotting devices. These may not be considered an immediate investment priority despite the breakthrough they would represent for conceptual clarity in meetings.

2. Input

2.1. Basic mapping : At this level operation, the aim is to build up the relationships between the topics accumulated in the directory instead of treating them as unrelated. There are two complementary approaches to this :

(a) hierarchical relationships : These are the logical whole/part relationships between topics (e.g. "water pollution" is a part of "environmental problems"). In principle these can be indicated by an adequate topic code design, but in practice this does not work because one topic may be a part of several other topics (e.g. "mater pollution" may also ba a part of "water resources", according to some participants) (b) functional relationships : These are the cause/effect relationships between topics (e.g. "industrialization" aggravates "water pollution")

A simple coding scheme is required to input such information (see example of Yearbook of World Problems in Human Potential). And once input, an identifier is required to delete or modify easily any such relationship.

Such a system of relationships can be integrated with the directory topic code table or held separate from it. If appropriately designed the automatic directory augmentation of topics could be extended to include relationships. In other words, if the message form allowed a user to specific the message topic not simply as "topic A", but rather " topicF aggravation of topic A", then such information could be used to augment the relationship table. Note that, whatever the form, input can be supplied :

(a) before the conference only,or (b) during the conference, depending on how dynamic the organizers wish the mapping to be.

Note that the nation of a "topic" (as discussed elsewhere) can be extended to cover agenda items, participant groups or anything which is a matter of concern.

Note that the organizers may wish to ensure a distinction between (or only permit) those topics and relationships of which they approve.

2.2. Individual mental mapping : With this option the aim is to obtain from individual participants their perception  of the interrelationship between those topics in the conference which are of interest to them. The option above is designed to group such perceptions into a single map. The two options are complementary since the input for this one can also be used to process the previous one.

2.3. Line printer graphics : This option relates mainly to the processing and form of output although it may necessitate a special form of input to modify the output maps.

2.4. Plotted graphics : As for 2.3.

3. Processing and output

3.1. Basic mapping : With this option the aim is simply to list out, appropriately sorted, the topics, and those to which they are related, with an indication of the nature of the relationship. This could well be integrated with any listing of the directory topic table.

In an extended form of this option, participants would indicate by input (or feedback) their approval, disapproval or abstention from any relationships indicated. This would be printed out as the results of an affective vote on each. This would be important where part of the debate involved disagreement on the nature of the map.

A further possibility would be to permit comments or reservations in addition, or as an alternative to, any such voting. The presence of these could be indicated by a reference number to a list of feedback messages about the particular relationship. Again this could prove very important where the debate is about the nature of the map (e.g. whether topic A aggravates topic  B directly or only via topic C or D)

Note that output listed in this form could be given to an inhouse graphics assistant to convert into a suitable visual map presentation. This would tend to be time consuming and costly.

3.2. Individual mental mapping : Input for this option can be used to generate the "vote" indications in the output of the option above. Specific tothis option is the  possibility of clustering the perceptions of participants in order to be able to generate one map for each cluster that shares such a similar perception (see the document that accompanies this annex). This permits a comparison of the implicit mental maps of participant groups and is a powerful indication of probable areas for agreement and disagreement. It is precisely because of the absence of such maps that the predictable nature of many debates is not rendered explicit. With them, debates can move on to a more fruitful level.

Note the value of being able to send a message addressed (on the basis of the relationship reference number) to "all participants who consider that topic A aggravates topic P", whether (a) to tell them how they are misinformed, or (b) to set up a lobby to counter the activities of some coalition with an alternative perspective.

3.3. Line printer graphics : If option 3.4 is not feasible, an attempt may be made to order the relationship information graphically (as horizontal or vertical lines) on one or more computer printout pages. There are several possibilities for this which merit further investigation. Although they cannot be as well-designed as those arising from 3.4, it may be possible to modify them relatively quickly. This could be important to the dynamics of a conference.

3.4. Plotted graphics : The aim here is to use a special graph plotter device to draw maps arising from the network of relationships input. Such devices are of many kinds. In size they may be able to produce maps from 30 cm. in length up to 100 cm. or more ; they may use one colour or many, etc. As with other hardware devices, they may be operated in-house or by an external service bureau.

The main processing problem, which may apply to option 3.3 also, is ordering the network of relationships input into a farm which can be appropriately and clearly laid out on one or more single sheets. This requires further discussion.

Related to this problem is the desirability of being able to produce a single sheet map for distribution to each participant in each meeting session on a given topic. In such a case the topic would be extracted from the mass of other topics and positioned on the page to make clear the nature of its sub-topics and the relationships to other topics (possibly to be discussed in other sessions).

A special problem arises with how or where to indicate the names of features of such maps. One technique being to put the first few/ characters on the map and the whole topic name on an accompanying sheet which serves as an index with a reference number to which people can refer in proposing modifications.

3.5.Meeting overview map : There is a strong case for a conference centre to be able to offer the organizer the possibility of producing a large map of the relationships between the issues touched explicitly or implicitly by the conference. This could be displayed in the foyer as a way of showing the relationship bet- u/een the various meeting sessions. Clearly the conference centre may reach the stage of having sufficient topic/relationship information from previous conferences to be able to generate a better initial map than can the organizer and participants at a particular meeting. This could prove a very attractive and convincing argument of a non-commercial nature, since it gives the conference centre a conceptual relationship to the organizer's substantive interests. Not only does the centre provide the physical environment and the communication environment (with the messaging facility), but also an important feature of the conceptual environment.


Annex 10: Output formats : general approach

1. Although it is desirable to determine output formats for each of the applications (messaging, directory, etc), it is not necessary to limit possibilities to one single style of output. It is preferable, if not essential, to be able to offer several possible styles to the organizer. It is even better to be able, in the case of major conferences, to respond to the organizer's desire for an alternative style of output of his own conception.

2. This approach is quite feasible if funds are available to recompile the output programs using standard "report program generator" software. This allows the organizer to specify what information he wants (from the input fields) in what positions on the output. The conference centre might in fact absorb the costs of this in order to attract the organizer to the centre, particularly since each output format prepared can be added to the tape library to increase the variety offered to future organizers.

3. As with the input formats, this approach avoids the absolute distinction between different styles of output :

  • messaging output form
  • directory output form
  • feedback output form
  • arrangements output form.

The decision to separate or combine data fields on one or more output forms would be up to the organizer, advised by the conference centre. How the forms are "labelled", would be decided at the same time. For example, "feedback output" might be treated as a "message" to all participants.

4. As with the input formats, there may be some constraints on this degree of freedom from a computer viewpoint or in terms of physical handling problems.

5. Note that from a computer viewpoint, output from the computer, in response to a "request message" from a participant for his complete directory profile, may itself be treated as a "message" from the computer to him.


Annex 11: Directory output formats

1. The general approach to output formats in considered separately.

2. Note that the "directory" may be output in any of the following forms :

  • a single computer printout (one copy) for consultation at a message desk or for display on a wall
  • a photoreduced copy for reproduction and distribution
  • either of the former split by participant or other grouping and distributed accordingly.
  • as a tape for input to a special printer to produce a typographical quality output for reproduction as a "printed" directory.

3. The kinds of output format which need to be envisaged include the following :

3.1 participant name and identifier code in alphabetic name order. This  may also include participant title, institution, home address(es), telephone numbers, conference address, nationality, languages, topic interests, group memberships, etc.

3.2 identifier code and participant name in code order. Any of the other information from 3.1 may be included.

3.3 nationality and participant name in alphabetic order of name within nationality. Any of the other information from 3.1 may be included.

3.4 language and participant name in alphabetic order of name within nationality. Any of the other information from 3.1 may be included.

3.5 topic/interests and participant name in alphabetic order of name within topic/interest. Any of the other information from 3.1 may be included. A special problem arises here of the language of the topic/interest text to be used. The same information may be required in several languages. Another possibility is to supply the information in the code order of the topic/interest. This would be valid if the code was designed to group together related topics.

3.6 conference hotel and participant name grouped by hotel. Again any of the other information from 2.1 may be included. This would mainly be useful to the conference secretariat and messaging service.

3.7 participant name and the names of other participants with whom he could usefully make contact, in order of participant name. Other information from 3.1 could be included, specially the topics in which they share an interest.

4. Other kinds of information could be included in the directory such as the following ;

4.1 topic/interest and code number in alphabetic order of topic. This could be combined with 3.5

4.2 participant group and code number in alphabetic order of group. This could be combined with 3.1, however there is a language problem here as in 3.5.

4.3 other coded information in alphabetic order or grouped for convenient consultation. This would be mainly intended to assist those using the message forms. It could well be prepared manually.

5. Note that if a messaging fee system is in operation (discussed separately), it would be very useful to incorporate in the directory, where relevant :

  • the number of people (and language requirements ?) in a code category to whom a message may be sent.
  • the estimated cost of a basic message to that code category (incorporating any cost reductions due to subsidy, as discussed elsewhere).

This style would then resemble that of a direct mail address catalogue, namely costs and numbers per category. This may, or may not, be desirable.


Annex 12: Modularization and systems possibilities

1. Further discussion is required to enable a decision to be taken on the investment implications of how the program is to be designed and split into modules. Specifically it is necessary to determine how the investment in the software can be phased over a period of time in relation to the hardware.

2 . A number of modules are implicit in the various facilities and options proposed. But it is also clear that the file design may render their apparent separation relatively superficial. The "modules" may rather constitute a question of what the organizer wants to use (or permit participants to use) of an extensive range of options.

3. Modules and operations must of course be considered in relation to the nature of processing and output :

(a) batch and with what frequency (b ) online and with what number of terminals.

4. The whole system needs to be carefully considered in terms of the possible future use of terminals at many locations around the conference centre. This would powerfully affect the messaging system since participants would not have to collect hardcopy from any particular point (and the messaging service would not have to deliver the message to that point).

5. The spread of terminals and their relationship to the messaging system would constitute a move towards a computer conferencing system. This is currently being used to link people who are geographically distant and cannot match their time schedules. Use of the technique within a conference centre gives it a "window" to participants and others located away from the conference centre. This can be very important to interaction between participants, contributers, organizers, sponsors and the centre prior to the conference. Conferences are now being :

(a) arranged and prepared by such a technique (b) held with its use to maintain links to participants who could not attend or are responsible for secondary conferences in other locations (c) followed up by contacts maintained with the aid of such a technique.

6. Attention needs to be given to the relationship between :

(a) the computer-based portions of the system (b) the physical handling portions of the system (sorting, checking, reproduction, etc) (c) the physical delivery portions of the system (message delivery, etc) (d) other operations (typing, translating, directory editing, etc).

Annex 13: Reproduction and addressing

The computer processed messages represent the extension of a continuum of messages from the handwritten category, through reports or printed materials which have to distributed. As such it overlaps and meshes with procedures for the reproduction and distribution of documents whether or not there is a computer-based messaging service.

The relationships are clarified in the accompanying table into which could be inserted, for a particular conference, the expected frequency of a particular type of message or whether such a type will be permitted in that conference.

Note that types 2 and 3 also include the conventional typing requi- rements of a conference. Type 3 includes the conventional repro- duction requirements. Types 4 and 5 include the conventional dis- tribution requirements.

The associated delivery questions are discussed separately.


Types of

text /message.

No reproduction(*)

Manually ;

adressed :   (**)

text ;

Address : labels  : thru  : computer:

Text

Manually  : addressed : (**)  :

reproduction(*)

Address labels thru computer

1. (a) Handwritten text (b) ... translation required

.

 

.

 . .

2 . (a) Text to be typed (b) ... translation required

 . . . .

3. (a) Typed text (document) (b) ... translation required

 . . . .

4. (a) Document (reproduction done) (b) ... translation required

 . . . .

5. (a) Brochure (reproduction done) (b) ... translation required

 . . . .

6. (a) Computer-processed text ; uncumulated (indiv.or group)

(b) ... translation required

 . . . .

7 . (a) Computer-processed text ; cumulated by individual

(b) ... translation required

 . . . .

8. (a) Computer-processed text ; cumulated by group

(b) ... translation required

 . . . .

(*) Whether the text is reproduced (by photocopy or offset) in parallel with computer address processing depends on how many copies are required and the relative effeciency of preparing multiple copies by computer (e.g. when few are required and the message is short). Note the text may be reproduced from computer output.

(**) Possibly with assistance at a message desk, or by use of labels previouslyrequested from the system, or by distribution in a meeting room, or "on request" at a message desk, or simply a single copy "on display".


Annex 14: Delivery of output

1.- To participant "address" (who may act as an intermediary "c/o" address for another person) :

(a) conference hotel (b) conference pigeonhole (c) temporary conference location (meeting room, foyer table,etc)

2.- To message desk :

(a) for pickup by a particular participant (b) for pickup by any interested participant "on request" (e.g. in the case of copies of a general message) (c) for consultation only (e.g. a single display copy of a directory listing) (d) for attachment to a wall display (e.g. a feedback analysis)

3.- To a meeting room :

(a) for distribution to all participants (b) for pickup by any interested participants (c) for interpreters (d) for meeting chairman, etc.

4.- To organizer/secretariat :

(a) in case of directory extracts for possible reproduction (b) in case of feedback analyses.

Note that attention must be given to the method of delivery in the case of urgent and/or confidential messages.

A participant may be sent a message saying "there is a confidential message for you at message desk 3". This approach may also be used for packets of documents or for reminders to pickup "the draft report of commission 3 at message desk 2" (or possibly to read the report at the message desk and leave comments).

Thought should be given to the design of address labels, envelopes, etc. For example, should window envelopes be used or should computer printout be such that it can be folded to substitute for an envelope. In any case provision should be made for a code link between the address label and texts separately reproduced.


Annex 15: Confidentiality

1. Special attention needs to be given to this question in the design of the system far if the wrong decisions are taken the usefulness to participants mill be severely reduced.

2. Specific references are made to confidentiality in connection with particular options and these mill not be discussed further.

3. In more general terms the conference centre has to be able to make it clear to participants what kind of confidentiality it is able to offer. This may be stated in comparison with other information services (e.g. post, telephone, etc)

(a) For most purposes a guarantee of confidentiality is not required. It is merely sufficient that the information not be publicized beforehand (e.g. that A is going to have a breakfast meeting with B in hotel X)

(b) In the case of messages exchanged during a meeting, there are different levels of sensitively and the participant must be very clear which level he is using and whether the system can be of any help :

- 1. it does not matter if anyone else sees it at any time - 2. it does not matter if anyone sees it after the meeting - 3. it should not be publicized, but it does not matter if someone sees it - 4. it does matter if it is seen, but if those who see it adopt unscheduled procedures to find out, they merit whatever pain the information causes them (e.g. "the chairman is a fool and should be replaced"). - 5. it does matter if the information is seen, but the risk of leakages to unauthorized persons is as acceptable as the possibility of "bugged" telephone communications. - 6. every effort should be made to avoid leakages, but the possibility that these may by chance occur is an acceptable risk - 7. no risk of leakage is acceptable.

4. It will probably be impossible for the conference centre to guarantee level 7 above and participants should be advised to deliver the message themselves. Clearly participants are free to suspect that someone will attempt to monitor message traffic during or after the conference. The centre must indicate what guarantees they can offer. There may be concern that the conference center is in a position to use the directory profile on each participant held by the computer - if only for subsequent commercial mailings (Or that others may copy the file for such purposes). The centre must state what its policy is on these matters and consider how best to render it credible.

5. Whilst high security communication may be almost impossible, it can only be emphasized that the risk of monitoring is likely to be acceptable to many participants for a high percentage of communications (as it is with the telephone system). But the conference centre should be crystal clear on its own degree of responsibility.


Annex 16: Exhibition

1 . The whole concept discussed in relation to conferences can of course be extended to exhibitions. There are special problems however.

2. Stands : These would constitute both meeting points (analogous to meeting rooms) and events (analogous to meetings). The various coding schemes and input and output documents could be extended to cover them. A special problem is the location of the stands (e.g. Hall a) whether that should be mentioned on output documents.

3. "Participants" : For many exhibitions some categories of participant do not register, they only buy a day ticket. For those who register (such as exhibitions), the messaging system can function. For those who do not, three procedures can be envisaged :

(a) on the basis of exhibitor and stand profiles, temporary participants can be supplied with a list of stands they should visit in the light of their own interests. This is just an extension of the conventional procedure with an exhibition printed programme , (b) as with (a), except that instead of stating interests verbally at an information desk and receiving a pre-printed interest/ stand sheet, the participant specifies his interests on a form which in processed by computer in order to supply him with a stand visit itinerary in the light of his interests. He could fill the form prior to his arrival at the exhibition(e.g. during a parallel conference) so that his itinerary would be available on arrival. If he wished, exhibitors could be informed of his interest so that they would be supplied with appropriate mailing lists. Alternatively an exhibitor could use the presence of an adequate number of participants interested in a particular product in order to send them an invitation (enclosed with the itinerary) to a presentation, cocktail party, etc. set up on the spur of the moment. (c) where appropriate, arrangements could be made for appointements with exhibitors (see Arrangements processing discussed separatsly).

4. Time : The time factor is very important in exhibitions. The dynamics would be considerably facilitated if message exchange was partly based on on-line access to the data base from terminals around the exhibition. This is discussed separately.

Creative Commons License
This work is licenced under a Creative Commons Licence.