
Add this to the lens section


The three phases of this study were greatly influenced by changes in
the software.  However, these changes in the software were generally
the result of how the software was used -- or not used. 

============================
Lens can be examined from different perspectives, each of which can be
demonstrated to have changed over time.  The original developers of
Lens designed it meet a particular set of perceived needs and
generalized it to meet anticipated needs.  The model of use was 
presented as the relationship between a secretary and a manager.
The secretary's (and Lens's) job is to read and prioritize messages
first, and then hand the prioritzed set to the manager (or Lens user).
People who listened to this had different reactions.  Some assumed
that this would be very useful.  Others recoiled and refused to use
it.  "I could never trust a machine to read my mail for me."  (Note
that new managers often have the same reaction to giving up control
over their paper mail to their new secretaries.)  Some people 
actually used (and continue to use) the software in this way.  However,
it quickly became apparent that many users wanted the prioritizing 
capabilities -- but only @i[after] they had read their mail.  This 
was possible through a debugging option in the original software,
and became a key feature of the third version of the software.

Through observation of actual use, the developers examined these 
needs and developed a new, richer understanding of the software.

Similarly, the users heard about the technology from its developers,
which established a set of expectations about what the technology was
and how it would be used.  Simply presenting the concept of rules
changed several people's perceptions of their own mail use.  As 
people began to use the software, and exchange experiences with 
each other, the perception of the software changed.  


Different individuals react to the same technology in different ways.
Each person uses some features and disregards others; two people may
use completely non-overlapping sets of features.  Previous experience
with other software affects each user's expectations about what Lens
is and can do, which affects the user's subsequent patterns of
interaction with the software.  All of these factors encourage
diversity in the use and perception of the technology.  Through
observation of actual use, the developers re-examine their own
understanding of the software and develop a richer understanding of
both the users' needs and the role of the technology in assisting with
those needs.

Some of the changes were personal and did not affect the overall use
of the software; others influenced the software designers and resulted
in significant changes in subsequent versions of the software.


This diagram does not adequately illustrate the role of changes over 
time.  Thus, as mentioned earlier, Lens is not a unitary phenomenon.
It changes both through use and through on-going development.  
Thus, we should really think of the Lens box as a series of boxes
with different changes over time.  These changes will vary by 
individual, since different people use different features of the 
software.


The next section will describe the history of the Lens project, related 
to this diagram.

Mention how people changed behavior when they went from one version to
another.  Leads us to expect that external events (not covered in
structuration model) may play an important role in use: sort of a
punctuated equilibrium idea.


@subsection[Changes in the Technology]

One of the easiest ways to see the changes in the technology is to
look at the changes in the rule editor.  Figure @ref[FIG.ruleeditor1]
shows an example of a rule created with the first rule editor.  The
rule has been given the name "Information Lens" and looks for messages
that contain the word "Lens" in the subject field.  When a message
matches, Lens moves it to the folder called "Lens".

@begin[figure]
@blankspace[3in]
@center[Insert picture of Phase 1 Rule Editor here]
@skip[2]
@caption[Original Information Lens Rule Editor:  Phase 1]
@tag[FIG.ruleeditor1]
@end[figure]

Figure @ref[FIG.ruleeditor2] shows how the rule editor looked in phase
3.  The user interface was designed to meet @i[Viewpoint] user
interface standards.  Notice the addition of menu buttons and of
multiple rule actions.  In this example, the user has specified that
messages addressed to or copied to the @b[Want Ads] distribution list,
which also contain the subject @b[Honda], are to be moved to the
@b[Car] mail folder.  Whenever a message meets these criteria, the
rule fires and the message is moved to the @b[Car] folder.  The field
labeled @c[To or cc:] was a feature added in response to many requests
by users.  In previous version, this example would have required two
separate rules: one addressed @i[to] Want Ads and one @i[copied] to
Want Ads.

@begin[figure]
@blankspace[5.5in]
@center[Insert picture of Phase 3 Rule Editor here]
@skip[2]
@caption[Revised Information Lens Rule Editor: Phase 3]
@tag[FIG.ruleeditor2]
@end[figure]

Features changed:  some added, some deleted.

More importantly, the concept of how it was used changed.

