Conference PaperPDF Available

Back to the future of EUD: the Logic of Bricolage for the paving of EUD roadmaps

Authors:

Abstract and Figures

Several recent approaches to EUD increasingly recognize an active role of users in the construction of the tools that support their daily practices. However, there is still a lack of a general framework that could play a role in the comparison of existing proposals and in the development of new EUD solutions. The paper proposes a conceptual framework and a related architecture, called Logic of Bricolage, that aims to be a step further in this direction. The concluding remarks point to the potential value of this conceptualization e�ffort in the EUD fi�eld.
Content may be subject to copyright.
Back to the future of EUD: the Logic of
Bricolage for the paving of EUD roadmaps?.
Federico Cabitza, Carla Simone and Iade Gesso
Universit`a degli Studi di Milano - Bicocca
Viale Sarca 336, 20126 Milano, Italy
{cabitza,gesso,simone}@disco.unimib.it
Abstract
Several recent approaches to EUD increasingly recognize an
active role of the users in the construction of the tools supporting their
daily practices. However, there is still a lack of a general framework that
could play a role in the comparison of existing proposals and in the
development of new EUD solutions. The paper proposes a conceptual
framework and a related architecture, called Logic of Bricolage, that aims
to be a step further in this direction. The framework is described and
the architecture instantiated in three concrete EUD environments (the
development of a document based application, the integration of existing
applications and the construction of mashups) to show its generality and
applicability. The concluding remarks point to the potential value of this
formalization effort in the EUD field.
1 Introduction
In the construction of software applications the separation between designers and
users has been criticized by the research community since the raise of Participatory
Design (PD) in the early 1970s [
27
]. Since then, users’s involvement in this process
of tool construction has evolved from the definition of system’s requirements and
the validation of mock-ups and prototypes into a more active participation in the
actual development of the solution. The combination of PD with some principles
of ethnomethodology led to emphasize that the process does not end with the
deployment of a solution (what in [
1
] we called Wildingist approach); but rather
it continues during the use of the system in the situated organizational context for
lots of good organizational reasons: e.g., users keep identifying alternative ways
of using/bypassing their tools; and express ever new needs in front of changes of
the context of use that require the system to evolve in an almost perpetual and
Tantalusian way. Indeed, the terms co-evolution and co-realization [
17
, p. 60]
have been introduced to point exactly to this phenomenon, which is a special case
of collaborative work among different peers involved in system’s construction.
As a parallel research activity – although deeply influenced by the above
approaches – End User Development [
20
] (EUD) has sought a way to respond to
?
This is the long version of the short paper published on the Proceedings of the
Fourth International Symposium on End-User Development, IS-EUD 2013, June 2013
Copenhagen, Denmark.
the users’ need to tailor, adapt or even partially reconstruct the IT systems that
are offered to them usually on the basis of only managerial choices and decisions
that regard merely technological and organizational aspects.
Irrespective of the different underlying disciplinary stances and of the histor-
ical evolution of the approaches mentioned above, we see researchers reach an
increasing agreement upon a set of tenets that are common in their solutions.
First, the awareness that still widespread approaches to design that are rooted
in the so called rational mould have to be abandoned in favor of a more col-
laborative relationship between designers and actual end-users (not only their
representatives): this insight brings to value methods and contributions from the
CSCW community and endorse them also for EUD design. Second, the awareness
that times are ripe for a re-interpretation of the traditional roles of “user” and
“designer”, in the light of the new understanding of what can guarantee a better
technological outcome; in [
1
], e.g., we submit that users should feel themselves
committed in a more and more active role in the development of their own tools,
while designers should limit themselves to carrying out a sort of maieutic task, so
as to increase the users’ awareness of what they can get by themselves or envision
in terms of feasible technology, and of how they can satisfy their ever-evolving
needs with such technology. This insight tries to go beyond complex (and open-
ended) questions about who intended end-users of EUD really are and can do
(e.g., [
17
,
3
,
16
]), as long as they are made more involved in IT construction, and
designers consequently less involved. Third, the awareness that there is a need
for methods and environments that coherently support the involved stakeholders
in EUD activities in light of the former two principles.
Besides this widespread awareness, also some terms have been (increasingly)
used in the related literature and have so far become familiar to EUD researchers:
terms like bricolage [
19
,
5
], facilitator [
17
], appropriation, task-artifact cycle [
16
]
and the like (although often with slightly different interpretations by different
authors). We take this recent convergence and shared acquaintance with key
concepts as the necessary, but not yet sufficient, precondition to take a more
effective action to make research contributions more influential on professional
practices. The paper aims to contribute a step further in this direction to fill an
apparent gap in current EUD debate, where a purposely general framework has not
yet submitted as a concrete reference that could help interested researchers bridge
existing EUD initiatives, as well as help EUD practitioners use concepts that are
unambiguous in meaning and definite in scope. We call this still intrinsically on-
progress conceptual framework for the conception of EUD enabling environments
“Logic of Bricolage” (LOB), after Lanzara seminal, and to some extent pioneering,
contribution to the field [19].
The paper starts presenting the LOB framework and then its instantiation in
three different, but relevant to our aims, EUD application domains: the case of
the construction of document based collaborative applications and information
systems; of the integration of existing devices and software components in a
collaborative setting; and of the integration of heterogeneous content in collabo-
rative mashups, be them both event-driven and data flow oriented. These three
situations cover a significant amount of concrete cases where users express the
requirement to be in full control of the development of their computational tools.
The concluding section discusses the advantages of such a conceptual framework,
how it is related to other proposals and the research agenda that is necessary to
make it a common reference for truly EUD environments.
2 Toward a Logic of Bricolage for EUD systems
The expression Logic of Bricolage was used by Lanzara
[19]
to point to some
general features that the “environments” supporting bricolage as an EUD practice
should provide. We chose this expression to denote a framework by which to
characterize and formalize some relevant features that EUD environments should
exhibit to support this collaborative practice, namely both the editing and
execution environments where tools are co-defined, and used, respectively. In
other words, these environments contains sets of functionalities that an EUD
platform provides to, on the one hand, build user-defined artifacts and their
behaviors (editing environments), and on the other hand, to interpret and execute
those behaviors at run time (execution environment), while the above mentioned
artifacts are used in the daily work of their end-users. The above mentioned
relevant features are described here below.
Constructs and Structures - Environments supporting bricolage have to oppose
traditional approaches that provide users with sophisticated (i.e., semantically
rich) modeling tools and facilitate the top-down construction of applications,
e.g. by conceiving the main “entities” involved, their attributes, their mutual
relationships, and the “business processes” where all these latter interact. To this
aim, the Logic of Bricolage requires to provide users with a set of“building blocks”
that they can arrange and compose together in a bottom-up fashion within a
conceptually consistent environment that defines their rules of composition. For
this basic concept we borrow from Lanzara
[19]
the term construct to denote all
the basic building blocks that end-users engaged in the active task of“bricolaging”
their tools can identify - and possibly construct - as the atomic entities that the
editing environment should make available: for this reason in LOB such end-users
are called bricolants. On the other hand, the term structures is used to denote
the working spaces and artifacts, as well as their computational behaviors, that
are constructed and used by the bricolants by means of the constructs previously
identified.
We further distinguish between Operand Constructs and Operator Constructs:
operands are the most atomic data structures, constants and variables that
make sense in a work setting and application domain (see Production 4 in
Figure 1); operators are all the feasible operations and micro-functions that users
deem necessary to be performed over the operands in their setting; these latter
can be either functional or actional (see Production 5), to indicate something
either akin to the evaluation of a function, or related to the production of some
actual effect in the computational environment, respectively: for example, the
G e n e r a t i v e P r o d u c t i o n s o f th e Lo g i c a l O f B r i c o l a g e
1) <webstructure>::= <la y o u t structure>+
2) <l ay o u t structure>::= <topological o b j e c t >+
3) <topologicalobject>::= <operandconstruct> < coordinates >?
4) <operandconstruct>::= <c o ns t a n t >|<typedvariable>|
<o p e r a t o r construct >(<operandconstruct>+)
5) <o p e r a t o r construct>::= <functionalo p e r a t o r construct>|
<actionalo p e r a t o r construct>
6) <annotation>::= <style> < t a r g e t r e f >+|<constant> <t a r g e t r e f >+
7) <t a r g e t r e f >::= <functional o p e r a t o r construct>(<t a r g e t >)
8) <c on s t a n t >::= <domainva l u e s >|<m u l t i med i a t e x t >
9) <t a r g e t >::= <controlstructure>|<topologicalobject>|
<annotation>
10) <style>::= <conventionalsym bol>+|op e r a t o r c o n s t r u c t (<t a r g e t >)
11) <controlstructure>::= <r e w r i t i n g rule>|<c o n n ec t o r >
12) <c on n e c t o r >: : <functionalo p e r a t o r construct>(<r e w r i t i n g rule >+)
13) <rewritingrule>::= <condition ><action>+
14) <condition>::= <functionalo p e r a t o r construct>(<s t a t e >)
15) <action>::= <actionalo p e r a t o r construct >(<s t a t e >)
16) <s t a t e >::= <operandconstruct>+
Le ge n da : The LOB gramm ar i s e x p r e s s e d in EBNFl i k e n o t a t i o n ; t h e r e f o r e ,
t he s ym bo l | mea ns a l t e r n a t i v e ; <> mean s v a r i a b l e ’ ; ‘ + ’
mea ns ‘ o ne or mo re oc c u r r e n c e s ’ ; me ans z e r o or mo re
o c c u r r e n c e s ’ ; ‘ ? m ean s ‘ z e r o or on e o c c u r r e n c e s ’ ; ‘ d oma in
v a lu e s a r e n ot s p e c i f i e d an d a r e t he t e r m i n a l s y mb o l s o f t h e
Grammar ( e . g . T ru e and F a l s e ) .
Figure 1: A preliminary formalization of the Logic of Bricolage
evaluation of a predicate and the storing or retrieving of a piece of information.
In particular, functional Operator constructs can be applied to operands to allow
for the recursive construction of more complex operands from simpler ones (see
Production 4).
According to the bottom-up approach advocated within the LOB framework,
both these kinds of construct have to be identified during the inception phase
of the platform within a cooperative setting or organization, as a result of the
collaboration among a community of end-users and the IT professionals. In fact,
not every kind of construct is easy to build: for example, according to the specific
application domain (e.g., information systems, computer-aided design), users
and developers can decide to implement operator constructs by specializing and
articulating a sequence of primitives that the platform exposes natively (see more
below), so as to simplify the work of “constructing” what the users consider as
“atomic” (black box) operations at their own level of description to use and invoke
while working with their artifacts.
Editing and Execution Environments - Arranging constructs into suitable struc-
tures requires an editing environment by which to shape the information structures
and the logic that is needed for the desired application: then we distinguish be-
tween Layout structures and Control structures
1
. The former ones are sort of
“work spaces” that are recognized by members of a community of users as the
physically inscribed and computationally augmented artifacts where and by
which they carry out their work. In the domain of computer-aided design and
collaborative drawing/editing, a Layout Structure is the working space where
users arrange the docking bars of their preferred commands, symbol stencils
and predefined configurations of elements that must be set up before the actual
work begins. In document-based information systems, Layout Structures are the
document templates of forms and charts that are used to both accumulate content
and coordinate activities; such structures are endowed of both physical properties
and symbolic properties, for instance, input controls (i.e., data fields), boilerplate
text, iconic elements and any visual affordances conveyed through the graphical
interface, which in LOB are all instances of Operand constructs (see Production
4). Accordingly, Productions 2 and 3 express the fact that Layout structures
result from the topological arrangement of Operand constructs. With reference to
Production 1, Layout structures can be aggregated in Web Structures, that are
recursively defined as interconnected sets of Layout Structures (see Production 1,
2 3 and 4).
Also Control Structures are recursively defined in terms of simpler rewriting
rules (see Production 11), that is sort of “conditioned actions” (Productions
14), which are expressed in terms of both kinds of Operator Constructs (see
Productions 16 and 17). Control Structures can be of arbitrary complexity,
ranging from simple rules to (recursively defined) set of instructions (i.e., both
sequential and concurrent processes) and are articulated by means of Connectors
(see Productions 12 and 13), i.e., particular primitives that specify the relationship
between sequences of Rewriting Rules, or input-output transformations (e.g.,
although many patterns are possible, in Production 13 we limit ourselves to
enumerating the elemental ones, like AND, OR, XOR and the like, by which other
logical composition of instructions can be defined
2
). In simple terms, Control
structures specify the behaviors of Layout structures, i.e., how the artifact acts on
the content inscribed therein, e.g., in response to events generated at interface level,
and how this level interacts with users during the habitual use of the application.
This kind of structure is interpreted (and hence executed) by the execution
environment: as said above this is the running application that has been previously
constructed in the editing environment by end-users and designers: such an
environment executes Operator Constructs (both functional and actional ones) by
interpreting them as more or less complex articulation of Primitives; these latter,
in their turn, are domain-independent functionalities exposed by the platform
that have been expressed in terms of lower level Application Programming
1
We prefer the expression “layout structure”instead of “information structure” (or “data
structure”), as we mean to hint at the material, spatial arrangement of meaningful
signs that “act at the surface” in promoting cognitive processes of sense making and
interpretation.
2
Sequences of activities are rendered by using the AND connector and exploiting the
transitive property of such operation.
Interfaces by IT professionals. In particular, the LOB framework conceives the
following primitives (besides the usual arithmetic and logical operations like +,
-, AND, OR etc.): Read and Write, that represent the conceptual operations at
the basis of any computation; Bind, which assigns constants (see Production
8) to variables; Aggregate, by which to build complex operands from simpler
ones; Compose, to build complex operators in terms of functional composition;
and Place, to associate an operand to a structure, i.e., create a topological
object (Productions 2 and 3) eventually specifying its geometric position with
respect to a reference point within the structure (cf. coordinates in Production 3).
Moreover, the Annotate primitive allows to associate a constant (usually a text)
with an Operand construct, that is to create a pair of values of those denoted
in Production 6 in Figure 1. It is noteworthy the fact that Operator constructs
can be just domain-specific specializations of primitives, like, e.g., a user-defined
procedure sum() can specialize the +primitive of a programming language; also
the functional operator construct mentioned in Production 7 uses the Annotate
primitive.
Annotations - An annotation is any user-defined content that is created as being
anchored to other content and conceived to be supplemental to such content.
Also annotations are a first-class concept of the LOB framework, for their central
role in collaborative work in supporting work articulation, knowledge sharing
and mutual understanding [24, 13, 4, 15, 2, 7].
For their supplementary nature, annotations act at a more informal level
than institutionalized structures and the official content that is accumulated
therein during situated practice, and as such they cannot be fully predermined
at definition time; rather, the platform must expose specific primitives for their
addition, deletion, etc. within the execution environment, that is when users
actually use their application. Annotations can be either stigmergic signs and
marks attached to the contents of a document (see productions 6 and in Figure 1,
where <style>also denotes an operator construct that changes the format or
visual rendering of the target), or any extempore comment and semantic tags
chosen by users from either domain specific taxonomies or setting-specific folk-
sonomies (see Productions 6, 7 and 8); notably, as annotations can have multiple
targets (see Production 6) they can express also various kinds of relationships
among (elements of) Layout Structures, in particular those links that constitute
a Web Structure (see Production 1). In addition, in LOB annotations can be
nested (see Productions 6 and 9, where targets can be annotations as well),
that is users should be able to annotate annotations, so as to allow for nested
threads of comments and tags, as we described in [
1
]. These written texts (i.e.,
constants in LOB, see production 8) are all conceived as pieces of a collaborative
and never-really-finished bricolage, which hosts informal communication and
handover between practitioners, their silent and ungoverned work of meaning
reconciliation, and the sedimentations of habits and customs in effective (yet still
unsupported computationally) conventions of cooperative work [12].
Between transiency and permanency - In complex systems (as socio-technical
systems are) change must be expected: this has become a sort of common place
in IT system design since its foundation as a scientific discipline in the 1960s; we
can relate it to the vast research undergone about exception handling in software
engineering so far and in what we called “struggle for flexibility” in [
1
]; yet the
effect of change must be recognized as intrinsically unpredictable, and this is a
fact that is less recognized than it should, at least in practice. Thus, Mansfield
[25
, p. 25
]
argues that ‘if the majority of computer-based socio-technical systems
fail to meet the expectations of their sponsors, perhaps that is due to their [too
rigid] architecture”; consequently he submits design-oriented principles that call,
among others, for the adoption of a layered architecture where some layers are
allowed to change (and adapt to changes, or evolve in response to them) at
different rates to account for the varying rate of impact of the events affecting
them. The LOB conceptual architecture depicted in terms of different layers in
Figure 2 recognizes this point.
Figure 2: A conceptual architecture for an environment supporting EUD bricolage.
LOB keywords are in italics.
We borrow again some terms from Lanzara’s Logic of Bricolage to qualify
the changing rate of the layers constituting the conceptual architecture depicted
in Figure 2. Any form of annotation carried out by practitioners over and upon
structures and their content can be seen as a more transient, informal and more
user-driven piece of bricolage, which acts at a sort of different layer with respect
to content, structures, constructs and obviously the platform’s primitives (see
Figure 2); nevertheless (or right in virtue of this complementarity), annotations
play an equally important role in making the artifacts-in-use flexible enough to
support also invisible work and hence be fully appropriated by their users. Layout
structures are the immediately less transient components as they correspond
to working spaces that users flexibly accomodate to their changing needs [
18
].
Decoupling layouts, i.e., data structures, from the logic acting upon them, i.e.,
control structures, is a well known engineering principle that the framework
recognizes. Yet, although formally decoupled Control structures in practice follow
and support the modifications of the objects/artifacts to which they are to apply:
therefore, they are at the same level of change rate. On the other hand, constructs,
especially the more basic and atomic ones, can be considered as changing at a
slower pace than the structures they are part of, while the more complex ones
can be revised (modified, deleted) more often but surely less frequently than the
above mentioned structures. Primitives, conversely, are quasi persistent as they
are conceived to be domain-independent and general enough to fulfil the users’
requirements that are expressed at construct level: for instance, it is clear that a
logic of composition (and a way to apply such a logic) must be more stable than
the objects it is applied to.
Finally, the layers of the underlying technological infrastructure can be con-
sidered as almost persistent, in that changes can be planned, postponed, made
incrementally depending on the triggering technological evolution or organiza-
tional strategy. The emphasis on this aspect is motivated by the fact that IT
professionals have to build the infrastructure and its relationships with constructs
and primitives plastic enough to avoid any friction between the different layers
that “drift” at different speed according to regular technological evolution and
the users’ needs.
In the next section we illustrate how the LOB conceptual architecture can
be instantiated to deal with concrete, although quite general, EUD practices to
support real work settings. To this aim, the formalization provided in Figure 1
will help identifying the components to be instantiated and to be offered to
bricolant end-users through the editing environments.
3 Instantiating LOB for specific contexts of use
This section describes three concrete environments that we reinterpret as in-
stantiations of the LOB conceptual architecture: the first environment is a
document-based collaborative system tailorable to the local work setting; the
second environment allows for the user defined integration of devices and software
components supporting groups of cooperating actors; the third one is an example
of a multi-layered and flexible mashup composition environment that allows for
the integration of data sources and functional components to produce enriched
and personalized results.
3.1 WOAD: Constructing Webs of Active Documents
Recent field studies conducted in different work settings (especially in the health-
care domain) inspired the conception of the Web of Active Documents (WOAD)
framework, a design oriented framework proposed in [
11
,
8
] to build document-
based collaborative systems. The core concepts of WOAD can be summarized as
follows in terms of: i) the information structure is composed of hyperlinked active
documents that can be annotated in every parts and sections and be associated
with any other document, comment and computational behavior; ii) there is no
rational and unified data model: users define their forms in a bottom up manner
and, in so doing, the platform instantiates the underlying flat data structures that
are necessary to store the content these forms will contain and to retrieve the full
history of the process of filling in them; iii) the presentation layer is in full control
of end users, who are called to both generate their own templates and specify
how their appearance should change later in use under particular conditions by
means mechanisms that are expressed in terms of if-then rules. Users can define
local rules that act on the documents’ content and, as hinted above, change how
documents look like (i.e., their physical affordances), to make themselves aware
of pertinent conditions according to some cooperative convention or business rule
like, e.g., the need to revise the content of a form, or to consider it provisional,
or to carefully consider some contextual condition (see [
1
] for other examples
of such conventions). The LOB conceptual architecture offers a framework that
incorporates the various WOAD’s components in a coherent picture as follows.
In the following we associate the concrete items constituting WOAD with items
of the LOB framework.
First, we specialize the constructs: remember that these are application domain
dependent and therefore they have to be defined by the users in cooperation with
designers and, when necessary, with IT professionals according to the needs of
the specific application domain.
The
Operand constructs
in WOAD are called datoms (document atom):
these are but any writable area with a unique name and a type (e.g., Integer,
String). A datom can recursively be a composition of one or more datoms: e.g.,
the ‘first name’ datom (a string) and the ‘family name’ one (also a string) can
be combined into a ‘person name’ datom that encompasses both. The
Operator
constructs
are a selection of atomic functions (including predicates, denoted as
functional in Figure 1): for example, doctors from a medical setting described
in [
12
] required, besides the standard arithmetic and boolean operations, also a
construct to perform the average, and another one checking the occurrence of a
value in a given set (the is-in construct). A list of Actional Operator Constructs
conceived to be applied to the Layout Structures or on their components has
been derived from a series of field studies and it encompasses basic operations like
save,retrieve and store (see [
6
] for the full list); one of these constructs, namely
annotate, can associate a didget (i.e., a document widget resulting from the
instantiation of a datom) with an annotation. More complex operator constructs
can be recursively defined by composing more elemental ones.
Web structures
are a graph of hyperlinked templates, i.e., WOAD
Layout Structures
; these
latter are a set of didgets: a didget is a topological object, i.e., an Operand
construct called datom (see above) that is put in some place, i.e., is coupled
to a set of coordinates (that in WOAD are represented as Cartesian pairs with
respect to the origin of the template). It is worthy of note the fact that the
two datoms mentioned above (first name, family name) can be used to create
a WOAD template (i.e., a Layout Structure), as well as a third datom, i.e.,
another Operand construct: in the former case the two-datom set is to be used
in the execution environment in documents that are instances of the template
encompassing it; in the latter case the set is intended to be used atomicaly as
component itself of other templates (i.e., as a topological object) in the editing
environment. In WOAD the
Control structures
are called mechanisms, i.e.,
if-then rules whose if-part is a Boolean expression that is recursively defined using
the predefined datom names as variables, and the operators identified above,
all together with the (obvious) constants of the basic types. The then-part is
a sequence of actions that has to be performed on the template or on its inner
components. Mechanisms are connected by the (implicit) OR connector. The
basic operations conceived by the WOAD framework for the definition of both
Templates and Mechanisms, i.e., Layout and Control Structures, respectively, can
be related to the LOB
Primitives
mentioned in Section 2, especially: aggregate,
by which more complex datoms (as Operand constructs) can be built from simpler
ones, and place, by which users can associate a didget with a Cartesian coordinate
with respect to the origin of a given template. Mechanisms, as a matter of fact,
are simple (and intrinsically local in scope) Control structures made of a single
Rewriting rule (see Productions 11 and 12 in Figure 1).
As mentioned in the previous section, the Primitives are offered through an
editing environment where Constructs and Structures can be defined. In WOAD
this environment is constituted by two visual editors: one for the construction
of mechanisms [
10
], and one for the construction of datoms and, by arranging
these latter topologically in terms of didgets, templates. The editing environment
is associated with an execution environment that has been tested on realistic
examples taken from the healthcare domain [9].
3.2 CASMAS: creating hybrid communities for cooperation.
Suppose that a set of applications and devices have to be integrated to support a
set of actors that cooperate by means of them. According to the Community-
Aware Multi Agent Systems (CASMAS) framework [
21
,
23
], both actors and their
tools all are represented as entities and integration can be seen alike to becoming
members of the same community: as such, they coordinate their behaviors through
a shared information space that contains coordinative information, as well as
the behaviors that are dynamically assigned to each entity to make it an active
member of the community: in CASMAS communication is asynchronous but it is
not message based. Instead, when an entity posts a request into the space, other
entities will react to this request according to their current behaviors.
The CASMAS framework encompasses a language to specify entities and their
behaviors. This language takes the declarative form of facts and rules (i.e., if-then
constructs), which offers the possibility to express behaviors in a modular way,
without the need to define complex and exhaustive control structures [
26
,
22
].
The rules constituting an entity’s behavior express what the entity is expected to
do when some conditions are satisfied: these conditions are matched against the
facts contained in the community’s space and in the entity’s local memory; the
action(s) that the entity should perform updates either the community space or
the memory of the entity itself.
The integration of a software application/device is realized by inserting a fact
in the memory of the entity representing it and by defining the behavior of this
entity. The fact contains attribute-value pairs that specify the information the
application/device makes available for sake of coordination with the other entities
of the same community; the entity’s behavior expresses conditions (among others)
on the concrete application/device attributes (when) and invokes some of the
functions the application/device exposes to the community (what): actually, the
entity is a sort of wrapper that mediates between the concrete application/de-
vice and the integration environment (community). CASMAS was evaluated in
controlled experiments with students with limited programming skills [22].
As done for the WOAD framework, we associate each CASMAS feature with
each item of the LOB framework with reference to the formalization depicted in
Figure 1.
In CASMAS, the
Operand constructs
are the facts that are contained in
and exchanged across community space(s): CASMAS facts are expressed ac-
cording to the syntax of the underlying rule-based language (currently, JBoss
Drools
3
). The
Operator constructs
are the basic functions and predicates that
are exposed by the underlying rule-based programming language; in particular
the actional operator constructs (actions in CASMAS) support the asynchronous
communication between entities, as well as the storing and retrieval of informa-
tion among the spaces and the local memories. In case of applications/devices’
memories, the store/retrieve actions respectively put and get information to/from
the data structures therein managed, obviously employing the LOB primitives
of read and write. The spaces that are implicitly connected through the entities
that are members of more than one community are the LOB Web structures;
each space is a
Layout structure
that contains the community’s facts and the
entities’ ones; differently from WOAD, facts (i.e., operand constructs) are not
geometrically localized within spaces, as CASMAS does not specify the coordi-
nates of its topological objects (i.e. the facts within the spaces) but only their
topological arrangement in terms of entity ownership. The if-then rules connected
through the OR connector and grouped according to the entities membership to
the community are the CASMAS
Control structures
: their if-parts encompass
sets of Operand and Operator constructs, as in WOAD; similarly, the then-part
3http://www.jboss.org/drools/
can either encompass the above mentioned put and get actional operator con-
structs, whenever the behavior regards applications/devices entities; or a post
action, in the other cases. The CASMAS framework defines the same primitives
seen for WOAD but, as anticipated above, it also explicitly encompasses the
read and write primitives as basic components of the put and get constructs:
the role of these primitives is to interact with the wrappers developed for each
device/application to be integrated.
3.3 DashMash: flexible configuration of EUD mashups
Recently, an increasing number of environments where users can combine in-
formation flows from different data sources, the so called mashups, has been
proposed, also for commercial use (e.g., Yahoo Pipes). For sake of exemplification,
we apply our exercise of LOB instantiation to the the DashMash framework [
14
]
4
,
which we take as representative of a wide class of applications that allow for the
collaborative user-driven aggregation of heterogeneous content. Indeed, DashMash
is a general-purpose EUD environment that adopts an approach in which the
design-time and the use-time are strictly intertwined: end-users can autonomously
define their own mashups and execute these latter “on the fly”, to progressively
check the result of their editing activities. Unlike most of the traditional ap-
proaches for the creation of mashups, the DashMash approach is based on events,
i.e., end-users can organize the flow of the information in response to events
published by some data sources, to which other system’s components subscribed
in advance. The DashMash approach provides end-users with an environment
that can be customized essentially in two ways: (i) through the development
of domain-specific components that allow to interact with the functionalities
provided by any kind of (local or remote) service; and (ii) providing end-users
with the access to data coming from private and domain-specific data sources, in
addition to publicly accessible ones. Nevertheless, the approach used in DashMash
provides end-users with an abstraction that makes them able to use the various
mashup components (e.g., data sources, filters and data viewers) that are auto-
matically composted on the basis of a pre-defined set of compatibility constraints,
relieving end-users from the need to know any technical detail about the used
components. DashMash has been experimented in the case of the construction
of a Web platform through which end users can construct their dashboards for
sentiment analysis of unsolicited feedback provided by users comments published
on the Web.
As for CASMAS, the DashMash Control structures are grouped to form
the behavior of each component. These constructs allow for typical publish
and subscribe patterns, like “if a new fact occurs, then publish an event” and
“if a subscribed event occurs, then perform some operations”. New facts or
operations pertain to single components only. For example, if the component is
the Composition Handler, then the new fact is any change in a component; the
4
This task is less detailed than in the other two cases as the mentioned paper does
not give all the necessary details.
components influenced by this kind of event (i.e., the subscribers) activate the
corresponding operations: for example, if the change is about a Filter Component
then all Data Components using this filter activate internal operations to send
the data to the new Filter Component and at the end this later notifies that
new-data are ready: this event is consumed by the Viewer Component subscribing
this event for the specific data. In this view, the Operand constructs are the data
and the events, while the main Operators constructs regard the publication of an
event, and the subscription for a specific kind of event. In DashMash, the Web
structure is the set of workspaces; each workspace is a Layout structure that
is composed by two inner Layout structures: one contains the output of all the
Viewer Components for what concerns the data (i.e., at the use level according
to [
2
]); the second contains a standard description of the workspace state in terms
of Components such as: Data Sources, Filters and Viewers (i.e., at the design
level).
More traditional mashups that, differently from DashMash, are uniquely
based on data flows can be described as graphs whose nodes are input-output
transformations, and whose arcs express the kind of connection that hold between
two nodes. In LOB terms, a mashup belonging to this class can be seen as a set of
rewriting rules that transform inputs into outputs, where arcs are as connectors
that express the appropriate structure of the data flow (e.g., either alternative or
parallel flows).
The three instantiations outlined above support our claim that the LOB
architecture is at the same time general enough to formally describe different
types of EUD application classes (e.g., information mashup, document-based
systems, integration of applications), and yet detailed enough to define a concrete
platform to apply recurring design patterns for EUD systems to be deployed in
different application domains.
4 Concluding remarks
We are convinced that in EUD “the best is yet to come”. This is not to discard
what has been done so far in this research field, but rather to recognize that the
last ten years or so of proposals and solutions that have been brought forth to
allow end-users to create and maintain their computational tools autonomously
have now reached a maturity level that requires a sort of backward reflection, as
well as an effort to generalize local solutions and intuitions into general insights
and concepts for future reuse and discussion. To this aim, we have presented
a general framework, called Logic of Bricolage. After [
17
, p. 308], who aptly
provides a lens through which to consider the utility of conceptual proposals, we
propose the LOB framework to: i) facilitate EUD researchers in making sense of
and describing their and others’ solutions (descriptive power); ii) help them talk
about their solutions by providing them with a common vocabulary (rhetorical
power), i.e., a very concise lexicon whose available terms cover few but essential
aspects of recurring EUD conceptual structures and underlying models and are
defined with some degree of unambiguous formalization (see Figure 1). Lastly, iii)
LOB is proposed to both inform and guide the design of the next EUD proposals
to come in heterogeneous application domains (applicative power), or at least
to foster discussion on the need of such a framework in the EUD field for the
dissemination of its tenets in multiple venues and research initiatives.
Differences and complementarities of LOB with respect to existing frameworks
are to be found in all these three dimensions. We are aware that LOB shares
some strong affinities with the notion of meta-design proposed by Fischer et
al. [e.g.,
16
], which however was not aimed at achieving an explicit formalization;
and with the hierarchical framework described in [
15
], which also acknowledges
the substantial continuity between design and usage of software applications. In
particular, the concept of Software Shaping Workshops (WWS) therein described
also allows for the definition of environments that are shaped according to specific
user communities where users can use or tailor the software tools supporting their
working practices. Yet, unlike our proposal, the WWS approach is more aimed
at the definition of an organization structure and of a methodology for EUD
design, rather than at the definition of a conceptual framework and architecture
supporting the description and shaping of each possible EUD environment;
even more importantly, such an approach is strongly oriented at the shaping
of the interaction of users with their tools (which are however constructed by
IT professionals), rather than at informing the users’ activity of autonomously
defining their tools themselves.
The LOB framework, instead aims to identify and separate concerns in EUD
platforms, associate these concerns with specific layers of a conceptual architecture,
and call objects pertaining to each layer with specific and evocative names, by
following the precept to“keep it simple, but not simpler”. In so doing, we purposely
avoided to characterize who end-users are or to borrow and adapt any complex
model of user roles: LOB is a (meta-)design-oriented [
16
] conceptual framework
where users are but active workers: what we call bricolant, to stress the idea that
they perform bricolage as they work, and that their work is always a form of
ad-hoc, highly situated bricolage. Bricolants are endowed with the only, and often
irremediably tacit, expertise to make their tools really meaningful and useful. In
the LOB light, an EUD platform is seen as the enabling environment that allow
bricolants to make these useful tools also usable, and computationally powerful
of course. To this aim, we envision a specific role, the maieuta-designer (see [
1
]
for a detailed characterization of this particular meta-designer), to help bricolant
users “help themselves” and reach an increasing level of autonomy with respect
to traditional IT professionals (i.e., designers, architects and programmers).
The LOB framework is therefore intended as one step toward a shared
systematization of technological approaches (both of the past ones and of those
still to come) that could soon reach enough simplicity and generality (as desirable
characteristics for good design and academic research) by progressively abstracting
and formalizing the lessons learned and best solutions that the field has so far
proposed and discussed. As such, in this paper we outlined the exercise to frame
some of the existing EUD platforms and environments in terms of LOB concepts;
in so doing, we aimed to highlight its descriptive power and show its applicability
in the EUD arena to make existing solutions more understandable and comparable,
and the next ones stand more firmly on the shoulders of the formers.
Bibliography
[1] Reference anonymized for the peer-review process.
[2]
Ardito, C., Buono, P., Costabile, M.F., Lanzilotti, R., Piccinno, A.: End
users as co-designers of their own tools and products. Journal of Visual
Languages & Computing 23(2), 78 – 90 (2012), special issue dedicated to
Prof. Piero Mussio
[3]
Ardito, C., Lanzilotti, R., Mussio, P., Parasiliti Provenza, L., Piccinno, A.:
Redefining the roles of users and designers in interactive system lifecycle.
In: Proceedings of CHItaly 2009, June 17-19, Rome, Italy. (2009)
[4]
Bringay, S., Barry, C., Charlet, J.: Annotations: A functionality to support
cooperation, coordination and awareness in the electronic medical record. In:
COOP’06: Proceedings of the 7th International Conference on the Design of
Cooperative Systems. France, Provence (2006)
[5]
Buescher, M., Gill, S., Mogensen, P., Shapiro, D.: Landscapes of practice:
Bricolage as a method for situated design. CSCW, Computer Supported
Cooperative Work 10(1), 1–28 (2001)
[6]
Cabitza, F.: ”Remain faithful to the earth!”: Reporting experiences of artifact-
centered design in healthcare. Computer Supported Cooperative Work
(CSCW) 20(4), 231—263 (2011)
[7]
Cabitza, F., Colombo, G., Simone, C.: Leveraging underspecification in
knowledge artifacts to foster collaborative activities in professional com-
munities. International Journal of Human - Computer Studies 71, 24—25
(2013)
[8]
Cabitza, F., Gesso, I.: Web of active documents: an architecture for flexible
electronic patient records. In: Fred, A., Filipe, J., Gamboa, H. (eds.) Biomed-
ical Engineering Systems and Technologies. Communications in Computer
and Information Science, vol. 127, pp. 44—56. Springer (2011)
[9]
Cabitza, F., Gesso, I.: Rule-based programming as easy as a child’s play. a
user study on active documents. In: IHCI’12: IADIS International Conference
Interfaces and Human Computer Interaction 2012 Lisbon, Portugal 21 - 23
July 2012 (Jul 2012)
[10]
Cabitza, F., Gesso, I., Simone, C.: Providing end-users with a visual editor
to make their electronic documents active. In: VL/HCC 2012: Proceedings of
the IEEE Symposium on Visual Languages and Human-Centric Computing
September 30 - October 4, 2012 - Innsbruck, Austria. pp. 171—174. IEEE
Computer Press, Innsbruck, Austria (2012)
[11]
Cabitza, F., Simone, C.: WOAD: a framework to enable the end-user devel-
opment of coordination oriented functionalities. Journal of Organizational
and End User Computing (JOEUC) 22(2) (2010)
[12]
Cabitza, F., Simone, C., Sarini, M.: Leveraging coordinative conventions to
promote collaboration awareness. Computer Supported Cooperative Work
(CSCW) 18(4), 301—330 (2009)
[13]
Cadiz, J.J., Gupta, A., Grudin, J.: Using web annotations for asynchronous
collaboration around documents. In: CSCW 2000: Proceedings of the 2000
ACM conference on Computer supported cooperative work. pp. 309–318.
ACM Press, New York, NY, USA (2000)
[14]
Cappiello, C., Daniel, F., Matera, M., Picozzi, M., Weiss, M.: Enabling
end user development through mashups: Requirements, abstractions and
innovation toolkits. In: Costabile, M., Dittrich, Y., Fischer, G., Piccinno,
A. (eds.) End-User Development, Lecture Notes in Computer Science, vol.
6654, pp. 9–24. Springer Berlin Heidelberg (2011)
[15]
Costabile, M.F., Fogli, D., Mussio, P., Piccinno, A.: Visual interactive systems
for end-user development: A model-based design methodology. Systems,
Man and Cybernetics, Part A: Systems and Humans, IEEE Transactions on
37(6) (Nov 2007)
[16]
Dick, H., Eden, H., Fischer, G., Zietz, J.: Empowering users to become
designers: using meta-design environments to enable and motivate sustainable
energy decisions. In: PDC ’12: Proceedings of the 12th Participatory Design
Conference - Volume 2. pp. 49—52. ACM, New York, NY, USA (2012)
[17]
Halverson, C., Ackerman, M., Erickson, T., Kellogg, W.A. (eds.): Resources,
Co-Evolution and Artifacts: Theory in CSCW. Springer Berlin, D, (2008)
[18]
Harris, J., Henderson, A.: A better mythology for system design. In: CHI’99:
Proceedings of the SIGCHI Conference on Human Factors in Computing
Systems. pp. 88—95. ACM Press, New York, NY, USA (1999)
[19]
Lanzara, G.: Between transient constructs and persistent structures: design-
ing systems in action. Journal of Strategic Information Systems 8(331-349)
(1999)
[20]
Lieberman, H., Patern`o, F., Wulf, V. (eds.): End User Development, Human-
Computer Interaction Series, vol. 9. Springer Netherlands (2006)
[21]
Locatelli, M.P., Simone, C.: A community based metaphor supporting EUD
within communities. In: Santucci, G. (ed.) Proceedings of the International
Conference on Advanced Visual Interfaces, AVI 2010, Roma, Italy, May
26-28, 2010. p. 406. AVI ’10, ACM Press (2010)
[22]
Locatelli, M.P., Simone, C.: Integration of services based on the community
metaphor: some guidelines from an experience of use. In: EUD4Services
Workshop (2011)
[23]
Locatelli, M.P., Simone, C.: End-users’ integration of applications and devices:
A cooperation based approach. In: From Research to Practice in the Design of
Cooperative Systems: Results and Open Challenges, pp. 167—181. Springer
London (2012)
[24]
Luff, P., Heath, C., Greatbatch, D.: Tasks-in-interaction: paper and screen
based documentation in collaborative activity. In: CSCW’92: Proceedings of
the 1992 ACM conference on CSCW. pp. 163–170. ACM Press, New York,
NY, USA (1992)
[25]
Mansfield, J.: The nature of change or the law of unintended consequences.
Imperial College Press, London, UK (2010)
[26]
Myers, B.A., Pane, J.F., Ko, A.: Natural programming languages and envi-
ronments. Communication of the ACM 47(9), 47–52 (Sep 2004)
[27]
Simonsen, J., Robertson, T.: Routledge International Handbook of Partici-
patory Design. Routledge (2012)

