The basic thesis:

I believe that there are a number of human activities that cannot be
studied in the traditional ways -- in particular, learning,
innovation, customization, coordination.  These are all meta-level
activities that are performed to enhance the long-term performance of
work, but not the immediate performance of it.  We know from
experimental psychology that short-term rewards outlast long-term
benefits.

Learning is co-adaptive:

Users are influenced by the environment in which the learning 
is situated and they actively interact with the environment.
To learn is to be active, not passive, to interact not 
react.

Innovation is co-adaptive:

Experimental Psychologists are looking for phenomena that can be
predicted and, ideally, controlled.  They look for the items that can
be replicated under different conditions and generalized to 
new situations.

What happens when the phenomena of interest are not directly 
replicable?  What if we are looking for unusual events?  What 
if, by controlling all the variables, we look the effect?  In 
Psychology, the effect is not there.  Yet, in individual circumstances

In Psychology, the term 'anecdotal evidence' is used as a slur, to
describe sloppy, poorly thought out research.  The reasons are good
ones: many apparent phenomena are the result of random variation.
People, including scientists, are susceptible to jumping to
conclusions and assuming an effect, even if one does not exist.
Perceptual Psychologists have demonstrated that people perceive
patterns in randomly generated processes -- and that is what much of
the scientific method is designed to prevent.  However, blindly
following research methods is not the answer, because sometimes the
assumptions that were critical in the original design of the method do
not hold in the new circumstance.  So it is here.  I am not interested
in controlling and predicting behavior.  Rather, I am interested
in identifying patterns within a complex environment that may 
appear in other environments as well.  The goal is to observe 
and explain, not predict and control.  

