Computer Supported Cooperative Work9: 75–100, 2000.© 2000Kluwer Academic Publishers. Printed in the Netherlands.

75

Tailoring as Collaboration: The Mediating Role ofMultiple Representations and Application Units

ANDERS I. MØRCH1 and NIKOLAY D. MEHANDJIEV2

1Oslo College, Faculty of Engineering, 0254 Oslo, Norway;2School of Management, University ofHull, Hull HU6 7RX, UK

(Received 5 February 1999)

Abstract. In this paper we see tailoring as indirect long-term collaboration between developers andusers: initiated by developers when they build software systems, and responded to by end users whenthey later tailor the systems. We have identified two features we consider important when supportingthis kind of collaboration: multiple representations and application units. Their main benefit is thatthey can enhance communication between developers and users, hence making it easier for usersto do the tailoring. We present two tailorable systems we have built to test these ideas. One of thesystems (ECHOES) is a collaborative system based on multiple representations, and the other system(BasicDraw) is an individual productivity tool based on multiple representations and applicationunits. We discuss lessons learned from the two projects and suggest directions for future work,including identifying some challenges that need to be overcome in order to bring end-user tailoringout of the prototyping laboratory and into user organizations.

Key words: application units, end-user tailoring, indirect long-term collaboration, multiple represen-tations, tailorable software systems

1. Introduction

We consider tailoring to be the activity of modifying an existing computer systemin the context of its use, rather than in the development context. In this paper weare concerned with tailorability as collaboration between developers and end-usertailors. From this perspective, we identify features of tailorable systems that areneeded to support such collaboration. These features are common to both group-ware systems such as workflow systems and to single user applications (individualproductivity tools).

1.1. WHY DO WE NEED TAILORING?

The main reason for tailoring, as we see it, is to account for the contrast betweenorganisational work with its situated, collaborative and changing nature, on the onehand, and the formal theories and models of work that underpin and constitute anyinformation system, on the other hand. There is a “cognitive distance” betweenusing an application and designing it (Malone et al., 1992), because designing

76 ANDERS I. MØRCH ET AL.

an application requires developing formal theories and models (such as computerprograms) whereas using it does not require the same degree of formality. Indeed, itis not a surprise that these models often break down because work is highly contextdependent and dominated by situated actions (Suchman, 1987). Workers thereforeneed the means to tailor the systems when work practices change, when the styleof working changes (Greenberg, 1991), and when systems behaviour has to beoverridden because the situation requires creativity in performing work (Bentleyand Dourish, 1995). Tailoring can be seen as continual development of a formalsystem, gradually leading to a better system through a process that is informed bythe users in the context of their work (Henderson and Kyng, 1991).

Tailoring is often required in order to implement organization-wide standardsfor shared systems, but even the individual productivity tools such as wordprocessors and drawing packages have to be tailored for specific tasks (Trigg andBødker, 1994). In an empirical study of word processor users Page et al. (1996)have shown that users do want custom functionality and that a large majorityof users (92%) do customize their application in various ways, such as settingparameters in preference forms.

1.2. WHO SHOULD DO TAILORING?

We believe that tailoring can only reach its full potential if done by the system’susers rather than by professional developers. This arrangement will bring tailor-ing closer to work so that users can improve their work tools aided by theirdomain expertise (Mackay, 1991; Eisenberg and Fischer, 1994). It will also avoidcommunication difficulties between users and developers (Poo and Layzell, 1992),and it will free developers to concentrate on designing new applications and genericapplication components.

Studies of end user development have shown that “super users” often emerge ina user organization. They are advanced end-users who have accumulated consid-erable expertise in local (in house) development and tailoring. They provide helpand guidance to other users and they train these users to participate in end userdevelopment activities. Super users are also referred to as local developers andgardeners (Nardi, 1993), or wizards and gatekeepers (Mackay, 1990). Super userscan be quite important for successful adoption of tailoring since they are likelyto be among the best qualified candidates to do tailoring. For end-users to beeffective with tailoring applications that support group work, they should also havethe organisational power to change the way work is done in the group.

1.3. FOCUS OF THIS PAPER

In this paper we see tailoring as indirect long-term collaboration betweendevelopers and end-users mediated by a computer system and positioned within the“different time, different place” corner of the CSCW matrix of time/place differ-

TAILORING AS COLLABORATION 77

ences (Johansen, 1988). From our perspective, we focus on the need for multiplerepresentations to support effective communication and shared understanding. Tomake multiple representations easily accessible to end users during use, we use theconcept of application units.

We illustrate our argument with two end-user tailorable systems (ECHOES andBasicDraw), which we have built in our laboratories. These two systems provideuser tailorability for different domains (ECHOES targets workflow systems andBasicDraw targets the domain of generic applications, drawing packages in partic-ular). Although the systems have been developed independently by the authors,we have found remarkable convergence between the two systems. We use thisconvergence, together with our experiences gained from testing the systems withend-user tailors, to support the validity of our argument, which is that multiplerepresentations and application units are useful for end-user tailoring.

We conclude the paper by describing the need to merge the features of bothsystems before embarking on the next stage of our planned work, which is toput tailorable systems to practical uses. During this process we have also built avocabulary for discussing tailorability of software systems.

2. Tailoring as indirect long-term collaboration

2.1. DIFFICULTIES ARISING FROM THE INDIRECT LONG-TERM NATURE OF

TAILORING

This section argues that tailoring is a form of collaborative work where developersand future users of a system engage in a type of indirect, long-term collaborationthat belongs to the “different time, different place” corner of the collaborationmatrix (Johansen, 1988). Developer and end-user are the generic terms we useto describe the two collaborating groups, but each group has a substantial internaldiversity. For example, developers can be further divided into analysts, designersand programmers, and users can be grouped into regular users and super users(which again includes local developers, gardeners, wizards, and gatekeepers).

Communication between these groups of people can be problematic even whenthey meet face-to-face (same time, same place), for example when misunder-standings occur. Although the direct mode of communication has the advantageof providing a richer communication channel for establishing and maintaininga shared context in which misunderstandings can be repaired, each group maystill interpret the context in different ways. This is to a large extent a resultof the ephemeralnature of speech. In indirect communication this problem isaddressed by designing shared representations, which create apersistentcontextfor communication. An example of a shared representation is the architect’sblueprint in the domain of building architecture, which is used by architects,building contractors, and clients to mediate communication during a buildingproject (Harper and Carter, 1994).

78 ANDERS I. MØRCH ET AL.

We compare end-user tailoring to home construction for explanatory purposesand we see tailoring as analogous to further development a building by itsinhabitants (e.g., homeowners). Further development is characterized by users(inhabitants) being separated in both time and place from the original developers.Similarly, end-users use and tailor a computer system in a context that is substan-tially different from the context in which it was first developed. The tailors of bothbuildings and software are well familiar with the functionality of the artifact from“the outside”. In both cases, however, they need to know more about the internalconstruction details and design decisions in order to make useful extensions tothe artifact. In the case of tailoring a building, we can use blueprints as a sharedrepresentation that “ships” information from developers to tailors, in addition tothe information embodied in the artifact itself.

Communication between developers and end-user tailors is primarily uni-direc-tional, because it is often impossible or impractical for end-user tailors to go backto developers to obtain further information. It is equally difficult for developers toanticipate the possible ways an artifact will be tailored in the future. This makesthe goal of creating a shared context that will prevent communication breakdownsmuch more difficult.

