

An optimal level of customization is based on a trade-off between time
spent customizing and benefit received from those customizations over
a period of time.  In order to understand how users make actual
trade-offs, it is important to identify the triggers and barriers to
customization.  This will enable us to increase user satisfaction
and/or productivity by adjusting the perceived costs and benefits and
increasing the likelihood of making an optimal set of customizations.

What happens when things break?  Most of the time, they are just
ignored.  

Users with an external reason to modify their work environments, such
as a software upgrade or a trip, will be more likely to begin proactive
modification of their work environments.  This is because there is
a cost associated with modification/innovation/coordination.  In order 
for people to do it, the costs have to be below a certain threshold 
or the benefits above a certain threshold.  If external events have 
already caused the user to "pay" the costs of modification, then 
the incremental costs of additional modification will be lower, and 
thus the user will be more likely to do it.


Many of these factors influence behavior at the same time, and the
patterns of customization for the organization may be obscured if
simply summarized.  For example, during exam week, people are
generally overloaded.  Students are studying, faculty are developing
exams and completing work before the end of the term, and the
extensive use of the system requires the Athena staff to operate at
peak levels.  In such a case, should we expect greater or lesser
levels of customization?  Some people are overloaded and simply not
interested in doing anything that would distract from the current work
load.  Others, however, may decide to "procrastinate" by customizing
their workstations, or decided that certain customizations are necessary
to improve efficiency -- the volume of work is sufficient such that 
customization is now worth doing.  It is difficult to distinguish 
among these situations without looking at individual cases.  This 
has implications if one wants to artificially induce changes...