(Tukey's recent work on coincidence and large numbers -- why do people
assume that there's some psychic phenomenon at work when one person 
hits the jackpot twice in the same year.  While it is true that 
there is a less than one in a trillion chance that that particular 
person will hit the jackpot twice, the chances that someone will 
is closer to one in four.  Which suddenly isn't all that unusual.)

Because of our own biases and tendencies to look for significance
when the result is merely the effect of the random distribution, 
many branches of science have turned to statistics to determine 
whether particular phenomena are "significant" or not.  Because 
these valuations have a great deal to do with sample size and 
the power of the tests being used, many "important" findings are 
not statistically "significant".

What do we do with phenomena that are changing -- in which the act of
isolating the phenomenon from it's environment fundamentally changes
it?  What happens when "controlling the variables" means removing 
the effects we are interested in?

The study of human interaction with technology is not a study of
natural phenomena.  It is a study of people, who are changed by the
technology they use, and technology, which is changed by the people
who create and use it.  To isolate either in an attempt to understand 
the "real" phenomena is to apply the wrong scientific models.

One must ask what the value of a controlled experiment is if 
the phenomenon being studied is how the people and the technology 
change over time.  

If we study change, why use static techniques?  This is not a case
where cetis parabis applies directly..."all other things being equal"
is not useful.  

The concept of situated action is not so different from the 
concept of stimulus control, although the two are derived from 
widely divergent branches of science, with very different 
global perspectives.  The former comes from anthropology, with 
an emphasis on the "gestalt" or whole.  The latter comes 
from behavioral psychology, in which the goal is to predict 
and control specific aspects of behavior.  Both are largely 
atheoretical, driven primarily by observation, not theory.

It has been said that the natural sciences have large quantities 
of data and very few theories that can explain it, whereas 
the social sciences have many theories and very little data.

Perhaps this is not accidental.  Perhaps this is because the 
richness of social scientific research so deeply involves the 
context in which it is situated that the principles that can 
be extracted in the natural sciences do not apply. 

The assumption in social sciences is that the observer is biased and
brings a model of the world with which to view situations.  Certain
patterns may emerge that appear in other contexts -- these are
important findings.  However, they are the result of complex
combinations of factors and are not necessarily predictable 
or controllable.  The nature of understanding here is different 
from that of the natural sciences.

(By the way, the natural sciences are changing to.  Until 
Goedel's theorem and Heisenberg's Principle of Uncertainty, 
Physicists assumed that they could continue with reductionist 
approaches until they reached some form of absolute proof. 
Goedel demonstrated that the mathematics we use will necessarily 
either overdescribe or underdescribe the phenomena.  Heisenberg


=======
What is important here is not the speculation that people 
adjust to their environments and that they provide new environments...


Given complex software, how and under what circumstances do 
people customize?  Argue that describing the use of customizable 
software as a co-adaptive phenomenon provides important insights.

 


What's the relationship between the structurational model and 
co-adaptive phenomena?

The structurational model addresses one of the problems in studying
this kind of phenomenon -- 



Why is this interesting?

What are the implications?


Things to draw together:

co-adaptive phenomena cannot be studied in traditional ways.

Specific characteristics of the local context affect the behavior 
and ...

============

The following is an informal list of expected findings, based 
on other research and the results of the pilot studies:

@skip[1]
@begin[enumerate, spacing 1.5]
users will resist customizing, even if there are long-term time savings,
(Mackay88d, Duncker)

external factors may cause users to proactively customize,

users will satisfice, not optimize, @cite(Newell)

users will be able to absorb more information about the system
over time (chunking) and should be better able to customize,

triggers and barriers will have differential effects on people
(e.g. a trigger for one person may be a barrier for another),

some customizations will result in innovation, 

users are not passive recipients of technology from management, and

users will share their customizations and innovations with 
each other in orderly ways, establishing group norms of behavior.

Fleming (1978)@citemark[fleming] offers predictions about which
individuals are most likely to adopt innovations and communicate them
with each other.  
@end[enumerate]

The sharing in this organization is likely to be higher
than in other organizations, with both the problems and the benefits
that that entails.  The following section describes the implications
of this work, both theoretical and practical.


==================

@b[Methodology]

Methodology discussion: Why isn't it possible to draw from positivist
theories of how individuals learn to study this phenomenon?  Why 
must the theory be drawn from an organizational model, rather 
than a Psychological one?

One might expect that the Psychology would provide help for examining
this co-adaptive phenomenon.  After all, the study of how people 
learn and innovate as individuals clearly falls into this category.
However, there are several built-in assumptions about the 
process of inquiry that makes this approach inappropriate.

Experimental Psychology generally draws from a hypothesis-testing 
strategy, in which phenomena are observed and theories are 
extended to explain the theory.  

The problem here is the notion of control.  In an experiment, there is
an independent variable which can be treated as a fixed element, at
least for the duration of the experiment.  Dependent variables are
then observed with respect to the independent variable.  The procedure
is to propose a hypothesis that can be tested by setting up a
comparison between two events.  The null hypothesis generally 
says that there is no difference between the two events and 
the goal of the experiment is to see if the null hypothesis 
can be disproved.

What do we do when the phenomena we are interested in are not only not
static, but also not independent of the dependent variables that we
study?  How do we arrange a methodology and a theoretically sound
basis for the study of the phenomenon?  What are we trying to 
prove and what are we trying to disprove here?  The questions 
don't make sense if we can't isolate the variables and test 
them independently.

This leads us into fundamental questions about "what constitutes
evidence".  As observers, we are biased.  We are influenced by the
models we choose and these influence the questions we ask and our
understanding of the models.  This is true of both experimental
research and ethnographic studies -- but the attitude toward them
differs.

Add this to the methods chapter

I collected records of dot files from everyone who participated in 
the study.  I also looked in the files to see who had set their 
files to be "world-readable" -- in other words, who had explicitly 
chosen to allow people to read their files.

Everyone answered a questionnaire about who they speak to in the
organization and who they gave and received customization files from.
Because of the variety of methods of sharing files, people did not
always remember who they got files from or (more often) who they had
given files to.  The most effective technique for remembering was 
to sit in the participants office, after the questionnaires had been 
filled out, and go through the key dot files and systematically 
determine whether particular items had been borrowed or not.

@b[Findings]

@b[Process versus Functional customizations]

In the Lens study, one person created a rule that identified messages
addressed to her personally.  This significantly affected her process
of reading electronic mail, and allowed her to avoid reading many
messages that she deemed unimportant.  Oddly enough, the latest
feature added to Project Athena's Zephyr system allows users to
differentiate between personal and system-generated zephyr messages
and place them at different locations on the screen.  This serves the
same function as the Lens rules, with a similar change in the user's
processing of information.  In each case, the use of this feature
affects the process of accomplishing work, which is not the case for
most other customizations.

Zephyr is a message broadcast system developed for Athena's
distributed network @cite[dellafera].  Zephyr provides a message
broadcast service similar to that on time-sharing systems, for use
when the system manager wants to notify users that a particular
printer is down or a disk will be unavailable while being serviced. 
Because there is no central computer at Athena, and because 
users may be located on different workstations at any time
(their directories and files are independent of the workstation), 
Zephyr was designed to allow the system administrators to contact
the users who are affected by system problems, without 
disturbing everyone else.  Zephyr has a subscription service,
but only sends messages to people who are currently logged on.

Users have appropriated Zephyr for their own purposes.  They conduct
real-time conversations with each other, or use it to find out whether
someone is there.  The benefit of Zephr messages over electronic mail
is that the message is only delivered if the person is there.  With
electronic mail, a message such as "interested in lunch in 15 minutes"
will remain in the recipient's mailbox long after lunch has passed and
must be deleted explicitly.  The OLC logs indicate that people learn
about Zephyr when they see other people using it in the clusters, 
and its use has grown greatly since its introduction in 1987.  The 
On-line consulting system uses zephyr for communicating with users,
with electronic mail as a backup if the user isn't there.  Users
sometimes request that messages also be sent via electronic mail,
so they can keep the instructions for later use.

@b[Exchange of customization files establishes and perpetuates social
norms]

Providing the ability to easily exchange customizations has important
organizational implications.  One of the earliest requests in the Lens
study was to allow users to exchange rules with each other.  Some
people copied each other's rules, even though the process was
initially cumbersome, and the rules were mostly irrelevant.  When 
first introduced to the concept of the Information Lens, many 
people had difficulty coming up with ideas for rules.  However,
when given a concrete set of examples, they were able to 
modify them for their own needs and come up with additional 
ideas for rules.  This has implications both for the teaching 
of how to customize and the importance of good default values
and examples.

Because it is easier to work from an example, and because one's
colleagues' examples are more likely to be relevant than someone
else's, it seems reasonable to expect that normative practices will
develop and be reinforced by the exchange of these files.  At Project
Athena, the standard methods of exchanging customizations is to mail a
copy of a "dot" file, which the recipient can use directly or edit
further.  Friends exchange files in this way, and the On-line
consulting system delivers its advice in this way as well.  One of the
by-products of this is to distribute social norms for behavior...as
well as perpetrate errors (John Brown @cite[Brown80] cites a well-known
"preventive maintenance" practice that everyone seems to know, 
which needed for a prototype machine a decade early but has long 
since ceased to be necessary.  -- elaborate --)

If the exchange of customizations is beneficial, then it is important
for software manufacturers to make those mechanisms available as one
of their design goals.  In an entirely menu-driven system, it is
difficult for one person to adopt another's changes.  If the system is
the same in all respects, but allows users to save some or all of
their customizations and send it to someone else, the system will be
expected have a different form of impact.

Because it takes time to figure out how do customize software in a
useful way, those who do it have produced something of value to the
organization.  Customization files can thus become part of the
currency of the organization and help some people obtain other
information or services that are of value.  Communication over the
exchange of customizations may also serve to establish and strengthen
weak ties @cite[Granovetter].

Who shares with whom?  Finding that geographic proximity plays an 
important role.  Office mates are more likely to notice each other's
interesting customizations and ask for them -- presumably because 
they spend more time in the same room and are more likely to 
see something.  People in open areas (watchmakers, VCG) should be 
more likely to share each others work.  

Note that in a distributed environment, the users don't end up 
seeing each other's work easily.  Ann's comment -- faculty don't 
share as much as students do -- they have private offices not 
individual ones.

@b[Users tend to "satisfice" rather than optimize]

Newell and Simon describe "satisficing" as a heuristic in which the
decision maker accepts the first option that meets a previously-set
acceptable standard @cite[newell].  In this case, satisficing would
mean that users will customize until the system is good enough, but
not until it's perfect.  The preliminary evidence suggests that most
people (with the exception of a few programmers) are happy to accept a
customization file that is close to their needs but not perfect.
(Quote from AL).

@b[Customization "gatekeepers" emerge]

Organizational patterns emerge, similar to the gatekeepers identified
by Allen @cite[Allen72].  An intrepid individual first tries out the
new software and figures out how to customize it, through trial and
error and reading the documentation.  This person provides the
customization file as a service to others in the organization, who
either ignore it, adopt it completely, or more commonly, adopt it and
modify it as needed.  If the process is extremely complex, as it
sometimes is at Athena, then additional people will take the original
complex file and make simpler customizations.  People learn who to ask
for customization files, for clarity as well as for
appropriateness.  {GD and the secretaries, AL and her manager.] It is
possible to identify the customization gatekeepers for each of the
major software products at Project Athena and how they relate to each
other.

This process, seen both at the Lens research site and at Project
Athena, serves to transmit standardized ways of doing things 
across the organization.  One effect can be to inhibit creativity 
(fewer people try the range of possibilities and so fewer are 
likely to come up with novel solutions).  On the other hand,
people in the organization generally see it as more efficient,
especially among people for whom programming is not their 
primary responsibility.

These findings agree with the findings that "local experts" tend to
emerge @cite[Bannon, Lang, Scharer].  However, here 
people are exchanging more than expertise, which is transient.
Their innovations are concrete and live on in the form of 
files that continue to be used over and over again.

@b[Social Pressure about customization]

People in different groups face different social norms when it comes
to customizing.  The operations group sees it as "hacking" and avoid
it all together, even though they are logged into their computers
throughout each work day.  The "watchmakers", the elite programming
group, vie with each other for the "neatest" customizations.  Members
of the rest of the staff don't feel much pressure either way, although
one mentioned that one can earn a little bit of extra respect from the
watchmakers by asking how to customize something in an interesting
way.

@b[Reverting to the Status Quo]

Even though some people have strong incentives to change (such as job
requirements in which their working environments should be as similar
as possible to that in the field), users who have invested time into
customizing their work environments are often loathe to change.  At
Athena, they have the option of using the old window manager -- or
making the new one look just like the old.  Some people have lived
through three or four different window managers and change each one to
be like the first one they used.  Old habits die hard.  (I should note
that most of these changes have to do with key bindings.  Just as
touch typists have resisted moving from the QWERTY keyboard to the
clearly superior Dvorak keyboard, people who have trained their
fingers to manipulate their windows and other software in particular
ways are reluctant to change.)

@b[Autologout:  Beth's example.]

When Athena used a timesharing model, many users created an .Xsession
file, which created a large Xterm window as a background.  When 
Athena shifted to a new release of the operating system software,
this customization cause problems.  The system would execute the 
commands in .Xsession and after it created the Xterm, would 
automatically logout.  As a result, people with this particular
customization would be unable to access their accounts at all.
This customization file continued to be used as an example 
of a useful customization in the system locker, even after the 
bug was identified, perpetuating the problem for new users.

@b[Athena Stories:]

Ken didn't know how to "kinit".  If he messed things up or wanted 
to get a new set of windows, he would log out and log in again.
He had been here for 3 weeks, but was unwilling to find someone 
and ask, even though he knew there must be an easier way.


=================
@b[the end]

The study of the interaction between users and technology is rich and
complex.  I have chosen to view this interaction from a different
perspective than is traditional in the theoretical literature, by
holding neither people nor the technology constant in the view.  I am
interested in how and under what circumstances people customize their
software and I contend that examining this as a co-adaptive
phenomenon provides important insights, both about customization
itself and about the nature of co-adaptive phenomena.

=========


@b[Implications for teaching]

The usual way of teaching users about software -- send them to a class
for a week to learn everything and then use it -- is not very useful.
A better strategy is to start with a simple set of "survival skills".
When the user gets bored, frustrated, or is able to take on more,
allow the user to learn more and customize more.


Conclusions:  What about co-adaptive systems, which explicitly capture
user context in various ways and use that information to modify the
software?  Also, capture changes in the organization -- the data feeds
back.  Is it chaotic and therefore unpredictable?  Is it good?  Does
it happen anyway?  How can we come to understand it?  It's a different
way of looking a computer networks -- not as imitations of existing
kinds of communication but as evolving ways of creating new kinds of
activities and communication.  To empower, to teach, to react to change,
to innovate.

================

If these data are at all representative, software users maintain lower 
levels of productivity even in the face of increasing technical 
sophistication of the software.  (Note the exception with users 
who cannot customize and are therefore forced to use the new 
system.  Even then, they will try to use it in the ways they 
already know.)

In order to change the situation, it will be important to reevaluate
the current approach to training and exchange of information about
software in general and customization in particular.

Most organizations' current approaches to customization and training
are inefficient, suppress innovation and may in some cases be harmful.
The following suggestions are designed to incorporate these data and
provide low-cost solutions.  However, before presenting suggestions,
it is important to describe how organizations currently handle
training and use of software.

@b[What do organizations do now?]

============
One of the most commonly cited reasons for not customizing or 
learning new things or incorporating other people's innovations 
is lack of time.  (Bicycle story.)  Also, people do not have 
a chance to examine how effective their software is, and they 
generally face unknown risks with respect to how long it will 
take to make things work correctly and whether or not they will 
introduce new problems that take large amounts of time to solve.



What's the difference between this suggestion and the establishment 
of "user groups"?  Clearly the latter have been very effective 
in helping people use new technology, particularly in the 
personal computer market.  First, it leaves people out -- only 
the people who are fundamentally interested in the technology 
will attend user group meetings.  Other people will simply not 
find the time to do so.


@b[Different levels of help]

At the individual user level, lowering the costs of learning and
customizing the software are likely to increase the user's ability to
use the technology effectively.  However, this may not be sufficient.
Even in cases in which the software is extremely flexible and easy to
use, users who are busy tend to develop an established pattern of
working and continue to use it even if it is not optimal.
Customizations that preserve these patterns, whether borrowed from
others or created by the user, are not likely to be changed.  Instead,
they will tend to be preserved over system upgrades or changes to new
software.

Translators and people who help others learn new software would
benefit from having access to information about the effectiveness of
their suggestions.  Software that records aspects of use and 
relate 

There is an inherent danger in recording performance data.  If 
used as an on-going judgement, then it will adversely affect the 
quality of work-life for the people involved.  It will also 
focus attention on the items that are most easily measured, 
rather than the items that most affect real productivity.



In the Psychology literature, there is a phenomenon called "functional
fixedness", originally identified by Duncker in 1945.  People learn to
use items in particular ways, which inhibits innovation.  What do we
make of this?


@b[The importance of reflection]

Activities such as customization, coordinating tasks, learning new 
things, and thinking about new ideas are all meta-level activities
that operate above the level of the work.  They require that users
think about the work, rather than do the work.  Tools that help 


then the current situation in most
organizations is ineffective in addressing user's constantly changing
needs with respect to the technology, nor does it facilitate the
transfer of innovations and the removal of ineffective or harmful
practices.  The following proposal takes the above findings into 
account:
 

@b[Testing this strategy]

You could measure the use of the software in several organizations and
take effectiveness ratings.  (Which types of tasks are performed and
which features are used/not used that could be effective.  What
percentage of people share the software and who are the most 
advanced users.  Who are the translators?)

Then, institute several of these kinds of meetings, with some of the
groups.  (Matched pairs, if possible.)  Continue to measure 
performance and sharing.  Expect that the result of the meetings 
will be to:  a) reduce amount of obsolete stuff  b) enhance the 
effectiveness of translators c) maybe add some closet translators 
who see the need d)increase the level of use.

