Subject: Thoughts on Community Access Systems, Part 3: Tasks

From: Frank Hecker <[email-masked]>
Date: Sun, 27 Sep 1992 19:25:17 -0700

Thus far we have envisioned a community access computer system as
providing a way for participants to come together as equals, each in
their own way, to enrich the public life of their community.  This
paper looks at the types of things that people might want to do in
such a system.

We start with two qualities that every task should have, one important
to the participant and one to the system.  (Here I use the word
"system" broadly, to mean not only the computer hardware and software
but also the people involved with it, including its sponsors and
administrators.)

>From a participant's point of view it is important that each task they
undertake be completed successfully, with a proper resolution and
sense of closure.  This means more than just that system operations be
carried out without error; the issue is that the system operations
possible may not exactly reflect what the participant actually wishes
to do, and thus an operation may complete successfully without the
participant's intent being carried out.

For example, suppose that a person wishes to obtain and read a book
from their local library.  They go to the library, find the book on
the shelf (assuming it's there), check it out, and go home with it.
At that point their initial goal has been achieved, and the task
completed to their satisfaction.

On the other hand, suppose that the book is not present but can be
found in another library somewhere, so that it must be specially
requested as an inter-library loan and sent to this library.  In this
case even though the system might have successfully completed its
operations (e.g., finding the book and initiating a loan request), the
person's task is left uncomplete and additional actions are still
required on their part, i.e., to come back to the library when the
book arrives and check it out.

It would be possible to partially remedy this deficiency by, e.g.,
enhancing the system so that when requesting a book the person could
have it sent directly to their home via overnight delivery (e.g., by
charging this service to a credit card).  Then even though the person
wouldn't yet have the book, still they would have completed all the
actions they need to take, so that the task from their point of view
would be essentially complete.

Turning now to the system's point of view, given that we wish to
promote as much participation as possible it is important that
completion of one task should in turn encourage the participant to
begin additional tasks, with each completed task linking to the next.
These other tasks might be repetitions of the original task or might
be new related or unrelated tasks.

Returning to the example above, once the person finishes reading the
book they go back to the library to return it.  This in turn puts them
in a situation where they are likely to find additional books that
they wish to check out, thus beginning the cycle again and increasing
their participation in the library system.

On the other hand, suppose that the library could print out a
brand-new copy of a book for each person requesting it, which the
person could keep or discard when they finished reading.  As with the
original example, this would satisfy the person's basic goal to get
and read the book; in fact, it might even be a better outcome since
they would not have to worry about returning the book.  However in one
sense it would be an inferior solution from the library's point of
view, since it would eliminate one factor encouraging people to visit
libraries.

In the original example I claimed that a library system should not
force a person to return to the library to pick up a requested book.
Why is it "bad" to have the person come back to the library in that
case, and "good" in this case?  Because the return visit to pick up a
book occurs at an unnatural point in the cycle of tasks: the person is
less likely to check out a new book when they have just received the
one they originally wanted.  Thus the benefits to the library of
having them visit are small relative to the inconvenience suffered by
the person.

In designing a community access system we therefore need to pursue
these twin aims of ensuring that participants' tasks be completed to
their satisfaction and that each completed task lead to another being
started, balancing one goal against the other when they are in
conflict.

At this point it's appropriate to try and categorize the particular
types of tasks that participants in a community access system might
want to undertake.  For now I'll be discussing these at a rather
abstract level.

Given that the essence of a community access system is participation,
it seems natural to characterize tasks according to how many people
participate in them, starting with tasks in which only one person
participates.  There are at least two general types of tasks here,
which I will call online grazing and document creation.  (Better
shorthand names are welcome; I'm not totally happy with any of those
I've used.)

By online grazing I mean a relatively undirected activity in which a
person moves through the system looking at new items, reading
documents that interest them, browsing through indices, trying out new
operations, etc.  In contrast document creation is more directed; the
person is trying to create some type of work, be it small or large.

The next group of tasks are those that are primarily one-to-one, one
person participating with another; this group includes such things as
having a conversation, one-on-one assistance or instruction, and
debate or argument, distinguished roughly as follows:  Conversation
assumes status equality between participants, with increased
interpersonal connection the goal.  Instruction assumes status
inequality (i.e., teacher-student) between participants, with learning
the goal.  Debate assumes a contested and fluid relative status
between participants, with enhanced status the goal.  (Thus debate
often includes the presence of an audience which does not participate
directly but can judge status claims.)

Tasks which can be one-to-many include asking questions, requesting
actions, and information sharing or publication.  Asking questions
involves one person asking for information (which may be a matter of
fact or of judgement), where that information may be supplied by any
of a number of different people.  On the other hand, when a person
requests an action to be performed typically only one or at most a
few people can perform that action, but the person making the request
has limited prior knowledge as to who to ask.  Information sharing
means one person disseminating information (which may be an entire
created work) for use, appreciation, or comments by others.

Finally, many-to-many tasks are those in which several people can
participate as roughly equal partners.  Common types include
collaboration and joint exercises, which I distinguish on the basis of
goals: the point of collaboration is to produce a created work (e.g.,
a document), while the goal of a joint exercise is to effect some
outcome.  Examples of joint exercises are voting and multi-person
simulation "games" (which are often not games per se but a way of
learning about complex systems and exploring possible solutions to
problems).

The next set of papers in this series will attempt to further
characterize these tasks and to explore how a community access system
might be designed to facilitate their completion, keeping in mind the
desired principles of task closure and linkage discussed above.

-- 
Frank Hecker
[email-masked]