External events may have interesting effects on customization 
activity.  For example, an unplanned event, such as an 
earthquake, may cause everyone to spend time organizing 
their work.  @comment[ Nobody has "time" to 
spend 2 days cleaning up their office, much as they'd like to.
But when all the contents of the office are on the floor anyway,
they have to put it back together again.  At that point, the 
relative cost is lower -- so people spend the extra time cleaning 
up.  (also, it's "soothing" for some people -- you can move into 
a zen-like state -- different than "working" or creative work.)

On-the-edge (not overwhelmed, because they don't optimize).  People
have something important to do and know that there's a faster way.
If the need is great, some may try to figure out the new way to 
do it.  (Anecdotes:  learning to program vs. reading paper tapes 
by hand.)]

What about the risks associated with customization?  These can 
take several forms.  A new change may have an unexpected 
effect.  If the effect is positive, the user may be pleased,
or innovate further.  However, the effect may make other software 
stop working or cause unexpected problems, such as corrupting 
data.  Such changes are especially dangerous if the results 
are not fully understood.  Adopting someone else's customizations 
can also have negative effects, especially if the original 
author made assumptions about the recipient's software 
environment that do not hold.  Finally, some customizations 
may be "hacks", which take advantage of bugs or features in 
the software.  When new versions of the software are introduced,
these kinds of customizations are particularly likely to break
and cause problems.

The perceived benefits associated with customization are affected by
whether or not they are short or long term.  Some changes are
relatively simple and have a large effect, such as creating a command
to do something that is repeated often.  Other changes may result in
changes in overall patterns of work (e.g. Lucy no longer reading
unimportant messages.)  Other changes require a lot of learning and
are used rarely (some kinds of emacs and Unix commands).  The ease of
access to the command is important.  (If you already remember it, it
may be easier to type something, as a touch typist with your hands on
the keyboard, than moving a mouse to get to something that is on the
screen.  Difference between syntactic languages: generative and lists
of things that you get with menus.)

Discuss why people don't customize more?  Similar to questions 
about why they don't spend time doing something that will 
ultimately be useful - boy on the bicycle story.  Relate to 
findings about delayed reinforcement in Psychology.

What are the barriers to customization?  One problem is the difficulty
that users have in being explicit, articulating what they want.  For
example, in the Information Lens study, users aren't usually conscious
that they manage mail differently at different times.  Articulating
rules that take these differences into account is difficult.  Since
the benefits accrue to the recipient (with message types) or at some
future time for the composer (with rules), the short-term incentives
to do it may be relatively too high.  Also, it's hard to be explicit
about things done unconsciously -- perhaps a better system would be
something with neural net or tutor -- observe behavior, feed it back.
Discussions with Debbie: we often have unseen assumptions about how
communication works, which break down in surprising ways when we build
systems that we assume mimic some part of human interaction.  Colab
example.

Editor tutor example: the costs of learning varies according to what
is already known and the complexity of the concept.  If a complex
procedure is relatively difficult to learn, such as creating macros,
and is rarely used, users will not find it worth the time to learn.
In most systems, there is a cross-over point after which it no longer
makes sense for users to learn new features.  However, Mackay (1985)
demonstrates that even experienced users may be far from this point
(secretaries with over 1-1/2 years of experience who did not know the
technique for "cut and paste".)  Not only do developers often focus on
adding features, but they often do so at the expense of making the
simple things harder.  (hypercard vs supercard.  Raise the threshold
for use) Note different implications for software design...  make it
easier to learn, provide tutoring at appropriate intervals, provide
feedback to users about their own behavior.

Expected interaction effects:


@subsection[Effects of customization decisions]

Affect on future behavior. 

Effects on other people -- lead to next chapter.

@section[Discussion]

People do not customize simply to make individual workstations a bit
more aesthetically pleasing.  Customization is influenced by the
technology (what are the existing defaults, dimensions of
customization, etc.) and others in the organization.  Social process.
Users adapt this complex environment and then struggle maintain it in
the face of change.  They don't optimize (with rare exceptions), don't
have feedback about what does and doesn't work, and don't ever have
the "time" to really do it the way they'd like.  so they live with
suboptimal systems and are greatly influenced by others.

@begin[enumerate]
The Problems With Customizing:  An Example

Case Studies of Customizations
@begin[enumerate]

@end[enumerate]

Common patterns of customization
@begin[enumerate]
Exploring the system

Expressing individual preferences

Innovations

Maintaining stability

Encoding repeated behavior patterns

Sharing work environments

@end[enumerate]

The process of customization
@begin[enumerate]
Deciding what to customize

Deciding when to customize
@begin[enumerate]
Triggers

Barriers

Making trade-offs
@end[enumerate]

Seeking information about customization

Effects of customization decisions
@end[enumerate]

Conclusions
@end[enumerate]


A2 has a great deal of perspective about how people use Athena and how
those uses and needs have changed over time.  She made sure that
questions about customization were not omitted from the set of
acceptable topics, because, although they make up only 10% of the
questions, she feels they are among the most important in terms of
acceptance of the system.  She pointed out that many of the
consultants and users "prepare personal cheat sheets; thus effectively
customizing themselves rather than the software for the uses of the
software that they typically make."

Based on her experiences with consulting for Athena users, she
wrote down a number of reasons for customizing:  

@begin[enumerate]
Efficiency: 
@begin[enumerate]
A memory aid,

fewer keystrokes,

make this release relevantly emulate the last one, 

get default states ready in advance,

form final sets from screen layout

console displays, 

aliases.
@end[enumerate]

Compensate for poorly-designed system or software: 
@begin[enumerate]
reverse the defaults that you hate, 

set appropriate defaults (e.g. set printer to handle PROCHART).
@end[enumerate]

Psychological/social:  
@begin[enumerate]
Hide out with Zephyr so it doesn't tell 
    people what they want to know (i.e. they can't find out if you're
    logged in and what you're doing), 

put up pictures that please you,

display pictures or layouts you authored that signify you or your news, 

provide a cozier environment in public workstation rooms while you use it.
@end[enumerate]

Figure out how to manipulate and navigate the system for its own sake:  
@begin[enumerate]
fun, 

engaging a test of wits, 

to show off.	
@end[enumerate]
@end[enumerate]


@subsection[Deciding what to customize]

Users in this environment have a wide variety of customization
options, ranging from very simple to very complex.  They can affect
the visual appearance of the screen (or the sound), by modifying the
color, font, and background pattern.  They can choose to automatically
run different programs and lay them out on the screen in different
ways.  In addition to customizing the static features of the system,
they can customize processes of use.  These include specifying the
methods of access to different functions or programs, such as changing
key bindings or mouse buttons, or specifying that access should be
provided via popup menus.  Actions that are repeated often may be
saved and performed automatically, at the user's discretion. 
Actions can be performed differently under different circumstances, 
such as when logging in to a different type of workstation or 
when running a demonstration.

@subsection[Deciding when to customize]
@label[decide]

With the exception of some of the system programmers, who pride 
themselves on how much they customize, most people report that 
they "don't customize much".  However, one has to ask "compared 
to what".  For example, A1 says he doesn't customize much, but 
has over 73 customization files, some dating back to 1986.

Almost everyone (over 84%) said that they spent the most time
customizing when they first arrived or when they start using a new
software package.  

@subheading[How often do people customize?]


Compare rates for different categories...

Table @ref[TABLE.customrate] shows how often people customize their
software, based both on self-report and actual customization rates.

The table is divided into several subcategories, to accommodate 
the numbers of files.

What's the point of this discussion?  That there's diversity.  OK.
That different job categories have different customization rates.
That people's self reports reflect (or don't reflect) their actual 
behavior.  Is it necessary to say this?

What percentage of people only customize a file once?

What percentage of people customize more than once a month?

What percentage of people only customize when there's a 
system upgrade??


It is not clear that an "average" customization rate has much meaning 
here, given the diversity in the kinds of customizations performed and 
the events that trigger the customizations.  The data are highly 
variable and ...

Note that ...


@begin[table]
@tag[TABLE.customrate]
@caption[How often do people customize their files?]
@include[TABLE.customrate]
@end[table]


TABLE.changes should talk about the effect of external changes on the
rate and level of customization, so it should include: office change,
job change, organizational change, and list stay same (re: window
manager), updated list of aliases (?), customization rate, and
customization level.


Managers -- beware of introducing new or buggy software.  If you 
force your employees to make an investment in learning it, and 
then remove it for other reasons, they will rightly resent it and 
it will lower productivity.  They will also be less likely to 
devote much time to learning the next system, and may use it 
at a significantly lower level than is optimal.

(Here, people make general purpose collections of customizations
to help people who are making wholesale conversions from one 
environment to another, eg uwm-mwm.  The new defaults assume 
old standards -- which means that the newest people come in 
and get stuff that's really old.)

C7 is an extreme customizer:  "I have sometimes spent more 
time on my own productivity tools than I have on the product.
I've seldom analyzed if it's worth it...You can sometimes 
get the time back, but sometimes not."  

C7:  "I like to fix things the right way -- not just hacks.
I try to avoid taking one copy with one fix.  Instead, I try to 
make them generalizable for other users."  (Note that he 
doesn't know who uses his files, nor does he get any feedback 
about that use.   The exception is is specialized Xload, 
which C6 and a few others use.

=========

E15: He usually waits until something passes a threshold and "becomes
a pain" before he decides to customize.  Or, he'll discover that he
does something repeatedly.  "I rarely see something from someone else
[and use it]."

D6: "I want the route with the least amount of time 
and energy.  If it doesn't work, there's this threshold that 
gets triggered...sometimes it's faster for me to do something
in an awkward way than to streamline it."

E2: "I use an application ferociously for a week... I'll customize
daily until I get it right."

One person described how he learned to use the window manager key
bindings: "I started out with the UWM popup menus.  I thought the key
bindings were obscure and didn't want to learn them.  Over the year, I
didn't feel like I spent time learning them, but obviously I did.  I
don't use the menus now at all".@comment[SW: not part of 51
interviews]


User-customizable software presents an opportunity for people in
organizations to appropriate the technology for their own purposes.
Changes in that software also affect how people work.  The
organizational structure in which users exchange information about
customizing both affects the customizations made and is affected by
the exchange of customizations.

One approach to the study of customization patterns would introduce
customization features and observe both use and changes in patterns of
work behavior.  People either will or won't use these features, or
they'll use them in unexpected ways.  This approach would be of
particular interest to software designers and those interested in the
characteristics of user innovation.

A second approach would observe the decision-makers in an organization
adopt technology and evaluate the extent to which they encourage or
discourage the use of customizable software.  This approach would be
of particular interest to organizational theorists. I propose to
combine these approaches, observing both the effect of introducing
customizable software and the ways in which the people in the
organization appropriate the technology for their needs.  By exploring
both, I hope to see more cyclic patterns in which effects of the
technology affect behavior which in turn effects the technology.

User customizable software has several unique characteristics that
make it especially suited to this co-adaptive type of analysis.  Not
only does the software encourage changes by the user, but those
changes leave artifacts that can be studied.  Rates of change, changes
with respect to external factors, patterns of propagation of files
throughout the organization, and the norms of behavior that become
established can all be studied.

The preceding example illustrates some of the triggers that result in
customization activity and the barriers that prevent it.  Participants
in the study were asked open-ended questions about their customization
activities and asked specifically what the triggers and barriers are.
The following sections explore these factors.

All of these factors create the context in which the user makes 
decisions about customization.  (These factors also influence 
other decisions that the user makes, such as whether or not to 
learn a new feature or whether or not to spend time developing 
an idea that could become a useful innovation.)