Basically, it provides a chance to reassess the performance.
The customization features lead into the features about how the 
software is used.

The results of these meetings could be fed back to software manufacturers,
to provide feedback about how different people use the software, 
where to direct their next efforts, and 

(If I were a software manufacturer, I'd run some of these sessions 
for "free" at my top customer's sites, to bring in feedback and 
to enhance the actual use of the software.)

@b[Could you do this without traveling anywhere?]

We do not yet have the infrastructure in place to effectively 
share each other's software environments, but places like 
Project Athena may provide some first clues as to how to do it...

==================

We know that people are very much influenced by the first software
they use - the first set of customizations they are given -- and that
the primary uses of customization among non-technical individuals is
to either: maintain consistency in the face of change or to capture
certain patterns of behavior that the user suddenly notices occur
often.


The equivalent of "spring cleaning" -- throw out things that 
aren't useful, think about what you do with the system, 
and learn a few new useful things.

Systems designers would benefit greatly by observing these
sessions, to see which features are used and accessible and 
which are inaccessible.  Over time, some features may become
more useful as the users' bases of knowledge increase.

What to do:

Let everyone look at everyone else's ways of doing things -- let
people bring their customized environments together and perform
various typical tasks -- watch each other and learn.
(Most people don't think they have innovations to share -- but 
many people do.  What one person thinks of as natural use, another 
person thinks of as a neat new idea.)

