Web augmentation techniques allow the adaptation of websites on client side using browser extensions or plug-ins designed to run dedicated user scripts. However, while number and variety of such scripts from publicly available repositories have grown remarkably in recent years, they usually neglect the user's personal pro le or individual preferences, and therefore fail to provide enhanced personalized services. At the same time recommender systems have become powerful tools to improve personalization on the Web. Yet, many popular websites lack this functionality, e. g., for missing nancial incentive. Therefore, we present a novel approach to empower user script developers to build more personalized augmenters by utilizing collaborative ltering functionality as an external service. Thus, script writers can build recommender systems into arbitrary websites, in fact operating across multiple website domains, while guarding privacy and supplying provenance information. This paper discusses the architecture of the proposed approach, including real-world application scenarios, and presents our tool kit and publicly available prototype. The results show the feasibility of combining Web augmentation with recommender systems, to empower the crowd to build new kinds of applications for a more personalized browsing experience.
In recent years web augmentation techniques, i. e., the addition of external content or behaviour to Web pages, have become a popular means for end users to adapt pages according to their own requirements, with reduced dependency on the website provider. Thereby, advanced users with knowledge of JavaScript, so-called scripters, write (user) scripts to modify web pages, which are then executed within the browser on client side { using dedicated browser plugThis work has been funded by grants Mincyt-bmwf AU/14/02, AU/14/09, oad AR13/2015, ICM-2013-06624. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
Copyright 20XX ACM X-XXXXX-XX-X/XX/XX ...$15.00. ins such as GreaseMonkey1, and without the inclusion of the sites' webmasters. These user scripts are often publicly shared, and to date there are several large repositories providing a vast amount of various scripts for all kinds of Web pages and modi cation tasks. For instance, GreaseFork2 has more than six thousand scripts, some of which are installed more than fty thousand times. Another well-known repository, called UserScripts3, hosts more than one hundred thousand scripts. Examples range from layout modi cation and tweaks (e. g., regarding video player size, video & audio customizations, etc.) on youtube.com4, managing comments on geocaching.com5, to improving navigation on dropbox.com by rendering a Tree View panel6.
Unfortunately, as pointed out by a recent survey [
Recommender systems meanwhile have a longer standing
history in various domains, such as e-commerce or music
recommendations, and have become one of the most
popular ways to personalize services and user experience.
Commonly, they are classi ed [
To alleviate these problems, we aim to introduce recommender system functionality for enhancing personalization in Web augmentation, combining the bene ts of both approaches. To illustrate the use of collaborative ltering 1http://www.greasespot.net (Firefox) 2http://greasyfork.org 3http://userscripts-mirror.org 4http://greasyfork.org/es/scripts/943-youtube-center 5http://userscripts-mirror.org/scripts/show/75959 6http://greasyfork.org/es/scripts/4955-dropbox-plus/code for realizing Personalization in Web Augmentation Applications (paa) we exhibit an example: The website cocktailscout.de is one of largest German language websites for cocktail recipes7, having a community of almost 4000 registered users, who can search, rate and comment recipes for drinks. A rating mechanism is used for ranking of recipes, and averages and distributions of ratings for each drink can be viewed. Yet the users' individual ratings are not exploited to give them personalized recipe recommendations. Instead, the site provides a random link to a recipe on each page. Containing more than 1500 recipe items, however, the site is a perfect target for implementing a collaborative ltering recommender system. Based on the tastes of similar users, personalized recommendations for drinks could be presented in one of the sidebars, as shown in Figure 1.
Typically, the implementation of such functionality heavily depends on the website provider, and in the world of online shopping there is a lot of incentive for service providers to introduce such recommenders for increasing sales and pro t. In contrast, for non-commercially oriented websites, or when items and monetization are not related directly, as with cocktail recipes, there is no such incentive for the site provider. For end users, however, recommender system techniques are commonly beyond the scope and to complex to be employed. Nevertheless, users of the CocktailScout website who are hobby JavaScript programmers, might be interested, and have the skills to implement a user script for utilizing the ratings and adding personalized recommendations of recipes. They do, however, lack access to a recommender system providing them with item recommendations.
Such a system could theoretically be implemented as a
content-based recommender on client-side, given a catalog
of items with features (such as a drink's ingredients), and
the user's interests (such as preferences for ingredients). If
no such item catalog is as available, however, the
alternative, namely to collect all possible items manually in the Web
augmentation script, seems to be a tedious task. For
collab7Highest global Alexa rank (http://www.alexa.com/) in a
comparison of 13 German language cocktail websites.
orative ltering, in contrast, such explicit domain knowledge
is not required, but instead, only explicit or implicit user
ratings (i. e., weighted relations between users and items) are
required. Therefore, for the paa approach we propose to
share ratings and compute recommendations using
collaborative ltering on a dedicated server, not least because of
the current trend to cloud services, and protection of users'
privacy. Consequently, providing a restful api for standard
http requests (and a corresponding object-oriented library
in JavaScript, the prevailing language in the Web
augmentation community), a recommendation service can be
offered to the exemplary cocktail-drinking hobby JavaScript
programmer. Providing a generic service, the approach has
the potential to reach and bene t a large existing web
augmentation community, and can be employed for arbitrary
websites, under control of users and on client-side, and it
may even go beyond single domains or the scope of a
single site provider. Thereby, providing a simple and clear api
and complete documentation is a key requirement, as we
also discovered in the context of the composition language
for building personalized recommenders and services in our
research project TheHiddenYou [
In the upcoming Section 2 we discuss related work in the context of our approach. The following Section 3 presents an overview of the approach, including the tasks for scripters. Next, Section 4 introduces several real-world application scenarios, and demonstrates the approach as seen by the users. Section 5 elaborates on the architecture in detail, in particular the server part, and the paa-api for scripters, which provides the functionality to store and retrieve item ratings, and to retrieve rating predictions and recommendations. In this context important issues are privacy and provenance, issues that are commonly disregarded in the Web augmentation community, but gain importance in the light of a central repository for collecting ratings. Finally, Section 6 discusses our prototype and some practical issues, before Section 7 presents conclusions and future work. 2.
This section discusses related research in several elds, such as adaptive hypermedia, Web personalization, recommender systems, as well as Web augmentation, and nally compares our approach to similar approaches which are used in practice.
Research on Web personalization has been steadily
growing, and in order to satisfy the huge number of end-users,
several approaches for personalizing Web content have emerged,
e.g. user pro ling for personalization [
Although usually recommenders work on server-side, some
approaches for client-side personalization have been
developed [
Web augmentation techniques are another way to achieve
personalization; augmentation allows users to customize
website user interfaces (UIs) in terms of content and
functionality, according to their own requirements [
A similar kind of systems to adapt existing third-party
Web content are intermediaries [
Some authors have proposed personalization as a service
[
This section gives an overview of the approach, in
particular as seen by the script writer, referring to the example
outlined in the introduction. The complete architecture and
technical details about the server will be explained in
Section 5. In short, the paa approach supports the scripter to
make adaptations to the website, as outlined in Figure 2. At
rst ratings are collected in the browser by the scripter 1
and sent to the server using dedicated api methods 2 . After
processing on the server 3 , another set of methods may be
used to retrieve previous ratings, rating predictions, as well
as recommendations 4 , to be nally employed to modify the
page 5 , for instance for link ordering, link hiding, link
annotation, or link generation, as classi ed by Brusilovsky [
Data Collection 1 : Scripters may rely on an existing rating mechanism to measure the user's interest in an item. If no such mechanism exits, it can be implemented by the scripter, either in terms of an explicit rating (e. g., 1-5 stars, like vs. dislike, etc.) or implicitly computing a score (e. g., based on page visit, time spent on the page, activities such as posting comments or uploading pictures). For modeling the user's interest, we rely on events relating users with items (both identi ed with unique ids) and including a numeric score for rating. For presentation purposes later on (cf. 5 ), here we also require additional features about an item, including a human readable name, or meta-info such as an image, to be shown as link in the web browser. For the usecase regarding cocktails, this means we will need the drink's url, its name, an image url, as well as a user id and the numeric rating from the page. Tasks for the scripter: To extract all this information, the scripter usually reads the Web page's document object model (dom): 1. Extract a unique user id from dom (or rely on user's login on the paa server's web interface; cf. Sect. 5); 2. Extract a unique item id from dom; 3. Extract further information about the item from dom, such as name (to be used as link text), or links (to be used for image links); 4. Extract the rating value, or compute a numeric rating from collected explicit or implicit user feedback (or rely on default scores of prede ned event types; cf. Sect. 5).
Send to Server 2 : As a next step, the previously collected data must be sent to the server, to ultimately collect a large number of such events as basis for the recommender algorithm. Tasks for the scripter: Send data to the server via the api, using our provided JavaScript library (parameter string, or object-oriented), or using http post requests.
Processing on Server 3 : On the server events are stored, a timestamp is added, and they are processed to be in a format for being used by the recommender (cf. Sect. 5).
Retrieval from Server 4 : As a next step, queries may
be performed from the script, either for any page on the site
or pages representing or containing items (i. e.,
automatically), or on demand of the user (i. e., manually, cf. `pull
recommendations' [
3 and storage on server
P A A S e r v e r 5 aAnudgmreecnotmamtioenndoaftriaotninsgins,tphreedpiacgtieons getRecommendations( Bob ) reply: [ { http://cocktail.de/piscosour.htm, "Pisco Sour", ".../piscosour.jpg" } , { http://.../blackrussian.htm, "Black Russian", ".../blackrussian.jpg" } ]
4 from server getRating( Bob, http://cocktail.de/whiterussian.htm ) reply: { rating: 4 , avg: 3.5 } getPrediction( Bob, http://cocktail.de/blackrussian.htm ) reply: { 4.5 } post requests.
Augmentation in Page 5 : The previously retrieved
information may nally be augmented in the page.
Previous and average ratings as well as their distributions may
be shown as additional information on the item page, or
for link annotation (cf. [
This section elaborates on several user script use-cases that can be realized with our approach, and focuses on bene ts for the end user.
Cocktail Recipes { Recommendation Scenario. In the previous sections and example we based on the example of cocktailscout.de, a site which has almost 4000 registered users and more than 1500 recipe items, and an existing rating mechanism. Only by exploiting these ratings on the paa server, personalized drink item recommendations can be generated for the user.
Bookstore { Rating Mechanism. The Argentinean online bookstore cuspide.com provides functionality to comment on books, but does neither o er ratings nor personalized recommendations. In such scenarios without a re-usable rating mechanism, a rating widget may be added to the page (cf. Fig. 3), to show items annotated with previous ratings and statistics, as well as to generate personalized recommendations. For the scripter this scenario is slightly more complicated, since it requires the de nition of what items can be rated in the rst place, i. e., a de nition of items to be processed by the user script.
Board Games #1 { Using Predictions. In addition to annotation and generation of links, to improve the visibility of relevant items for the user, rating predictions may be exploited for link hiding and re-ordering. This is particularly useful for sites with a large catalog of items, such as the board gaming community website boardgamegeek.com, with around 77.000 games grouped by publishers, artists, as well as various categories and families (and more than one million of registered users). Even though a rating mechanism exits, personalized recommendations of games are not given to users. Instead, the site displays a list of 50 currently `hot' games. To personalize this list using the paa approach, e. g., it can be re-ordered according to rating predictions for these items and users, and games having a particularly bad prediction (e. g., below a certain threshold) can be hidden.
Board Games #2 { Feedback & Event Types. As
an alternative to the previous scenarios, where users are
required to give explicit ratings, other kinds of user feedback
may be exploited, such as explicit feedback without numeric
ratings, or implicit user feedback. On boardgamegeek.com,
besides explicit ratings, users can become fan of a game,
subscribe, tag, record plays, add games to collections, and
much more. In addition to these explicit events, implicit
feedback may be recorded directly in the browser (i. e.,
behaviors exhibited by the user while using the site; cf. [
Scienti c Literature { Cross Domain. Finally, since Web augmentation scripts can be de ned to run on multiple websites, going beyond the scope of a single content provider, the paa approach enables personalized link recommendations across multiple domains. This feature is specially useful for those Web sites sharing an underlying domain. For instance, for scienti c literature search, a script can track user activities such as page visits and downloads on sites such as acm dl, Springer, ieee Xplore, or Science Direct10. In every site of this list, the same item (Paper) may be de ned with similar properties (url, title, authors, abstract). Based on events collected from these user activities, a recommendations pane can be added to each of these websites to present potentially relevant scienti c literature 10http://dl.acm.org/, http://link.springer.com/, http://ieeexplore.ieee.org/, http://www.sciencedirect.com/ from any of the sites to the user, as shown exemplary in Figure 5. 5.
As it was explained in the introduction, on client-side dedicated plug-ins enable the execution of user scripts to manipulate the dom in the browser. Such user scripts, written in JavaScript language, may execute http requests to external restful apis. This is shown in Figure 6, alongside with the proposed paa architecture and components of the server, which will be explained in more detail in the following. In paa, requests can be made manually using standard scripting tools (e. g., functions provided by Firefox or GreaseMonkey), or using our JavaScript library, which provides functions for sending parameters concatenated as a single strings (e. g., userName=Bob&rating=4&...), or in an object-oriented manner. The latter option is shown exemplary in Figure 7, including code to extract the parameters from the dom, and the interal library implementation is presented in Figure 8.
Processing of Events. As mentioned in step 3 in Section 3, events that are stored on the server are equipped with a timestamp, before all parameters are checked for validity, and events are stored to the database. Furthermore, provided userNames and item ids (itemIri11) are mapped to numeric ids, and stored along with the rating and the timestamp in a separate table to be accessed directly by the recommender engine.
Di erent Types of Events. To distinguish between
different types of events, such as explicit numeric ratings and
other kinds of feedback, the scripter can choose to supply a
custom eventType (e. g., `pictureUpload'). Except for the
distinction, this allows us to provide a default rating value
for several pre-de ned event types (following a classi cation
of observable user behaviour found in literature [
Rating Accumulation. Whereas events represent user actions, for the recommender engine we rely on ratings only. For this, the rating values provided with the events may be used directly. De ned by a parameter insertAs, rst, events may simply be added as `new' ratings (i. e., several ratings per user for a single item are provided to the recommender engine). Second, the rating speci ed by the event may `replace' the previous one. Finally, as an alternative multiple events may be accumulated { in a way that can be con gured by the scripter { to compute the rating value to 11commonly uris/iris (http://tools.ietf.org/html/rfc3987)
Client-Side
(JavaScript)
(JavaScript)
e.g. GreaseMonkey HTTP } Iotbemtaidnaetdafrom DOM } iInteitmizicarleizaattioionnand } oUbsetaricnreedatfiroonm(uthseernDaOmMe) } RoabttianignecdrefarotimonD(vOaMlu)e } sEevnedntincgretaotisoenrvaenrd } and handle the result with Obtain recommendations receiveRecommendations() I U b e W Relational
Views
} fwoerbresqitue,eustsienrg)
De ne and serialize data (current script, recommendations from the server } fsucnricpttieorn) t(odehanneddleby the
Perform the request and execute the callback the server’s response (i.e., recommendations) be used by the recommender. Since user scripts are typically run once per page load, this may be a particularly useful option to track implicit user feedback in terms of potentially many events regarding a single item. For this accumulation, ratings may be derived as `sum', `average', or `median' of event scores. While summing or averaging, weights for older events may be decreased, e. g., linearly or logarithmic. Furthermore, the aggregationScope can optionally be limited to a certain number of most recent events, or using a time window. As a result, the rating scale must allow oat values, and consequently also the ratings provided from the user script can be continuous, allowing di erent scales or binary ratings. For the future we are planning extensions, and we aim to make this computation more customizable, for instance, to enable that di erent event types contribute to the accumulation in di erent manners.
Authentication & Web UI. User authentication is not required if while making api calls the user script provides a userName. Clearly this is security issue, because in this basic form there is no authentication involved. This option was enabled for the sake of simplicity, and for simple scenarios where security is not an issue. Alternatively, instead of providing a user name, the parameter paaAuthRequired can be set to true, enabling authentication via the paa website (the current status can be queried using getLoginStatus(), to open the login form if necessary). Once logged in, the corresponding cookie is being included by the browser when making calls to the server's api. Via the Web user interface, users can furthermore manage their pro le data and view coarse grained provenance information. Thereby, the user may be provided with insights to what data is being stored and how it is used, including information on why speci c recommendations were given. This increases transparency and helps to gain the users' trust, and to satisfy users who might normally be reluctant to share personal data with providers of (commercially oriented) personalization services.
Recommender Engine on Server. For adding events,
as well as for queries to the recommender engine, every api
query must provide the script's pluginName,
pluginNamespace, and the site domain. These de ne the operation
domain for the recommender, i. e., the view for ratings that
are seen by the recommender engine (also user names must
be unique within this operation domain). For computing
predictions and recommendations the current generic
prototype implementation relies on the open-source framework
LensKit12, con gured to perform item-item collaborative
ltering for scoring items (cf. [
Provision to Client. Finally, for answering queries regarding ratings, predictions, and recommendations, again user names and item ids are mapped to numeric ids and vice versa, and previously stored itemNames and meta infor12http://lenskit.org/ { Recommender Toolkit 13http://lenskit.org/documentation/algorithms/item-item/ mation (stored per event) are added where applicable. Example responses are shown online along with the prototype, as discussed in the following section.
The implemented paa prototype is publicly available online14, including our object-oriented JavaScript library with example scripts and instructions for their usage. The implementation bases on Jersey15 for handling restful http requests, and employs Spring Security16 for authentication, which also allows the future integration of identity providers such as Openid (supported by Google) or Facebook Connect, to lower the barrier for acquiring users. In general, persistence is realized with Hibernate17, however, using relational views LensKit12 accesses the underlying database directly.
The prototype shows the feasibility of combining Web augmentation with recommender systems. It was not yet optimized for performance (prediction accuracy and response times), yet it shows that the approach is suitable for empowering scripters to build new kinds of augmentations.
Since we base on established item-item collaborative ltering algorithms, the evaluation of prediction accuracy was not a goal for this paper. However, we do plan to do this in the future, along with an evaluation of our methods for computing the cumulative score from di erent event types. In this context, an interesting question is how well does the chosen LensKit con guration generalize for all kinds of items, and how can it be made con gurable by the scripter.
Concerning response times, on one hand, the approach is limited by the connection to the server through Internet, however, with optimizations possible, for instance by providing api methods to combine several http requests into one (e. g., storage of multiple events as a batch, or combining the storage of an event with a query for recommendations), or by reducing the amount of redundantly transferred event meta information. On the other hand, the computation of recommendations on the server is currently made on demand for each request, but could be made con gurable, such that the scripter may de ne whether recommendations should be computed in advance, or if they have to reincorporate all the latest added events.
As with collaborative ltering recommenders in general, the known cold start problem is an issue to be considered, also for script writers. To mitigate this problem, in situations where ratings are publicly available, the scripter may add them as a batch, e. g., by extracting user ratings from cocktailscout.de, or using the xml api of boardgamegeek.com. Additionally, to support early development of new scripts, our prototype can be con gured to append random items to the list of recommendations, until the recommender algorithm can compute enough actual ones.
Finally, so far our approach does not foresee the removal of items. In an open environment, where every end user can add items, maybe role-based user management, a reputation based approach, or a voting mechanism can be used to decide which items to remove. In this context, it also may happen that websites change their url structure. While this is something that every Web augmentation approach has to 14http://paa.cis.jku.at/ 15http://jersey.java.net/ { jax-rs Reference Impl. 16http://projects.spring.io/spring-security/ 17http://hibernate.org/ { Object Relational Mapping deal with, this may cause additional database maintenance e orts if the ids of items are a ected. 7.
We have shown the feasibility for providing collaborative ltering recommender system functionality as a service for Web augmentation. By providing a simple api and corresponding object-oriented JavaScript library, user script writers may employ ratings, predictions, as well as recommendations of items, to develop new kinds of recommender applications for arbitrary websites. Thus, end users bene t from personalization of the Web browsing experience through annotation, re-ordering, hiding, and generation of links. Several real world world application scenarios were discussed, and we presented our publicly available server prototype.
To improve and further evaluate the proposed approach, we foresee several lines of potential future work. Therefore, we are currently working on an extended prototype, mainly to add some minor features, improve response times, and add further means of con guration for the scripter. In a profound evaluation we aim to cover the issues outlined in the previous section: recommendation relevancy, the serverside computation of scores, response times and their e ect on users' browsing experience, and methods to cope with the removal of items or changing urls. In this kind of systems another very well known issue is the cold start problem, in this sense, we plan to provide scripters with some mechanisms to de ne how the script adapts the Web page when the available ratings are not enough. A possibility we are studying is to allow a scripter to use a single user pro le in several scripts. In this context, we also plan to conduct several user studies, rst, with scripters to evaluate the comprehensibility of the api for implementing pre-de ned tasks, and how the provided service is being accepted. Second, we intend to evaluate performance, quality of recommendations, as well as scalability, in terms of a larger case study with users, employing experts or a number of end users, e. g., from the boardgamegeek.com community. There, publicly available ratings can be exploited to reduce the cold start problem, or to build a dataset for an o ine evaluation of the employed recommender algorithm. Finally, with a complete prototype and documentation, downloads of our scripts and usage of the api can be evaluated in long term study.
In terms of functionality, we foresee several expansions.
Support for di erent data formats for the api (e. g., json,
xml, rdf) allows the reduction of technical heterogeneity,
and enables simpler integration with arbitrary websites {
also to give the scripters more options. Moreover, using
rdf facilitates the use of semantic Web technologies and
resources, not least to supply further structured information
about items from resources such as dbpedia. Together with
user pro le data and item features collected in the browser,
or extracted from online social networks, this information
may be exploited by the recommender algorithms, for
instance to better determine user-user or item-item
similarities, or for improving recommendation results with
contentbased and hybrid recommender mechanisms on server side.
In this context it is particularly interesting how well the
current implementation recommends newly added items or
items with few ratings, and if the algorithms can be made
con gurable for end users or scripters, to include items from
the long tail for increasing serendipity in recommendations.
In this context, the recommender system algorithms may
also be con gured via the api in a more elaborate way,
for instance using LensKit's Groovy-based dsl18.
Furthermore, feedback on recommendations may be exploited to
improve recommendations (i. e., when the user follows a
recommended link, or rates the corresponding item afterwards),
and item recommendations that are constantly ignored may
be excluded in the future. The set of items considered by
the recommender may also be de ned by the scripter, for
instance, by providing a speci c set or lter criteria via the
api, as with a Recommendation Query Language (cf. [
To decentralize the approach, giving even more control to the user script writer, we plan to investigate how the server functionality can be hosted by a generic "platform as a service" provider of cloud computing services, and if the api functionality can be provided as a downloadable and congurable bundle. Going beyond the server side approach, the question remains whether the architecture can be reimplemented to be independent of a single third party recommendation service provider, with recommendations being computed on client-side, and exchanging anonymized data via a dedicated data exchange server only, or relying on a peer-to-peer architecture.
Finally, we foresee the implementation of a browser
plugin to o er a graphical user interface for con guration and
augmentation of recommendations, to be used by scripters
or even end-users, based on a dsl to de ne extraction and
placement of item and user information in the dom (cf. [