Piotr Jankowski
Department of Geography, University
of Idaho, Idaho, USA
piotrj@uidaho.edu
Milosz Stasik
Department of Geography, University
of Idaho, Idaho, USA
2.
Design Requirements for the Internet-based SUDSS
The main purpose of designing the Internet-based
SUDSS has been the development of a software prototype for a series of
experiments in space and time distributed collaborative work environment.
Theoretical foundations to guide such empirical research have been laid
in Nyerges and Jankowski (1997). The space and
time distributed environment may provide not only a public exchange forum
during the exploratory stage of the decision making process but also an
alternative venue to community (town) meeting. The possible advantages
of the space and time distributed arrangement for CSDM over the other arrangements
(especially the meeting arrangement) include the flexibility of choosing
the place and time of participation and the increased sense of participation
equality. During the experiments the groups of participants will use the
SUDSS software prototype to work on a real world problem of land use zoning.
The problem is representative of many spatial decision problems combining
the issues of resource management and policy development.
Based on the characteristics of the land use zoning problem and experiment
participants (group members may range from advanced to novices in using
spatial decision support tools and in collaborative problem solving) the
following design requirements were specified:
3.
Design of SUDSS Prototype
In the SUDSS prototype, similar to other decision support systems,
the graphical user interface is the sole access point to communication
with other group members, database, problem exploration tools, modeling
tools, and generated problem solutions. Since it is our intent to create
a simple to use and intuitive user interface, it is important to use publicly
accepted and widely used tools. Communication tools include Hypertext Markup
Language (HTML) documents as well as Simple Mail Transfer Protocol (SMTP)
mail tools supporting Multipurpose Internet Mail Extension (MIME) formats.
In the current prototype users are unable to use other data than those
verified by the server. Also, the access to communication tools is somewhat
limited. The usage of certain words suggesting out-of-subject discussion
results in automatic exclusion from the discussion. The purpose of these
measures is to create a controlled experiment environment.
The interface design considerations
were focused on the fact that predominant users of the SUDSS prototype
are inexperienced in GIS modeling. Moreover, the assumption has been that
some users may even have limited experience with working with the Windows
environment, necessitating simplified interface design. Excess common
elements such as controls, long lists of choices or options, and a nested
hierarchy of windows may be a major obstacle to a new user. The user is
provided with a two-level interface promising a logical, intuitive flow
of system use. At the main-level the user has the ability to control the
activation of more advanced modeless windows of the second level offering
a full set of tools responsible for completing a specific part of the task.
Figure 1 SUDSS
Main-Level Window
All
major tools are assigned to six self-explanatory system functions represented
by the corresponding six buttons (see Figure 1):
file operation, request, communication, explore, evaluate and vote. The
latter three buttons allow the user to work on the project, create problem
solution alternatives, evaluate alternatives proposed by other users, and
finally vote on feasible alternatives. The three buttons top-row
allow the user to participate in collaborative work by providing a means
of expressing opinion (communication button) and changing session constraints
(request button). Users have the ability to increase the time needed to
complete a task by submitting a request to the server (see Figure
2).
An important issue has been
how many and how advanced the second-level controls should be. The guiding
design principle in this regard has been the striving for a balance between
the utmost simplicity and robustness of the SUDSS prototype. The only functions
where a beginner may find help necessary are in the evaluation and exploration
panels. There is a certain minimum of functions that have to be implemented
in the software to assure its functionality. In the case of the exploration
window these are: drawing tools (simple graphical utilities), spatial analysis
tools (implementation of ESRI's Map Objects), and commentary tools (allowing
the attachment of short explanatory notes to the project). Implementation
of simple support tools such as "tool tips", "tips of the day", and help
files allows problems related to SUDSS use to be overcome. "Tool tips"
seem to be an especially beneficial utility. Short notes are able
to provide necessary information without the technical jargon usually associated
with help files.
4.
Architectural Considerations for SUDSS
An important practical question in designing an SUDSS prototype has
been whether to develop a stand-alone tool, independent of World Wide Web
(WWW) browser software (Figure 3, part A) or,
to aim for a wide range of users, creating a tool that can become a part
of existing WWW browser software (Figure 3,
part B). Since the use of WWW browsers has gained public acceptance and
has been growing at an exponential rate (by 341,634% a year according to
the Internet Book Shop) there is a strong rationale to implement an SUDSS
prototype as a part of a popular browser. New technologies including Microsoft
Activex controls make such an implementation relatively easy. There is,
however, a strong argument in favor of developing a stand-alone SUDSS prototype.
A stand-alone software allows all restrictions related to WWW browser
extensions and plug-in modules to be bypassed. It also avoids the unnecessary
software overhead resulting from the need to use browser software. For
these reasons, the implementation of an SUDSS prototype as a WWW browser
plug-in is less attractive at this point than creating a stand-alone software
able to directly utilize capabilities of the TCP/IP protocol.
The stand-alone SUDSS prototype
has the ability to use not only the HTTP protocol (and consequently WWW)
but also uses other protocols such as SMTP and FTP. Choosing TCP/IP as
a network transport protocol opens the access to the Internet and thousands
of servers with millions of potential users. The weakness of the TCP/IP
protocol is its packet-switched architecture and the communication through
Class C network connections (unreliable network service) with high residual
error rate. However, without implementation of multimedia transmission
(especially live) this datagram service is adequate for the needs of the
SUDSS prototype.
Figure 3 Stand-alone
SUDSS prototype (A) vs. SUDSS prototype as WWW plug-in software (B)
One of the most important concerns about the system architecture is data management in respect to the transmission media. The question is whether data should be distributed to users only once (Figure 4, part A) or whether they should be distributed gradually in response to the user's demands (Figure 4, part B). The first option allows the user to freely interact with the entire project database from the beginning, though it is often true that parts of the database are not used at all. This raises a concern about bandwidth and storage conservancy. The second option uses action-aware database management to diminish the amount of data transferred over the network during a collaborative meeting. The intended consequences of this option are the decrease of the server load and also the decrease of the demand on the availability of users' personal storage space.
Figure 4 A simple, one-step database transfer (A) vs. action-aware database management diminishing the amount of data transferred
The
idea behind the action-aware database management is that the user's action
related to specific objects (e.g. map entities) invokes a background request
sent to the server to deliver database records related to these objects.
If the initial check-up indicates that all required records have been already
sent no further action is performed. If an object is used for the first
time, appropriate records are sent over to the user. Although, due
to additional data overhead, the size of data transmitted in this way is
slightly larger than the size of the same data transferred with the entire
database (Figure 4, part A), the action-aware
database management may prove to be a more efficient way of using database
resources. Unfortunately there are several obstacles that restrict implementation
of this concept. Among the most important ones are: server processing time
(time needed to process a query and prepare a set of relevant records),
transfer time of data in the real life situation over a Public Switched
Telephone Network (PSTN) using at best 28000 bps modem, and the need for
an uninterrupted network connection throughout the problem exploration
time. Considering the above, a full data transfer to the user is the solution
implemented in the prototype version of SUDSS.
The implementation of a
timer function is a simple way to keep collaborative work on schedule,
motivated, and effective. Every major step of the experiment project is
going to have some initial time allocated. It is a challenge to the users
to use this time as efficiently as possible. There are two principle design
possibilities to regulate the use of time. Either a timer is hard-coded
into the client software or it is activated, run, reset and stopped from
the server. The first option assigns limited time resources to each task
and does not take into account the dynamics of human-computer interaction.
Even if the user is unable to complete a task within the time limits, there
is no possible way to get additional work time. The timer implementation
is in this solution problem-independent. The latter design is a more attractive
alternative allowing the control over the decision making process
to be left to the user and the server. It allows flexible time allocation,
context-aware response to group needs and the implementation of objective
time management. It is based on the constant monitoring by the server of
users' behavior and their work progress. Such a design assumes, however,
that the user stays on-line throughout the experiment time. Since an experiment
session may last several days, the necessity to stay on-line may be unacceptable
for many users. On the other hand, the lack of timer implementation in
the software may result in a complete lack of synchronization and inability
to continue work with the rest of the group. If the user's computer time
used to control the work process differs from the time on the server this
may result in significant time loss during every step of the task. In the
case of large groups working under distributed time conditions the inability
to adjust time as well as other settings would result in less effective
collaboration. The need for a central time control mechanism allowing to
make such adjustments is obvious. A reasonable solution in this case is
that timer settings are set and checked explicitly from the server and
- if necessary - adjusted during routine data exchange between a client
and the server. Even sporadic, short connections with the server performed
on a timely basis ought to be sufficient to verify accuracy and prevent
any further problems.
Unfortunately, when the
user stays off-line for more than several hours some controls may be disabled
if the timer runs out. At this point the client software will attempt to
establish the connection with the server. If the timer reading on the server
indicates that the user has still time to work on the current task, the
client timer will be reset and controls enabled. If time has run out the
user will be given a chance to continue work on the next task. However,
if the user does not take any action for the time exceeding a given phase
of the experiment the server will remove that person from the access list
in order to keep the group motivated.
The above elements will
be implemented as an 'auto' facilitator function. Since the SUDSS prototype
is designed to provide time-space distributed collaborative work capabilities,
it is likely that human control over the experiment will be limited. It
is then our goal to allow the server to control actions at any given step
of the process.
5. Conclusion
The idea of GIS empowering communities to participate in decision
making about community pertinent problems has stimulated a number of interesting
research issues. One of them is how groups of people, comprised of the
diverse community members, can collaborate outside the confines of the
traditional public meeting environment to better understand and consequently
propose feasible solution alternatives to a land use zoning problem. We
will study this issue through a controlled experiment with groups of participants
collaborating over the Internet in a time and space distributed computing
environment. The participants will use a prototype of a spatial understanding
and decision support system designed for the use on the Internet. The prototype
provides tools for communication among group members, database access,
problem exploration, spatial modeling, and the evaluation of proposed solution
alternatives. The effectiveness of the prototype design will be tested
and assessed in the course of the experiment.
Armstrong, M.P., Densham, P.J., Kemp, K. (1996) Report from the Specialist Meeting on Collaborative Spatial Decision Making, Initiative 17, National Center for Geographic Information Analysis, UC Santa Barbara, September 17-21, 1995.
Couclelis, H., Monmonier, M. (1995) Using SUSS to resolve NIMBY: How Spatial Understanding Support System can help with the "not in my back yard" syndrome, Geographical Systems, 2, 83-101.
DeSanctis, G. (1993) Confronting environmental dilemmas through group decision support systems, The Environmental Professional, 15, 207-218.
Nyerges, T., Jankowski, P. (1997) Framing GIS-supported Collaborative Decision Making: Enhanced Adoptive Structuration Theory, Geographical Systems, in press.
Jankowski, P., Nyerges, T.L., Smith, A., Moore, T.J., Horvath, E. (1997) Spatial Group Choice: A SDSS tool for collaborative spatial decision making, International Journal of Geographical Information Systems, in press.
Sclove, R.E. (1996) Town Meetings on Technology. Technology Review, July 1996: 25-31
Silver, M.S. (1991) Systems that support decision makers: description and analysis. New York: John Wiley.
The Internet Book Shop at: http://www.bookshop.co.uk/69656999/INFOPACK/growth.htm.
JGIDA
vol.1, no.1 
JGIDA
Home
