[AG-TECH] Human factors and AG

Wenjun Liu wliu at mcs.anl.gov
Thu Aug 29 12:52:23 CDT 2002

So many people have responded to this question (though still not as many as
responses to some of the true AG-TECH questions), it is like a collection of
what we know and care all about human factors and AG, which makes me believe
a systematic treatment of this topic may help a little bit.

(This email is too long to be an email. So I shortened it below for quick
read. Long version is attached behind for interested readers.)

Short version:

"Human Factors" imply cognitive factors that were focuses of traditional
HCI. What we are talking about these days is actually more than cognitive
human factors. Computer-mediated group activities and collaborative work are
what we are interested in and what CSCW is about.

CSCW is not successful so far due to technical and institutional problems.
Technical problem is mainly difficulties to translate thick descriptions
generated by CSCW studies of the sociality of work into practical system
design guidelines. Pattern languages with an emphasis on interactions
between the physical and the social provide a promising solution to this
technical problem. For AG, understanding everyday work practices of AG users
and their physical (technical) requirements is a systematic way to get
involved in HF (for lack of a better term) efforts.

Long version:

1. Human Factors

First all, I guess "Human Factors" is no longer an appropriate term for the
subject we are talking about. It has been 20 years now since the first major
HCI conference was held in 1982 and there are have been dramatic changes in
this field. "Human Factors" more or less means cognitive factors of human
users of computer systems. Its main purpose is to identify those cognitive
factors for better user interface design. With the coming of larger computer
systems that go beyond a workstation, people soon realized that simply
considering cognitive factors is not enough for system design. Other aspects
of human behavior, for example, interaction with other people and artifacts
in a complex technological environment, play an important role in our daily
work practice and should be considered in system design process. This is the
beginning of CSCW, whose main purpose is to better support computer-mediated
group activities, a striking change from emphasis on mere individual
cognition and user interface design.

CSCW has not met with a great deal of success so far. Many CSCW systems do
not cause severe problems; they simply sit there underused. The lack of
successful CSCW systems is due to both technical and institutional problems.
Technically, it's not easy to translate thick descriptions generated by CSCW
studies of the sociality of work into practical system design guidelines.
CSCW-ists find that in the process of translating their detailed accounts
into formal requirements, the richness and significance of their work often
get lost, distorted or misconstrued. On the other hand, designers and
developers, whose job is to implement new technology and redesign work,
often find that it's hard for them to use those lengthy analytic ethnography
found in CSCW. Institutionally, it is easy to get a bunch of engineers and
social scientists temporarily together but hard to benefit from those
fleeting level meetings and hallway conversations. As someone said,
engineers are, by and large, "pleasant and well-mannered people" and social
scientists "occasionally have surprisingly useful things to say". But to
have impact, it has to be embedded in the design process, which is not the
case at this time for most projects. What is more likely to happen in the
near future is to see a few more individual students working at both
graduate and undergraduate level on this area and get their theses done
without leaving many impacts.

The technical difficulties mentioned above are quickly becoming the new
focus of CSCW and efforts in this area are often called bridging the gap
between the social and the technical. There are various solutions offered so
far. Here I would like to introduce one solution that seems promising and
acceptable to both sides: pattern languages.

Before object-oriented programming and design patterns became popular among
computer scientists, pattern languages were already discussed by architects
(especially Christopher Alexander) who were seeking a timeless way to build
towns, villages, and buildings. Pattern languages try to prototype certain
arrangements of building that can be used again and again. Patterns are
grounded in the social, with a focus on interactions between the physical
forms of the built environment and personal and social behavior of the
inhabitants within it. Different patterns are appropriate for different
activities. For example, Street Café is built along a busy path for casual
meeting, people watching, etc. The Flow Through Rooms and Office Connections
are meant for spontaneous interactions with spatial components of the
workplace to accommodate activities and roles. Any given pattern may have
smaller patterns inside and can participate in larger patterns. The whole
idea is very similar to classes and sub-classes in object-oriented
programming but has a strong emphasis on interactions between the physical
and the social.

Pattern languages provide an answer to problems of translating thick
descriptions generated by CSCW studies of the sociality of work into
practical system design guidelines. It is acceptable to social scientists
who want to go beyond mere case studies of specific workplace and generalize
their results for broader use. It endorses the ideal type concept in social
science first used by Max Weber and followed by many. It is useful for
engineers who usually do not have time to digest thick descriptions of the
sociality of work of many CSCW studies. To design a specific computer system
to support certain activities, a pattern of those activities with its social
and physical (technical) requirements should provide a direct guideline for
design. Besides, pattern language sounds more familiar to engineers working
in OOP.

2. AG

Back to AG. Many HF issues raised in AG community are actually technical
problems, for example, node operator and quality of video. With technical
improvements, I believe AG will be node operator-less and quality of video
should make interactions over AG as close to face-to-face interactions as
possible. But certain social problems will still exist even with better
technology, for instance, how will interactions over AG (or "intermediation"
in general) facilitate or inhibit certain activities, for example
collaboration? Pattern languages of workplace and activities within it
should help us better understand what work practices we want to support and
what are their physical and technical requirements. Hence, understanding
everyday work practice of AG users and start working on patterns of
workplace activities of those users seems to me an appropriate way to get
involved in efforts started by HCI and CSCW.


----- Original Message -----
From: "Julia Shiela Mullen" <jsm at WPI.EDU>
To: <ag-tech at mcs.anl.gov>
Sent: Wednesday, August 28, 2002 2:48 PM
Subject: [AG-TECH] Human factors and AG

> Hi -
> We have an undergraduate who is interested in
> human factors and the Access Grid.  At WPI
> we require each student to complete a major
> project which relates technology and society.
> (This project is a graduation requirement.)
> The descriptions and content of such projects
> is fairly flexible.  We are currently at the
> beginning of her project experience so I am
> turning to the AG community for suggestions.
> What is the AG community most interested in
> with regards to 'human factors and the AG'?
> Is there a wish list of studies that folks
> would like to see?   Are there project ideas
> that we just didn't have the manpower for?
> I welcome any and all suggestions - I will
> present them to the student and we will
> see what interests her.
> Thanks for your help on this -
>   Julie
> ------------------------------------------
>   Julia S. Mullen, Ph.D
>   Academic Computing Application Scientist
>   Computing and Communications Center
>   Worcester Polytechnic Institute
>   Worcester, MA
>   phone: 508.831.6054
>   fax:   508.831.5680
>   email: jsm at wpi.edu

More information about the ag-tech mailing list