2.2. TAILORING AS COLLABORATION TO FURTHER DEVELOP A COMPLEX

ARTIFACT

It can be said that communication between developers and users occurs everytime an artifact is used. What makes tailoring different, though, is the fact thatindirect (tailoring) communication concerns theredesignor further developmentof an existing artifact. Reeves and Shipman argue that to make indirect communi-cation in software design useful it is not enough to have access to technologiesfor e-mail and threaded discussions, because discussion about the artifact mustbe embedded in the artifact (Reeves and Shipman, 1992). Further, preserving thecontext in which an artifact was conceived and designed, makes indirect communi-cation persist and be of value for long-term collaborative design (Fischer et al.,1992).

To participate in long-term communication, end-users need to be able to haveaccess to, read, understand and respond to the materials and artifacts designerscreated and used when they were developing the software system. This kindof information need to be embedded in the system itself and be available tothe users when they later tailor the system. For example, researchers who studysoftware maintenance (e.g. Freeman and Layzell, 1994) have found that organiza-tional goals, business rules and other relevant business contextual information areimportant assets that need to be included in the maintenance documentation, sothat maintainers can understand the context in which the system was developed.

Apart from information about the business context, we also need informationabout the technical design issues and decisions, since the software being tailored

TAILORING AS COLLABORATION 79

is a formal software system where business domain aspects are interlocked withtechnical design aspects.

3. Support for indirect long-term collaboration in tailoring

The factors described in the previous section represent a significant challenge todesigning methods and tools for end-user tailoring. We now present an approachto building tools that can support indirect long-term collaboration in end-usertailoring. The approach is based on the following techniques:

multiple representations that capture and preserve a rich development contextso that it can be shared among developers and users, in addition to allowingusers to control an application system’s functionality, and

application units that make multiple representations accessible to end-usersduring use. Application units create cognitive chunks that are easier tocomprehend than complete application systems.

We describe each technique in detail within the remaining part of this section. Inthe next two sections we illustrate how we have built computer support for multiplerepresentations and application units in two tailorable software systems.

3.1. MULTIPLE REPRESENTATIONS

Tailoring prevents us from taking for granted any shared context of direct (face toface) communication. Instead the context has to be explicitly defined and storedwithin the tailorable system.

A tailorable system, as any other kind of software system, is a formal system.Using formal representations is thus inevitable, and tailoring may require program-ming. Formal notations can be made to work with end users, but they should befairly simple and oriented strictly to user tasks (Nardi, 1993). A programminglanguage for end users should comprise of a small number of domain-orientedconstructs, such as the constructs “sum” and “average” of the spreadsheet formulalanguage. Otherwise users are not likely to have the time nor the motivation to learnthe language.

Achieving simplicity when representing a complex entity such as a softwaresystem is not trivial. One approach is to use many simple representations, eachdescribing a separate aspect of the system. The representations should abstract thetechnical details as far as possible, and provide a user-oriented view of the system.However, in many situations tailoring also requires information about technicaldesign decisions. We thus distinguish between user-oriented and more technicalrepresentations (both kinds are created during the development of a system):

user-oriented representations, which capture high-level views of a system aswell as aspects of the domain in which the system will operate, such asorganizational structure, the flow of information, and “how to use” the system.

80 ANDERS I. MØRCH ET AL.

design representations, which are more technical than user-oriented represen-tations in that they address basic design decisions, and the context in whichthose decisions were made. Design representations thus include answers to“what” and “why” questions. The latter kind are referred to as the system’sdesign rationale (Moran and Carroll, 1996).

We argue that a tailorable system’s multiple representations should be a richset of user-oriented and design representations capturing all tailor-relevant aspectsof the system and its domain of operation. Some of those representations willbe executable, since they describe a system in terms that are translatable intoprogram code. Others will be non-executable, since we are not able to auto-matically generate program code from them. An example of executable designrepresentations is a formal design specification such as StateCharts, an exampleof non-executable design representations can be a design rationale document.

Multiple representations (MRs) are created by developers in different ways.Some MRs are created as part of the system development process (e.g., require-ments specifications). Other MRs, such as design rationale documents, will notalways be available because developers are not required to produce them. In somecases the usefulness of such documents can even be questioned since they are costlyto produce and there is little immediate benefit from making them. Studies haveshown that a large portion of software projects are terminated before there is aneed to tailor them (they are never put to use), and therefore the cost of creatingthe design rationale documents is not paid back to the developers (Grudin, 1996).

On the other hand, to create sustainable software products will requiresuccessful software maintenance, and this is a frequent and costly activity. Freemanand Layzell (1995) have found evidence that shows that maintenance is moreeffective when the software professionals performing it have access to additionalinformation about design decisions and the context in which they were made.

Our approach to this issue is to integrate MR capture into the very essenceof software development, coupling it with the activities designers are engaged inanyway. For example, capturing and preserving a shared context by developersshould require no more work than clicking a mouse button at the right time (tosnapshot a document, to record a conversation, to start a video, etc.). Similarly, itshould be possible to easily dispose of captured contexts when they later turn outto be irrelevant. However, we should not reject all dead-ends. Rejected alternativesthat were highly praised, or alternatives that may turn out to be easier to implementin the future, we may want to keep as alternative designs.

In this section we have addressed some of the factors that are needed to makemultiple representations serve the needs of indirect long term collaboration. Next,we introduce application units as a way to make MRs operational for applicationsystems.

TAILORING AS COLLABORATION 81

3.2. APPLICATION UNITS

Multiple representations (MRs) by themselves are not sufficient for end-users totailor a system, because users will not know (a) which MRs exist, (b) how to gethold of them, (c) how they are connected to other MRs, and (d) how they are linkedwith the rest of the software system. The idea of application units is precisely toanswer these questions. Application units (AUs) are seen as the common buildingblocks of end-user tailorable systems (Mørch, 1995). AUs integrate different MRs,each MR representing a different aspect of the system. The user interface is thepoint of convergence between the different MRs.

By reconceptualizing the basic unit of an interactive system to be an applicationunit rather than an application system, the complexity of interactive systems can besubstantially reduced because applications units are smaller than applications. Anapplication can be partitioned into user-accessible, self-contained application unitsthat group related representations together. This makes the turnaround time fromusing an application to tailoring it shorter, and the effects of tailoring will be morequickly visible to the end users.

An application unit consists of three kinds of representations (MRs), which arereferred to as aspects: (a) user interface, (b) rationale, and (c) program code. Weuse the term aspect to stress that application units are primarily a way of seeingrather than a way of building a computer application. Aspects are a way to concep-tualize computer applications for the purpose of simplifying end-user tailoring. Theidea of application units and their associated aspects has been inspired by the waywe perceive everyday artifacts, such as the TrioVingTM card key shown in Figure1. The card key presents three aspects that provide mutually exclusive views ofits functionalities, and the interface between adjacent aspects is well-defined (theaspects can be formally integrated). By this we mean that aspects cannot be reducedto smaller units other than application units without losing the triadic structure norcan different aspects be analysed by the same methods and techniques.

The interface aspect of an application unit is the aspect the user is most likely tointeract with, since it is the aspect the user is first aware of. The rationale aspect isa collection of uninterpreted (non-executable) representations, both user-orientedand design-oriented. For example, the card key has a non-executable user-orientedrepresentation embedded in the artifact, which tells a user how to operate the cardkey. This kind of representation is meant for a human reader (in contrast to anexecutable specification, which is intended to be also interpreted by the computerto generate code).

