@device[Postscript]
@make[article]
@use[bibliography "/mit/mackay/thesis/thesis.bib"]

@style(fontfamily helvetica, size 10)
@style(indent 0, spread .5)
@style(references=1nAPA)

@modify(Fnenv, size -1, indent 0)
@modify(HD2,below 1)
@modify(HD3,below 1)
@modify(HD4,below 1)

@heading[Patterns of Sharing Customizable Software]
@center[@b{Wendy E. Mackay}]

@section[Abstract]

Much of the research in cooperative work develops or examines software
that is explicitly designed to support information sharing, such as
electronic mail@cite[Malone3, Borenstein], group-oriented decision
tools@cite[Stefik1], project management tools@cite[Begeman, Sathi],
and electronic calendars@cite[Greif].  However, other types of
information sharing occur naturally within organizations, sometimes in
unexpected ways.  In this article, I discuss a phenomenon that occurs
with user-customizable software: when members of organizations share
their customization files, they establish and maintain standard
patterns of behavior throughout the organization.  After providing
evidence for this phenomenon, I will discuss some of the implications
for both organizational theory and system design.

@section[Introduction]

One of the properties of a user interface is that it dictates and
constrains the patterns of interaction between the user and the
software application.@foot[For example, command-oriented interfaces
may require the user to remember and type a syntactically-correct set
of commands.  A menu-oriented interface reminds the user of the
options available and is operated by pointing to or typing choices.]
Increasingly, application software is designed to be "customizable" by
the end user.  Within the constraints allowed by the designer, users
can encode and preserve their preferred patterns of use.  These
customizations, together with choices about which applications to use,
make up the unique "software environment" for each individual
user.@foot[Not all end users can make such choices about their
software environments.  Some must use a single application in a
fully-prescribed, standard way.  The research described here is
relevant to people who have latitude in what, how much and in what way
they use software to accomplish their work.]

The activity of customizing one's own software applications might be
viewed as a reasonably solitary task.  After all, the goal is to allow
each user to express his or her @i[individual] preferences.  However,
customizations are rarely independent; users may be greatly influenced
by how other members of the organization customize their workstations.
Because people have varying levels of desire and ability to customize,
and have limited amounts of time, they often look to friends and
colleagues for customization ideas.  Borrowing customizations has
numerous advantages for individual users.  They can reduce the time
spent learning how to customize, which increases the time available
for accomplishing actual work.  They can also experience how other
people work, find out out new ways of doing things and benefit from
each other's innovations.