Benefits:

Learning from others with similar jobs makes it easier to share 
things that are useful

Reflecting upon own use of the software -- preferably with 
performance metrics.  (Thus, if I have a history file that 
I ordinarily don't look at, someone at this session may be 
able to interpret it for me into a graph that says how the 
system is being used.  I can then interpret it in the context 
of my own work and see if the analysis is useful or not.
(For example, if I've just been doing something very unusual,
the data might not be very useful.)

Not that the naturally-selected translators will be participating 
here  -- both active and inactive ones.  They will be gathering 
both information about the technology and information about 
the groups' needs.  Over the course of the year, they should 
be better prepared to help others, newcomers who join, etc.


What's the advantage for:

Management

provide a way of continuously updating employee skills

incorporating employee-created innovations into general use.

Reducing the impact of inefficient or outmoded patterns of behavior.

Individual users:

For people who never have time, this is an opportunity to
think about individual use of the system, update the environment 
and fix the annoying "bugs" that have accumulated over time,
learn new things from people with similar jobs, and 
not get overloaded with customization the rest of the time.

Novices:

A chance to get one's feet wet and ask questions in an environment 
in which it is acceptable to ask.
Prevent the fear that there will be no chance later to find out 
more.

Translators:

Provide tools for reflecting on effective use of the system,
Provide information about the actual use of the software,
Enhance skills
Increase network with other translators

Software developers

(Observe, not participate.  If they participate, it becomes a "training
session" centered around the technology.  These should be "user
sessions" centered around the use of the technology.  Tricks and 
hints should be incorporated, but only at the next level.)

Consider holding the session with participants from two different 
but related job types, or people with the same jobs in different 
organizations.  This will provide the most cross-fertilization of 
skills.

Can this sort of thing be done electronically???

It would be kind of interesting if the right hookups were available --
users could share each other's work environments for a time - need
a metalevel of observation and discussion over the actual use 
of the software.


===================

Users have a number of incentives to share customizations, including
taking advantage of each other's work, learning new methods of
accomplishing useful tasks, avoiding errors, and generally saving
time.  The net result is that users adopt patterns of use from each
other, propagating both useful innovations and errors throughout the
organization.  New users are more likely to customize, but they have
less knowledge and skills than they will later.  They are more
likely to adopt others' patterns of working, even if they aren't
suitable or contain errors and inefficiencies, because they do not
have the skills or knowledge to evaluate the effectiveness of the
software.

The participants in this study requested the following in the 
design of customizable software:
@skip[1]
@begin[enumerate]
The ability to browse through others' useful ideas,

Better mechanisms for sharing customizations,

Methods of finding out which customizations are used and effective, and 

Methods of identifying customizations that are ineffective.
@end[enumerate]

The sharing of customization files has an interesting impact on how
people use software in organizations.  Because customized software
encodes patterns of use, and because people exchange and use each
other's customized software, then the organization has a method for
establishing and perpetuating standard patterns of behavior, without
being aware of it.  Once created, a particular customization may be
used by many people for many years.  Some of these patterns are
"addictive", because, once learned, people are highly resistant to
change.  One of the most insidious examples is the use of
key-bindings. Just as touch-typists who learned to use the QWERTY
keyboard resisted learning the demonstrably superior Dvorak
keyboard,@foot[The QWERTY keyboard was designed to slow people down
enough that they would not exceed the limitations of the typewriters
created at the turn of the century @cite{yates}.  Since then,
typewriter technology has improved significantly and a much
easier-to-use keyboard, the Dvorak, has been developed.  Despite its
advantages, touch-typists refuse to switch because of their existing
investment in the other keyboard.] users who become accustomed to one
set of key bindings resist learning new ones.  When users work with
several different applications at the same time, the possibilities for
confusion and interference among applications are even
greater@cite[norman3, card].

The customization files get passed on throughout the organization,
for better or for worse.  Inefficient and "superstitious" patterns
of work are passed along, as are clever ideas and innovative ways of
accomplishing tasks.  Because they are not examined, they do not
"improve"; they become part of the on-going repertoire of behavior
in the organization.  The on-going effects are important for
understanding how users appropriate and are influenced by the
technology they use.

Some users go to great lengths to "fix" an improved user interface,
because of their investment in a previous version of the software.
They modify everything so that daily patterns of use remain the
same.  Interestingly, some users do not feel capable of customizing
the software "back" to the old way and become resigned to learning
the new key bindings.  This has important implications for user
interface designers and software manufacturers, who may release an
early version of a product with a poorly-designed interface,
expecting to "fix it in an update".  It may be the case that many of
the users will resist the improved version.  These improvements may,
in fact, be most helpful to those users who feel unable to customize
the software and resign themselves to learning the new key bindings.
The result may be that users who shift may, in the long run, achieve
higher productivity. In this study, several non-technical members
(E5, B1, A8) of the staff were forced to learn the new window
manager because they were unaware that they had a choice.

When customization is accomplished via files that can be shared, the
customization file becomes a mechanism for both encoding and sharing
patterns of use.  Unlike other forms of sharing information, such as
meetings or exchanging electronic mail, the customization files are
not transient.  The files continue to affect day-to-day patterns of
behavior over time.  Note that customization is accomplished
differently on different computer systems, and these differences
affect the patterns and levels of sharing.  Systems such as Unix and
VMS use customization files that can be copied or mailed in whole or
in part.  Systems such as the MacIntosh have graphical interfaces
for customization but require the exchange of the entire
customization program. This research concerns customizations that
are embodied in files.

=======================

Two competing processes appear to be at work here, which we find on
the macroscopic level as well.  The first is the principal of the
learning curve: as users become more used to something they establish
standardized patterns of use that make them more efficient, but less
innovative.  When disruptions of certain kinds occur, particularly
disruptions that require users to reflect upon their use of the
technology and explore other possibilities, opportunities for
innovation arise.  People enter the organization, invest time in
learning, and then gradually cease to explore new things. Patterns of
responding that were developed to compensate for errors in the
technology continue, even though the original problems in the
technology have been corrected.  Some individuals continue to innovate
and explore over long periods of time -- but they are rare.
Interestingly, the translators appear to keep on top of the new
technology better than others, even though they are often less
technical, because they are constantly coming into contact with new
people with new needs and are forced to re-evaluate their
understanding of the technology and its use.

The translators do not help the "old-timers" much, especially those
who are not particularly technical or interested in the system.  These
people have obsolete patterns of use that simply age, becoming less
effective over time as more and more things break.  Introduction of
new features are unlikely to be discovered by these people -- so a
technology solution is not sufficient.  It makes more sense to give 
these people periodic opportunities to re-evaluate their use of 
the technology in the light of advances in both the technology and 
in the group's understanding of how to use it effectively.

Two processes serve to reduce people's customization activities. When
you first learn a piece of software, especially if you are new to the
job and the organization, you are more likely to spend a lot of time
customizing it.  Very few people continue to customize on a regular
basis.  The other trend is that as you go from one system to another,
each successive system is likely to result in less customization.
This is partly because you learn that if you spend a lot of time
customizing, you'll just have to do it over again.  Competing issues
are customization to maintain stability -- which is either over time
or across platforms, to reduce switching costs.  Learning a new
system takes time and people become successively less willing to do
it.  They are also less willing to convert from one way of doing
things to another, even if the new way is "better" in some ways.  So
the lesson is -- it's very important which system you learn (well)
first, because it will be with you for a long time. It's also very
important which customizations you create at first (or borrow),
because those will stay with you as well.

In the face of this ongoing "extinction" of new behavior, moving
towards a steady state, is the ongoing introduction of new technology
and the changing of work environments, which force people to continue
to modify things.  Disruptions are not necessarily bad, therefore --
especially if they cause people to stop, reflect upon their own
behavior (preferably with some data about how they use the system),
and make some adjustments.  In many cases, learning a few commands or
automating a process or two can have a big influence on general
productivity.  (The example of secretaries not knowing cut and paste.)
However, if the person is already pretty proficient at the software
and the job hasn't changed much, the chances that learning a new 
feature will help is less likely.


In one sense, these findings aren't surprising.  Given the diversity
of human behavior and the different ways in which people can interact
with technology, these patterns are all plausible.  What makes them
important is that they are not just speculation, they are supported by
data and that if they are indeed common, then the decisions made by
both software manufacturers and managers in organizations that use
customizable software are clearly not optimal.  Because people
customize the most when they are new to the system and know the least
about the technology and their future use of it, the changes they make
are less likely to be appropriate.  Creating feedback mechanisms and
opportunities for reflection about the use of customizations (and
general use of features and patterns of work) may help to
significantly increase productivity, if done when the users is both
more familiar with the technology and with their needs and use of it
in the context of their work.  Software manufacturers who define the
software development process in terms of creating features (the
classic functional spec), miss the point that users interpret and use
the software in different ways.  The software development process must
include examination of the use of the software over time, by people in
organizations, not just the structure of the code.  Forward-thinking
software manufacturers will provide a mechanism for observing the
innovations that users make and bringing them back into the
organization.  This may kill two birds with one stone -- it will allow 
people in the end user organizations an opportunity to reflect 
upon their daily use and needs and it will allow software manufacturers
the opportunity to benefit from their innovations.  (Note too that 
it will allow the software manufacturer to make changes along the 
dimensions of customization, which make provide entirely new uses
of the software.)


@\Decision process:
@\@\Users weigh perceived costs and benefits

@\Sharing:
@\@\Customization is a social activity

@\Encoding:
@\@\Users encode repeated patterns of use

@\Context:
@\@\Users impose work context through customization

@\Reflection:
@\@\External events help users reflect on own use

@\Stability:
@\@\Users strive to maintain stability


@end[comment]



