Talk at CRL:  Users and Customizable Software:  A Co-Adaptive Phenomenon

Why should we care about Customization?

Three different levels:

1.  Customization itself is interesting:

	We have misconceptions about it
	SW manufacturers want to do it more, but for the wrong reasons
	It has an interesting effect on individuals and organizations

2.  Customization is easier to study than two harder problems:
	Learning and innovation.  Yet many of the issues are 
	the same, so solutions here may provide insights there.

3.  Customization provides a way of studying co-adaptive phenomena:
	Leaves artifacts -- helps to explain a way that users
	can modify and appropriate the techonolgy they use 
	at an individual and small group level.

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

What is customization?

May be defined in different ways.  You have an intuitive understanding 
of customization...But I'll use a more precisely defined subset 
to make the analysis more rigorous.

-->

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

What do we already know about customization?

1.  SW Manufacturer's perspective

	Good marketing tool -- single software works
	for multiple users.  Better = more features

2.  User's Perspective

	I can do it ... but mostly don't want to

3.  Organizational Perspective

	Individual activity -- not org. problem unless
	someone's environment is very different from 
	anothers and prevents cooperation/help

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

Is this right?  What happens when we take a look at an organization?

First, let's do it from a theoretical perspective --

Should we ask what happens when customizable SW is introduced?
	e.g. the effect on users?

Or should we take an org. behavior perspective and look at 
	how an organization causes technological choice?

Neither appears adequate -- would miss something.  So let's 
look at both.

Adopt the Giddens/Orlikowski model...with multiple influences.
	Particular interest in the individual -- the co-adaptive
	nature of people's relationship to technology.

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

Theory :  Present picture

Co-Adaptive:  Present definition

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

What does this theory/co-adaptive perspective buy us?

We'll see different results...If we took perspective A, we'd miss....
If we took perspective B, we'd miss ... 

But the results show ...., which requires both.

(Justify this ... users innovate and change the technology -- 
but they are also changed by the technology.)

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

A note on methodology:  These are human-made artifacts, used by 
people and the people change them.  Thus, many of the notions 
of holding everything constant and studying the variable that 
changes tend to obscure the more important things.  Also, we 
want to find out what's really going on -- and sometimes rare
events are as interesting or more interesting than the "mean"
most common events.  We have to ask why we're asking the questions
before we decide how we're answering them:

Identify phenomena and patterns, challenge assumptions,
verify that certain kinds of interactions occur.


This is not "natural science".  It's something else.  While some 
of the techniques and philosophies of the scientific method apply,
some do not.  In particular, the whole issue of "control" of 
variables, holding everything constant to isolate a phenomenon,
may fundamentally miss the point.

Rather than doing bad science, let's rethink what we want to know.

We need to be able to build things and we need to understand 
that people will use the things we build in new ways.  They 
will innovate and they will both change and be changed by the 
technology.  This is one of the reasons why participatory 
design and iterative design techniques are so important.

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

What's the first story:

Start with Lens -- a co-adaptive phenomenon.

Show how it changes over time.

What's the second story:

Athena/customization.  Different software, same phenomena.

People take on certain roles.  People object to certain kinds 
of activities.

Matches what I found with resistance to learning.

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

What are the assumptions about how people customize software?

1.  Solitary activity
2.  People actually do it
3.  More features are better
4.  Not very important

What actually happens?

1.  A small number of people customize a lot, most don't.
2.  Of the people who don't or do it rarely, they often get 
    customizations from other people.  (not necessarily 
    ideal ones).
3.  The files don't go away.  Most people take the first thing
    they get and leave it.  They don't get feedback and 
    they don't change it unless it starts to cause a visible 
    error.
4.  Because customizations continue to affect behavior, they 
    are very important.
5.  They are often the source of user innovations, and the 
    methods of exchange are the same as for other kinds of 
    innovations.



Why study customization files?

1.  Interesting by itself
2.  Findings from customization may help us better understand 
    more complex topics:  learning and innovation.
3.  They leave artifacts that continue to affect behavior.
4.  The artifacts can be studied.
5.  The artifacts facilitate exchange among people and 
    the exchange patterns can be studied.
6.  Can identify the triggers and barriers to customization
    and perhaps generalize to other activities.

Methodology note:  people have a hard time remembering where they 
got things from.  They do better when they look at the file and 
try to describe where something came from.


Situation in VCG -- Russ performed the role of customization czar for
a while, then Jud took over.  Jud's comment that Michael probably had
the most prototypical VCG customizations, but he's "too smart to lend
it to other people because he know's he'll have to support them."
Jud doesn't like to customize, but when he does, he likes to share 
it with the others in the group.

There's a real cohesiveness to this group, much more so than any of 
the other groups at Athena.

Graphing this -- can't do geographic distance easily, because we've 
just had a major office change.

=========

Customizations borrowed from other people may change your 
way of working.

For example, if someone else puts up a load average, 
or a websters it clutters up your screen -- and may 
induce you to use it.  Similarly, with LOGOUT button.


===========

Back in  LENS data -- system programmers aren't the only ones with 
lots of rules.