Patterns of sharing may begin as soon as a person joins an
organization.  In order to learn a new computer system, a newcomer
usually needs help "getting set up" from a more experienced member of
the organization.  The newcomer may have to seek help directly or
someone may volunteer to help.  In some organizations, a senior person
may be assigned to help the newcomer.  In any case, one of the first
activities is to provide a default set of customization files, which
the newcomer may then modify.  At this point, the newcomer may have
some strong preferences and make some changes.  However, many of the
items are likely to be evaluated later, when the user has some more
experience with the system.  Over time, the newcomer may notice
customizations made by other people, particularly those of people with
similar jobs or geographically nearby.  Users may adopt customizations
because of suggestions by other group members, or they may notice how
other people work and ask how it's done.  In some organizations,
customization questions and suggestions are posted, so that everyone
can learn from each other.

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.@Comment[CSCW: A key-binding refers to the action that is
associated with a key or combination of keys on a computer keyboard.
For example, in order to move the cursor forward by one word, I might
bind a pair of keys, @p[CONTROL] and @p[F], to the function
"move-forward-one-word".  Alternatively, I might choose to designate a
key from the numeric keypad for that function.]  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.@foot[This is an especially important user interface
consideration in multi-tasking environments, where multiple
applications may be in use simultaneously.  Actions from one
application may interfere with commands from another.  @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 may of the users will resist the
improved version.  These improvements may, in fact, help 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. (Cite findings with
MW and JJ.)

When customization is accomplished via files that can be shared, the
customization file becomes a mechanism for both encoding and sharing
patterns of use.  From a research standpoint, this means that patterns
of use are encoded in artifacts which can be traced throughout an
organization. rather like tracing the spread of genetic traits
throughout a population.  Like genetic traits, these files have 
on-going affects on behavior -- 


Unlike other forms of sharing information, such as meetings or
exchanging electronic mail, these are not transient.  The files
continue to affect day-to-day patterns of behavior over time.
Systematic study of records of changes, correlated across the
individuals in an organization, will provide a view of a communication
network within the organization that has on-going impact.

@foot[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.]

People often join an organization with existing computer experience
and corresponding preferences.  They may spend a great deal of 
time trying to make the new system operate in a way that is similar
to the one they used before.


The purpose of this article is to discuss the social
aspects of an apparently non-social practice, that of customizing
one's software environment.  This work fits into a theoretical
framework that argues we must examine both how users are affected by
the technologies they use and how they affect and appropriate the
technology for their own purposes.  I will present a case study to
illustrate the framework, and then discuss in detail how people in the
same organization shared their customizations.  (The customizations
here were rules from a system called the Information Lens, which helps
people express preferences for how they manage their electronic mail).
I will conclude with recommendations for the design of customizable
software.  Specifically, developers should expect that users will
share their customizations, for better or for worse, and think about
the impact of this on the long-term use of the system.  Issues such as
copying versus reference to central customizations, adding
"reflection", etc.

This article will trace the patterns of exchange of a particular type
of customization file -- Information Lens rules -- which are designed
to customize the processing of one's mail.

I will discuss customization from an individual user's perspective,
evaluating the triggers and barriers that affect choices about 
how much and when to customize.  I will then discuss the social 
aspects of customization, identifying and tracing how customizations
spread throughout an organization and have on-going effects 
on the behavior of the organization.  I will argue that this 
finding fits within a theoretical framework that takes into 
account the actions of individual agents, as well as the technology 
and the institutional properties.

@section[Results]

The patterns of sharing are similar to those found by Allen
@citemark[Allen72], who identified "gatekeepers" in engineering
organizations.  Gatekeepers are highly skilled individual contributors
who actively seek technical information outside of the organization
translate it for the use of internal colleagues.  (Notes: Trigg's
term: bridge, not gatekeep.  My findings: some organizations can have
everyone be a gatekeeper.  Similar to what academic researchers do --
they evaluate their own skills and interests, and then look for holes
in the field or new opportunities, and try to become the unique expert
in that area.  Technical staff at PARC did this -- via choice of
distribution lists, sending FYI info to each other and becoming expert
in certain areas.)

@section[Design Implications]

Software manufacturers, in response to customer demand, are
increasingly making software applications customizable by end users.
However, it is not clear that they consider the impact of 
design decisions on either individuals or on the results of 
sharing these customizations within an organization.

Individuals make choices about when to customize, responding to
external (or internal) triggers or deciding that the barriers are too
great.  The design of the software can affect these triggers and 
barriers.  For example, reflective software.

Reflective software provides users with feedback about what they
actually do.  This is somewhat different from Zuboff's @cite(Zuboff)
notion of "informating", which provides information about the
@i[system].  The notion here is that users need to know what their
individual patterns of using the software are, and better yet, if they
are effective.  Prototype software is sometimes instrumented such that
researchers can examine the user's behavior.  The recommendation here
is to provide similar capabilities for users.  (Note that providing
all possible information, such as keystroke logs, is likely to be less
helpful than a summary of small set of patterns.)  Users are often
unaware of their actual behavior @cite[mackay88d, allen72].  Choices 
about the cost of customizing are based on perceptions, not actual 
behavior.  It is almost a truism in Experimental Psychology that 
one should not simply ask subjects what they do, since they are 
rarely correct.  

Suggestions about reflective software should apply to learning, as
should the methods of sharing customizations...  The benefits of
artifacts in customizations relate to learning as well -- history
files, emacs logs, records of use in the context of the task -- may be
shared, commented on by others (either other peers in the network or
by software agents), and reflected on by the user him/herself.

Software manufacturers do not explicitly support the sharing of
customizations.  Nor do they consider the effects such sharing may
have on the use of their software over time.  Because most use of
customizations is not reflective (users don't usually examine which
customizations are truly effective and which are not), the patterns of
use do not necessarily improve over time.  Another important
consideration is the impact of delivering a poorly-conceived version
of the software.  Usually, poor decisions can be fixed with a new
release.  But here, users who get used to one pattern will be unlikely
to switch to a new one, even if it is better.  HOWEVER, the solution
is not to simply release the software without examples of
customizations.  This simply gives the role of creating the first set
of standards to someone in the end user organization, who is unlikely
to have either the skills or the time to systematically test the
possibilities and design a useful starting point for future
customizations.  (Interestingly, the "lead-users" are less likely to
continue to use an inefficient pattern, since they tend to be more
reflective about their own use of customizations.  It's the people
they gave their early versions to, and the people who received it from
them, who are the ones who suffer.)  Individual differences also play
a part.  Each individual has a different set of triggers and 
barriers that affect when and how much customization is done.

This aspect of software has an interesting impact on organizations.
Customization are normally thought of as an individual activity --
something that one does in the privacy of one's office.  However, if
we look at individuals' choices -- many of them are dictated by other
people's customizations.  Most people do not take the time to
systematically customize their work environments.  Instead, they copy
things from other people (system design differences affect the ways
and levels of sharing possible).  They walk down the hall, see
something interesting and ask about it.  They share good stuff and bad
-- and through this sharing, unconsciously establish and perpetrate
socially accepted norms of behavior -- with lots of individual
differences.

In the study, users asked for:

@begin[enumerate, spacing 1.5]
The ability to browse through 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]