Although most everyday artifacts are easy to use, they are not easy to modify.First, they are difficult to modify because they are not meant to be modified. In thecase of the card key, for example, none of the aspects are intended to be modified.Second, they are difficult to modify because the building blocks they are made outof are static (black boxes). Computer applications, on the other hand, have a greaterpotential for modifiability because they are built out of dynamic building blocksthat can be changed by tailoring them at different levels of complexity (Mørch,

82 ANDERS I. MØRCH ET AL.

Figure 1. The TrioVingTM card key illustrates what we mean by application unit (AU). An AUis a partly autonomous and usable building block providing easy access to three different butcoupled aspects (MRs): (a) interface, (b) rationale, and (c) code. The rationale on the card-keyreads: “This side up. Push all the way in.” The rationale is a use-oriented representation createdby an end-user. We argue in this paper that the code aspect should be high-level and notlow-level as shown here.

1997a). However, for this to become an option for end users it should not requirethem to write low-level (computer oriented) code. If they need to write code itshould be at a level that match the task the users wish to perform (Nardi, 1993).

We now present two systems we have built on the basis of the ideas presentedin the previous two sections. The systems have been tested with end-users in twoseparate usability studies. We report on some findings from the studies and discussthe lessons we have learned from this.

4. Two tailorable systems

We are interested in end-user tailoring for different types of software applications,from organisation-wide work coordination systems such as workflows to individualproductivity tools such as word processors and drawing packages. The systemswe describe in this section target the opposite ends of this spectrum: ECHOESallows end-user tailoring of a workflow application, and BasicDraw allows end-user tailoring of a basic drawing tool. We have found the convergence of commontailoring features to be quite remarkable, especially if we bear in mind that the

TAILORING AS COLLABORATION 83

two systems were developed in isolation by authors working in different areas ofcomputer science (Information Systems Engineering and CSCW/HCI).

4.1. ECHOES

ECHOES (Easily CHangeable OfficE Systems) is a research prototype systemthat was built to test some ideas relating to end-user tailoring of organizationalcoordination systems. ECHOES consists of two tightly integrated subsystems, anapplication system and a tailoring interface. The application system functions as astandard workflow application, but its operations (functionality and structure) canbe controlled by non-programmers through the tailoring interface. The tailoringinterface generates a set of representations (MRs), which present the functionalityand the structure of the application system in different ways that we have found tobe useful for end-users. Each representation addresses a different view of the sameunderlying application at different levels of abstraction. Using these representa-tions, certain users can monitor how the application functions, and change it whennecessary.

4.1.1. Rationale

ECHOES was built on the premise that tailoring should be accomplished in anend-user tailoring language that is (a) domain-oriented and (b) visual. A domain-oriented workflow language will use high-level constructs specific to a user’s worktasks such as clerks, activities (or services), information flows, electronic forms,and a set of rules for creating meaningful structures out of these concepts, suchas “a clerk can perform several activities”, “forms travel along information flowsbetween activities”, and so on. Appropriate visual icons can be devised to describeclerks, forms, activities, thus combining the benefits of domain-oriented and visuallanguages. Baroth and Hartsough (1995) claim on the basis of two successfulindustrial-strength visual programming projects that “the most dramatic gains ofproductivity can be attributed to the communication among the customer, thedeveloper and the computer, facilitated by the visual syntax of the tools.” They haveobserved that users “watch over the shoulder” of programmers and comment onthe program while the programmers write code. In addition, once the applicationswere installed, users were able to maintain the applications without help from theprogrammers.

Visual languages lend themselves well to presenting concepts and metaphorsfrom the application domain. Each representation in such a language is made to fit aparticular aspect of the domain, as demonstrated in Figure 2. The figure shows howECHOES represents a small system for processing student applications. The flowof forms between activities is represented by a data-flow based representation at thetop left corner of the figure (the information flow description). This is overlappedby a description of responsibilities of people, the organizational description. Therepresentation of the processing inside one of the activities (we call them services)

84 ANDERS I. MØRCH ET AL.

is partially visible at the back. The snapshot also contains a representation of thedetailed operations that is executed in one of the service description components(bottom right corner of Figure 2). It shows program code written in a high-leveltextual programming language (“Get A; Send to Y”). This language has domain-oriented constructs, which are oriented towards workflow operations.

All representations are executable, and together they form a visual language,where each representation communicates to the end user a small coherent aspectof the application. However, this does not come for free. Each representation needsto be carefully designed and integrated with the rest of the system to help end-usertailors to comprehend and navigate between them. Later in this paper we will showthat integration of MRs can be accomplished by application units.

4.1.2. Implementation

ECHOES was implemented in the VisualWorks Smalltalk environment using theHotDraw application framework (Johnson, 1992). The architecture that underliesthe prototype (Mehandjiev and Bottaci, 1996) provides the means for interpretingthe representations and making sure that (a) all representations are synchronizedwith each other by immediate propagation of any changes made to any of the otherrepresentations, and (b) new representations can be added when required, and (c)changes in existing representations have minimal effect on the rest of the system.Indeed, the workflow application will still function even if no representations exist,it will just not be tailorable any longer.

4.1.3. Experiences regarding the use of multiple representations

We have conducted an informal study of the tailoring facilities of ECHOES byobserving two end users performing tailoring modifications (Mehandjiev, 1997).The goal of the study was not to prove that end users can do tailoring, but ratherto gain some feedback regarding the use of multiple representations for end-usertailoring. We should stress here that full-blown evaluation studies are not feasible atthis stage of our work since this would require long-term observation of enhance-ability practices by a large number of real application managers. This can not beattempted with neither of the research systems presented in this paper, because theywere conceived and implemented as “proof of concept” prototypes to get feedbackabout particular ideas. Therefore they do not provide a comprehensive coverage ofall the features needed for industry-strength applications to be evaluated “out-of-the-labs”, and in the concluding part of this paper we argue that we have to mergeimportant features of our systems before this can happen.

Difficulties in evaluation studies are widely discussed in the literature (Greenet al., 1983; Hoc et al., 1990; Green and Petre, 1996). Visual tailoring systems ofthe scale of ECHOES are even more difficult to evaluate using objective criteria,because the complexity of the system requires complex evaluation scenarios, whichmakes any evaluation study difficult to repeat. The evaluation studies reported

TAILORING AS COLLABORATION 85

Figure 2. A snapshot of ECHOES tailoring interface, which shows several of its visualrepresentations associated with adding a new activity to the system. In order to add a newactivity, the user has to drop a new service symbol from the palette on the information flowdiagram at the top left corner. Then the system will prompt the user to specify who is toperform the new activity (service). This is shown in the organisational description at thebottom center. Then the new service will be added to the system, with a default representationof the processing inside it. A fragment of this representation, which is more technical thanthe other representation, is shown at the top right corner. Elements of the processing inside aservice can be further expanded into statements in a high-level textual language as shown inthe bottom right corner.

in the literature are predominantly qualitative and informal. In one such study(Malone et al., 1992), the modelling power of the system is tested by constructing arange of different applications. That study does not attempt to evaluate the systemwith end users. The authors of another study (Baroth and Hartsough, 1995), alsoreport empirical data from qualitative observations of the use of commercial visualprogramming systems (LabView and VEE).

