despite being a distance course with optional attendance of class, a sense of community was created. Students also established contact to external people, e. g., native
speakers (50% of the students according to the questionnaire).
However, we could also observe that unconstrained active participation results in distraction: e. g., in the microblogging service, students posted messages in other languages
than English. Additionally, some users seemed not to be
aware (or not to care) that their messages were readable by
all other users and posted pejorative messages (I'm too fat",
My boss is an idiot"). It is therefore important to note that
although Web 2.0 applications fulll their goal of stimulating participation, their usage in a classroom does not relieve
the teacher of his role as a moderator.
The problem that the openness of a service can potentially interfere with the intended functionality of the learning application that uses the service was also relevant for
the social bookmarking application. There, in theory, foreign users might add resources using the same tags, but with
a dierent semantic. In this concrete example, we avoided
the problem by using specially marked tags. This is not a
bullet-proof solution, but minimizes potential problems.
We also noted that mobile access to the Web 2.0 is still
to come (Principle independent access"). Most students
used the standard Web access to the services. In the microbloggin service, only about 10% used the mobile phone regularly to send/receive messages. Paradoxically, one problem
with receiving the messages via SMS was the success of the
service: on some days, more than 50 messages were sent by
the students, quickly cluttering any SMS inbox.
To our knowledge, the students did not use any of the advanced assembly features (architecture of assembly"), such
as the integration of the services in their homepage or blog.
We believe that this is caused by the students still being unfamiliar with such possibilities, and that we did not provide
instructions on how to do so. However, we did observe that
students used standard personalization features, such as uploading background pictures and personal avatar pictures.
4.2 Web 2.0 for Prototypes
The exploitation of existing Web 2.0 services for our research allowed to realize running prototypes quickly and relieved us from the burden of technical details such as managing user load and of the dicult task of designing user
interfaces. Nevertheless, such an approach is not without
drawbacks and one needs to be aware of potential shortcomings.
First of all, in the architecture of assembly" one becomes
dependent of an API controlled by a third party. This is
more severe than using a programming library, since API
changes directly aect the application: the perpetual beta
stage of Web 2.0 applications has the consequence that one
cannot download a specic version and stick to it. Similarly,
conditions of use can change. During our Twitter usage, the
service introduced rate limits that regulated the amount of
requests per hour a client could send. This con
icted with
our goal to download all of the students' messages.
However, for most part Web 2.0 service owners aim at
keeping close and good contact to their users, including
developers. The perpetual beta" of Web 2.0 applications
aims at increasing the value a user gets from using the service. Additionally, the architecture of participation brings
hal-00588757, version 1 - 10 May 2011
forward an interest of developers in new usages of their service. Thus, in our experience, they are very interested in
feedback and open to suggestions. For instance, most sites
will make exceptions to rate limits upon request.
Having to rely on external APIs also involves the problem that sometimes not all required functionality is implemented. However, as long as the wished-for functionality
is there in principle (as a rule of thumb: as long as it is
achievable by the Web interface), it is possible to articially
extend" the functionalities. In the micro-blogging prototype, the API allowed only to retrieve the last 20 messages
of each user, which sometimes was insucient. Despite the
API limitation, the Web interface allowed to browser all
messages of a user. Thus, we implemented a crawler that
retrieved the necessary messages by parsing the Web page.
An additional problem raised by using services not under direct control concerns user identication. More often
than not, each service requires the creation of a new login;
only rarely can existing accounts on one service be reused
for a dierent service. The non-existing single-sign-on is a
well-known problem in the Web, however decentralized approaches such as OpenID
14
might answer these problems.
But currently, students still need to create their own accounts and these accounts needs to be matched to the student accounts used within the educational organization.
One drawback of the perpetual beta" is that user interfaces will change. Usually the change improves the service,
but still, the changes need to be re
ected in user manuals
written for the students. During our usage of the microblogging service, the user interface and underlying metaphors
were changed twice. Since the changes happened after the
students had become familiar with the service, there was not
immediate need for adapting the user manual. The situation would have been dierent if the change had taken place
during the start of the lecture.
Depending on the degree of integrating of the third party
Web 2.0 services and one's own application, security becomes an issue. A client application such as an learning management system cannot directly control the service provider
and depends on his reliability. This matter is complicated
when mashups or widgets are used since these include additional sources of vulnerability [22].
In our experiments, we did not use the diverse data on
an epic scale" for learning support, but are using it for research: we have now a corpus of 5400 Twitter updates to
be analyzed for linguistic patterns, such as typical language
learning problems. For instance, we were able to identify
typical mistakes by Chinese learners and are now preparing
special Twitter lessons to overcome these problems.
5. CONCLUSIONS
This paper made the following contributions: we showed
that insofar as one can speak of an innate pedagogy of technology, the Web 2.0 pedagogy is best associated with constructivism and social learning. This claim is based on an
analysis of the technological principles of Web 2.0. Thus,
our work extends prior research that explores the potential
of Web 2.0 for education in general by [19, 2] and explains
Web 2.0 principles for an educational audience [6].
Furthermore, we showed that Web 2.0 yields potential for
research on technology-supported learning. By exploiting
14
http://openid.net/
existing Web 2.0 services and thanks to the openness of
these services, it is possible to assemble in limited amount
of time complex prototypes that allow to assess the validity
of research hypotheses. We discussed two example applications that illustrate this claim and presented the lessons we
learned from these examples.
To summarize, Web 2.0 oers an intriguing and unparalleled wealth of functionality at a very high level. The
exploitation of this functionality oers a high potential for
the future of technology-enhanced learning. However, it is
important not to forget that even if technology can be inspiring, the main focus in e-learning should still lie on the
needs of the learner.