@subsection[Changes in the user's perception of the technology]

@subsection[Changes in the developer's perceptions of the technolgy]

@subsection[Lens Story #1]

(Note somewhere:  phase 1 developed at MIT.  phase 2 developed 
at MIT but modified at research site.  phase 3 developed 
entirely at research site.  This affected the acceptance of 
the software.)

Another feature that was added in the local version was the ability to
group personal rules into different @i[rulesets], which can be
executed at different times.  Rules in the "new mail" ruleset are
applied automatically when new messages are retrieved to the user's
workstation, before the user sees the new messages.  Rules in other
rulesets ("folder" rulesets) are applied when the user explicitly
invokes them on a specified folder.  Users primarily invoke folder
rulesets after they have at least skimmed the messages in a folder.



Lens example:  How users co-opted the system.

1.  Designers assumed that everyone would run rules on messages
before reading the mail.  Assumed that the rules for dealing with
a single message would always be the same.  (In other words,
one message may have several rules run over it, but it wouldn't
matter when the rules were run.)

2.  Some users refused to use Lens under those conditions.  They
didn't want the system to manage their mail before they saw it.

3.  A "feature" in the system, which allowed people to run rules
at a time other than just prior to bringing in new mail was discovered
by some people.  People then lined up in two camps:  those who
ran rules before reading mail and those who ran rules after
reading mail.  Not surprisingly, the kinds of rules for the two
were different.  Since people were only allowed one set of rules,
they had to choose one strategy or another.

4.  Ramana Rao added the ability to run multiple rulesets at different
times in a newer version of lens.  Most people chose to have multiple
rulesets, some for pre-reading mail, and others for after reading mail
Some people continued to do one or the other.

5.  In looking at what people were doing with these multiple
rulesets, they were in effect providing information to the system
about their work context, which affected the rules.  For example,
when very busy, more delete rules are used.  When working on a project,
information about that project is treated as higher priority.  The
context changes can be minute -to-minute or day-to-day or month-to-month,
the system doesn't care.  It's just when and which ruleset you use.

The key here is that the same message is treated very differently
according to the user's defined context.  A message that hasn't been
read yet is different from the same message after its been read.
And that message may be different again after a phone call comes.

Conclude:  a message is not a message is not a message.
A user's interaction with a message, not the content of the message
or the user's content alone, but the combination of the two is
what makes a system like Lens useful.

Users modify the system to provide information about their
own context, which enhances the usefulness of the rules.

NOW, how do you provide tools that specifically help people provide
information about their context to the system, to help them
manage their information.

@subsection[Lens Story #2]

The original designer of the tool (Malone) was influenced by the needs
evident at the research site.  The users were influenced by the
software, but also demanded and created changes in it, and used it in
ways that were unanticipated by the designers.  Over a period of time,
the software evolved in a number of directions in response to the
users.

In the Lens study, it appeared that users were more likely to create
new rules at specific times.  For some people, the times were related
to opportunities, such as a three-day weekend.  Others modified their
rules at regular intervals, such as once every ten days.  Still others
modified their rules in response to a particular event, such as the
arrival of the interviewer.  Events such as planning for or returning
from a trip caused people to rethink their strategies for handling 
their mail and increased the likelihood of editing rules.

I will present case study data that describes how individuals reacted
to changes in their environments or were self-directed in making
changes to the software.  I found a great deal of diversity in
people's decisions about how much and when to customize their software
environments.  I will attempt to explain this with a cost/benefit
analysis and identify the characteristics of users and the technology
that are most likely to result in modification by users.

Another observation from the lens study was that users who described
themselves as "overloaded" were less likely to spend time using tools
that helped them reduce overload.  Not surprisingly, people who felt
very much in control were also less likely to spend time organizing
(they had either already invested the time and were reaping the
benefits or their jobs or personalities were such that they were able
to manage the flow of tasks/information.)  The most interesting group
were the people who were "on the edge" - basically handling things but
at their limits.  These people were able to try new things and were
more innovative than their peers.  They had a higher need than the
people who felt in control, thus the benefits were higher.  They were
also more willing to pay the costs of organizing, because they weren't
completely overloaded.  Panic induces paralysis.  

Users who have very little incentive to modify won't because the
benefits aren't worth the costs.  Users who are overloaded have the
incentive, but are not willing to risk the possibility of losing it
all.  Thus, we expect people who are in a state in which they are
basically in control, but nearing the edge, to be the most likely to
innovate/modify their working environments.  Notice that this changes
over time.  When a user comes in contact with a new piece of software,
the tendency is to move into "survival" mode first.  The goal is to
replicate the set of tasks that the user was able to accomplish before
and try to get the job done.  Over time, as that set of tasks becomes 
familiar, the user can do them more easily.  At this point, the 
user moves from an "overload" situation to an "in control" situation, 
and is able to pick up more.  Some users will stop here, others will 
begin to increase the demands of the job, taking on more responsibilities, 
etc.

When studying the introduction of the information lens, I observed
several patterns in people's use of the software.  They found that it
was not "trivial" to use, and not just because of speed or overt
user interface issues.  The problems were related to the difficulty
involved in articulating behavior and the costs associated with
organizing activities.

Some situations seem to increase the likelihood that people will spend
time "organizing".  Not surprisingly, when the researcher was actually
there, people worked on their rules more.  But the rate actually rose
@i[before] we arrived; they remembered to use the system and collected
questions for us to answer.  People organize their offices and
software environments to remind themselves of things (cite Malone's
desk paper).  (Cite example of different email strategies and
management of inboxes in Mackay (1988).)  So it's not surprising that
being reminded about a tool that helps one organize will result in a
higher probability that the tool will be used.

Consider using data from editor tutor study here.  Users who received
random interruptions with advice on commands learned as much as those
who received advice in context.  Lead to user model in Jonassen
chapter and IFCEB paper.

@subsection[Lens Story #3]

The idea for the Information Lens was grounded in the growing needs of
people to manage an increasing volume of electronic mail.  As a member
of a leading edge research community, Malone was exposed to the
technology at an early stage in its evolution and was able to observe
the problems that would later face people other organizations that
rely heavily on electronic mail for internal communication.

The specific design of the solution was deeply influenced by the
computer and organizational environment in which it was created.  For
example, the notion of the "anyone" server is interesting to an
organization that conducts all of it's "broadcast" message traffic
through distribution lists, rather than through electronic
conferences, such as Netnews.

When the technology was first introduced, it failed miserably.  Not
only was it buggy and slow, but it also violated a number of
principals in terms of how people used electronic mail.  The next
version worked better, and several people used it.  One person found a
"debugging" feature that allowed him to run rules at a different time.
This addressed a problem and caused a number of people to start using
it who had refused to do so before.  Then, a local programmer built a
version that fit with the model that everyone was used to.  This
version made the "bug" discovered earlier into a useful feature.  At
this point, a relatively large number of people started using lens,
and used it in ways quite different from that predicted in the
original design.

The original design was influenced by and derived from a set of needs
at the original site.  As is often the case (cite Tatar), the 
implementation made a number of assumptions and made a number of 
things that people took for granted harder, while making other 
things easier.  (Even though it was designed to be purely an 
addition.)  Thus, the use of the NEXT key was different, and caused 
people many problems.  This of course is only a problem for this 
audience, which has a set of expectations based on their use of 
other related systems.  However, it is almost always the case that 
there are interaction effects with other technology that is 
simultaneously available on the system.

The next version of the software was better accepted, and used 
in different ways.  This new use suggested a set of different 
possibilities.  Interestingly, this lead to multiple development 
paths for new versions -- object lens and argus.

@comment[ Talk about the influences on people -- who shared who's
rules.  How did they get started.  What caused innovations and
changes?  (e.g. going on a trip.)  Individual differences]


@subsection[Lens Story #4]

Tom frustrated with email as a lead user -- gets idea for lens.
  - specific influences due to existing technology
    (network, dl's not notes, was dl's work)
  - specific influence due to environment at PARC and at MIT

So -- the user innovates...influenced by the technology.  

Builds lens at MIT -- incorporates ideas from old environment,
	adds new.  Via Ken Grant.

Version #1: Tested at PARC.  7 people. all but 1 stopped use -- he
	was from MIT.  Decides to develop own version for 
	personal use.  Reasons:  slow, buggy, characteristics
	like "next" didn't work and were expected to.  No examples,
	too complex.  Didn't know what to use it for.  (But SL
	made 98 rules.)

Ideas from study changed ideas of what's available / possible.
	Researcher worked with RR - new ideas.  Also, simply 
	talking to people about use of email changed ideas.
	And -- people changed views when told of idea of lens.

Version #2.  Takes some things into account.  More users. Critical
	feature was local support for asking questions.  Many 
	more users got started.  (None from study #1).  Researcher
	provides a demo, sets up a 1-page mini-guide, 3-page
	"day in the life" run-through of features from a user's
	perspective and 5 sample rules to help people get started.
	Works with each individual, based on answers to mail study,
	helps them create rules.

	RR decides to develop his version further for local group.
	Removes unused features:  message types, anyone.  Provides
	support and incorporates ideas.

	User innovations:  Bauer uses customization fields to 
	create a short-hand for communication with secretary --
	instead of separate message types.

Version #3:  RR's version.  Switch over as people change machine
	software.  Impact - had to completely reenter all rules.
	Faster turnaround, someone available to set things up.
	User ideas incorporated:  multiple rulesets, boring rule,
	rulesets for different purposes (inbox, sorting, other)
	Rules start to be exchanged.  Use of "to or cc".

	Individuals share rules among themselves.  

Versions #4/#5:  Two different, independent development efforts
	at MIT -- Argus and Object Lens.  One focused on extensions
	based on user innovations, scaled prototype, integration 
	into Unix environment, handling of information other than 
	mail. Explores concept of annotation/filter pair -- to 
	allow receivers as much control as senders (more).  Defines
	problem as a balance of control between senders and 
	receivers.  (Results in researcher innovation)

	 Object Lens explores issues related to object-oriented
	messages and active agents.
	
@section[Analysis of Individual Use]

Patterns of changes will be graphed for individuals and correlated
with external changes in the environment.  I propose to reanalyze the
data, with respect to individual rule changing patterns.  I expect to
see reactions to known external events, including timing of
interviews, long weekends, etc.  I will base the analysis on the logs
of all lens changes with dates, and link it back to the interview
data.  So far, I have looked at: the visit of researcher, earthquake,
new system upgrade.

@subsection[Why is it important to look at individuals?]  

Mackay (1988c)@citemark[mackay88c] identified at least three forms of
appropriation of electronic mail by individuals, in addition to
communication: time management, task allocation, and information
management.  It was important to identify the behavior patterns of
individuals in order to discover that the technology had been
appropriated in these ways.  Individual analyses are particularly
important when the behavior is highly variable (making summary
statistics highly misleading) or when individual patterns cancel each
other out.

Several extreme behavior patterns produced important insights.  For
example, one person found two rules to be very effective ("it changed
my life"), while another wrote 98 (and found it somewhat effective).
By examining each individual, it was possible to gain an understanding
of how the rules differentially affected their mail sorting behavior,
and thus had differential effects on overall satisfaction.

We can't evaluate rule strategies unless we look at individuals.  From
there, we begin to see different patterns of behavior and different
reasons for different activities. Once we pull out these reasons, we
can look more globally to see if these patterns hold.

The purpose of examining individuals is to understand how people make
unique decisions about customization -- and what affects those
decisions.  The proposed theoretical framework allows us to look for
both how the user is influenced by new technology and how the user
appropriates the technology for his or her own purposes.  By studying
individuals, we will be able to identify the set of triggers and
barriers that affect the use of new technology.  By studying the
organization, we can see how these individual patterns affect the
behavior of the organization as a whole.


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.  ]

Ramana introduced a tree structure for representing users mail 
folders.  This was very popular (in fact, the most uniformly 
highly-praised feature of Lens) and changed everyone's behavior.
People quickly reorganized their mail folders from one level
(basically a list), to a tree structure with 3-4 layers.  Some 
people used this conversion as an opportunity to "clean up"
their folders, sometimes adding new ones that made sense in 
the hierarchy and sometimes deleting ones that were no longer 
useful.  

This is an example of an external event that causes people to 
think about how they organize their software environment and 
work to improve it.  Some people do this without external 
prompting, but most only do it with an external event (and 
some never organize their files at all).

The explanation of Lens caused people to critically examine their
personal use of mail and served to focus attention on particular kinds
of problems.  Because Lens provided scenarios for solving these
problems, people were able to apply these ideas to problems in their
own work.  Although individuals were attracted to different Lens
features, the overall explanation of Lens provided a common ground for
discussion.

@subsection[Examples of user innovation]

Individuals over a period of two years used electronic mail and a
version of the Information Lens.  Individuals had highly divergent
patterns of electronic mail use and highly divergent patterns of
adopting the information lens.  Individuals did not simply adopt the
new technology, they changed it.  They redefined the purposes for
which it was used, some actually found ways to modify it, and they
created innovative patterns of use.  This is an example in which
their behavior was both influenced by the introduction of a new
technology, but they also influenced the technology itself.

One example of user innovation was the discovery that led to the 
use of multiple rulesets.

One advantage of multiple rulesets is that they can be created 
for different purposes and used at different times.  The user 
need not explicitly articulate the purpose; s/he need only run 
the rules.  Thus, if I have a set of rules that I run when I'm 
busy and can't deal with a large volume of electronic mail, 
I need not explain all this to the system -- nor do I need to 
be fully aware that that's what I use it form.  All I need to 
do is run it when I determine that I'm busy -- I evaluate 
my own state and run rules accordingly.  Thus, I can make the 
automated system more effective by choosing the circumstances
under which I use the system.  

This relates to the more general problem of making things explicit for
the computer.  Most people do not "know" the rules they use for
managing their electronic mail.  When asked, they can make up rules,
but these do not always correspond with their actual behavior.  They
usually refer to an "ideal" processing state and include a variety of
misperceptions about the behavior of the system as well as the user.
It is thus not surprising that people find it difficult to articulate
the rules they want and need for processing their electronic mail --
although they often can come up with examples of tools that would make
things easier or solve a particular problem.  When designing the 
system, providing a means for allowing users to direct the system 
without explicitly articulating rules, is likely to be more useful.
Will this result in more innovations, because the users are likely 
to use the system based on their actual, rather than articulated,
use and thus discover new aspects of their behavior and the system?

@section[Patterns of Sharing Rules]

One of the properties of a user interface is that it both guides and
constrains the patterns of interaction between the user and the
software application.  Increasingly, application software is designed
to be "customizable" by the end user, providing specific mechanisms by
which users may specify individual preferences about the software and
how they will interact with it over multiple sessions.  Users may thus
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.

The activity of customizing one's own software applications might be
viewed as a reasonably solitary task.  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, because people have varying levels of
desire and ability to customize, and have limited amounts of time,
they may 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 and reduce
the risk of making errors, 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.

Do 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.)

From a research standpoint, customization files are interesting to
study because the users' patterns of use are encoded as artifacts that
can be traced throughout an organization, rather like tracing the
spread of genetic traits throughout a population.  More importantly,
the use of these files continues to affect daily 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
over time.

Purpose: discuss the social aspects of an apparently non-social
practice, that of customizing one's software environment.  I will
trace how customizations spread through an organization and the
on-going effects this has on the behavior of the organization.  I will
conclude with recommendations for the design of customizable software,
e.g. that developers should expect that users will share their
customizations, for better or for worse, and consider the impact of
this on the long-term use of the system.

@subsection[Exchange of Information Lens Rules]

Although some individuals in the organization created their own unique
sets of rules, many shared rules with each other.  Four people became
the sources of these rules:

@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.

"Regular user"	@\Non-technical person who liked and used the 
locally-developed version of Lens.  Shared with other non-technical 
users.

"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.
@end[description]  

Not surprisingly, the person with the most visible effect was the
researcher, who gave most of the Lens users a preliminary set of five
examples of rules.@foot(People could choose to use Lens without
participating in this study.)  These rules acted as default rules
which users could customize for their own purposes.  The rules were
chosen to illustrate rules that others in an earlier study had found
useful, as well as point out a technical trick that users might find
helpful.  The sample rules were included in a five-page "mini-manual"
which consisted of a one-page summary of the Lens features, a page of
the five sample rules, 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.)

The programmer who created the local version of the Information Lens,
which was more readily accepted by the members of the lab, also 
shared rules.  He gave advice about rules to approximately 
one third of the active Lens users, but did not provide direct 
copies for them to use.  He introduced a number of innovations, 
but these were incorporated into the design of the software and 
made available to everyone.

One of the non-technical members of the staff was intrigued by 
the strategy of one of his colleagues and created his own set of 
rules based on that strategy.  He then provided a complete copy 
of the rules to another of his (non-technical) colleagues.

The most interesting person was the earliest and most steadfast user
of Lens.  One of the top technical members of the lab, he immediately
began experimenting and created almost 100 rules.  Throughout the
project, he conferred with the developers and made numerous
suggestions to the developers; he was also vocal with complaints.  He
created a number of innovations that were incorporated into the local
version of the software.

This person created a number of complex, but useful rules that could
be traced in other people's rulesets.  A good example is the "Boring"
rule.  He had noticed that some messages (usually "flames") result in
a long string of replies.  If the original message is not interesting,
chances are very good that the replies will not be particularly
interesting either.  Fortunately, the mail system identifies these
replies by placing "RE:" in the subject field and appending the
contents of subject of the original message.  For example, if the
orginal message has the following subject: Tyrolian Ski Bindings, then
subsequent messages will have the subject: RE: Tyrolian Ski Bindings.
He added a feature that allowed users to identify a potentially boring
message and creates a Lens rule to automatically delete it. (For
example: If subject: RE: Tyrolian Ski Bindings then delete message.)

Another example was the identification of a well-liked author in 
a commonly-read jokes distribution list.  He created two rules.
The first identified and saved jokes by this author; the second
identifies all other jokes and deletes them.  This combination 
of rules also proved popular and was shared by x of his colleagues.

Most people were uncomfortable with the idea of automatically deleting
messages from a particular sender, even if they were quite sure that
the sender would be unlikely to send anything important.  Many people
in the lab were annoyed by a person outside the lab who had discovered
an internal mailing list and was using it to announce various
seminars.  "Fred" created a rule that effectively deleted all of the
seminar announcements without risking the deletion of potentially
important messages.

In each case, these rule appeared in other people's rulesets.  They
were copied and used, and sometimes discarded.  Most of the people who
copied the rules were programmers with quite long lists of their own
rules.  These people ususually adopted one or two rules at a time.
One of his colleagues adopted his entire set of rules; but found they
weren't appropriate.  This person stopped using Lens for many months,
and then rediscovered its usefulness when filtering mail after
returning from a trip.

People adopt some of his rules.  you can tell who talks to whom.
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.


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.

@comment[Check to see if any of the ones Stan has 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. )]

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.  ]

Although the number of users was quite small, and there were no
facilities for exchanging rules, it appeared that users did in fact
share rules with each other.  It also appeared that users with similar
interests were more likely to share rules.  I decided to investigate
this further, as part of a study about how users customize software.

=======CSCW PAPER==========

Four people shared rules or information about rules with
others in the organization.  The first two are not surprising.  I, as
the researcher, provided five sample rules for beginning users.  Three
rules were chosen because users in an earlier study had found them
useful; two illustrated a trick that users might find helpful.  The
author of the local version of the software gave rule advice to
approximately one third of the active Lens users, but did not provide
copies for them.  He introduced a number of innovations, but these
were incorporated into the design of the software and made available
to everyone.

In addition, two other people shared their rules with other members of
the organization.  One was a non-technical person who liked and used
the locally-developed version of Lens.  He adopted a strategy, but not
the actual rules, of a colleague.  He then provided a complete copy of
the rules to another non-technical colleague. The other person could
be considered a "rule-guru": a highly technical person who wrote the
most rules and provided feedback and ideas to the developers.  One of
the top technical members of the lab, he began experimenting with Lens
as soon as it became available and created almost 100 rules. He
created a number of innovations that were incorporated into the local
version of the software.

The rule guru created a number of complex, and useful rules that could
be traced in other people's rulesets.  I traced three of these rules
or rule combinations: One allowed users to identify sets of related
but uninteresting rules and delete them (the "boring" rule).  Another
pair identified jokes by a well-liked author and deleted jokes by
others.  Another identified a person from outside the lab who was
announcing seminars and deleted the announcements without deleting
personal messages from him.  (Most people were uncomfortable with
automatically deleting messages from a particular sender, even if the
sender never sent anything of interest.)

Four people copied the boring rule, and three each used the joke rules
and the delete rule.  They were all programmers with 6-62 of their own
rules.  One person adopted the rule-guru's entire set of rules.  This
colleague quickly found them inappropriate and stopped using Lens for
many months.  He then rediscovered its usefulness when filtering mail
after returning from a trip.

One might have expected the developer to be the primary source of
rules.  After all, he has the most knowledge of the software.  But in
fact, he only provided advice, not sample rules.  His rules were
designed to test the system and were quite different from those of a
normal user.  The other three rule-sharers were interested in how
people used the system.  They each developed rules that they thought
would be useful for themselves, but also thought about their general
usefulness.  They each addressed a different need: "getting started",
non-technical user, and programmer.

A different form of rule-sharing also occurred.  Two manager-secretary
teams agreed on a standard form of communication and created a
corresponding set of rules to facilitate processing of the mail
messages.  In another case, members of a group agreed to customize
their Lens rules to make their interactions with each other more
efficient.  These examples have a different character than the
previous ones.  They involve a social commitment to work together in a
particular way.  In the other examples, users are sharing their
@i[individual] patterns of working with each other.

The function served by the latter group may be similar to the
gatekeeper phenomenon identified by Allen (1972). @citemark[Allen72]
Gatekeepers are skilled individual contributors who actively seek
technical information outside of the organization and translate it for
the use of their colleagues.  In this case, several people in the
organization developed strategies for using rules, which they shared
with their colleagues.  However, the number of users was quite small,
making it difficult to generalize from these results.  These findings
raise several questions.  Do certain people identify themselves as a
source of customizations for others?  Are the exchanges one-way or
mutually shared?  What are the circumstances under which people decide
to share their ideas and customizations?  The second study will
investigate these questions further, in the context of a study of how
users customize software.

@section[Suggestions For Future Research]

The findings from the Lens study suggest that users are likely to be
influenced by a variety of factors when deciding to customize their
software environments.  Some users are likely to share their
customizations and a few may actively create and distribute
customization files for other people's use.  Will different people act
in this "sharing" role (get a better term, like gatekeeper) for
different software applications?  Or will the same people share their
files across applications.  (The Lens study found that individuals
sorted themselves into different areas of expertise.  Other users came
to know who was knowledgeable about which area and would tend to ask
that person for help and forward interesting information to that
person.  Customization files may be that way too.)

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".

These 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.)

Users have a number of incentives to share customizations, including
taking advantage of 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, propogating both useful innovations and errors throughout the
organization.  

Software manufacturers, in response to customer demand, are
increasingly making software applications customizable by end users.
However, the results of this study indicate that customizable 
software is not always used in the manner in which it was 
intended.  Software design decisions will affect how individuals
customize and how these customizations are shared 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.

@subsection[Implications For Software Design]

The design of the mechanism by which customization can occur is
important.  Some customizable software, such as that on an Apple
MacIntosh, has a "direct manipulation" interface.  Users modify the
software, from the default values provided by the software
manufacturer.  However, they do not have an easy way of sharing parts
of their customizations.  In such cases, each user really does make a
completely individualized set of customizations, strongly influenced
by the design decisions of the manufacturer.

Recommendation:

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 (Mackay, 1988d, Allen,
1972).@citemark[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.

@subsection[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 purposes.  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.


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
potential customizations are more likely to be evaluated later, when
the user has additional experience with the system.  Over time, the
newcomer may notice customizations made by other people, particularly
those of people with similar jobs or who are 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, these individual customizations can
establish and perpetuate standardized patterns of behavior, without
the members of the organization 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, in which a software function is associated
with a key or combination of keys on a computer keyboard.@foot[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 easier
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.

The customization files get passed on throughout the organization, for
better or for worse.  Inefficient and "superstitious" patterns of work
are passed along, as well as 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.

===========

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]

This suggests several design implications.  Customizable software is
not always used in the manner in which it is intended.  Software
design decisions are important because they affect how individuals
customize and how these customizations are shared within an
organization.  For example, customizable software with a "direct
manipulation" interface may be easier to use but harder to share.
Software designers should consider how to assist the people who become
the translators or sources of customizations for their peers.  The
quality of the examples they create will affect the overall perception
and use of the manufacturer's software.

Software manufacturers should consider designing software to be
@i[reflective], allowing users to become more aware of their own
patterns of use, and provide methods for evaluating effectiveness.
Reflective software is somewhat different from Zuboff's (1988)
@citemark(Zuboff) notion of "informating", which provides users with
information about the state of the @i[system].  Reflective software
should increase the user's awareness of how they actually use the
software.  Techniques used to instrument software for feedback to user
interface researchers may be useful here, particularly those that
summarize behavior.  (Keystroke logs are unlikely to help.)  Since
most people do not spend much time evaluating their own patterns of
use, these features may be of more help to the translators rather than
regular users.  However, given the influence of these people on the
rest of the organization, it is important to help them reduce the
number of inefficient or ineffective customizations and increase the
creation and sharing of user innovations.

Software manufacturers should consider the impact of delivering a
poorly-conceived set of default values when the first version of the
software is shipped.  Unlike many features that can be fixed in
subsequent updates, decisions that affect individual patterns of use
are likely to have long-term effects.  Many of the users in this study
insisted on using the first pattern they learned when they arrived at
the site, and a number spent a significant amount of time retrofitting
new "improved" software to be like the old familiar software.  The
solution is not to release software without any examples of
customization.  This simply shifts the burden of creating sharable
customizations to volunteers in the organization, who may lack both
technical skills and an appreciation for the elements of a good user
interface.  Even though some people will continue to improve their
customizations, these are less likely to be shared among members of
the organization.

In conclusion, this study has demonstrated that customization 
is not a purely individual activity.  Members of an organization 
may become translators for others and create customization files
for others to use.  These files continue to affect behavior 
for long periods of times (several years) and serve to establish
and perpetuate standard patterns of behavior throughout the 
organization.





@begin[comment]
====================================================

Software manufacturers should consider designing software to be
@i[reflective], allowing users to become more aware of their own
patterns of use, and provide methods for evaluating effectiveness.
Reflective software is somewhat different from Zuboff's (1988)
@citemark(Zuboff) notion of "informating", which provides users with
information about the state of the @i[system].  Reflective software
could increase the user's awareness of how they actually use the
software.  Techniques used to instrument software for feedback to user
interface researchers may be useful here, particularly those that
summarize behavior.  (Keystroke logs are unlikely to help.)  Since
most people do not spend much time evaluating their own patterns of
use, these features may be of more help to the people who share their
usage patterns with others, rather than regular users.  However, given
the influence of these people on the rest of the organization, it is
important to help them reduce the number of inefficient or ineffective
patterns and increase the creation and sharing of user
innovations.


Software manufacturers should consider the impact of delivering a
poorly-conceived set of default values when the first version of the
software is shipped.  Unlike many features that can be fixed in
subsequent updates, decisions that affect individual patterns of use
are likely to have long-term effects.  Many of the users in this study
insisted on using the first pattern they learned when they arrived at
the site, and a number spent a significant amount of time retrofitting
new "improved" software to be like the old familiar software.  The
solution is not to release software without any examples of
customization.  This simply shifts the burden of creating sharable
customizations to volunteers in the organization, who may lack both
technical skills and an appreciation for the elements of a good user
interface.  Even though some people will continue to improve their
customizations, these are less likely to be shared among members of
the organization.

@subsection[Implications For Organizational Theory]

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.

When designing the system, providing a means for allowing users to
direct the system without explicitly articulating rules, is likely to
be more useful.  Will this result in more innovations, because the
users are likely to use the system based on their actual, rather than
articulated, use and thus discover new aspects of their behavior and
the system?

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.

Individuals over a period of two years used electronic mail and a
version of the Information Lens.  Individuals had highly divergent
patterns of electronic mail use and highly divergent patterns of
adopting the information lens.  Individuals did not simply adopt the
new technology, they changed it.  They redefined the purposes for
which it was used, some actually found ways to modify it, and they
created innovative patterns of use.  This is an example in which
their behavior was both influenced by the introduction of a new
technology, but they also influenced the technology itself.

Conclusion:  customizations are often sources of user innovations.
Users can apply these features in new ways.

Rather than treating the user interface as a single system, which
individuals customize in unique ways, consider creating collections of
customizations that are specific to common patterns of use.
Individuals should then be permitted to make unique customizations
within these common patterns.

Note:  do not assume that "programmers" or "secretaries" adequately 
defines a pattern of use.  As shown above, individuals have 
diverse patterns of use within job categories.  The patterns should 
be influenced by whatever combination of factors is most relevant.

Note:  If Peggy's is a common pattern -- and Huberman's chaos work 
suggests it is -- then it reflects the pattern of extreme willingness
to experiment at the beginning, followed by a more rigid pattern 
as the person settles into effective patterns of behavior.  This 
relates to the patterns of innovation found (Utterback), and 
the notion of shaping behavior -- with increased activity when 
a reinforcer doesn't appear, followed by more systematic behavior
as it is shaped.  However, note that this may be a U-shaped curve:
Card points out that users who face an entirely new system go 
into a kind of "survival mode", figuring out what they need to 
survive.  It is only later that they are able to explore and 
learn new things.  May relate to "chunking" -- users can only 
absorb so much information, and they need to chunk it to get 
more.  Perhaps chunking is a two-edged sword, in which users may 
chunk and use the extra "room" to learn new things or they 
may chunk into pieces and lose the ability to re-evaluate items 
within the chunks or rearrange the boundaries.

Distribution lists have as many unifying characteristics as the
characteristics that unite any group of people.  Thus, it is not
possible to talk about messages from these lists by themselves -- it
must be qualified with the kind of d.l.  For example, a list composed
of four members of an active working group who are exchanging
work-related information and delegating tasks several times a day may
be treated as more important than personally-addressed messages.  In
contrast, a list based on the participant's geographic location is
less likely to contain information of interest.  (Thus, one sees "lost
car keys" and "fire alarm test tomorrow" kinds of messages.)

In studies of the use of Argus, several people developed a two-step
strategy, with one set of rules for sifting and another for subsequent
filing after the files had been read. The patterns of use of Lens
rules at Athena were quite different than at the previous research
site, because the people shared the ideas about it.  also, the
software didn't name rulesets "folder" and "new mail".  So people
would create a ruleset with one rule, and others with several.  Many
more rulesets here.  This speaks to the evolution of the software
as well -- users are influenced by how people talk about it.
One effect of my first paper, which identified two strategies
(prioritizing and archiving) allowed people to evaluate their 
own behavior and identify themselves as using one or both strategies.
However, this also served to limit their ideas about how to use 
rulesets in these ways -- few people used them in other ways,
such as the two-step strategy I mentioned.  


People adopt some of his rules.  you can tell who talks to whom.
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.

Check to see if any of the ones Stan has 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. )

Thus, a manager with a secretary who pre-categorizes work may save the
manager time -- a different person in the organization pays the cost
than the person who gets the benefits.

"Uncertainty" in work reduces people's incentives to spend what seems
like "non-productive" time on organizing -- causing an overall
decrease in productivity.  If a project is "on hold" for an
undetermined amount of time, if people are "about to move", etc., then
behavior changes.  People must make the trade-off.  If you think
you'll move soon, wait to do the org activity after the move, to make
it more productive.  If you think it will be a long time -- do the org
behavior now and get on with things...act as the uncertainty isn't
there.  Could we measure productive/less productive people -- or
people at different times in their work lives in more or less
uncertain times and find out if there is an overall productivity cost?
If so, is this really the reason?

Cost of not knowing that your office will be moved.  Don't do some
of the organizing activities that help day-to-day, because it is
assumed that everything will change again soon.  So you stay in
a disorganized state for a long time -- since the state of uncertainty
seems to usually extend past the predictions.  (Mark Twain -- nothing
so surprising as an event, long predicted, that finally comes.)


The idea for the Information Lens was based on the belief 
people to manage an increasing volume of electronic mail.  As a member
of a leading edge research community, Malone was exposed to the
technology at an early stage in its evolution and was able to observe
the problems that would later face people other organizations that
rely heavily on electronic mail for internal communication.

The specific design of the solution was deeply influenced by the
computer and organizational environment in which it was created.  For
example, the notion of the "anyone" server is interesting to an
organization that conducts all of it's "broadcast" message traffic
through distribution lists, rather than through electronic
conferences, such as Netnews.

Reasons for developing own version (three): versions one, two were slow,
buggy, characteristics like "next" didn't work and were expected to.
No examples, too complex.  Didn't know what to use it for.  (But SL
made 98 rules.)

What about the costs of using the new technology?  People tend to think 
about the benefits of introducing a technology, but not about the 
extra burdens it creates.  some of these burdens are quite small --
eg. looking through a large message type tree to select a message
to send, rather than simply sending it -- but they affect the users'
perception of the system.  

Lens may be seen as a diagnostic tool, to discover the kinds of
activities the organization is engaged in and what it considers
important.  It can be a diagnostic tool for finding out what the
organization does.  Note, too, that the ability to record data (a tool
for researchers), has an important impact on the user's reflection
about his or her use of mail -- which causes change in and of itself.

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.

From a software manufacturer's perspective, each release of the 
software provides new functionality and solves some or all of 
the "known bugs".  While this works find when the "user" of the 
software is another program, it doesn't work as well when the 
users are people.  

If people never customized (or established standardized patterns of
use), then software upgrades would not present a problem.  Users would
simply stop using the software in the old way and begin using it in
the new way.  However, users invest time in learning to use software
in a particular way.  They customize it, influenced by advice from 
others in the organization.  Although most people express dissatisfaction 
with some of the characteristics of the software, they rarely spend 
the time to make it perfect.  It's good enough.  When a new version 
of the software appears, it rarely simply adds features.  It often 
changes things that the user is used to, which causes the user to 
learn something new.  The Athena study shows that users avoid this 
wherever possible -- preferring to return to a less-efficient but 
more familiar interface. 

Will different people act in this "sharing" role (get a better term,
like gatekeeper) for different software applications?  Or will the
same people share their files across applications.  (The Lens study
found that individuals sorted themselves into different areas of
expertise.  Other users came to know who was knowledgeable about which
area and would tend to ask that person for help and forward
interesting information to that person.  Customization files may be
that way too.)

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".

These patterns of sharing are similar to those found by Allen (1972)
@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.)

Users have a number of incentives to share customizations, including
taking advantage of 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.  

Three factors appeared to have a strong influence on user's choices
about how to use Lens: reflection about their own use of the software,
the behavior of others in the organization, and external events.
 
(caused by external events such as visits by the interviewer,
viewing of the Lens profile, recreating rules because of an impending
trip or a conversion from one version of the software to another).

If we looked in different organizations, would we find these 
customization gatekeepers?  Is there an optimal level for each?

I would predict that users fit into three different categories: Some
people are not interested in customization or in sharing their
experiences with others, either because they do not have the technical
skills or they do not find it particularly interesting to do so.
Other people have sufficient technical skills or are willing to learn
them, but don't share their customization files because other people
in the organization already have those roles.  The third category are
the relatively small number of people who like to share their
customizations with others in the organization.  I found two kinds of
these people: those without many social skills who want other people
to use the system as they do (often very technical "hackers"), and
those who interpret the other persons job and moderate the kinds of
advice and help they give based on a combination of their own
experiences and their perceptions of the other person's.  The rewards
for sharing files may be a combination of wanting to help others,
obtaining recognition for technical expertise, and wanting to 
help people in the organization be more productive.  Since most 
people do not want to spend much time customizing, they also don't 
want to talk to everyone in the organization about it.  Thus, there 
is a limited amount of recognition to go around -- if a person 
who was a customization expert in one organization arrives at 
a new organization, I would predict that he or she will only become 
a customization expert is the role is not already filled or if
the new-comer has sufficiently greater skills and desire to do 
this than the existing person.  Similarly, if one customization 
expert leaves the organization, someone else will start to fill 
that role.

If this is the case, then there should be a self-regulating number
of customization experts in each organization.  

@subsection[Implications For Software Design]

Software manufacturers, in response to customer demand, are
increasingly making software applications customizable by end users.
However, the results of this study indicate that customizable software
is not always used in the manner in which it was intended.  Software
design decisions will affect how individuals customize and how these
customizations are shared 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. 

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 (Mackay, 1988d, Allen,
1972).@citemark[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.

Because software is not always used in the manner in which it is
intended, design decisions are important because they affect how
individuals customize and how these customizations are shared within
an organization.  For example, customizable software with a "direct
manipulation" interface may be easier to use but harder to share.
Software designers should consider how to assist the people who become
the translators or sources of customizations for their peers.  The
quality of the examples they create will affect the overall perception
and use of the manufacturer's software.

@end[comment]