The studies reported here have been designed to test the facility ofusing multiple representations (ECHOES and BasicDraw) and application units(BasicDraw) for end-user tailoring. The ECHOES study used a combination of“think aloud” protocol analysis and semi-structured interviews. It consisted ofobserving two users when they were performing tailoring tasks. Each user wasobserved by two evaluators. The actions and utterances of the users were capturedon videotape. To reduce intrusiveness, the camera was pointed at the screen frombehind their backs. The material from the videotape was later transcribed, and the

86 ANDERS I. MØRCH ET AL.

notes were compared with notes taken by the evaluators. These observations werecomplemented by semi-structured interviews with each user before and after theevaluation study, on which users were asked to fill in a short questionnaire.

The two users were selected to match the expected profile of end-user tailors.Both are administrators at the University of Hull, and they had both taken part inmanual workflow systems similar to the ones they were asked to modify. They arenot computer programmers or designers, although they use computers at quite anadvanced level. They would fit into the category of “super users” described earlier.

After a short training and introduction to a particular workflow system, eachuser was given a problem scenario and asked to perform several tailoring tasks.Both scenarios involved adding a new activity to the system in a manner quitesimilar to the situation described in Figure 2. In order to accomplish these tasks,users had to modify the flow of work in the system by changing the informationflow diagram, and to modify the form routing behavior specified inside servicedescriptions by creating new routing rules.

4.1.4. Summary of results and lessons learned

Both users were able to perform the tailoring scenarios. Our ideas regarding thefacility of multiple representations were supported. Indeed we found that the users’efforts were helped by the use of multiple representations, which formed a highly-interactive domain-specific tailoring language. The importance of domain expertisecame through quite strongly, suggesting that a successful end-user tailor should beexpert in the application domain.

Both users showed good command of multiple representations (MRs). We usedvisual representations for most of the MRs, but only those visual representa-tions that were designed to fit the underlying programming paradigm well werepreferred, as was the case with the information flow description (see Figure 2).Text-based representations were preferred in other cases. For example, both usersexpressed certain form routing rules as textual rules. They also seemed morecomfortable with textual rules for describing what happens inside a service.

The multiplicity of representations by itself did not confuse the users. Noneof them confused representations relating to different domain aspects even whensome of the representations were quite similar in appearance. This was the casewith the information flow description (behavior), and the organizational description(structure), which shared virtually identical symbols. None of the users mistookone for the other, or tried to relate them in incorrect ways. This was not the case inthe opposite situation, where two representations (information flow and servicedescription) were related to the same domain aspect (organizational behavior).These representations had quite different appearances and were based on differentparadigms (data flow and control flow), but they were still mistaken by both users.This shows that to optimize the benefits of MRs, they have to be carefully chosen,and integrated both in terms of the tailoring interface and in terms of the aspectsthey represent. It seems that careful aspect-oriented design of any MR language

TAILORING AS COLLABORATION 87

is needed to ensure the proper level of consistency and integration when tailoringdifferent MRs.

Another interesting lesson we learned concerned the use of the multi-representational tailoring language for system development. One of the workflowapplications was successfully built using the tailoring language itself. Furthermore,printouts of different representations in this language were used as requirementsanalysis diagrams during the development. This experience is further discussed in(Mehandjiev and Bottaci, 1998). However, we can not draw any significant conclu-sions regarding the usefulness of our tailoring language because of the small sizeof the application. It is also necessary to re-evaluate the system with a larger userpopulation and to design the evaluation tasks so that they more directly address ourworking hypothesis.

4.2. BASICDRAW

BasicDraw is a tailorable individual productivity tool for creating and editing basicgeometrical shapes. BasicDraw has been tested with end-users in an experimentwith the goal of identifying usability problems with its tailoring interface (Mørch,1997b).

4.2.1. Rationale

BasicDraw was built on the premise of simplifying end-user tailoring by (a) recon-ceptualizing a computer application to be seen not as a monolithic system but asa collection of integrated application units, and (b) making the program code ofapplication units task-oriented, and (c) making the program code easily accessiblefrom the user interface.

Application units (AUs) in BasicDraw are associated with GUI (Graphical UserInterface) widgets. However, an AU is more than a GUI widget: it serves as ahandle for many other representations as well (the GUI view being only one).Application units share many characteristics with software components such asVisual Basic Custom Controls (VBX) and JavaBeans. These software componentsare reusable program modules associated with GUI widgets (JavaBeans can alsohave non-visual components) and they can be combined to create new applications.

Application units are modelled after the structure of everyday artifacts, suchas the card key shown in Figure 1. The card key can be conceptualized as anintegrated unit of three distinct aspects: user interface, rationale, and programcode. Based on this conceptualization each of the three aspects has the followinguseful characteristics: (a) directly accessible from point-of-use (the user interface),(b) connected to one or more adjacent aspects by well-defined interfaces, and (c)can be analyzed on its own terms (allowing separation of concerns). We considerthese characteristics to be equally useful for computational artifacts as they arefor everyday artifacts. This hypotheses has been implemented and tested and wedescribe the results below.

88 ANDERS I. MØRCH ET AL.

4.2.2. Implementation

BasicDraw is implemented in the BETA object-oriented programming language(Madsen et al., 1993) on a Macintosh computer using the MacEnv applica-tion framework (Knudsen et al., 1993). BasicDraw has a set of tailoring toolsembedded, each crafted to support tailoring a specific aspect of the system. Thetools thus allow certain users to modify BasicDraw application at different levelsof complexity (Mørch, 1997a).

Application units (AUs) in BasicDraw are specializations (in the object-orientedsense) of conventional graphical user interface (GUI) widgets (menus, operations,and graphical shapes). An application unit is thus a specialized GUI widget, whichhas been extended with eventhandlers for handling tailoring events. The neweventhandlers serve two purposes: (a) to give end-users access to the different AUaspects (MRs) from the user interface, and (b) to formalize the interface betweenadjacent aspects. The former is accomplished when the user holds down a modifierkey (option/alt, shift, or ctrl) while performing the normal interaction gesture on anapplication unit. The latter is accomplished automatically by the computer (linkingaspects, saving changes when aspects have been changed, recompiling code, etc.)

An example of an application unit is shown in Figure 3. The screen snapshotshows the three aspects of the Scale operation for rectangular objects. This is oneof many AUs accessible in the user interface of BasicDraw (indeed, each GUIobject serves as a handle for at least one AU). By holding down the shift key onthe bounding box of the rectangle (the gesture for scaling) the user gets accessto the rationale, and holding down the ctrl key gives the user access to the code.By holding down the option/alt key the user is presented with a property sheet forcustomizing the AU (not shown in the figure).

To discuss tailoring we have developed a vocabulary, which is introduced andexplained in this section. To support users to do tailoring we have built a set oftailoring tools. The tailoring tools are referred to asaspect editors, and BasicDrawhas three aspect editors – one for each type of application unit aspect (Figure 3).

Customizationis the activity of changing the user interface aspect by settingparameters of user interface objects in a presentation editor (e.g., Mørch, 1998).A presentation editor is a property sheet that allows a user to modify propertiesof presentation objects (i.e., tailoring their “look and feel”). Customization willtypically also include the means for selecting among a variety of configurationoptions, including options that are not directly associated with GUI widgets, suchas the frequency of automatically saving documents in a word processor (Page etal., 1996).

