This paper presents our research activities on the design of Web 2.0 applications currently ongoing at Politecnico di Milano. Our approaches are based on model-driven development techniques: in particular, they extend Web 1.0 models to cope with the technological characteristics of the new applications and exploit design patterns to capture the desired behaviors. Two main research activities are presented, considering two orthogonal issues of Web 2.0 applications: the social and the technological aspects. Moreover, other ongoing research directions are outlined.
The advent of the so-called Web 2.0 has shifted the focus of Web application development towards a more prominent role of the end-users , now considered as the critical success factor. Among the many facets of Web 2.0 in our research at Politecnico di Milano we have considered both the social and the technological aspects.
From a social point of view, we are witnessing a shift
towards collaborative and community-based applications.
Community-driven applications can be defined as Web
applications targeted to a set of users (the community),
purposely designed for encouraging the social interaction of
community members: content production and
dissemination, content processing (rating, categorization,
transformation), and inter-user relationship development. The success
of Web 2.0 community-based applications depends on
several factors, some of which are immaterial: quality of
content, cohesion of interests, suitable mechanism for
emergence of outstanding contributions and contributors, which
add up to the well-known “traditional” criteria of
usability of the interface and global quality of the user’s
experience. Many tools and algorithms have been developed for
addressing specific topics related to social network
analysis [
From a technological point of view richer interfaces are
needed to improve user experience. Indeed, traditional
HTML interfaces are showing their limits, compared to
desktop applications, both in terms of content presentation
and manipulation (HTML was designed for documents, not
GUIs, and multimedia support is limited) as well as in terms
of interaction (server-side computation implies full page
refresh at each user-generated event). Web 2.0 applications
demand a novel development paradigm [
In this paper we show how conceptual and platformindependent models can be used in the design and development of Web 2.0 applications (considering both social and technological aspects), in the tradition of Model Driven Development (MDD). Compared to several frameworks addressing social issues and supporting specific RIA platforms, our approach is technology-neutral and can be automatically converted into implementations in all the most popular RIA technologies and frameworks.
The envisioned development paradigm is based on the
extension of MDD approaches conceived for traditional
Web 1.0 applications and on the usage of design patterns.
For convenience, we will refer to the WebML [
The paper is organized as follows: Section 2 explains how social aspects have been integrated in our methodology. Section 3 gives an overview on the extensions of the WebML model to capture the technological features. Section 4 briefly describes other current research directions related to Web 2.0. Finally, Section 5 presents future trends and draws the conclusions. 2
Our research on Web 2.0 social features aims to
integrate the social perspective typical of emerging Web 2.0
applications within a structured Web Engineering approach,
based on model-driven development. The result is a
seamless development paradigm that is capable of capturing both
conventional Web development issues (data storage,
publication, management, Web service publication and
invocation, user profile management, etc.) and the essential
design patterns that appear in state of the art social Web 2.0
applications. Our current results comprise a set of classified
model-driven design patterns for community-based Web
applications, validated by means of an analysis of pattern
occurrence in top-ranking Web 2.0 social applications and the
extension of well-known Web development processes (i.e.,
RUP [
To identify best practices in social Web applications we analyzed ten of the most popular Web 2.0 community applications and distilled a number of recurring design patterns. The analysis of the pattern set lead to the individuation of nine core concepts that are the main focus of the social activities in Web 2.0 applications. Table 1 shows the design patterns grouped by their underlying social concept. Patterns are further distinguished into front-end patterns and back-end patterns: front-end patterns relate to the interface for the community members to express their activity, back-end patterns reflect the system responses to membergenerated interaction.
The complete list of social features and relative patterns
can be found in [
Concept Item Clustering User Clustering Item Relevance User Reputation Connections Scoring Communication Permissions Interoperability Front-end Design Pattern Organization Browse by Tag Group Creation Group Participation Rating Flagging Social Visualization Relationship Setting Browse by Connection Talk Recommendation Invitation Permission Setting Exportation
Back-end Design Pattern Rel. Adjustment Rep. Adjustment Payment Reward Notification Permission Check Syndication content and the individuation of interesting items can be eased by providing the user with a group hierarchy. Secondarily, Item Clustering can be used by the community members, like any metadata, as further information to understand the properties of a given item. While traditional Web applications usually provide users with a standard classification (e.g., a hierarchy) for content items, most social application prefer to implement a collaborative approach to Item Clustering.
A general solution for collaborative Item Clustering is
the Organization front-end pattern [
Design patterns are not applied in isolation, but within
the framework of analysis and design activities forming the
development process of a certain class of artifacts. Several
process schemes have been tailored to Web applications,
starting from the more general notion of software life-cycle
model. We extended the WebML process [
In the analysis of requirements of social Web applications, community governance and social processes emerge with a prominent role. Communication experts should identify the social processes needed to foster user participation: which user activities are critical for the community, which strategies are due for community monitoring (e.g., moderation, codes of conduct), and what reward and reputation mechanism to install; social network experts, instead, define the abstract models that represent member relationships and meaningful indicators for monitoring them, which will allow community administrators to trace the community’s trends and govern its evolution. Furthermore, the analysis of requirements about users is expanded, to address multiple perspectives: • Content management: as in conventional Web applications, functional roles must be identified, e.g., by classifying users into stakeholders, administrators, editors, etc. The question is “who can read/update what?”. • Governance: social roles must be elicited. The question is: “who is controlled by whom?”. Different governance models may require alternative social roles: democratic moderation relies on a shared code of conduct whereby every member can monitor others and draw attention to violations. In such a system, the users’ hierarchy consists simply of moderators and contributors. Alternatively, in more structured communities, the governance model could reflect some existing formal organization (e.g., a company’s hierarchy). • Social behavior: another classification of users can be obtained by the observation of their participation: behaviors such as pioneers, killers, lurkers can be defined and help monitor the community’s status and plan reinforcement or corrective activities.
Besides users’ roles, the analyst should pinpoint the relationships that members can set-up (e.g., group creation, friend-of-a-friend linking, etc) and the degree of collaboration they can establish (e.g., application sharing, invitation, etc). Once user roles are identified under all the relevant perspectives and the allowed relationships are determined, roles can be mapped into user types and associated to the activities that each type is entitled to perform, including relationship-setting activities.
In the design of Web applications, several tasks are affected by a community-driven focus: 1) the design of the data model of the application should encompass the metadata needed to reflect the members roles, relationships, profile data, and reward policies; 2) the design of the hypertext front-end should integrate the selection of the navigation, contribution and social interaction pattern; 3) the design of the hypertext back-end should comprise the back-end design patterns needed to support the supported social community governance and processes.
Once the main design patterns are identified, the modeldriven design of the Web application is guided by the pattern instantiation process and by the gradual integration of the pattern instances. When WebML is used as the modeling language, the WebML models for the front-end and back-end can be directly obtained by instantiation and composition of the proposed patterns.
As an example, the instantiation procedure of the Organization pattern follows these subsequent steps: 1. The units specified in the pattern and their connections are first instantiated in the page (e.g., into a page called My Videos). The instantiation requires the use of a particular entity (e.g. a Video entity) to perform the Item role in the pattern. The role instantiation is usually reflected by the data model where the role entity and instantiated entity are both included in the model, linked by the means of a specialization relationship (e.g., the Video entity is a specialization of an abstract Item entity). 2. The pattern is enriched by selecting the suitable data elements to show (e.g. the information attributes of the current video in the Video DataUnit, typically Title, Description and the Video itself). 3. The pattern is integrated with other patterns and model elements to obtain the desired functionalities. For example, by design-time decision, the upload functionality can be added to the My Videos page eventually reusing suitable units of the pattern. Finally the page is integrated with the rest of the application with incoming and outgoing hypertext links.
The last phase is particularly delicate, as it can involve a high level of complexity, especially when the design requires merging several patterns in the same hypertext page. The definition of a formal procedure to address the WebML pattern composition issues is one of our current research topics. 3
Our works on the technological aspects of Web2.0
applications focused on the definition of a conceptual model
that supports RIA application design, by abstracting from
specific implementation technologies [
A RIA application can be described by its structure and behavior. The former comprises a data model, which specifies the content objects underlying the applications, and an interface model, which describes the front-end exposed to the user. The latter is represented by a dynamic model that describes what happens when the user or other sources of events interact with the application.
Data distribution among client and server can be reflected by refining the data model in order to provide a designer with entities and relationships to represent distributed query execution: in RIAs, contents reside both on the server and in the clients, in the form of main memory objects associated with the server/client applications both in terms of visibility and duration; persistent storage is provided, on the server, by means of standard mechanism (e.g., database, file systems etc.), while, on the client, some technologies also allow the permanent storage of data for local (or offline) application access. Data of RIA applications are therefore characterized by two different dimensions: (1) the architectural tier of existence, which can be the server or the client, and (2) the level of persistence, which can be permanent or temporary. Figure 2 depicts an example of a RIA data model: it represents a simplified version of a multimedia, collaborative platform for the publication, sharing and discovery of contents produced by user’s communities. Graphically, we mark client entities and relationships with a “C” icon, and server elements with a “S” symbol; a filled icon denotes temporary persistence and a non-filled icon permanent persistence.
The entities/relationships on the left-hand side represent data persistently stored on the server, like in traditional Web applications. Content items are the main interaction objects for the application: the MMItem entity represents content published on the platform (e.g., photos, videos or audio tracks), while the Member entity represents all application users. A self-relationship connects each user with his friend list; members manage one or more Playlist, each one aggregating a set of content items. A MMItem belongs to a given member and it is associated to one or more Tag and Comment instances, created by registered users. Data about content items, playlists, comments and tags are persistently stored also on the client, to allow disconnected usage of the application: while off-line, the user can process new items to upload on the platform, update his playlists, and manage associated tags and comments. Reconciliation with the server can be triggered when he goes online.
As data model elements are partitioned considering the architectural tier of existence, a similar approach can be NotificationFilter S OID QueryString FilterFileType
CreatedBy 1:1
AddressedTo used to mark interface model elements in order to distribute computation competencies across client and server. In particular, the designer should be able to specify how the computation of the page and of its content is distributed between the client and the server, how distributed data are managed (to minimize data transmissions), how and when replicated data are synchronized, etc. We therefore distinguish three different aspects of interface modeling, each one related to a specific feature to represent: structural composition, content publication, and content management.
From the technological standpoint, RIAs have a different physical structure than traditional Web 1.0 applications: the latter consist of multiple independent templates, processed by the server and simply rendered by the client. RIAs, instead, typically consist of a single application “clientcontainer” (e.g., a Java applet or a FLASH movie), which loads different data and components based on the user’s interaction, Moreover, the structure of the interface consists of a topmost page (eventually contained into a traditional, server-computed HTML page) partitioned into peer-level sub-pages, independently calculated and rendered by the client, possibly in collaboration with the server. As a consequence, we design the structural composition of RIAs by distinguish between two types of pages, classified into server pages (marked with a circled “S”, and representing traditional Web 1.0 pages, where content and presentation are calculated by the server, whereas rendering and event detection are handled by the client) and client pages (marked with a circled “C”, and representing pages incorporating content or logics managed – at least in part – by the client). To reflect the complex, single-application shell structure of RIA applications, client pages can contain other client sub-pages.
For each page (or sub-page) the interface model specifies the data to be shown, the available interaction mechanisms, and the operations that may be triggered by the user using the provided interaction mechanisms. To this aim, we refined all the WebML concepts related to content publication and management with the explicit specification of distribution between the server and the client: content and operation units, selectors, and ordering clauses can be defined either as server or as client, with some constraints on the possible combinations. Units contained in a server page are computed by the server and are defined as server units, while units contained in a client page are computed by the client (possibly invoking the server) and are defined as client units. For a client unit it is possible to: 1) publish or manipulate content locally stored at the client-side or (by invoking the server) at the server-side (i.e., the reference entity/relationship of the unit can be either a server or a client one, persistent or temporary, as seen in the data model); 2) have client-side selector conditions and/or server-side selector conditions; the former are computed locally at the client, whereas the latter are executed at the server-side. 3) have client-side or server-side ordering clauses; the former are computed locally at the client, whereas the latter are executed at the server-side. Instead, server units are entirely computed by the server and therefore cannot use client-side entity/relationships and cannot comprise client-side selectors and ordering clauses.
As in Web 1.0 applications all the computations
performed by the server must rely only on data and operations
computable at the server side to cope with the asymmetric
nature of the Web (where the client calls the server and not
vice versa), in RIAs, instead, Web applications are allowed
to manage bidirectional communications in order to provide
advanced features like distributed event management.
Previous works [
Content Navigation Search Content File Type Filter
Keyword: String fileType: S tring
Search Result
Content Details selItem: OID
S MMItem [ S Title contains Keyword] [ C MMFileType = fileType]
S MMItem [ S OID = selItem]
Figure 3 shows an examples of RIAs interface models based on the data model for the multimedia, collaborative platform of Figure 2. The Content Navigation client page contains two entry units: Search Content accepts a keyword to be matched in the item’s title, while File Type Filter accepts its file type (e.g., audio, video). Both entry units are linked to the Search Result index unit, defined over the server entity MMItem and provide the parameters to be used in the parametric conditions of the index unit (e.g., parameter Keyword:string is used by the selector condition [Title contains Keyword]). Notice that the computation of the page is managed by the client: however, being the Search Result defined over a server entity, the data of the searched items are retrieved from the database server. The query is then refined by the client, through the application of the second, client selector condition, which filters the retrieved instance without the need for a further server request. The selection of a result from the list triggers the calculation of the Content Details data unit, which retrieves the data about the selected item from the server.
This example shows how the computation of the selectors of the client index unit can be partitioned between the server to comply with the trade-off between efficiency and usability of the designed functionality: server-side selectors allow reducing the data to be transmitted to the client, client-side selectors avoid to invoke the server for their computation. Similar considerations apply also to the partitioning of ordering clauses.
Further examples combining units defined over client
and server entities/relationships to exploit the client storage
capacities are available in [
While the data and interface model allow to represent
how content and data management can be distributed
between the client and the server, the dynamic model explains
what happens upon the interaction of the user or, possibly,
of other events (like, for example, Web service calls). Rich
Internet applications offer a very flexible runtime behavior:
they allow one to selectively (re)compute or refresh only
a portion of the interface of the application and to
maintain unchanged all the pieces of information that are not
affected by the interaction, so that unneeded re-computation
can be avoided. Dually, the interaction may cause some
pieces of content, which were previously displayed, to be
deactivated or invalidated because they are no longer
consistent with the rest of the page. The interface model
presented in the previous subsection has been extended in [
Currently, we are working also on other research projects, which can benefit from the Web 2.0 features.
Within the European PHAROS project1 we are developing an audio-visual Web search portal, permitting users to pose advanced queries to multi-media materials, access results of queries using multi-modal and multi-channel interfaces, and personalize the search experience by saving queries in a personal profile, so that they can be exploited for asynchronous notification of new relevant audiovisual information. This ongoing research demonstrates that the model-driven approach can help the design of such a complex application and the generation of code of sophisticated Rich Internet Application front-ends, typical of the multimedia portals of the future.
1Platform for searcHing of Audiovisual Resources across Online
Spaces – http://www.pharos-audiovisual-search.eu/
We are addressing also the problem of defining a Web
design process suitable for the multi-cultural audience of
a Web application in the globalization era [
In this paper we have presented some research directions ongoing at Politecnico di Milano on Web 2.0 applications, mainly focussing on the social and the technological aspects of Web 2.0. The two aspects are orthogonal and in the design of an application including both of them, they can be considered in different steps: for example, first the design of the application including the patterns for the social aspects can be defined, then it can be refined with the extensions proposed for implementing the application in a RIA platform.
We believe that in the future social Web applications will be more and more integrated in conventional Web applications: we foresee that in the next years companies will start integrating also social features in their B2C portals, organizations will foster user generated content and peer to peer interaction in their Intranets, and so on. As far as the technological aspects are concerned, the current trend is already showing an increasing supply of new tools and several new Web applications are adopting the new technologies. However, the focus of the available tools is on the implementation of the applications for a specific framework/platform.
We believe that the integration of traditional modeldriven Web Engineering methods supporting conventional Web development issues (data storage, publication, management, Web service publication and invocation, user profile management, etc.) with RIAs and social Web 2.0 characteristics is an essential factor for supporting the development of well-crafted, maintainable, usable, and socially effective Web 2.0 applications.