Information Technology Reference
In-Depth Information
Seguin, 1998), or DreamObjects (Lukosch, 2003),
are prominent means to support developers. They
offer solutions for the development of tools for
computer-mediated interaction as pre-fabricated
building blocks. These frameworks help during
the development process by providing components
that hide most of the dirty and difficult work such
as network connection management, process
scheduling, data sharing, or data consistency. They
also impose a specific way of shaping the group
process by, e.g., providing means for starting a
collaborative session. If the framework perfectly
matches the requirements of the project, it will
simplify the development. Unfortunately, this is
often not the case.
During the development of several tools for
computer-mediated interaction in national or
international projects, we experienced and identi-
fied several properties that complicate the use of
frameworks (Lukosch & Schümmer, 2006a):
application could benefit from more than
one framework (Fayad & Schmidt, 1997).
Black-box components : Frameworks often
only provide black-box components. These
components are designed for a specific con-
text like a specific structure of the underly-
ing data model or specific mechanisms for
processing user input and normally cannot
be adapted.
Lack of documentation : Most groupware
frameworks have emerged from research
projects. Thus, the main focus has been on
the functional aspects of the framework
rather than the documentation of the frame-
work for novices. However, a didactically
sound description of the framework's dy-
namic aspects is crucial for training devel-
opers in using the framework.
Communication problems : Groupware
frameworks often address the problem
space from a technical perspective rather
than approaching the problem space from a
human-computer interaction view. The in-
teraction design thus often becomes tech-
nology driven. Developers continue to use
their technical language while clients and
end-users express their requirements with
terms used in the specific interaction set-
ting. The problem of communication be-
tween end-users and developers stays an
open issue in these cases.
Programming language : Framework de-
velopers often chose the programming lan-
guage that is currently en-vogue or that has
been used in other projects before. Reuse
is thus limited by the chosen programming
language.
Distribution architecture : As with the pro-
gramming languages, framework devel-
opers often limit the applicability of the
framework by offering only one distribu-
tion architecture that fits the first intended
applications best. This may mean that the
framework for instance only supports a cli-
ent/server-architecture or that it uses peer-
to-peer mechanisms.
From these observations, we conclude that
the framework approach is not sufficient for sup-
porting the development of tools for computer-
mediated interaction.As other authors pointed out
for general software development (e.g. (Johnson,
1997), (Brugali & Sycara, 2000), or (Biggerstaff
& Richter, 1987)), we argue that the development
of tools for computer-mediated interaction should
focus on design reuse rather than code reuse. The
developers should be trained in a way so that they
can understand and reproduce the framework
developer's design decisions.
Framework dominance : Framework de-
velopers often assume that the applica-
tion can be created on top of exactly one
framework. They design the framework as
center around which the application should
be built. The framework in this case domi-
nates the application structure and compli-
cates application development when the
Search WWH ::




Custom Search