SOLVING INFORMATION OVERLOAD WITH CONFERENCE SUMMARIES
by Bob Sprigge


For practical reasons, we have developed ways to deliver
information initially in the form of SUMMARIES with the option
to delve behind for details only if required.

This article suggests that the idea of summaries is lacking from
most conferencing systems and ought to be included in future
ones. Summaries will assist in the information overload or
communication indigestion in that less will need to be read to
learn the same.

Structure of storage of items in conferencing systems is
critical. Here we are not discussing the format of individual
items but how items relate to each other from the users'
viewpoint.

In interpersonal messaging (electronic mail), messages can be
joined by using REPLY or FORWARD, etc. In conferencing, items
are usually related in a chronological order and sometimes in a
tree structure. They can also be organized by topic. On EIES,
for example, an individual can set up a "Notebook" which has
items related by page numbers and the user can set aside certain
ranges of pages for particular aspects of the topic.

The term "structure" is used here to mean structure imposed or
encouraged by the system. There is also the possibility of
secondary relationships created by users using cross referencing
techniques. A system could use a rigid imposed structure, none
at all, or anything in between.

Here I propose that:

1. The concept of structures of item relationships covers the
many different requirements currently known as conferencing.

2. There is no structure suitable for all situations.

3. Every situation has several optimum structures or combination
of structures.

4. One of the optimum structures for an information sharing
conference is the one described below as the SUMMARY AND
WORKSHOP STRUCTURE.

There are conferences which plan events, conferences which seek
to share information, conferences for research and development
of a product, conferences for running a business, and they do
not share the need for the same structure.

The summary and workshop structure can be best described with a
diagram, but words will have to convey the idea here.

First, take the viewpoint of someone joining an existing
conference. They wish to catch up with the discussion and read
everything but this is impractical due to the number of items.
So they need summaries along the way. Now take the viewpoint of
a user of a conference organized on purely chronological lines.
They want to add a new topic to an existing hotly-debated single
topic. Then look at how fragmented a tree-structured conference
can become unless carefully pruned. This is the problem that
the summary and workshop structure is meant to solve.

This structure consists of the "main line" and "workshops".

The only items which appear in the main line of the conference
are the proposals for workshops and subsequent summaries. The
Moderator keeps any item which should be a workshop item off the
main line. Workshops may report back once with a summary, some
with several summaries and many with none. Summaries are made
by the members of the workshop as and when they see fit, but
with the possible advice of the Moderator.

Members of a workshop may not agree on a summary and so a
minority report may also appear appended to the summary. One of
the many advantages of this type of structure is the reduction
in communication (or information) overload. A member of a
conference only reads the proposals for workshops and the
summaries and joins only those workshops of interest.

Occasionally a workshop would split into two to discuss
different aspects of a topic--some members might take part in
both workshops. There would be nothing to prevent two
conferences sharing a workshop which may or may not start or
finish at the same time and would probably have different
summaries, each suitable for its own conference.

This structure is designed for particular types of conferences,
and would be highly unsuitable for other applications which need
a structure or combination of structures designed specifically
for their purposes. Such designing is required for many other
forms of non-synchronous information exchange.

Let us hope that we can design near optimum structures for each
requirement. Please let me know if you can suggest other words
to replace "structures" and "workshops".

-----

Author's Note: Bob Sprigge has been networking from England for
some time and is part of NETREACH there. He is currently
logging on from Luxembourg where he is an Informaticien for the
European Economic Commission.