"The real question before us lies here: do these instruments
further life and enhance its values, or not?" - Mumford (1934)
p. 318
ABSTRACT
Computers have become an integral part of our everyday
lives. Banks, airlines, motor vehicle administrations, police
departments, Social Security, and the Internal Revenue Service
all depend on computers. From their introduction, people have
questioned the impact computers will have on society. We believe
it is our responsibility as system designers to achieve organizational
goals while serving human needs and protecting individual rights.
The proposed Social Impact Statements (Shneiderman, 1990) would
identify the impacts of information systems on direct and indirect
users, who may be employees or the public. This paper proposes
a framework for implementing Social Impact Statements for federal
and local government agencies and regulated industries, with optional
participation by the other privately held corporations. A Social
Impact Statement should describe the new system and its benefits,
acknowledge concerns and potential barriers, outline the development
process, and address fundamental principles. Examples from our
work with the Maryland Department of Juvenile Justice are offered.
KEYWORDS: Social impact,
Public participation, Design
INTRODUCTION
From its inception, people have been pondering the
impact computers will have on society and on the image individuals
have of themselves (Wiener, 1954; Sterling, 1974). Many analysts
believe the social repercussions of computers may be as potent
as those of the automobile and the telephone (Kling, 1980; Dunlop
& Kling, 1991; Huff & Finholt, 1994).
Information systems are increasingly required to
manage the government, utilities, and public services that citizens
in modern societies have come to expect. But many critics have
pointed out the negative effects of modern technologies: "technological
evolution is leading to something new: a worldwide interlocked
monolithic, technical-political web of unprecedented negative
implications. And it is surely creating terrible and possibly
catastrophic impacts on the earth" (Mander, 1991).
This negative view does not help in shaping more
effective technology or preventing damage from technology failures.
Constructive criticism and guidelines for design could be helpful
in reversing the long history of disruptions in telephone, banking,
or charge card systems, dissatisfaction with privacy protection
or incorrect credit histories, dislocation through deskilling
or layoffs, and deaths from flawed medical instruments. While
guarantees of perfection are not possible, we believe that policies
and processes can be developed that will more often lead to satisfying
outcomes.
This hopeful stance was part of a larger argument
about taking responsibility for shaping the future (Shneiderman,
1990). The Declaration of Responsibility stated that: "We,
the researchers, designers, managers, implementers, testers, and
trainers of user interfaces and information systems, recognize
the powerful influence of our science and technology. Therefore
we commit ourselves to studying ways to enable users to accomplish
their personal and organizational goals while pursuing higher
societal goals and serving human needs."
The second part of the Declaration proposed writing
a Social Impact Statement (SIS), similar to an Environmental Impact
Statement (Battle, Fischman, & Squillace, 1994). The goal
is a high quality system whose design is discussed early and widely,
thereby uncovering concerns and enabling stakeholders to openly
state their positions. Such open discussions might improve quality
which should lead to increased system acceptance. Of course there
is the danger that these discussions will elevate fears or force
designers to make unreasonable compromises, but these risks seem
reasonable in a well-managed organization. The practicality of
writing SISs was addressed by Huff (1995) who used them as a teaching
tool.
This paper focuses on SISs as a tool to engage public
participation in information technology design. First, we outline
a framework for implementing a SIS:
1. Preparation
2. Evaluation
3. Enforcement
and then present a list of Social Impact Issues:
1. Describe the new system and its benefits.
1.1 Convey the high level goals of the new system.
1.2 Define the stakeholders.
1.3 Identify specific benefits.
2. Acknowledge concerns and potential barriers.
2.1 Anticipate changes in job functions and potential layoffs.
2.2 Address security and privacy issues.
2.3 Avoid potential biases.
2.4 Recognize needs for more staff, training, and hardware.
2.5 Propose plan for backups of data and equipment.
3. Outline the development process.
3.1 Present an estimated project schedule.
3.2 Propose process for making decisions.
3.3 Discuss expectations of how stakeholders will be involved.
3.4 Outline plan for migrating to the new system.
3.5 Describe plan for measuring the success of
the new system.
4. Address fundamental principles.
4.1 Weigh individual rights vs. societal benefits.
4.2 Assess trade-offs between centralization and decentralization.
4.3 Preserve democratic principles.
4.4 Ensure diverse access.
4.5 Promote simplicity and preserve what works.
FRAMEWORK
We propose a three stage framework for implementing
a SIS. First, the SIS is prepared by system designers within the
organization (or contracted by the organization), then presented
to the stakeholders and the appropriate review panel for evaluation.
Once approved, it must be enforced. Our goals are to encourage
maximum participation in the review process by structuring the
document, limiting its size, and controlling its complexity.
1. Preparation
The SIS should be produced early enough in the development
process to influence the project schedule, system requirements,
and the budget. It should be developed by the system design team
which may include end users, managers, internal or external software
developers, and possibly clients. Even for complex systems, the
SIS should be of a size and complexity that it is understandable
by users with relevant background. Some practical alternatives
are to focus on those issues that seem the most dangerous or those
that seem key to the system's success.
2. Evaluation
After the SIS is written, it is evaluated by the
appropriate review panel plus management, other designers, end
users, and anyone else who will be impacted by the proposed system.
Potential review panels include federal government units (e.g.
General Accounting Organization, Office Personnel Management),
state legislatures, regulatory agencies (e.g. SEC, FAA, FCC),
professional societies, and labor unions (Table 1).
| Organization | Review Panel |
| Government agencies
(e.g. IRS, Social Security) | Inspector general, GAO, OPM |
| State government agencies
(e.g. motor vehicles, courts) | State legislative bodies |
| Public utilities
(e.g. phone, electricity) | Review boards |
| Regulated industries
(e.g. banking, airlines) | Regulatory agencies
(e.g. SEC, FAA, FCC) |
| Commercial industry (optional)
(e.g. Microsoft, IBM) | Board of directors, management |
| Research groups (optional)
(e.g. universities, R&D labs) | Professional organizations
(e.g. ACM, IEEE) |
Table 1. Organizations and appropriate Review Panels
The review panel would receive the written report,
hold public hearings, and request modifications. A group of knowledgeable
authorities might be assembled for consultation. Private citizen
groups would also be given the opportunity to present their concerns
and suggest alternatives (Wurth, 1992).
3. Enforcement
Once the SIS is adopted, it must be enforced. A SIS
serves to document the "intentions" of the new system
and the stakeholders need to see those "intentions"
backed up by actions. Typically, the review panel is the proper
authority for enforcement. There needs to be a recognized cost
to the organization for not adhering to the SIS.
DEPARTMENT OF JUVENILE JUSTICE
We are working with the Maryland Department of Juvenile
Justice (DJJ) on redesigning their information system, ISYS (Information
System for Youth Services). ISYS is a terminal-based system used
by approximately 600 workers to support the processing of 50,000
juvenile case referrals per year. The next generation system,
NISYS, will run on PCs in a windows environment.
The NISYS redesign effort has raised several social
impact issues. Who should be allowed to see a juvenile's case
history? How will the handling of the youths be effected? How
will jobs be changed? As the user interface designers, it has
been our responsibility to consider the impact of our designs
on DJJ, the citizens of Maryland, and the youthÕs served.
The executive staff of DJJ will be responsible for reviewing and
accepting our designs, and finally for enforcing them. By offering
examples related to our work, we hope to inspire others to consider
the impacts of their designs.
SOCIAL IMPACT ISSUES
A SIS should discuss the effects a new system will
have both within the organization and on society at large:
describe the new system and its benefits,
acknowledge concerns and potential barriers,
outline the development process, and
address fundamental principles.
We recognize that the issues discussed are not complete,
rather they are meant to prompt insightful dialogue about the
contents. It is difficult, if not impossible, to enumerate all
of the potential impacts a new system. To help in this effort,
Markus (1984) defines a framework that identifies the potential
impacts that different kinds of systems are likely to have.
1. Describe the new system and its benefits.
A SIS should begin by describing the proposed system
and its goals. This includes identifying who will be impacted
and specifying the benefits they will receive.
1.1 Convey the high level goals of the new system.
In order to be effective evaluators, stakeholders
need to understand the purpose of the new system. A brief system
description should be provided and the goals should be enumerated.
The goals may range from reducing costs to improving worker morale
to meeting new legislative requirements.
DJJ: The next generation
ISYS, NISYS, will be an integrated software system designed to
support juvenile case tracking for DJJ operations. The primary
goal is to increase the availability of staff to serve the youths
and their families by reducing the time that front-line workers
spend on administrative tasks, improving the quality of decisions,
and the timeliness and accuracy of the data. A secondary goal
is to improve the communication of DJJ personnel across divisions.
1.2 Define the stakeholders.
A stakeholder is anyone who will be affected, directly
or indirectly, by the new system like the end users, the software
staff, and the organization's clients. Those interacting directly
with the system are considered primary stakeholders; secondary
stakeholders interact indirectly. A motor vehicle licensing officer
using a computer system is considered a primary stakeholder while
the driver applicant is a secondary stakeholder. This classification
does not reflect the degree to which the stakeholder is impacted.
For example, incorrect information might cause the applicant's
license request to be rejected. Explicitly defining the stakeholders
alerts designers to unanticipated impacts which may be biased
towards certain stakeholders (Friedman & Nissenbaum, 1995).
DJJ: For NISYS, the primary
stakeholders include the DJJ personnel who will use the system,
such as the case managers and supervisors, and the MIS staff that
will support the new system. The secondary stakeholders include
the youths and their families, the victims, other state agencies,
and the citizens of Maryland. The information contained in NISYS
will directly influence how DJJ interacts with the youths.
1.3 Identify specific benefits.
"A critical factor for successful implementation
of any innovation is that its benefits be construed as benefits
by the potential adopters (Kaplan, 1994)." The benefits may
include reduced costs, faster performance, shorter learning times,
reduced errors, and increased user satisfaction and they differ
by stakeholder. For example, an organization may be interested
in reducing costs while employees may be more interested in reducing
the workload. In order to motivate all stakeholders, the potential
benefits for each must be described. The "benefits to the
organization as a whole may not be sufficient motivation (Kaplan,
1994)."
DJJ: As an organization,
DJJ will benefit from NISYS's ability to gather the data needed
to obtain funding from the state and federal legislation in a
timely fashion. NISYS will reduce the time front-line workers
spend on administrative tasks by automatically generating required
letters and reports. Most importantly NISYS will allow workers
to focus more of their time and attention to working with the
youths and their families in an attempt to reduce the rate of
recidivism in Maryland.
2. Acknowledge concerns and potential barriers.
Identifying potential problems and concerns early
in the development process allows an organization to manage them
more effectively and minimize harmful rumors. Open and honest
discussion about these problems benefits all stakeholders.
2.1 Anticipate changes in job functions and potential
layoffs.
Change is a major cause of stress because it causes
uncertainty. Using the SIS to describe anticipated changes can
help reduce speculation and fear plus it allows an organization
to manage them proactively (Kaplan, 1994). Stakeholders are most
concerned with negative impacts such as layoffs, demotions, decreased
skill requirements, and potential health problems. However, not
all change is bad. Some positive changes may include enlarged
job roles, new employment opportunities, increased wages, and
flexible working arrangements (Ralls, 1994). It is hard to guess
how some changes will impact an organization. Marcus (1984) discusses
how changes in work flow can affect communication, socialization
(involvement vs. isolation), and loyalties.
Today, job security is a major concern. When considering
layoffs, organizations should weigh the consequences both to society
and to individuals. Sterling (1974) points out that the cost of
finding employment for those laid off is met by society not the
organization and there is no way to measure the loss to individuals
who are forced into less satisfactory employment. Iacono and Kling
(1991) illustrates this point with the example of long distance
operators whose jobs became less satisfying because their jobs
became more automated and required less skill.
DJJ: In several offices,
case referrals are being entered into ISYS by clerical staff.
The NISYS design team is investigating techniques for facilitating
electronic data entry. Some possibilities include scanning in
the case referrals or having the police departments transfer them
electronically. Both these techniques would drastically reduce
the role of the clerical staff, who might be trained as case workers
or as administrative assistants.
2.2 Address security and privacy issues.
Before computers, it was easier to physically lock
away and secure information. Today, information can be collected
and misused without ever violating physical barriers (Ladd, 1991).
There are several measures that can be taken to secure electronic
data including isolating computers (no network access), isolating
networks (no internet access), requiring passwords, encryption
protection, and monitoring logins. The method chosen should be
appropriate to the criticality and confidentiality of the data.
Information systems should only collect the data
needed. To apply for a driver's license, an applicant should not
have to provide their annual income. Storage space has become
increasingly affordable so more organizations are maintaining
huge databases, often containing irrelevant information. An organization's
desire to collect data about its clients or employees may be in
conflict with an individual's right to privacy. One compromise
is to store aggregate data (e.g. average number of logins per
day for all employees) rather than individual data (e.g. number
of times John logged into system).
A conflicting issue is accountability. Users should
be responsible for their actions. The question is how to do this
without violating their privacy. One approach is to keep a log
of changes and when they were made so authorship is not as important.
A user's identity would only be recorded for critical functions,
like deleting a record.
DJJ: Since the juvenile
data, especially the medical information, is confidential, there
is an ongoing discussion of whether or not NISYS should be connected
to outside networks. DJJ is trying to decide whether or not the
benefits of network access outweigh the potential security risk.
Another discussion is about what information should be recorded
for each youth. The information necessary depends primarily on
how the case is handled. If a youth is never placed in a DJJ facility,
does medical information need to be collected?
2.3 Avoid potential biases.
Most system designs contain biases, both intentional
and unintentional, but well-designed systems can limit these biases
(Friedman and Nissenbaum, 1995). Functionality may be biased toward
select groups of stakeholders, certain data may foster biased
judgments, and some display techniques may encourage hasty decisions.
For instance, an airlines reservations systems showed clear bias
by always putting one airline's flights first. Unfortunately,
it is not possible to avoid all biases, but thoughtful designs
can minimize them.
DJJ: There are several
sources of potential bias with respect to how a youth is treated.
For example, who should know if a youth is HIV positive? The medical
staff needs to know to treat the youth but do the cases workers
need to know? Should the victim that was attacked be told? Also,
what should happen to cases that are found not guilty? Should
they still appear on the youth's record? If so, aren't they a
source of bias? Also, the youth records naturally focus on negative
behavior, but shouldn't equal attention be given to positive behavior
(e.g., getting a job or staying drug free)?
2.4 Recognize needs for more staff, training,
and hardware.
A successful system requires more than functioning
software. Additional software staff may be needed, users may require
formal training, and more hardware may be required to provide
adequate access. Inadequate training and education are typical
reasons new systems do not achieve their potential. ÒManagers
in too many organizations still perceive people and technology
as substitutes, rather than complements. They invest in technology,
but too often neglect to invest in the people who operate and
use the technology (Ralls, 1994)."
DJJ: The failure of ISYS
is due in large part to the lack of machines and inadequate training.
For NISYS, DJJ is planning on significantly increasing the number
of machines. Additional MIS staff may be required to handle the
increase maintenance responsibilities. Formal training is another
key especially since NISYS is expected to run in a windows environment
and most DJJ employees have little experience, if any, in a windows
environment.
2.5 Propose plan for backups of data and equipment.
Unfortunately, all systems have the potential to
fail. These failures can cause loss of business and productivity
or possibly catastrophes resulting in loss of life. Organizations
have the moral responsibility to take the steps necessary to minimize
the impact these failures have on individuals and on society in
general. A standard practice to protect data is to back it up
periodically. For critical systems, like air traffic control systems,
a backup system should be in place.
DJJ: Procedures to perform
routine backups to protect against data loss will be needed. In
case of a long term failure, DJJ should also have a backup paper
system in place so case processing can continue. A youth's processing
should continue even when the system fails.
3. Outline the development process.
The development process can have a significant impact
on an organization. Work routines are disturbed, critical decisions
need to be made, and training may be required. Outlining the process
allows everyone involved to anticipate disruptions and plan accordingly.
3.1 Present an estimated project schedule.
The project schedule should outline the basic development
stages, such as requirements generation, design, and implementation,
and estimate how long each will take. The idea is to provide the
stakeholders with a rough idea of what to expect and when. Keeping
the stakeholders abreast of what is happening enhances their satisfaction
with the entire process.
DJJ: The NISYS project
is currently in the requirements generation and early design phase.
The Request for Proposals (RFP) is scheduled to be ready by July
1, 1996. Once a contract is awarded, it is anticipated that it
will be two years until initial product roll out.
3.2 Propose process for making decisions.
A component of any development process is making
decisions. Hardware needs to be chosen, functionality needs to
be decided on, and the user interface needs to be designed. A
SIS should outline the process for obtaining input and making
decisions. Assuming a democratic process, each stakeholder would
be given a vote. In some cases, an executive review committee
might be a more practical alternative. In any case, the process
should include informing the stakeholders about the resulting
decisions including the motivation behind these decisions and
the reason for rejecting proposed alternatives.
DJJ: Final decisions about
the NISYS design will be made by upper management with input from
their staff. It will the University of Maryland's responsibility
to present alternative designs and perform usability tests where
appropriate.
3.3 Discuss expectations of how stakeholders will
be involved.
Each stakeholder is interested in what is expected
of them personally. Their involvement might consist of filling
out questionnaires, participating in usability studies, and receiving
training. Or, it might consist of procuring hardware, writing
contracts, and analyzing user feedback. The SIS should explain
what is expected and whether participation is voluntary or mandatory.
If participation is voluntary, explain how volunteers will be
chosen. All stakeholders should be given the opportunity to participate
in the development process. Active participants will probably
be more satisfied with the resulting system than those who are
not.
DJJ: Users will be encouraged
to be active participants in the design process. Specifically,
users will be asked to fill out questionnaires, participate in
interviews, review user interface designs, and produce process
maps.
3.4 Outline plan for migrating to the new system.
Migrating to the new system requires careful planning.
Users may require training, the software staff may need to perform
backups, and hardware may need to be installed. An evolutionary
approach of smaller more manageable steps is preferable to the
"flip the switch" approach (Kaplan, 1994). A backup
plan should be in place in case the new system fails during migration
or the transition takes longer than anticipated. Another issue
to consider is how long the old system and the new system will
overlap because the work load during this period will be increased.
DJJ: In order to familiarize
their employees with graphical window environments, DJJ plans
to provide courses in PC applications, such as word processors
and spreadsheets. A training lab is currently under development.
Formal training for NISYS will also be provided. Ideally, some
PCs would be deployed early so users could begin integrating them
into their work life. Unfortunately, state procurement practices
may make this difficult.
3.5 Describe plan for measuring the success of
the new system.
Often times, stakeholders are left wondering if the
system goals were ever achieved. The success or failure of the
system to meet specific goals should be conveyed to the stakeholders
along with the plan for correcting any shortcomings. Specific
goals, like reduce the amount of paper used by ten percent, can
be measured over time. More subjective goals like, improve user
satisfaction, can be evaluated by administering questionnaires.
DJJ: The Questionnaire
for User Interaction Satisfaction (QUIS) (Chin, Diehl, & Norman,
1988), was administered to 332 employees to measure user satisfaction
with ISYS. Using this as a benchmark, the QUIS could be readministered
to measure the success of NISYS.
4. Address fundamental principles.
As we continue to develop systems on the forefront
of technology, we must strive to serve human needs by addressing
fundamental principles.
4.1 Weigh individual rights vs. societal benefits.
There are times during system design when individual
rights conflict with societal benefits. When developing new technologies,
it is the obligation of the SIS authors to weigh alternatives,
for example, it was recently decided that tax records could be
searched to locate individuals who refused to pay child support.
DJJ: While a youth's record
is confidential, case workers are entitled to know if the youth
they are dealing with has a violent history, but should future
school teachers, neighbors, or employers be entitled to this information?
4.2 Assess trade-offs between centralization and
decentralization.
Centralization vs. decentralization is a long running
debate about whether computer systems will result in decisions
being made by a few select people (centralization) or by broader
more diverse groups (decentralization) (George & King, 1991).
For example, a decentralized system gives more control to the
end users, while a centralized system ensures consistent policies.
However, with control also comes responsibility which needs to
be delegated. For example, will end users be responsible for backing
up their personal data or will additional software staff be hired
to do this? A SIS should assess the trade-offs and choose the
approach that best suits the needs of the organization and society.
DJJ: Internally, DJJ is
wrestling with the desire to empower their workers by giving them
more control (e.g., letting them create their own customized reports,
etc.) without burdening them with additional responsibility (e.g.
data backups). Another question is if NISYS automatically generates
reports who should be responsible for requesting that function.
Should workers continue to generate the reports and forward them
to their supervisors or should the supervisors simply generate
the reports themselves?
4.3 Preserve democratic principles.
Successful system design depends, in part, on active
user participation and unless users are given a vote, it can be
difficult to motivate them to participate. Giving users a "vote"
requires management to relinquish some control. This does not
mean that users should be given full control over the system design.
For example, management may give users control over certain system
aspects but within a budget they define. While the ideal may be
a democracy, the hierarchical nature of many organizations makes
this difficult.
4.4 Ensure diverse access.
It is very common to see the phrase "Equal Opportunity
Employer" on job announcements. Unfortunately, very few systems
provide equal access. Ideally, systems should be designed to meet
everyone's needs: young, old, handicapped, rural, foreign, etc.
While it may not be practical to design systems that accommodate
everyone, this should not excuse designers from considering alternative
designs that satisfy wider audiences. A SIS should outline an
organization's policy on ensuring equal opportunity and define
the intended users of the system. In some cases, an organization
may choose to provide alternative systems to ensure diverse access.
DJJ: Within DJJ there
is an employee with impaired vision and another with impaired
motor coordination. While NISYS will not directly incorporate
functionality to accommodate these individuals, different input
devices will be investigated, time permitting.
4.5 Promote simplicity and preserve what works.
Designers should be careful not to overlook simple
solutions. Today, with technology advancing rapidly, we often
get carried away with integrating the latest breakthroughs into
our system designs. It is important recognize when certain technology
works and when it does not. If organizations have devised good
ways of handling their needs, then incorporate them into the new
system. Designers should acknowledge and preserve what works,
not reinvent solutions.
DJJ: One of the design
goals of NISYS is that it is not so complex that users have to
constantly refer to technical manuals and look up obscure codes.
The basic functionality of ISYS is a good starting point for
NISYS (e.g., add a case, add a placement, add a review, etc.).
Currently, many factors, such as the user interface and accessibility
problems, make it difficult to perform these functions, but these
functions still reflect DJJÕs needs.
CONCLUSION
In 1974, Sterling recognized that "systems will
not become humanized on their own without the conscious effort
of concerned citizens.Ó Incorporating SISs into the development
process would be one step toward achieving that goal. In our society,
success is too often measured in terms of immediate costs: ÒThe
utility of humanizing procedures is not apparent from cost/benefit
calculations but arises from the point of view of quality of life
- not only of our own but also of future generations who will
be saddled with the systems which are designed and implemented
today (Sterling, 1974)."
This paper takes a step in clarifying what a Social
Impact Statement might contain and how it might be integrated
into a realistic development process. We recognize the need to
keep the effort, cost, and time appropriate to the project, while
facilitating a thoughtful review. We believe that there can be
large improvements from such a process by preventing costly problems
which may be expensive to repair, improving privacy protection,
minimizing legal challenges, and creating more satisfying work
environments. Well designed systems will be valued by users and
appreciated by colleagues. Information system designers have no
Hippocratic Oath, but excellence in design can win respect and
inspire others to higher performance.
ACKNOWLEDGMENTS
We thank Batya Friedman for encouraging us to explore
this domain and our reviewers, Judy Olsen and Kent Norman, for
providing us with valuable feedback. This report was supported
by funding from the Maryland Department of Juvenile Justice.
REFERENCES
Battle, Jackson, Fischman, Robert, and Squillace,
Mark, (1994), Environmental Law Volume 1 - Environmental Decision
making NEPA and the Endangered Species Act, Anderson Publishing
Co. WWW version prepared in April 1994 by Robert Fischman, Indiana
University, School of Law, Bloomington, IN, http://www.law.indiana.edu/envdec.
Chin, John, Diehl, Virginia, and Norman, Kent, (1988),
"Development of an instrument measuring user satisfaction
of the human-computer interface", Proceedings of CHI '88
- Human Factors in Computer Systems, ACM, New York, 213-218.
Dunlop, Charles and Kling Rob (editors), (1991),
Computerization and Controversy: Value Conflicts and Social
Choices, Academic Press, Inc., San Diego, CA.
Friedman, Batya and Nissenbaum, Helen (1995), "Bias
in Computer Systems", ACM Transactions on Information
Systems, in press.
George, Joey and King, John, (1991), "Examining
the Computing and Centralization Debate", Communications
of the ACM 34, 7, ACM, New York, NY, 63-72.
Huff, Chuck, (1995), Practical Guidance for Doing
a Social Impact Statement (SIS), St. Olaf College, in preparation.
Huff, Chuck and Finholt, Thomas, Editors, (1994),
Social Issues in Computing: Putting Computing in its Place,
McGraw-Hill, Inc., New York.
Iacono, Susan, and Kling, Rob (1991), "Computerization,
Office Routines, and Changes in Clerical Work", Computerization
and Controversy Value Conflicts and Social Choices, Dunlop,
Charles, and Kling, Rob (editors), Academic Press, Inc., San Diego,
CA.
Kaplan, Bonnie, (1994), "Reducing barriers to
physician data entry for computer-based patient records",
Topics Health Information Management 15, 1, Aspen Publishers,
Inc., 24-34.
Kling, Rob, (1980), "Social Analyses of Computing:
Theoretical Perspectives in Recent Empirical Research", Computing
Surveys 12, 1, 61-110.
Ladd, John, (1991), "Computers and Moral Responsibility:
A Framework for an Ethical Analysis", Computerization
and Controversy Value Conflicts and Social Choices, Dunlop,
Charles, and Kling, Rob (editors), Academic Press, Inc., San Diego,
CA.
Mander, Jerry, (1991), In the Absence of the Sacred:
The Failure of Technology and the Survival of the Indian Nations,
Sierra Club Books, San Francisco, CA.
Markus, M. Lynne, (1984), Systems in Organizations
Bugs and Features, Pitman Publishing Inc., Boston, MA.
Mumford, Lewis, (1934), Technics and Civilization,
Harcourt Brace and World, Inc., New York, NY.
Ralls, Scott, (1994), Integrating Technology with
Workers in the New American Workplace, U.S. Department of
Labor, Office of the American Workplace, Washington, DC.
Shneiderman, Ben, (1990), "Human values and
the future of technology: A declaration of empowerment,"
Keynote address, ACM SIGCAS Conference on Computers and the
Quality of Life CQL '90 (Sept 1990), Special Issue of SIGCAS
Computers & Society, 20, 3 (October 1990), 1-6. Reprinted
in ACM SIGCHI Bulletin (January 1991).
Sterling, Theodor, (1974), "Guidelines for Humanizing
Computerized Information Systems: A Report from Stanley House",
Communications of the ACM 17, 11, ACM, New York, NY, 609-613.
Wiener, Norbert, (1954), The Human Use of Human
Beings: Cybernetics and Society, Doubleday and Company, Inc.,
Garden City, NY.
Wurth, Albert, (1992), "Public Participation
in Technological Decisions: A New Model", Science Technology
Society Bulletin 12, STS Press, 289-293.