Supplementary resource (1)

ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
T he current organizational and technological evolution suggests to conceive tai-lorability and EUD also in terms of integration of off the shelf applications and devices that support collaboration. To this aim this chapter proposes an approach that leverages the ability of actors to coordinate their activities and then grounds integration on the notion of cooperation. The resulting technological environment is presented and illustrated through a case derived from an ongoing project. Some considerations derived from a short experimentation conclude the chapter.
Article
Full-text available
The paper discusses the conventions used by medical practitioners to improve their collaboration mediated by Clinical Records. The case study focuses on the coordinative conventions identified in two wards of an Italian hospital and highlights their role and importance in the definition of the requirements of any system supportive of collaborative work practices. These requirements are expressed in terms of the provision of artifact-mediated information that promotes collaboration awareness. The study identified several kinds of Awareness Promoting Information (API): the paper discusses how they can be conveyed both in the web of documental artifacts constituting a Clinical Record and in its computer-based counterpart, the Electronic Patient Record (EPR). The paper ends with the implications for the design of EPRs and for their integration with Hospital Information Systems in light of the findings.
Article
Full-text available
Unsustainable energy consumption is a systemic problem facing societies. While technological innovations are necessary to address this problem, they are not sufficient; they need to be integrated with social and behavioral changes in order to be most effective. Our approach is based on understanding and using participatory design as a paradigm for software design as well as the foundation for socio-technical environments that enable and support a cultural shift from passive consumers of energy to active decisions makers. Our research is grounded in two theoretical frameworks, meta-design and cultures of participation. We are developing EMPIRE, a socio-technical environment supporting rich ecologies of participation that enable people to become active designers of their energy consumption. EMPIRE engages people to participate in the design of their own energy environment and supports individuals and communities in understanding and making more sustainable choices regarding energy.
Article
Full-text available
In our Age of exponential technological advance, recent developments are determining an evolution of end users from passive information consumers into information producers. Users are increasingly willing and, indeed, determined to shape the software they use to tailor it to their own needs. Based on a brief review of research activities we performed in the last decade, this paper analyzes some challenges that software designers face to comply with the new roles of end users in the software life cycle, and discusses how to provide end users with software environments that empower them to become co-designers of their own tools and products. The examples reported in the paper show why and how end users are involved in design activities in various application domains.
Conference Paper
Full-text available
The recent technological development, including the evolution of the World Wide Web into the so-called Web 2.0, determine new roles for users, who evolve from information consumers to the more active role of information producers. People, who are not interested in software per se, are increasingly willing to modify and/or create software artefacts in various ways, thus users and developers are not anymore two mutually exclusive groups of people. In this paper types of users that are between pure end users and software developers are analyzed, and the implications of the new user roles in the design and development of interactive systems are discussed.
Book
This absorbing book provides a broad introduction to the surprising nature of change, and explains how the Law of Unintended Consequences arises from the waves of change following one simple change. Change is a constant topic of discussion, whether be it on climate, politics, technology, or any of the many other changes in our lives. However, does anyone truly understand what change is? Over time, mankind has deliberately built social and technology based systems that are goal-directed — there are goals to achieve and requirements to be met. Building such systems is man’s way of planning for the future, and these plans are based on predicting the behavior of the system and its environment, at specified times in the future. Unfortunately, in a truly complex social or technical environment, this planned predictability can break down into a morass of surprising and unexpected consequences. Such unpredictability stems from the propagation of the effects of change through the influence of one event on another. The Nature of Change explains in detail the mechanism of change and will serve as an introduction to complex systems, or as complementary reading for systems engineering. This textbook will be especially useful to professionals in system building or business change management, and to students studying systems in a variety of fields such as information technology, business, law and society.
Article
On-line observation and tracking of design processes reveal that design practices often display surprising features that defy our understanding, descriptions, and planning capabilities. Systems tend to be fragmented, untidy and unpredictable, often turning the designers’ setting and practice into a “swamp”. Drawing on stories of system development projects the author highlights the role of transient constructs as dynamic carriers of knowledge and effective vehicles for sensemaking. Transient constructs help resolve the dynamic tension between stability and change in design processes. On the one hand, given their unfinished and makeshift character, they allow for variability, online experimentation, and cognitive transactions; on the other hand, they may occasionally coalesce into more stable and persistent structures, which are continuously reconfigured by a never ending activity of bricolage.
Conference Paper
The interest of the Electronic Medical Record EMR is from now on obvious. However, Health Professionals still not have at their disposal tools allowing them to support their cooperative practices. In the French DocPatient project, we try to improve practitioners' cooperation when they use the medical documents by implementing a document-based EMR. Our assumption is that a best integration of the way they use these medical documents in the EMR design will improve its utility, its use and its acceptance. In this paper, we show that annotations practices must be transposed in the EMR to reinforce collaboration, coordination and awareness.
Article
Collaborative problem solving often involves actors with heterogeneous competences or that see a common problem from different perspectives: this can make mutual understanding difficult. The paper presents case studies in different domains where collaboration leverages shared representations, and discusses the main reasons why these representations succeeded in fostering mutual understanding. We observed how the technologies proposed to manage those representations were successful only to the extent they were made able to adapt to the dynamic and open conventions that actors adopted during their activities. The point of the paper is that locality, openness and underspecification are key factors in this process, for their capability to promote tacit knowledge and to let competent actors reach a sufficient level of mutual understanding towards some common goal. The paper proposes a conceptual framework to characterize the notion of knowledge artifact interpreted as a semiotic system where actors can make sense of shared and underspecified representations, and derives from this notion implications for the design of a supportive technology. http://www.sciencedirect.com/science/article/pii/S107158191200033X)