@section[Implications For Organizational Theory]

This research illustrates the importance of considering not 
only the consequences of individual interactions with 
technology, but also the effects of sharing of technology 
among members of an organization.  Decisions made by individuals
may have strong effects on the use of the technology by 
the organization, especially if those decisions are embodied
in exchangeable files that continue to have an impact on 
user behavior over time.

The sharing of customizations is a subset of a larger set of issues,
including how users learn to use new technology and the ways they
innovate and appropriate the technology for their own purpose.  As
users learn a new technology, they are influenced both by its design
and the established patterns of use by other members of the
organization.  At the same time, individuals innovate.  By sharing 
these with other members of the organization, they act to affect 
the structure of the organization.

Software does not remain static when it is introduced into an
organization.  People in the organization evolve their individual
patterns of use, share them with each other, react to external
changes, both technical and non-technical, and sometimes proactively
modify the system to produce real innovations.

@section[Implications For Learning and Innovation]

The triggers and barriers to customizing software are similar 
to those for learning new features or innovating.  While there 
are tremendous individual differences, if we understand the 
characteristics of the triggers and barriers to each of these 
activities, it may be possible to shift the trade-offs so as 
to increase both learning and innovation.

@newpage
@section[A Co-Adaptive Analysis]

Co-Adaptive Analysis:  The introduction of a prototype system into 
an organization:  It was specifically designed to be tailorable.
But was tailored in unanticipated ways.  Caused SW to change.