Tailoring of rationale is referred to asintegrationand this is accomplished bywriting design rationale documents, creating design diagrams, and pasting bitmappictures in a drawing editor (the Rationale viewer in Figure 3). None of the inte-grated rationale can be interpreted by the computer. The reason for this is usercomprehension: automatically parsed design specifications are difficult to read byend-users. Rationale is an example of what we previously have referred to as non-

TAILORING AS COLLABORATION 89

Figure 3. The BasicDraw application consists of application units, and each applicationunit has three aspects: interface, rationale, and program code. The screen image shows thethree aspects of the Scale application unit for rectangular objects. The tailoring experimentdescribed in this section required the users to make changes to each of the three aspects.

executable representations. Its main purpose is to serve end-user tailoring in thesame way blueprints can serve building redesign: to answer questions that arerelevant for building: how to use the application, what it does (its design), andwhy it does it that way. The rationales we show in this paper mainly address the“how to use” and “what it does” questions.

Tailoring byextensionis the activity of changing program code. This is accom-plished in an extension editor, which is accessible at runtime. When the extensionsare incorporated into BasicDraw they do not modify the old code – they only add toit. (The old code is displayed in the Implementation viewer of Figure 3.) The mainreason for keeping old code, rather than discarding or overriding it, is safety: toprevent users from accidentally bypassing or destroying mechanisms that alreadywork (because old code is typically connected to other parts of the program in non-trivial ways). The new code to be added has to be compiled and linked with the oldcode before re-executing the application.

Each application unit aspect is to a large extent independent and hence can betailored independently of other aspects. To tailor the code, for example, the end

90 ANDERS I. MØRCH ET AL.

user needs to be concerned with writing new code in an efficient manner (i.e.,using the proper programming language constructs) and effectively utilizing previ-ously written code. On the other hand, to tailor the interface, the tailor needs to beconcerned about how to best support user tasks, and user tasks are different fromprogram code (tasks are typically open-ended and informal whereas program codemust follow the rules of a formal grammar).

Application unit aspects also depend on each other. The consequence of this isthat when one aspect has changed, other aspects and the interface between theaspects may have to be updated as well. For example, when tailoring the userinterface, the tailor will often need to make changes to the program code as well,keeping it compatible with the interface changes made, and vice versa. In eithercase, the rationale may have to be updated. How to re-link aspects can to a largeextent be automated by the computer (saving changes, updating files, compilingand linking code, managing versions, etc.).

4.2.3. Experiences regarding the tailoring of application units

BasicDraw has been tested in an informal usability experiment. The users’ inter-actions with the system were recorded on videotape. The goal of the experimentwas to assess the usability of the tailoring tools described above. Twelve college-level students participated in the experiment. All of them had some knowledge ofprogramming (they had taken at an introductory course in object-oriented program-ming), but for most of them it was more than one year since they had last written aprogram (the majority of the participants were students in social informatics).

Two small but representative exercises were given to the users. One of theexercises is discussed below: how to create a square shape by tailoring a rectangleshape. At the code level the task can be described as how to make a subclass ofthe BasicRectangle class and extending its ScaleObject method by implementing arule saying that the two sides of the rectangle should be of equal value.

The users were also asked to create a menu item for the square shape bycustomizing the shape menu. None of the users had any difficulties doing this.It was accomplished by changing the value of a menu item title in a property sheet(Mørch, 1998). Tailoring the rationale was perceived to be more complex thantailoring the interface, but less complex than tailoring the code.

While talking aloud during problem solving the users revealed they werethinking in both user-oriented and design-oriented terms, but not at the same time.An excerpt from one of the protocols is reproduced in Table I. The excerpt showsUser #9 first thinking about the problem in terms of the user interface and thenswitches to a more design-oriented (but not code specific) level, and finally to thecode level. However, this was not a sequential move because in between the threelevels he would return to a previous level, often the interface, and reformulate theproblem before switching to the design and code-level aspects again (evidenced bythe larger time gaps in the protocol segment, but not actually displayed).

TAILORING AS COLLABORATION 91

Table I. Protocol segment of User #9, which illustrates recurrent tailoring behavior: access toMRs (aspects) at different levels of abstraction during the process of understanding and solvingthe problem, and evidenced by deictic references. Deictic references describe what the user does(points to, reads from, looks at, writes, etc.) while talking

Time Verbal protocol: User #9 in exercise I Deictic references

15:45 I was thinking that if I grabbed up here (on the rectangle) and pulled Tests Scale in draw

it out like this, then it would end up with width and height having window

equal values. . . .

19:09 I have to find the one that has changed the most, get its value, and

set the other (side) equal to that value.

Then, how can I do that? Let me see. Hmm . . . Looks at rationale

19:47 Yes, after I have released the mouse I have a new width and a new Starts to write code

height, and I can find them by using getwidth( ) and getheight( ).

The conclusion we can draw from this small tailoring exercise is that usersfound it useful to have access to different aspects of the application in order totailor it at levels below the user interface. The users would almost always start atthe user interface and then go as deep as needed in order to get the problem solved.During this process they would return to previous levels several times. Althoughthe users were told to tailor the systems at three levels, they were not told to do soin a specific order. The verbal protocol is supported by deictic references the usersmade while talking (see Table I).

4.2.4. Summary of results and lessons learned