The claim is that, to understand what's going on, we have to really 
look at the cycle of influences on how the technology was used.
What got appropriated, adopted, and used.  (Who's using it now??)

@begin[enumerate] 

@begin[multiple]
@b[co-adaptive analysis of the development of the
Information Lens].  

Trace how the software was created, moved to MIT to be developed,
tried at source site, didn't work, but created Stan as guru, Ramana as
interested party (participated at MIT), back to revised version,
incorporated items that were of interest to the local folks (e.g.  use
of NEXT key was standard at PARC, not an issue at MIT).  Second
version had some minimal acceptance.  Many features not used.  system
difficult to support.  Ramana steps in with a version designed for the
parc community. Stripped down, based on what people really liked and
omits hard/unused features.  (Including message types).  Adds data
collection.  @end[multiple]

@begin[enumerate] 
Influenced by the technology -- Look at effect of data collection
and discussions with interviewer on user behavior -- cite benefit of
"reflective" software that tells you what you actually do, as opposed
to what you think you do.  Tom's design was influenced by problems 
observed at a Lead user site.


Influence on the technology -- Talk about how use factors
influenced use.  (eg. use of dl's influences concept of anyone
server).  Appropriating the technology:  both use of email (cite study)
for task, time management.  User innovations:  use of lens rules,
boring rule, customization as a poor man's message types.
Identify the principle for the researcher -- ie that the problem
as stated by Malone is not just one of filtering -- it's also one 
of annotating by the end user.  Value of message changes over 
time by user -- what's a "boring" discussion one week may not 
be next week.  Also, sender can't tell you this will be boring.
So, you need tools to annotate as a way to facilitate this.
(Cite Argus software here...possible to do with Xmark).
@end[enumerate] 

@b[Look at individual use.]  Some people used a lot, some very little.
Use changed.  Triggers and barriers differ.

@begin[multiple]
@b[Sharing customizations and patterns of use.]

Social roles of customization.  Look at the development of "rule
guru".  Stan starts out with a lot of rules.  Not ramana, who is the
developer.  Stan is the key user.  People adopt some of his rules.
you can tell who talks to whom.  (See this same effect at Athena).
Points about gatekeepers.  About the benefit of having "artifacts" --
unlike gatekeepers, people see things and someone becomes the person
responsible for handling it.  Not necessarily the developer -- unless
the developer is an innovative user as well.  Can trace the path of
influences among people.  Who's tied in, who isn't.  Implications???
Facilitate.  Problem of copy vs. point to -- do you use someone 
else's stuff "as is" and let them maintain it?  Benefit:  they 
fix bugs, "take care of it".  BUT, if their use diverges, or they 
move, you're stuck.
@end[multiple]
@end[enumerate] 

@newpage

@b[Contrast three models:]

@begin[description]
VMS	@\Login.com.  everyone is unique.  No updates at system level.
patterns of behavior copied...forever.

Athena	@\some central control (standard .cshrc file), with 
customizations on top.  Personal customizations are 
affected when the system changes.

MacIntosh @\everyone unique.  not easy to share files -- quite 
distributed.  Customizations that people do on startup.
Three forms: inits, desk accessories, cdevs (control panel device).

LISP	@\exchange a world..."sysout".  Saved as you left it or you get 
a standard one.
@end[description]


@b[What are the ways in which sharing occurs?]

This is not an exhaustive list.  Some are proactive.  Some are
reactive.  Some are solicited.  Some are unsolicited.  Some involve
on-going exchange.  Some involve changing roles (eg.  technical guru
-> translator -> end user.)

@begin[enumerate, spacing 1.5]
Walk by and see someone else's screen.  (e.g. Mickey Mouse background).
Ask how did you do that?  (user visible)

Watch someone performing some task and notice that they have a useful
method -- ask how it's done.  (not easily visible)

Someone helps you get set up.

You ask someone to help you get set up.

You have a problem/question and ask someone.

Someone has a new idea and tells you about it.

New ideas are posted in a common area and you look.  

Someone tells you to look in the common area.

You have a symbolic link to someone else's file and it's automatically 
updated and you get the change.

You experiment and create it yourself.

You get the standard file and use it.
@end[enumerate]

Look at different organization -- some are supplied by organization, 
some are local group, some are individual.

What about incompatibilities?  Secretary can't use superclock and
grant manager at the same time on the MacIntosh.

@b[Scenario:]  

New software arrives with little in the way of instruction and few
examples.  An intrepid soul decides to figure it out and create a
customization file.  S/he either gives it to other people or other
people ask for it.  Over time, the intrepid soul continues making
changes, often getting rid of inefficient or incorrect items.
However, those same changes are rarely adopted by the group of users.
They pass on their own variations of the original file to other
people.  Since the first set of customization files are likely to be
less good, almost by definition the usage patterns will be suboptimal
-- and these are the onces that are perpetuated.  This is especially
the case if the originator of the file is a "hacker" who has
difficulty talking to people.  Most people will prefer to talk to a
translator, who thinks in terms of how people will use it rather than
in terms of the nifty features available.

@b[Apple MacIntosh Customization Files]

The Apple menu is always there and contains desk accessories.  Some
are supplied by Apple, some by other vendors.  One of Apple's is the
control panel, which is extensible by programmers.  CDEV's are
controlled by the control panel.  Can get public domain CDEVs.  Can
get them from the producer of a device (e.g. video board).  Each
machine has its own "system folder" which contains the two files that
are the system (system and finder) plus all the CDEVs and inits.

@begin[enumerate, spacing 1.5]
Control Panel: A desk accessory that lets you change things like mouse
acceleration, speaker level, color, etc.

Desk accessories:  Can add extra desk accessories -- eg. calculator.

CDEV: Programmers can add control panel devices to control new
functions.  For example, a video board.

Inits are programs, not data files.  Don't modify them.  May add 
or delete.  usually they setup things for an application.  (eg have 
to put an Oracle init in system folder as well as have Oracle SW).
Reserves needed menu, etc.

Fonts and function keys.
@end[enumerate]

Limitations:

@begin[enumerate, spacing 1.5]
Can't take part of the program and send it.  

No symbolic links.

Could make everyone use centralized CDEV files -- one change would
change it for everyone.  Couldn't have part of it centralized and part
of it local.

@end[enumerate]


Differences:  granularity is different.  The whole working program, 
rather than parts.  Also, central/local control.  Also, symbolic 
link.

@newpage
@section[Patterns of rule exchange]

Over a period of x time, n people used the Information Lens.  Four
people were the main sources of rules for others in the organization.
Each of these people had a different role:

@begin[description]  
Researcher	@\Announced the Lens study, interviewed participants
and provided a set of five example rules when they got started.

Developer	@\Created the local version of the software, based on
own ideas and findings from user's experience with the earlier version 
of Lens.

"Lead user"	@\Highly technical, one of the first users of the first
version of Lens.  Immediately wrote almost 100 rules, provided feedback 
and ideas to the developer.

"Regular user"	@\Non-technical person who liked and used the 
locally-developed version of Lens.
@end[description]  

Not surprisingly, the person with the most direct effect was the
researcher, who gave most of the participants in the study a set of
five examples of rules.  (People could choose to use Lens without
participating in the study.  However, there was a 5-page "mini-manual"
which consisted of a one-page summary of the features, a one-page set
of five examples, and a three-page "day-in-the-life" example of how
someone would use all the features throughout the day to solve a
"typical" set of mail filtering problems.)

Figure @ref[FIG.lenspatterns] shows the patterns of exchange of rules.
A single arrow indicates that the source person provided a single rule
to the recipient.  A bold arrow indicates that the recipient took the
entire set of rules from the source person.

@begin[figure]
@begin[center]
@graphic(postscript=/mit/mackay/thesis/FIG.lenspatterns,
magnify=.80, BoundingBox = ".75inch, 4.5inch, 7.5inch, 10.5inch ")
@comment[clock measurements:  9:00,    6:00,  3:00,     12:00]
@caption[Patterns of Exchange of Lens Rules]
@end[center]
@tag[FIG.lenspatterns]
@end[figure]

Because of the small numbers of users and the low general levels 
of use (due to many system constraints), this data only provides
a glimpse of the kinds of exchange patterns that might be set up.
I intend to examine this more thoroughly at Project Athena.

@section[Tracing the path of a complex rule]

Lanning was one of the earliest and most consistent users of the
various versions of Lens.  Throughout the project, he conferred with
the developers and made numerous suggestions to the developers.  (He
was also vocal with complaints.)  He instituted the "To or CC" command
-- because so many of his rules required this.  Turned out to be so
useful that, in Ramana's version of the software, this was added as an
extra field option.  Quit different from the original lens.  (Would
have required LISP to use a logical OR).

Also instituted the idea of the "Boring" rule.  First person to 
take into account that one's perceptions of what is interesting 
etc is based on the reader, not the sender.  When reading email,
choose the "boring" option, when you see a message that you 
think will cause a long string of answers -- that you're not interested 
in.  Takes advantage of the fact that messages that are replies
to an original message use a common format  RE:  <previous subject>.
Give example.  By choosing the "boring" option, when you come 
across a message for the first time, you can have a rule automatically 
created that says "If the subject is RE: <message subject>, then 
automatically delete".  This is a single rule, which is simply 
the logical OR of all of these possible subjects.

@b[Can trace who used this rule.]

Also, one of the first things he did was figure out how to do 
a Dave Barry rule.  It turns out that the Jokes distribution list 
has too many jokes.  But one author, Dave Barry, is consistently 
funny.  so he wrote 2 rules -- the first isolates messages from 
Dave Barry and the second identifies non-Dave Barry jokes and 
deletes them.  

@b[Can trace who adopted this rule and when.]

also, look at what Bobrow did.  First, created a complete copy of 
Lannings 94 rules.  Didn't like it.  then tried using it for 
going on vacation -- liked it.  

People usually let someone else in the organization act as the 
"first user" -- and let that person play.  Then this person 
becomes the local source of ideas -- you send nifty rules to this 
person and ask for his/hers.  Also, when you see other peoples
rules that look interesting, chances are that the rule when 
through this person at one time.

complex, generally useful rules
copied: lifschitz, barry, auto

Used the "set char" feature -- 

Not ramana -- why???

==========

Sources of rules at PARC: 

Huberman gave set of prioritizing rules to Brown.  (Copied
entire set)  -- Card also uses prioritizing rules, but can't 
trace source.  Card= 7 rules on 0ct. 10.  Huberman = 10 rules on 
Oct. 14.

Wendy's 5 example rules (derived from pass 1 -- with no rules)
How many people started with these?  How many people ended with these?


Stan Lanning's weird rules:

	Boring
	Dave Barry
	
Check to see what he's got 1 year later (2 years later)

Then check to see if any of the ones he'd deleted 
are still in use by others.  Do any of these fire?

(Firing of rules is a method of determining whether 
or not the rule is useful.  Note finding in Stan's
that higher percentage of recently changed rules 
fire. )

Stan innovations:

	Boring -- introduce annotation/ automatic rules
	characteristics
	dave barry
	cars  (bauer tried)
	lifschitz, sheridan

Introduced Archive ruleset -- heard about it in my paper...

Ramana
	multi-rulesets?

Bauer
	customizations as an alternative to message types.

===========

Discussion with Ralph about history files:

record history files.  Do you use it to fix typo's or to "parameterize"
commands?  Do you use the kill ring in emacs in the same way?


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

Dave Barry Changes: 

16 Dec 87 ~~|	If   Body:  Barry
 3 Feb 88 __|	     To-or-cc:  Jokes
		Then: hardcopy, stop

15 Feb 88	If   Text:  Barry		Changed from Body to Text
23 Aug 88 __|	     To-or-cc:  Jokes
		Then: hardcopy, stop

26 Aug 88	If   To-or-cc:  Jokes		Changed so no hardcopy
current  __|	     Text:  Barry
		Then: stop

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


@b[Why is it important to look at organizations?]  

Examining individuals provides an understanding of the specific
factors that influence certain kinds of behavior.  Examining this from
an organizational perspective provides different kinds of insights.

For example, one might ask if individual customizations of software
affects user interactions in the workplace.  At first, the answer
would probably be "no".  After all, what an individual does in the
privacy of his or her office, for reasons of personal taste and
efficiency, appears to have little to do with the rest of the
organization.  However, one of the key mechanisms for adopting 
customizations is through copying other people's files.  This 
has an on-going impact on both the communication patterns within 
the organization and encourages standard patterns of behavior.
Both useful innovations and errors can be propagated throughout
the organization in this way.

Another social/organizational impact occurs when customization is used
to improve the communication among members of a group.  In the Lens
study, a self-identified group customized the lens rules to make their
interactions with each other more efficient.  In another example,
manager/secretary communication patterns that were set up to match the
particular forms of communication that each set preferred.  (Describe
both examples.)

Customizations that turn into user innovations may well result from
situations in which groups attempt to modify the software to meet
their needs.  In the previous example of manager/secretary
relationships, the manager decided to use customization fields in the
display of the rule system to create a mechanism for communicating in
a standard/automatable way with his secretary.  @comment[just add a
field, rather than specific message types, to communicate.  ]

At Athena, the use of Zephyr has also been affected by the
organizational context.  The On-line consulting system used Zephyr in
new ways and influenced the subsequent design of both the software
@i[and] the design of the customization mechanisms.  When people see
other people's visible customizations, it may change both their
understanding of what's possible and may also result in new
interactions with other people.

One of the most interesting phenomena at the organizational level is
the potential for the creation of "customization experts".  They often
share their customizations with newcomers or people who don't want to
learn how to customize (based on the principal that it's more
convenient to copy than create).  This spreads usage norms throughout
the organization and affects relationships among people.  Innovations
by people who do not share their customizations will not be as
effective as those of the customization "gatekeepers".