All users participating in the experiment were able to complete the two exercises,which required tailoring the three AU aspects of a selected set of application units(similar in complexity to the example just described). After the experiment theusers were asked to fill out a questionnaire to comment on the exercises. One of theusers responded by saying: “It was easy to change the name of menus, then it wasa small step up to understand the rationale and how to use it, but the most difficultwas to understand how to change the BETA code” (User #6). The increasing degreeof difficulty associated with tailoring at the different levels has informed us thatmultiple levels of intermediate representations – to bridge between user interfaceand program code – are necessary for full support of end-user tailoring.

BETA’s syntax was perceived by some users to be difficult, but only one userthought that a scripting language would improve end-user tailoring. Our first inter-pretation of this was that the dividing line between what can be expected ofend-users without any knowledge of programming and what can be expected ofend-user programmers is not, as often perceived, related to the distinction between

92 ANDERS I. MØRCH ET AL.

small languages (with a “little” syntax) and full-fledged languages (like BETA), butrather related to the distinction between high-level task-oriented mechanisms, onone hand, and low-level computer-oriented code, on the other hand. The BETAcode the users had access to was deliberately made to be task-oriented ratherthan computer-oriented. This was possible since the users had only access tothe program code of application units, and application units are, by definition,task-oriented.

However, the above interpretation cannot be used to explain the difficulties theusers experienced when they were writingnew code, which warrants a secondinterpretation. When writing new code they had access to the full power of theBETA language. This was certainly not to their advantage. On a few occasionsthe evaluator had to bring the users back on track when they were trying to figureout what language constructs they had available. They did not need the full powerof the BETA language to make extensions. On the contrary, it seemed to increasetheir chances of getting lost. In such a situation a scripting language, which hasa simpler syntax than a full-fledged programming language, can make it easier towrite program code, because a “smaller” language will be able to constrain thespace of possible extensions (Fischer and Lemke, 1988).

The BasicDraw study suffers from some of the same problems we found in theECHOES study: we need to test the system with more users and to bring in userswho are not trained in computer science. Alternatively we can bring the system outof the prototyping laboratory and into real user organizations. The latter requiresthat the system exhibit industry strength standards. We plan to address these issuesin further work by embedding tailoring tools into commercial application systems,along the lines suggested by Oppermann (1994).

5. General discussion

Our experiences with the ECHOES and BasicDraw studies have provided us withinsights into several issues related to tailoring of software systems. The similaritiesin our findings are significant enough to support their validity, and the differencesin our approaches can be fruitfully combined to suggest some directions for furtherwork. In this section we discuss the similarities and differences, and outline anagenda for further work on end-user tailoring.

5.1. SIMILARITIES

The major rationale informing our work is seeing tailoring as a collaborativeactivity between people (developers and end-user tailors) who are separated in timeand geographical location, and having different backgrounds. The collaboration ismediated by the software system, and this requires a richer communication mediumthan what is required when the same people meet face to face. To provide analternative to a shared (face to face) context, we enriched the two systems with

TAILORING AS COLLABORATION 93

multiple representations. We found that the subjects used these representations andfound them helpful in the tailoring activities. This has a clear potential to expandthe scope of tailorability and to bridge the gap between professional developmenttools, on one hand, and commercial software applications such as word processorsand messaging systems, on the other hand.

To facilitate the access to multiple representations both systems linked represen-tations together around domain oriented concepts presented in the user interface ofthe systems. For example, the concept of a “service” (an activity) in ECHOES inte-grated representations that were concerned with (a) processing inside the service,(b) the flow of information between the services, and (c) the priority of differentservices. The second system, BasicDraw, used Application Units for integratingdifferent representations that the users needed to have access to when they tailoredthe system.

We found that visual languages can be used to facilitate communicationbetween developers and end users about certain aspects of a system. For otheraspects textual languages were found superior. In a well designed tailoringlanguage each aspect of a system should ideally be described using a singlerepresentational paradigm because we found that end-user tailors tend to confusedifferent representations related to the same aspect. How different the symbolsets and techniques for tailoring across representational paradigms should be totake full advantage of the uniqueness of each aspect needs to be further investi-gated.

Both systems used MRs to address aspects of the systems at different levelsof abstraction. The users found this feature to be useful, especially the users whoexperienced difficulties when there was a large discrepancy between the differentabstraction levels. One of the difficulties experienced by several BasicDraw userswas to reconcile the discrepancy between user interface, on one hand, and theprogramming language they had available to make changes to the user interface,on the other hand. When they did not remember what constructs they could use, orhow the constructs should be put together to form correct syntax, the users wouldask the evaluator for assistance. However, when they later found out that relevantexamples of correct code could be copied from other application units, the userswere much more comfortable making code changes.

5.2. DIFFERENCES

The main difference between the two systems is the fact that they target differenttypes of applications (workflow versus individual productivity). Another differ-ence is the degree to which the two systems formalize the notion of applicationunit (AU). AUs are the basic building block in BasicDraw, and they are the mainmechanism for partitioning the system’s complexity into manageable units. Theyare used to define triads of MRs (aspects), which are connected at the user interface.However, each aspect is conceptually different from the other aspects and therefore

94 ANDERS I. MØRCH ET AL.

requires its each own set of terminology and tools (property sheets, drawing editors,code editors, etc.). In contrast, ECHOES uses domain concepts to link togetherdifferent representations in a much more informal way. For example, a servicein ECHOES may be the sole subject of one representation and just a symbol inanother, but it is still used to link and navigate between the two representations.

Another noticeable difference is the manner in which multiple representa-tions are used to enrich communication. Both systems target different dimensionsof richness by using multiple representations for different purposes. ECHOEStargets the domain-oriented dimension with representations that focus on differentaspects of the application domain (organizational structure and information flow),or describes domain concepts (such as “service”) at different levels of detail.BasicDraw, on the other hand, includes both user-oriented and design represen-tations of the system, by showing the design rationale of implementation codeand use-oriented representations for how to use the system. Related to this isthe difference in the degree to which these kinds of representations are inter-preted by the computer. The rationale diagrams in BasicDraw are non-executablerepresentations, whereas ECHOES representations are executable.

There is a great scope of combining these two approaches to further enrichthe information that end-user tailors can tap into when tailoring complex applica-tions. For example, we can enrich ECHOES with a design rationale representationscheme, which would describe basic design decisions and the context in which theywere taken. One such decision may concern the reasons for specializing certain jobfunctions, or the order in which forms are queued for processing. ECHOES hasa rudimentary facility for such representations, called “assumption descriptions”.They are read-only textual representations of the assumptions used to interpret andexecute the high-level visual representations. Re-conceptualising these informaltextual representations as depictions of design decisions with their underlying argu-mentation may provide additional support for the tailoring activities of ECHOES’users.

5.3. FURTHER WORK

The premise of tailoring as indirect long-term collaboration between developersand users has resulted in two approaches. The approaches confirm the usefulnessof multiple representations and application units for enabling end-user tailoring.However, we have also identified shortcomings in our work. We now generalizefrom the lessons learned and we outline an agenda for further work on tailor-ing and ways to expand the scope of end-user participation in systems develop-ment.

If we are to evaluate the feasibility of end-user tailoring in an organizationalsetting, we have to integrate tailoring facilities in commercial-strength products,such as a word-processor or a message-based collaboration system. Indeed,commercial application systems, such as MS Word and Lotus Notes do provide

TAILORING AS COLLABORATION 95

tailoring support at different levels of complexity (user interface customizationand textual scripting languages for integration of new functionality). Althoughthese languages are simpler than full-blown object-oriented languages, they arestill oriented towards the computing domain rather than the application domain(Ousterhout, 1998).

Most users barely ever scrape the surface of the application systems they use.When tailoring takes place below the user interface, the users first have to findout that tailoring is an option and then get access to the tools they need to use.Even when they get access to the tools, such as a toolkit or a code editor, they willexperience that the code they have to write is not in terms of the tasks they wish toperform. We and others (i.e., Nardi, 1993; Eisenberg and Fischer, 1994) have foundthat end users describe tailoring tasks not in terms of a programming language butin terms that relate to the various representations of the task and the system theyhave access to. The distinction between language and representation thus becomessignificant. A challenge is to create a repertoire of intermediate-level representa-tions that can bridge the gap between the highly user-oriented representations, suchas task-domain concepts and visual user interfaces, and the underlying code of theapplication system written in a programming language. What these intermediate-level representations should be is still an open issue for future research. What wehave presented in this paper is a few examples that should serve as a starting pointfor further work.

Another, related direction for further work is to provide high-level, domain-oriented languages from which end-users can build extensions to applications thathave been built with an object-oriented language or a scripting language (Figure 4).Domain-oriented languages will contain only a subset of the language constructsfound in a scripting language, but will provide the end-user with the means tocreate domain-oriented extensions to applications that have already been written(or extended) in a scripting language. An example of domain-oriented extensionsare business rules. Although business rules have to follow a formal grammarthey are oriented towards a specific application domain. As such the distinctionbetween representation and language is less than in a general purpose language.The different domain-oriented representations in ECHOES are examples of busi-ness language constructs. However, a disadvantage of domain-oriented languagesis that they can only be used for a limited number of applications, and for eachnew application domain a new language has to be created. The trade-off betweenspecificity and usefulness of tailoring languages has to be further investigated.

Creating domain-oriented tailoring languages for work coordination, visualcritiquing, and other collaborative application domains is one of the avenues forfurther work we plan to explore. In doing this, we plan to combine the strengthsof the two systems described above by (a) using application units for cognitivepartitioning of the application into manageable chunks, and (b) by enriching thecommunication contents of the tailoring interface through the use of multipleuser-oriented and design-oriented representations.

96 ANDERS I. MØRCH ET AL.

Figure 4. Tailoring by extension needs to be supported by domain-oriented languages ratherthan full-blown programming languages. Tailors need languages that allow them to buildextensions to applications at different levels of abstractions. Languages to support tailoringwill typically be subsets of the languages that are used to develop an application layer. Forexample, to tailor a generic application implemented in BETA, a scripting language that allowsthe user to create extensions to BETA applications will be sufficient. The extensions shouldnot require that old code be recompiled and the new code should translate into code that canbe linked with the runtime system and be available for further tailoring.

6. Related work

Regatta VPL is a system with graphical tailoring facilities for the domain ofcoordination systems (Swenson et al., 1994). Regatta VPL uses a graphical plan-ning tool so that workers can tailor workflow processes on-the-fly by modifyingtheir representations. This encourages iterative development and individual owner-ship of processes. Regatta VPL, however, does not support MRs and this accountsfor its rather narrow communication channel between initial developers of thesystem and the users.

Oval (Malone et al., 1992) represents the “toolkit” approach to radical tailoringwhere applications are assembled from general-purpose building blocks. In Ovalthere are four types of building blocks: objects, views, agents and links. Developersin Oval can develop a range of applications using these four building blocks. Thetailoring and development interface of Oval consist of form-based templates todefine properties of objects and links between them. The objects can have multipleviews. Oval has no scripting language, but it does have a rule-based language forresponding to external events (agents), such as mechanisms for filtering incomingmessages in e-mail applications.

The degree of interactiveness between users and systems is also consideredimportant for success in end-user tailoring (Nardi, 1993; Burnett, 1995). Highlyinteractive languages help users gain immediate feedback from their actions. Thisstyle of interaction provides a closely coupled loop between the users and theapplication, extending direct manipulation from program construction into thestage of program evaluation.

A representative of the highly interactive tailoring systems is CityTraffic, anapplication built using AgentSheets’ visual language (Repenning and Sumner,

TAILORING AS COLLABORATION 97

1995). Users of CityTraffic can change city traffic parameters and even topologyof streets while the cars are running. Repenning and Sumner call this type ofprogramming/interaction “participatory theater”, because it lets the users direct theplay (the behavior of an application) without stopping the play (while the programis executing).

An alternative approach to tailoring seen from the perspective of situated workand how to bypass overly prescriptive application systems is provided by Free-flow (Dourish et al., 1996). Freeflow enables workers to overwrite coordinationplans proposed by the system when necessary. The system uses rich coordi-nation constraints between activities, which enable more flexible coordinationfunctionality.

Software components share many of the characteristics of application units.In fact, OpenDoc part objects and Visual Basic Custom Controls (VBX) haveinspired the idea of application units. However, neither of them treats rationaleas first class entity that is combined with program code and the user interface at thebasic building block level. However, the sophistication of component integrationarchitectures provided by the OpenDoc and ActiveX is beyond the scope of thework presented here.

Application units share the philosophy of the JavaBeans component model, andapplication units are in many ways similar to visual JavaBeans components. A beanis a reusable software component that can be manipulated in a designer toolkit, andit supports the three aspects of application units. Rationale can be integrated in aWeb-browser. However, it is not possible to tailor a bean at run-time, which is aprerequisite for end-user tailoring.

7. Conclusions

End-user tailoring addresses the problem of how to create systems that are bettertuned to workers’ needs and organizational changes. We address this from theperspective of letting the end-users do the tailoring, and we have found that inorder to accomplish this they need both domain expertise and advanced skills incomputer use.

We have presented the results of two PhD theses in which two tailorable systemshave been developed and tested with users. We have compared the features ofthe two systems, in particular features that we consider important when consid-ering tailoring as indirect long-term collaboration between developers and end-usertailors.

We explicitly set out to build better tailoring interfaces by supporting the collab-oration aspects of tailoring. We consider the availability of a rich communicationmedium to be necessary for providing a shared context between developers andend-user tailors, so that the latter group can better comprehend the system andthe design context provided by the former group. The richness of the communi-cation medium can be achieved by multiple representations, while the cognitive

98 ANDERS I. MØRCH ET AL.

complexity of communication and grouping of representations can be managed byapplication units.

Our next logical step will be to merge the features described in this paper into acommercial software system such as a word processor or a message-based collabo-ration tool. We will use such a system as a vehicle for evaluating the opportunitiesand problems born by end-user tailoring.

Technology, however, is not sufficient to solve all problems related to end-user tailoring and indirect long-term collaboration. In order to take advantageof the tailoring technology organizations should not just use the technology tomaintain the old ways of working (to pave the cow paths). Instead they need toinnovate and to come up with new ways of using the technology and to experimentwith new ways of collaborating with each other. This requires also new ways ofseeing technology. What we have presented in this paper is one new way of seeingtechnology.

Acknowledgments

We would like to acknowledge the contribution of Leonardo Bottaci and KristenNygaard, who were instrumental in guiding the work described here. We wouldalso like to thank all users that helped us gain feedback by participating in ourevaluation studies and going through the evaluation scenarios.

References

Baroth, E. and C. Hartsough (1995): Visual Programming in the Real World. In M. Burnett, A. Gold-berg and T. Lewis (eds.):Visual Object-Oriented Programming: Concepts and Environments.Englewood Cliffs, NJ: Prentice Hall.

Bentley, R. and P. Dourish (1995): Medium versus Mechanism: Supporting Collaboration ThroughCustomization.Proceedings of ECSCW ’95 European Conference on Computer-SupportedCooperative Work, Stockholm, 1995. Kluwer Academic Publishers.

Burnett, M.M., M.J. Baker and P. van Zee (1995): Scaling up Visual Programming Languages.IEEEComputer, vol. 28, no. 3, p. 45.

Dourish, P., J. Holmes, A. MacLean, P. Marqvardsen and A. Zbyslaw (1996): Freeflow: MediatingBetween Representation and Action in Workflow Systems.Proceedings of CSCW ’96 Confer-ence on Computer-Supported Cooperative Work, Boston MA, November 1996. New York: ACMPress.

Eisenberg, M. and G. Fischer (1994): Programmable Design Environments: Integrating End-UserProgramming with Domain-Oriented Assistance.Proceedings CHI ’94 Human Factors inComputing Systems, Boston MA, April 1994. New York: ACM Press, pp. 431–437.

Fischer, G., J. Grudin, A.C. Lemke, R. McCall, J. Ostwald, B. Reeves and F. Shipman (1992):Supporting Indirect, Collaborative Design with Integrated Knowledge-based Design Environ-ments.Human Computer Interaction(Special Issue on Computer Supported Cooperative Work),vol. 7, no. 3. New York: ACM Press, pp. 218–314.

Fischer, G. and A.C. Lemke (1988): Constrained Design Processes: Steps Toward ConvivialComputing. In R. Guindon (ed.):Cognitive Science and its Application for Human-ComputerInteraction. Hillsdale, NJ: Lawrence Erlbaum, pp. 1–58.

TAILORING AS COLLABORATION 99

Freeman, M.J. and P.J. Layzell (1994): Experience Realising a Meta-Model for Wide SystemUnderstanding: The Global System Model.Software – Practice and Experience, vol. 24, no.8, pp. 703–728.

Green, T.R.G., S.J. Payne and G.C. van der Veer (1983):The Psychology of Computer Use. London,UK: Academic Press.

Green, T.R.G. and M. Petre (1996): Usability Analysis of Visual Programming Environments: A‘Cognitive Dimensions’ Framework.J. Visual Languages and Computing, vol. 7, no. 2, pp. 131–174.

Greenberg, S. (1991): Personalizable Groupware: Accommodating Individual Roles and GroupDifferences.Proceedings of ECSCW ’91 European Conference on Computer-Supported Cooper-ative Work, Amsterdam, September 1991. Kluwer Academic Publishers, pp. 17–31.

Grudin, J. (1996): Evaluating Opportunities for Design Capture. In T.P. Moran and J.M. Carroll(eds.):Design Rationale: Concepts, Techniques, and Use. Mahwah, NJ: Lawrence Erlbaum,pp. 453–470.

Harper, R. and K. Carter (1994): Keeping People Apart.Computer Supported Cooperative Work, vol.2, no. 3, pp. 199–207.

Hoc, J.M., T.R.G. Green, R. Samurcay and D.J. Gilmore (1990):Psychology of Programming. SanDiego, CA: Academic Press.

Johansen, R. (1988):Groupware: Computer Support for Business Teams. New York: The Free Press.Johnson, R.E. (1992): Documenting Frameworks Using Patterns.Proceedings OOPSLA ’92. ACM

SIGPLAN Notices, vol. 27, no. 10, pp. 63–76.Knudsen, J.L., L. Bak and C. Nørgaard (1993): The Mjølner BETA User Interface System. In J.

Lindskov Knudsen, M. Løfgren, O. Lehrmann Madsen and B. Magnusson (eds.):Object-Oriented Environments: The Mjølner Approach. New York: Prentice-Hall, pp. 227–233.

Mackay, W.E. (1990): Patterns of Sharing Customizable Software.Proceedings CSCW ’90 Confer-ence on Computer-Supported Cooperative Work, Los Angeles, 7–10 October 1990. New York:ACM Press, pp. 209–221.

Mackay, W.E. (1991):Beyond Iterative Design: User Innovation in Co-adaptive Systems. TechnicalReport EPC-1991-130, Rank Xerox Research Centre, Cambridge UK.

Madsen, O.L., B. Møller-Pedersen and K. Nygaard (1993):Object-Oriented Programming in theBETA Programming Language. Wokingham UK: Addison-Wesley.

Maller, V. (1992): User Enhanceable Systems. An Outline Proposal for New DTI/SERC AdvancedTechnology Programme in IT.User Enhanceable Systems: Enabling Technologies, JFIT Prelim-inary Proposals Workshop. DTI, London.

Malone, T.W., K-Y. Lai and C. Fry (1992): Experiments with Oval: A Radically Tailorable Tool forCooperative Work.Proceedings of CSCW ’92 Conference on Computer-Supported CooperativeWork, Toronto, Oct. 31–Nov. 4, 1992. ACM Press, pp. 289–297.

Mehandjiev N. (1997):User Enhanceability for Information Systems Through Visual Programming.PhD thesis, Department of Computer Science, University of Hull, UK.

Mehandjiev N. and L. Bottaci (1998): The Place of User Enhanceability in User-Oriented Soft-ware Development.Journal of End User Computing: Special Issue on Scaling Up End UserDevelopment, vol. 10, no. 2, pp. 4–14.

Mehandjiev N. and L. Bottaci (1996): User-enhanceability for Organizational Information SystemsThrough Visual Programming.Proceedings of CAiSE ’96, Heraklion, Greece, May 1996. LectureNotes in Computer Science 1080. Berlin: Springer-Verlag.

Miller, E., M. Kado, M. Hirakawa and T. Ichikawa (1995): HI-VISUAL as a User-CustomizableVisual Programming Environment.11th International IEEE Symposium on Visual LanguagesVL ’95. IEEE Computer Society Press.

Moran, T.P. and J.M. Carroll (1996):Design Rationale: Concepts, Techniques, and Use. Mahwah,NJ: Lawrence Erlbaum.

100 ANDERS I. MØRCH ET AL.

Mørch, A. (1995): Application Units: Basic Building Blocks of Tailorable Applications.Proceedingsof EWHCI ’95 East-West Conference on HCI, Moscow, Russia, July 1995. Lecture Notes inComputer Science 1015. Berlin: Springer-Verlag, pp. 45–62.

Mørch, A. (1997a): Three Levels of End-User Tailoring: Customization, Integration, and Extension.In M. Kyng and L. Mathiassen (eds.):Computers and Design in Context. Cambridge, MA: MITPress, pp. 51–76.

Mørch, A.I. (1997b):Method and Tools for Tailoring of Object-Oriented Applications: An EvolvingArtifacts Approach. PhD thesis, Department of Informatics, University of Oslo, 1997.

Mørch, A.I. (1998): Tailoring Tools for System Development.Journal of End User Computing, vol.10, no. 2, pp. 23–30.

Nardi, B.A. (1993): A Small Matter of Programming: Perspectives on End User Computing.Cambridge, MA: MIT Press.

Oppermann, R. (1994):Adaptive User Support. Hillsdale, NJ: Lawrence Erlbaum.Ousterhout, J.K. (1998): Scripting: Higher-Level Programming for the 21st Century.IEEE Computer,

vol. 31, no. 3, pp. 23–30.Page, S.R., T.J. Johnsgard, U. Albert and C.D. Allen (1996): User Customization of a Word

Processor.Proceedings CHI ’96 Human Factors in Computing Systems, Vancouver, 13–18 April1996. New York: ACM Press, pp. 340–346.

Panko, R.R. (1988):End User Computing: Management, Applications and Technology. John Wiley& Sons.

Poo, D. and P. Layzell (1992): An Evolutionary Structural Model for Software Maintenance.Journalof Systems and Software, vol. 18, no. 2, pp. 113–123.

Reeves, B. and F. Shipman (1992): Supporting Communication between Designers with Artifact-Centered Evolving Information Spaces.Proceedings CSCW ’92 Conference on Computer-Supported Cooperative Work, Toronto, 31 October–4 November 1992. New York: ACM Press,pp. 394–401.

Repenning, A. and T. Sumner (1995): Agentsheets: A Medium for Creating Domain-Oriented VisualLanguages.IEEE Computer, vol. 28, no. 3, pp. 17–25.

Shu, N.C. (1988):Visual Programming. New York: Van Nostrand Reinhold Company Inc.Suchman, L (1987):Plans and Situated Actions: The Problem of Human-Machine Communication.

New York: Cambridge University Press.Sumner, T. and M. Stolze (1997): Evolution, Not Revolution: Participatory Design in the Toolbelt

Era. In M. Kyng and L. Mathiassen (eds.):Computers and Design in Context. Cambridge, MA:MIT Press, pp. 1–26.

Swenson, K.D., K.T. Irwin, R.J. Maxwell, T. Matsumoto and B. Saghari (1994): A Business ProcessEnvironment Supporting Collaborative Planning.Journal of Collaborative Computing, vol. 1,no. 1, pp. 15–34.

Trigg, R.H. and S. Bødker (1994): From Implementation to Design: Tailoring and the Emergenceof Systematization in CSCW.Proceedings CSCW ’94 Conference on Computer-SupportedCooperative Work, Chapel Hill, 22–26 October. New York: ACM Press, pp. 45–54.