UNIVERSIDAD POLITÉCNICA DE MADRID

Transcription

1 UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingenieros de Telecomunicación CONTRIBUTION TO PROACTIVITY IN MOBILE CONTEXT-AWARE RECOMMENDER SYSTEMS TESIS DOCTORAL Daniel Gallego Vico Ingeniero de Telecomunicación Madrid, España Septiembre, 2013

2

3 Departamento de Ingeniería de Sistemas Telemáticos Escuela Técnica Superior de Ingenieros de Telecomunicación CONTRIBUTION TO PROACTIVITY IN MOBILE CONTEXT-AWARE RECOMMENDER SYSTEMS TESIS DOCTORAL Autor: Daniel Gallego Vico Ingeniero de Telecomunicación Director: Gabriel Huecas Fernández-Toribio Doctor Ingeniero de Telecomunicación Septiembre, 2013

4

5 Tribunal nombrado por el Magnífico. y Excelentísimo. Sr. Rector de la Universidad Politécnica de Madrid, el día 16 de Septiembre de Presidente: Vocal: Vocal: Vocal: Secretario: Suplente: Suplente: Realizado el acto de defensa y lectura de la Tesis el día 26 de Septiembre de 2013 en Madrid, habiendo obtenido la calificación de El presidente, El secretario, Los vocales,

6

7 ABSTRACT Recommender systems are powerful information filtering tools which offer users personalized suggestions about items whose aim is to satisfy their needs. Traditionally the information used to make recommendations has been based on users ratings or data on the item s consumption history and transactions carried out in the system. However, due to the remarkable growth in mobile devices in our society, new opportunities have arisen to improve these systems by implementing them in ubiquitous environments which provide rich context-awareness information on their location or current activity. Because of this current all-mobile lifestyle, users are socially connected permanently, which allows their context to be enhanced not only with physical information, but also with a social dimension. As a result of these novel contextual data sources, the advent of mobile Context-Aware Recommender Systems (CARS) as a research area has appeared to improve the level of personalization in recommendation. On the other hand, this new scenario in which users have their mobile devices with them all the time offers the possibility of looking into new ways of making recommendations. Evolving the traditional user request-response pattern to a proactive approach is now possible as a result of this rich contextual scenario. Thus, the key idea is that recommendations are made to the user when the current situation is appropriate, attending to the available contextual information without an explicit user request being necessary. This dissertation proposes a set of models, algorithms and methods to incorporate proactivity into mobile CARS, while the impact of proactivity is studied in terms of user experience to extract significant outcomes as to "what", "when" and "how" proactive recommendations have to be notified to users. To this end, the development of this dissertation starts from the proposal of a general architecture for building mobile CARS in scenarios with rich social data along with a new way of managing a recommendation process through a REST interface to make this architecture multi-device and cross-platform compatible. Details as regards its implementation and evaluation in a Spanish banking scenario are provided to validate its usefulness and user acceptance. After that, a novel model is presented for proactivity in mobile CARS which shows the key ideas related to decide when a situation warrants a proactive recommendation by establishing algorithms that represent the relationship between the appropriateness of a situation and the suitability of the candidate items to be recommended. A validation of these ideas in the area of e-learning authoring tools is also presented. Following the previous model, this dissertation presents the design and implementation of new mobile user interfaces for proactive notifications. The results of an evaluation among users testing these novel interfaces is also shown to study the impact of proactivity in the user experience of mobile CARS, while significant factors associated to proactivity are also identified. The last stage of this dissertation merges the previous outcomes to design a new methodology to calculate the appropriateness of a situation so as to incorporate proactivity into mobile CARS. Additionally, this work provides details about its validation in a European e-learning social network in which the whole architecture and proactive recommendation model together with its methods have been implemented. Finally, this dissertation opens up a discussion about the conclusions obtained throughout this research, resulting in useful information from the different design and implementation stages of proactive mobile CARS.

8

9 RESUMEN Los sistemas de recomendación son potentes herramientas de filtrado de información que permiten a usuarios solicitar sugerencias sobre ítems que cubran sus necesidades. Tradicionalmente estas recomendaciones han estado basadas en opiniones de los mismos, así como en datos obtenidos de su consumo histórico o comportamiento en el propio sistema. Sin embargo, debido a la gran penetración y uso de los dispositivos móviles en nuestra sociedad, han surgido nuevas oportunidades en el campo de los sistemas de recomendación móviles gracias a la información contextual que se puede obtener sobre la localización o actividad de los usuarios. Debido a este estilo de vida en el que todo tiende a la movilidad y donde los usuarios están plenamente interconectados, la información contextual no sólo es física, sino que también adquiere una dimensión social. Todo esto ha dado lugar a una nueva área de investigación relacionada con los Sistemas de Recomendación Basados en Contexto (CARS) móviles donde se busca incrementar el nivel de personalización de las recomendaciones al usar dicha información. Por otro lado, este nuevo escenario en el que los usuarios llevan en todo momento un terminal móvil consigo abre la puerta a nuevas formas de recomendar. Sustituir el tradicional patrón de uso basado en petición-respuesta para evolucionar hacia un sistema proactivo es ahora posible. Estos sistemas deben identificar el momento más adecuado para generar una recomendación sin una petición explícita del usuario, siendo para ello necesario analizar su contexto. Esta tesis doctoral propone un conjunto de modelos, algoritmos y métodos orientados a incorporar proactividad en CARS móviles, a la vez que se estudia el impacto que este tipo de recomendaciones tienen en la experiencia de usuario con el fin de extraer importantes conclusiones sobre "qué", "cuándo" y "cómo" se debe notificar proactivamente. Con este propósito, se comienza planteando una arquitectura general para construir CARS móviles en escenarios sociales. Adicionalmente, se propone una nueva forma de representar el proceso de recomendación a través de una interfaz REST, lo que permite crear una arquitectura independiente de dispositivo y plataforma. Los detalles de su implementación tras su puesta en marcha en el entorno bancario español permiten asimismo validar el sistema construido. Tras esto se presenta un novedoso modelo para incorporar proactividad en CARS móviles. Éste muestra las ideas principales que permiten analizar una situación para decidir cuándo es apropiada una recomendación proactiva. Para ello se presentan algoritmos que establecen relaciones entre lo propicia que es una situación y cómo esto influye en los elementos a recomendar. Asimismo, para demostrar la viabilidad de este modelo se describe su aplicación a un escenario de recomendación para herramientas de creación de contenidos educativos. Siguiendo el modelo anterior, se presenta el diseño e implementación de nuevos interfaces móviles de usuario para recomendaciones proactivas, así como los resultados de su evaluación entre usuarios, lo que aportó importantes conclusiones para identificar cuáles son los factores más relevantes a considerar en el diseño de sistemas proactivos. A raíz de los resultados anteriores, el último punto de esta tesis presenta una metodología para calcular cuán apropiada es una situación de cara a recomendar de manera proactiva siguiendo el modelo propuesto. Como conclusión, se describe la validación llevada a cabo tras la aplicación de la arquitectura, modelo de recomendación y métodos descritos en este trabajo en una red social de aprendizaje europea. Finalmente, esta tesis discute las conclusiones obtenidas a lo largo de la extensa investigación llevada a cabo, y que ha propiciado la consecución de una buena base teórica y práctica para la creación de sistemas de recomendación móviles proactivos basados en información contextual.

10

11 Acknowledgments

12

13 Contents Abstract Resumen Acknowledgments List of Illustrations List of Tables List of Acronyms 1 Introduction Objectives Research Methodology Structure of this Document State of the Art Recommender Systems General Overview Data and Knowledge Sources Recommendation Techniques Data Mining Methods Recommender Systems and Human Computer Interaction Context-Aware Recommender Systems Defining Context Modeling Contextual Information in Recommender Systems Obtaining Contextual Information Paradigms for Incorporating Context in Recommender Systems Mobile Recommender Systems Mobile Context-Aware Recommendation Systems Challenges Proactivity Minimizing the Costs of Proactivity Processing Interruptions Deciding about Notifications Notification Cues Timing a Notification Adapting Notification Modalities to User Preferences Proactivity in Recommender Systems Related Recommender Systems Research: Application Fields Banking Learning

14 CONTENTS 3 An Architecture for Social Mobile CARS Introduction Objectives Design Recommendation Model Architecture Implementation Scenario Banking Data Anonymization Recommender Application Manager and API Mobile Client Evaluation and Results Description and Objectives Demographics and Data Collection Results Discussion Contribution Conclusions A Model for Proactivity in Mobile CARS Introduction Objectives Design Challenges and Requirements Context Process Overview Phase I: Situation Assessment Phase II: Item Assessment User Feedback Application to E-Learning Authoring Tools Motivation Scenario: Use Cases Model Adaptation Contribution Conclusions Proactivity Impact in Mobile CARS User Experience Introduction Objectives Design and Implementation of the Mobile Application Design Guidelines for Proactive Notifications Scenario Technological Decisions Mobile User Interfaces for Proactive Recommendations User Interfaces for Visualizing Recommended Items

15 CONTENTS 5.4 Evaluation and Results Description and Objectives Demographics and Data Collection Results Discussion Limitations of the Study Proactivity Impact Recommendations Visualization Contribution Conclusions Methods to Incorporate Proactivity into Mobile CARS Introduction Objectives Recommendation Model Scenario: The Virtual Science Hub Motivation: Requirements and Challenges Phase I: Social Context Generation Method Evaluation and results Phase II: Situation Assessment Method Evaluation and Results Application to ViSH: Features and Values Phase III: Item Assessment Method Evaluation and Results Application to ViSH: Features and Values Discussion Limitations of the Study Phase I Phase II Phase III Displaying Proactive Recommendations in ViSH Contribution Conclusions Validation and Results Validation in National Projects Perdidos en la Gran Ciudad Validation in European Projects GLOBAL excursion Dissemination of Results Publications Research Visit Teaching

16 CONTENTS 8 Conclusions What kind of architecture is suitable for building mobile context-aware recommender systems in scenarios with rich social data? How can proactivity be incorporated into mobile CARS? Which UX factors are considered in proactive recommenders? Contributions Future Research Bibliography 195

17 Illustrations 2.1 General relationships between items, users and transactions Examples of common used rating scales: unary (like), binary (thumbs up / thumbs down), scalar (five-star and slider) Contextual information hierarchical structure for Location context Multidimensional model for the User Item Time recommendation space [Adomavicius 2005a] General components of traditional recommender systems Paradigms for incorporating context in recommender systems Screen sizes and densities in Android devices [Android-Developer 2013a] Model for generating context-aware recommendations using social data in mobile recommender systems Steps to generate the social context General architecture for building mobile context-aware recommender systems based on social data Architecture deployed for the banking scenario and its recommendation process flow Smartphone and tablet mobile applications showing a restaurant recommendation Social clusters distribution by average expense in credit card per year, age and size Application survey results Model for proactivity in mobile context-aware recommender systems Scenario for recommending in mobile e-learning authoring tools Model for generating proactive context-aware recommendations in e-learning authoring tools Proactive user interface based on status bar notification. Notification icon and message in the status bar (a), and expanded notification (b) Proactive user interface based on widgets Ranking user interface: initial view (a) and after giving feedback (b) Map user interface: map visualization (a) and place details (b) Evaluation results of status bar notification Evaluation results of widget notification Comparison between widget (W) and status bar (SB) notifications Evaluation results of ranking recommendation visualization Evaluation results of map recommendation visualization

18 ILLUSTRATIONS 6.1 Model for generating proactive context-aware recommendations in mobile recommender systems Distribution of users and learning objects in the social clusters generated Context model Evaluation results of appropriateness corresponding to the geographical, temporal, device and activity context feature values Evaluation results of weights corresponding to every context feature Visualization of proactive recommendations in ViSH

19 Tables 2.1 Summary of main recommendation techniques Summary of HTTP methods available for the REST API resources Context information used in the recommendations process Survey scenarios for proactive resturant recommendations Scenarios responses for the status bar notification Scenarios responses for the widget notification Statistics related to the comparison between widget (W) and status bar (SB) notifications Context features and their values for the ViSH scenario Appropriateness factors of context model features values Weighting of context model features Applicability factors of context model features values

20 TABLES

21 Acronyms A-GPS Assisted Global Positioning System API Application Program Interface CARS Context-Aware Recommender Systems CF Collaborative Filtering E-Commerce Electronic Commerce E-Learning Electronic Learning EC European Commission GPS Global Positioning System HCI Human Computer Interaction ICT Information and Communication Technology IT Information Technology LO Learning Object M-Commerce Mobile Commerce PC Personal Computer REST Representational State Transfer TEL Technology Enhanced Learning U-Commerce Ubiquitous Commerce UI User Interface UPM Universidad Politecnica de Madrid URI Uniform Resource Identifier URL Uniform Resource Locator UX User experience ViSH Virtual Science Hub

22 TABLES

23 Chapter 1 Introduction Recommender Systems are powerful information filtering tools that are currently becoming widely used in Information Technologies. Since the first recommendation algorithms were proposed in the mid-1990s, the field has evolved very quickly especially in recent years resulting from the Internet information overload phenomenon. Thousands of new articles, blog posts, movies, books and songs among others "items" are available every day. In this scenario, selecting the most suitable one for every person is even more difficult as maybe the best choice is not the most popular, it being really complex for anybody to find it out from among an overwhelming set of options. As a result, recommender systems have proved to be key tools in solving this problem. Companies such as Amazon or Netflix are good examples of the benefits of using recommender systems in their platforms, as important percentages of their sales are achieved from recommendations provided to their users, e.g. 75% of the content watched on Netflix comes from its recommendation engine [Amatriain 2012]. Furthermore, not only are commercial applications implementing these techniques, but also other domains such as e-learning or social networks are using recommendations intensively on a daily basis. As regards social networks, they can add an important dimension to recommender systems design as the level of personalization in the recommendation process may be improved if the system knows more about its users. In fact, a social network is not necessary per se to incorporate social information in the recommendation process. Several entities such as banks or telecommunication providers also have detailed personal data of their clients behavior, consumption trends, etc. Therefore, by using the social knowledge they have about them, they might generate enhanced recommendations about their products, or even more interestingly, about other items that can be inferred by taking into account aggregated information extracted from their customers activity. However, how to merge social information from different sources is still a problem in recommender systems design as they are usually domain-dependent. At the same time, the rapid evolution of mobile devices and data networks in the last decade have contributed to the current all-mobile lifestyle based on the huge market penetration of

24 2 CHAPTER 1. INTRODUCTION smartphones and tablets. Everything is currently going mobile, and thus recommender systems have evolved to become ubiquitous too. Almost every mobile device currently has a set of sensors such as GPS, accelerometer or compass. They provide the possibility of analyzing the real world related to a user in a more accurate way. By integrating this information in traditional recommender systems, contextual information extracted from these sensors can be used to improve the level of personalization in attending, for example, to the current user s location or activity. These systems, usually known as Context-Aware Recommender Systems (CARS) [Adomavicius 2011], have given rise to new recommendation algorithms, creating a new paradigm for designing recommender systems in which the system is aware of the current physical, social or temporal environment of the user. As a consequence of this real-time knowledge on the user, novel ways of recommending can be looked into to rethink the traditional user request-response pattern commonly used in recommender systems and incorporate proactivity: recommendations are made to the user when the current situation is appropriate without the need for an explicit request. Based on these ideas, this dissertation aims to answer the question: How could proactivity be incorporated into mobile context-aware recommender systems to improve the quality of the recommendations and the user experience in scenarios with rich social data? Keeping in mind this idea, this work addresses three open challenges to the research community: 1. What kind of architecture is suitable for building mobile context-aware recommender systems in scenarios with rich social data? 2. How can proactivity be incorporated into mobile context-aware recommender systems? 3. Which factors need to be considered in the implementation of a proactive recommender system in terms of user experience? This research embraces the study of the improvements achieved in the recommendation paradigm as a result of the synergy between proactivity and mobile CARS in order to take advantage of a changing ubiquitous environment. The main outcome is the proposal of a novel model for generating proactive context-aware recommendations supported by a general architecture to be used in social scenarios, as well as the methods to make recommendations proactively in mobile applications based on user experience.

25 1.1. OBJECTIVES Objectives As a result, this dissertation can be divided into two overall objectives: the proposal of a general architecture for building mobile CARS with rich social data and, on top of it, the proposal of models and methods to evolve current mobile recommender system design based on using contextual information from users and their environment to incorporate proactivity into the recommendation process, along with an appropriate user experience. Thus, the specific objectives of this work can be summarized as follows: To identify which elements are needed for designing mobile context-aware recommender systems with rich social data. This study should clarify which modules are necessary and how they have to be used in a general architecture. To propose a novel architecture valuable for building mobile context-aware recommender systems capable of using contextual information from different social sources as well as different mobile devices. As a result of the previous study, this proposal should include a set of functionalities to handle this architecture in the use case analyzed. To implement and test the proposed general architecture in a real scenario. It should be built taking advantage of current technologies in the area of recommender systems and mobile development. To identify open challenges related to generating proactive recommendations in mobile context-aware recommender systems. I will study the implications of incorporating proactivity into these kinds of systems not only in terms of methodological aspects, but also user experience factors. To propose a general model for proactivity in mobile context-aware recommender systems. It should be as general as possible in order to be used in current recommender systems wanting to incorporate proactivity. To evaluate the impact and suitability of proactive recommendations in terms of user experience in these systems. I will evaluate different ways of providing proactive recommendations to mobile users so as to study the impact of proactivity in their user

26 4 CHAPTER 1. INTRODUCTION experience, as well as analyzing the most important factors to consider when recommending proactively. To provide general methods for incorporating proactivity into mobile context-aware recommender systems. As a result of the previous evaluation, I will design novel methods to incorporate proactivity following the general model proposed. To validate the feasibility of the research approach. In order to assess these contributions the objectives described in this document should be validated in different real scenarios to demonstrate the suitability of the model and methods proposed. 1.2 Research Methodology The implementation of proactivity features in mobile CARS presents significant research challenges that involve several steps not only in terms of designing new artifacts (e.g. models), but also with the aim of developing technology-based solutions that have to be evaluated to demonstrate their validity in order to become real research contributions. In this spirit, this dissertation follows a design science approach. To be more precise, it satisfies the seven guidelines for design science in information systems research provided by Hevner et al. [Hevner 2004] as follows: 1. Design as an Artifact. This work contains the description of several artifacts that were created: a general architecture for mobile CARS, as well as models, algorithms and user experience methods for incorporating proactivity. 2. Problem Relevance. The relevance of the investigated problem is demonstrated through the presence of a vast array of related work in this field, in addition to significant business problems detected. 3. Design Evaluation. In order to show the functionality and utility of the approach presented, suitable evaluation methods are described and applied such that a discussion of the developed solution can be provided. 4. Research Contributions. Novel contributions that have been validated in several research projects are generated within this work (refer to section 8.4).

27 1.2. RESEARCH METHODOLOGY 5 5. Research Rigor. This approach is designed based on related work and empirical evidence. Furthermore it is evaluated through rigorous statistical methods and quality measures derived from the quantitative studies carried out. 6. Design as a Search Process. The review of work behind this dissertation to understand the problem of incorporating proactivity into mobile CARS addresses the guideline that interprets design science as a research process for finding appropriate solutions. For that reason, this dissertation provides descriptions and evaluations of the most valuable artifacts generated during this work to solve the problems set out. 7. Communication of Research. The major contributions contained in this work have been published in the academic community (refer to section 7.3). As a result of this research methodology, the work carried out in the Perdidos en la Gran Ciudad i and GLOBAL excursion ii projects has helped me to identify these challenges. The research associated to this dissertation has been partially supported by these projects in which building a recommender system was a key requirement. During this dissertation, and especially in chapter 7, I will give details on how the work carried out in these projects helped me to design, implement, test and validate the contributions proposed. However, as these projects have taken on special importance in the research methodology I followed to make this dissertation, I will briefly explain now the details relate to it. I started from the main objectives explained in section 1.1 to carry out wide-ranging research into the architectures, technologies and interfaces related to building mobile CARS in scenarios with rich social data. Bearing in mind the conclusions of this initial study, I designed a general architecture capable of being used in different scenarios with a recommendation model independent of the technologies used on the client and server side. In addition to this, I designed a generic REST API to manage contextual information and request recommendations for mobile CARS following this architecture. The work carried out in the Perdidos en la Gran Ciudad project allowed me to implement and validate the previous architecture in a real banking scenario. As a result, the system involved i ii

28 6 CHAPTER 1. INTRODUCTION strict requirements as regards the special conditions these scenarios present in relation to handling sensitive data from the banking entity. As a result, new challenges appeared such as managing huge amounts of banking data in a secure and private way or generating the recommendations in real time using information from real purchases from Bankinter clients, together with contextual information retrieved from the mobile clients and the social relationships established between the bank customers. Thus, new adaptations to the architecture were made in order to overcome the challenges that arose. In the process of developing the system, I had the opportunity to evaluate the ideas implemented and the project itself among Bankinter customers. A spiral model methodology was carried out to enhance the final system taking into consideration the feedback given by users using it at all times. The main outcome of this project was a mobile CARS capable of generating cross-domain recommendations about different places (e.g. shops, supermarkets or restaurants) to Bankinter clients. Interesting research questions arose as a consequence of the results achieved in this project as the idea of proactivity came up: recommending without an explicit user request being made. In other words, investigating how mobile CARS can analyze the current situation of a user to provide him/her with personalized recommendations in a proactive way. An extensive review of the literature was carried out related to proactivity in recommender systems. As a result, I got in contact with Dr. Wolfgang Woerndl to collaborate with him for three months in a research stay at the Group of Applied Informatics and Cooperative Systems of the Technical University of Munich, in Germany. During that time, I contributed to the definition of a new model for proactivity in mobile CARS, achieving a new paradigm of assessing the situation of users to make recommendations to them proactively. Moreover, I designed and developed a mobile application following the model created to evaluate novel methods of recommending proactively by attending to user experience criteria. By studying the impact and acceptance of these kinds of novel recommendation methods among users, I reached significant outcomes on how to design user interfaces for proactivity in mobile applications, as well as determining important factors related to decide whether a situation warrants a proactive recommendation. Further research was required for combining and extending the previous results into a more general recommendation model which incorporated proactivity into mobile CARS. Related to that

29 1.3. STRUCTURE OF THIS DOCUMENT 7 new model, I also designed a set of novel methods to assess the appropriateness of a situation to generate a proactive recommendation. A final validation was carried out throughout the GLOBAL excursion European project in which I participated when I returned from Munich. GLOBAL excursion aims to introducing e-infrastructures to educators and pupils. It provides scientists and teachers with a package of activities, materials and tools for enabling the integration of e-infrastructures into school curricula. The main access point is the GLOBAL Virtual Science Hub (ViSH). It contains a selection of e-infrastructures, a collaborative content repository where scientists and teachers are able to exchange and establish collaborations, and a virtual excursion room, where pupils are able to experience real e-science applications. In this educational scenario I was responsible for integrating a mobile CARS in ViSH. By using the previously defined general architecture, but this time including the new proactive recommendation model and its related methods, I built the ViSH recommender system capable of recommending learning objects and peers to its users. Apart from this, the appropriateness of proactive recommendations for educators using the platform was evaluated among teachers and scientists by studying different situations involving several devices and user activities, as well as temporal or geographical factors. As a result of this study, a valuable user model was developed of use in applications in other educational scenarios as regards proactivity. The entirety of this work as a whole has provided the author with a wide scientific context and has set out his work on an international basis, which is the main reason for the author to apply for the Doctor International Seal of Quality. 1.3 Structure of this Document Chapter 2: State of the Art In this chapter, an in-depth study of current background and related work is presented to give a general overview of recommender systems and their evolution in recent years. The study includes the current state of the art of recommendation paradigms, paying special attention to those based on using context-awareness information. Additional studies related to the implications of recommender systems in terms of human computer interaction, as well as their application in mobile systems and the novel research results related to incorporate proactivity are also detailed.

30 8 CHAPTER 1. INTRODUCTION Chapter 3: An Architecture for Social Mobile CARS In this chapter, results of the design and implementation of a new architecture for building mobile CARS are presented. The general architecture and its REST API are described, to be then applied to the Perdidos en la Gran Ciudad project carried out in the context of the research collaboration between the Universidad Politécnica de Madrid and the Spanish bank Bankinter. This architecture allows personalized recommendations to be generated in scenarios with rich social data and context-aware information coming from mobile devices, making the recommendation model independent of the technologies chosen for both the client and server sides. Methodological and technical details on its application in the banking scenario to generate cross-domain recommendations as to places (e.g. restaurants or shops) are provided, as well as the results from the user evaluation carried out among Bankinter clients. Chapter 4: A Model for Proactivity in Mobile CARS In this chapter, a model for proactivity in mobile CARS is presented attending to how the current situation of a user can be assessed to decide whether it deserves a proactive recommendation. The model proposes a general paradigm to be applied in existing recommender systems that only need to include the analysis of contextual information to evaluate the situation, the final item being an assessment process capable of supporting contextual and non-contextual methods. To validate the model proposed, details on its application to generate proactive recommendations in online e-learning authoring tools are also presented. Chapter 5: Proactivity Impact in Mobile CARS User Experience In this chapter, the design and implementation of novel user interfaces to visualize proactive recommendations in mobile CARS are presented. An evaluation carried out among users using the application developed to look into the impact of proactive recommendations and the usability of these proactive user interfaces is detailed. As a result, significant outcomes regarding the factors that have to be considered when designing proactive mobile CARS in terms of user experience are explained.

31 1.3. STRUCTURE OF THIS DOCUMENT 9 Chapter 6: Methods to Incorporate Proactivity into Mobile CARS In this chapter, a novel model for proactivity in mobile CARS is proposed keeping in mind the previous contributions. The methods related to this model for assessing the appropriateness of a situation in order to decide whether it warrants a proactive recommendation are also presented. Furthermore, as part of the GLOBAL excursion European project, a validation of the initial architecture for building mobile CARS including the new methods for incorporating proactivity into them is also described. How the methods were applied to that scenario to recommend learning objects and peers to users registered in the educational social network developed within the project are detailed. In addition, the results of the study among educators evaluating the appropriateness and importance of proactive recommendations in their daily teaching experience are also presented to show remarkable outcomes extracted from using this kind of system in educational scenarios. Chapter 7: Validation and Results In this chapter, general results from the different projects involved are presented along with the validation of every contribution. It also details the results of this dissertation from the point of view of scientific results as dissemination into the research community, apart from additional information on the activities associated with this dissertation. Chapter 8: Conclusions In this chapter, the author summarizes the main contributions presented in this dissertation and outlines several future research activities based on this work.

32 10 CHAPTER 1. INTRODUCTION

33 Chapter 2 State of the Art 2.1 Recommender Systems In our daily life it is often necessary to make choices without sufficient information or personal experience about the alternatives we have to buy or use something attending to our needs. Usually we rely on recommendations from other people (sometimes acquaintances or friends) either by word of mouth, reviews in media or general guides. Recommender systems try to do this automatically by assisting and augmenting this natural process providing "recommendations as inputs, which the system then aggregates and directs to appropriate recipients" [Resnick 1997]. Another broad definition defines recommender systems as "software tools and techniques providing suggestions for items to be of use to a user" [Ricci 2010a]. "Item" is the general term used to denote what the system recommends to users. Therefore these systems made recommendations to users when they request suggestions about items they may need. These recommendations usually focus on a specific type of items (e.g. books or movies). But recent proposals, such as the one described in this dissertation, try to offer cross-domain recommendations of items belonging to several categories or domains. Therefore, recommender systems are primarily directed towards individuals who lack sufficient personal experience or competence to evaluate the potentially overwhelming number of alternative items offered by web sites, mobile applications or e-commerce platforms. This section provides a general overview of Recommender Systems and give details about the main different types existing in the field General Overview Recommender systems emerged as an independent research area in the mid-1990s with the first papers on collaborative filtering [Goldberg 1992], [Resnick 1994], [Shardanand 1995] because they proved to be powerful tools for helping people to find content, products or services based on

34 12 CHAPTER 2. STATE OF THE ART their needs. These systems use analytic technologies to generate personalized recommendations which are offered as a ranked list of items. In performing this ranking, recommender systems try to predict what the most suitable items are, based on the user s preferences and constraints. Whereas at the beginning the majority of research was limited to recommend movies and shops, since 2007 this research began to extend to other fields such as books, documents or music [Park 2012], being one of the most important catalysts the domain-independent property of collaborative filtering. This is not unexpected, as recommender systems have been traditionally applied to commercial usage because they can drive a significant increase in purchase volume and may further alter the mix of products users buy [Hosanagar 2012]. Consequently, the role played by these systems can be seen from two perspectives: service providers and users. Recommender System Functions for Service Providers When we think about service providers that use recommender systems we can refer to commercial platforms like Amazon i or Netflix ii focused on recommending their products to end users (e.g. books and movies among others respectively), or even to social platforms like Facebook iii or Twitter iv (which recommend mainly new social connections) that make money in a more indirect way because their aim is to achieve more and more users because they are based on advertising business models. However, we can also think about non-commercial platforms that include recommender systems in their processes to help their users. Regardless of the type of service provider, the reasons to integrate recommender systems in their environments can be described by at least one or more of the following functions [Ricci 2011] Increase the number of items sold. This is probably the most important function for commercial recommender systems. Because of it users discover additional items compared to those usually sold without any kind of recommendation technique. The same principle can be applied to non-commercial scenarios where there is no cost for the user when selecting an item. In general, we can say that from the service provider s point of view, the i ii iii iv

35 2.1. RECOMMENDER SYSTEMS 13 primary goal of introducing a recommender system is to increase the conversion rate, i.e., the number of users that accept the recommendation and consume an item, compared to the number of simple visitors that just browse through the information. Sell more diverse items. As I mentioned above, recommender systems can help to select items that might be hard to find without a precise recommendation among a huge number of items available. For instance, in a book recommender system like Amazon, it is useless to recommend only the best-sellers (as almost everyone knows them). The service provider needs to advertise users the entire catalogue, but the best way to do it without affording the risk of suggesting an inappropriate book for a user is using a recommender system to generate personalized recommendations to the right users. Increase the user satisfaction. By helping users to find the items they need in terms of relevancy or accuracy, a recommender systems can increase the usage and likelihood that a recommendation will be accepted. Furthermore, if the user experience is good due to a properly designed human-computer interaction, they will also enjoy using the system. Increase user fidelity. The longer the user interacts with the site, the more refined his/her user model becomes and therefore the more personalized the recommendations provided are. Consequently this can foster users to be loyal to the site. Increase the personalization. As a consequence of all the previous functions, the system understands better what the user wants or needs, increasing that way the level of personalization not only in the recommendations generated, but also in the way the site treat him/her. Recommender Systems Functions for Users From the end-user point of view, Herlocker et al. [Herlocker 2004] define a set of popular goals and tasks that a recommender system can assist in implementing. Annotation in context. Given an existing situation, select only those items that are suitable to the user s context. For instance, in a restaurant recommendation, consider the user s location as context information to recommend only restaurants that are at distance by walking.

36 14 CHAPTER 2. STATE OF THE ART Find good items. Provide to the user with a recommendation on a list of the best items, among all the available in the system, ranked according to his/her preferences. Find all good items. It consists of recommending all the items available in the system that are suitable or fit the user s needs. Recommend a sequence. It is based on recommending items in a sequential way, attending to the idea that they are suitable to be consumed in a specific order. For instance, if we think about a system focusing on recommending research papers given a topic, we can imagine a sequence of important papers that should be read in a certain order to make easier for the user to understand better the area under study. Recommend a bundle. It is similar to the previous function, but considering that the order is not relevant. For example, a tourist recommendation about points of interest in a city that should be visited. Recommend synergetic bundles. Items that in bundle have more utility for the user than recommended singularly. For example, fork, knife and spoon in a cutlery domain. Just browsing. Sometimes users visit sites when they do not have the necessity of purchasing because they find it pleasant, or just for curiosity. In this situation, the task of the recommender is to help the user to browse the items that are more likely to be consumed by the user or are side with his/her scope of interest. Credible recommendations. Users frequently do not automatically trust a recommender. It is typical that many of them look for recommendations that they know they like before starting to believe in the system (e.g. their favorite books in sites like Amazon). For that reason, users can change their profiles in order to test the recommender. An interesting task would be to let the users do it to test how the system behaves. In other cases, users will not trust the system due to a possible level of bias in the source of recommendations. Therefore, recommender systems have to offer trustworthiness by using suitable data to recommend. Improve profile. Recommender system should be able of gathering feedback from users after they have been recommended to improve their profiles. Otherwise, it can only provide to a target user with the same recommendation that would be delivered to an "average" user.

37 2.1. RECOMMENDER SYSTEMS 15 Express self. Some users may not care about the recommendations at all. Rather, what it is important to them is that they are allowed to express their opinions and feelings. A recommender system can leverage that to encourage users in self-expression by providing them with feedback methods so as to retrieve information that will improve the quality of future recommendations. Help others. Some users are happy to contribute with information (e.g. their evaluations of items) because they believe that the community and the recommender system itself benefit from their contribution. For example, in an e-learning platform, a teacher can help their colleagues by rating all the learning objects he/she uses to facilitate the community distinguishes between rich and poor pedagogical resources. Influence others. In recommender systems, there are users whose main goal is to explicitly influence others to purchase or consume a set of specific items. Trying to avoid this practice, or at least mitigate it, is an important task in any recommender system Data and Knowledge Sources Recommender systems are known for being complex information processing and filtering tools that take as input heterogeneous kinds of data in order to output recommendations. The data are primarily about the items to suggest and the user who will receive these recommendations. The sources of data can be very diverse attending to the scenario in which the recommender system is deployed or the area of knowledge related to it. In any case, a general simplified classification (illustrated in Figure 2.1) of data used in recommender systems refers to three kinds of objects that will be involved in the recommendation process: items, users and transactions. Items Items are the elements recommended to users. They can be characterized by their value or utility for the user, as well as their complexity and attributes or features. The value of an item may be positive if the item is useful for him/her, or negative if its appropriateness determines that it is a wrong decision for the user when selecting it. Apart from this, the value of an item can be related to the cost of acquiring it, which includes not only a real monetary cost eventually paid but also the cognitive cost of searching it or deciding if accepting or rejecting it.

38 16 CHAPTER 2. STATE OF THE ART Figure 2.1 : General relationships between items, users and transactions. Complexity refers to the data representation behind the item. For example, in an e-learning platform where teachers receive recommendations on educational materials, the recommender system must take into account aspects like the structure of the object, the time-dependent importance of the item or its representation (maybe textual or graphically based). But, at the same time, the recommender system designer must understand that even if the user is not paying for being recommended, there is always a cognitive cost associated to searching and selecting items. Apart from this, an item can be described by a set of attributes or features that will be closely related to its complexity. In a simple case, the item could be represented by a single id, or following the previous learning example, when recommending educational material the topic (e.g. biology), the target level (e.g. elementary school) or the language in which the material is available (e.g. English) could be the set of features used to represent it.

39 2.1. RECOMMENDER SYSTEMS 17 Users Users in a recommender system may have very diverse goals and characteristics based on the scenario of recommendation. Therefore a wide range of information about users can be exploited to increase the level of personalization in the recommendations provided. User data is said to constitute the user model [Fischer 2001], [Kobsa 2001]. The selection of what information is considered to build the model depends on the recommendation technique chosen, but as a general rule, the user model profiles the user, i.e. encodes his/her preferences, needs and behavior. Since no personalization is possible without a convenient user model, unless the recommendation is non-personalized (e.g. suggestions based on top items), the user model will always play a center role when designing a recommender system. Furthermore, taking into account the recent advances in social network analysis, a user model may include those relations between users so as to being able of utilizing that information to recommend items to users that were preferred by similar or trusted users, or even suggest similar people to the target user (e.g. a friend of a friend or someone with the same interests). Transactions A transaction can be defined as recorded information between a user and the recommender systems, where they may involve in addition an item or other users (Figure 2.1). This information is generated during the human-computer interaction and can be useful for the recommendation algorithm used. For instance, a transaction log may contain a reference to the item selected by the user and a description of the context (e.g. user location) in which that particular situation took place. In addition to this, it may also include an explicit feedback provided by the user about the item, allowing the system to be adaptive. A good example of feedback is the ratings given by the user for a selected item. Ratings are the most common and popular form of transaction. They may be collected explicitly (e.g. the user provides his/her opinion about an item) or implicitly (e.g. the recommender annotates if the user accepts or rejects the recommendation provided). According to the classification proposed by Schafer et al. [Schafer 2007], ratings can take on a variety of forms (the most common are presented in Figure 2.2):

40 18 CHAPTER 2. STATE OF THE ART Figure 2.2 : Examples of common used rating scales: unary (like), binary (thumbs up / thumbs down), scalar (five-star and slider). Unary ratings can indicate that a user has observed or purchased an item, or otherwise rated the item positively. The absence of rating indicates that we have no information relating the user to the item. A good example of this kind of rating has been popularized by Facebook through the "Like" button. Binary ratings indicate that the user choices between good or bad when evaluating an item. YouTube i uses this to allow users rating videos positively ("I like this") or negatively ("I dislike this") with a visual representation of a thumbs up / thumbs down icons. Scalar ratings can consist of either numerical ratings, such as the five-stars (Netfilx) or the slider (Origo ii ) methods, as well as ordinal ratings such as "strongly agree, agree, neutral, disagree, strongly disagree" (i.e. Likert scale [Likert 1932]) where users are asked to select the term that best indicates their opinion as regards an item. In more recent studies, Sparling and Sen [Sparling 2011] evaluate the cost and benefits in terms of cognitive load and decision time associated with different rating scales, showing that users prefer the five-star scale overall, though the best option may depend on the type of item rated as well as the target users. Another form of user transaction consists of tags associated by users with the items existing in the system. Marinho et al. [Marinho 2011] survey how the social tagging process carried out by users in a recommender system can improve the suggestions provided. For instance, in MovieLens iii recommender systems tags represent how their users feel about a movie (e.g. "too i ii iii

41 2.1. RECOMMENDER SYSTEMS 19 Table 2.1 : Summary of main recommendation techniques. Recommendation Technique Collaborative filtering Content-based Demographic Knowledge-based Community/Social-based Hybrid Description The user is recommended items that people with similar tastes and preferences liked in the past. The user is recommended items similar to the ones the user preferred in the past. The user is recommended items based on his/her demographic user profile attending to the ratings given by users in the same niche. The user is recommended items based on inferences about his/her needs and preferences. The user is recommended items based on his/her acquaintances preferences and shared interests. Combine two or more techniques to improve recommendations performance and deal with disadvantages suffered by using them standalone. long" or "boring") or inform about its topic or category (e.g. "thriller") Recommendation Techniques The core functionality of a recommender system consists of identifying the useful items for the user among the existing ones. Therefore, it must predict the utility of some of them to decide by comparison which one is worth recommending. This prediction is not a straightforward step, and so different methods and algorithms exist to calculate it. As a result, several types of recommender systems have been proposed since the first collaborative filtering based systems appeared. The main ones are described in the following lines attending to the taxonomy provided by Burke [Burke 2007] that has become a classical way of distinguish between recommender systems and referring to them.

42 20 CHAPTER 2. STATE OF THE ART Collaborative filtering In 1994 Resnick et at. [Resnick 1994] proposed the first ideas related to providing collaborative filtering (CF) of Netnews. The simplest and original implementation of this approach recommends to the active user items that other users with similar tastes liked in the past [Schafer 2007]. In other words, these systems evaluate or filter items considering the opinions and rates of other users that are similar to the active user. The similarity in tastes between two users is calculated based on the similarity in the rating history of them. For instance, if Bob liked the "Iron Man" and "The Avengers" movies, and Alice liked "Iron Man", a collaborative system should predict that the "The Avengers" is also suitable for her. However, this technique has their own limitations [Adomavicius 2005c]. As described below, mostly of them are related to the cold start problem, i.e. serious degradation of recommendation quality when only a small number of purchasing records or ratings are available [Ahn 2008], [Lam 2008]: New user problem. In a real scenario less simplified than the previous example, the system must first learn the user s preferences from the ratings that he/she makes before being able of recommending new items. Therefore if the user has not provided enough information about his/her tastes, the recommendations cannot be generated, or at least, they cannot be done with suitable accuracy. New item problem. New items are added regularly to recommender systems. CF rely solely on users preferences to generate recommendations. Thus, until new items are rated by a substantial number of users, the recommender would not be able to suggest them. Sparsity. In any recommender system, the number of ratings already obtained is usually very small compared to the number of ratings needed to predict items utility. Effective prediction of ratings from a small number of examples is important. But despite that, it is still primary for these systems to reach a critical mass of users in order to avoid recommending only a small set of highly rated items. For example, in the movie recommendation scenario there may be many movies that have been rated only by few people. These movies would be recommended very rarely, even if those few users gave high ratings to them. Besides, for

43 2.1. RECOMMENDER SYSTEMS 21 the user whose tastes are unusual compared to the rest of the population there will not be any other users who are particularly similar, leading to poor recommendations. Grey sheep. It refers to those users whose opinions do not consistently agree or disagree with any group of people and thus do not benefit from CF (sometimes called grey users). Similar to this, the Black sheep problem exists. It corresponds to users that are the opposite group, whose idiosyncratic tastes make recommendations nearly impossible. Although this is a failure of the recommender system, non-electronic recommenders also have great problems in these cases, and for that reason black sheep is an acceptable failure. Anyway, despite these problems CF is considered to be the most popular widely implemented technique in recommender systems and important applications can be found due to its use in platforms like Amazon [Linden 2003] or because of the leverage of initiatives such as the Netflix Prize i competition launched in October 2006 to improve prediction accuracy in CF algorithms. Moreover, new proposals to improve it are still appearing [Koren 2011]. Content-based These systems recommend similar items to a user based upon a description of the item and a profile of the user s interests [Pazzani 2007]. The similarity of items is calculated based on features associated with the compared items and the old ones that the user liked. For example, if Bob has positively rated the "Iron Man" movie that belongs to the "action" genre, then the system can learn to recommend other movies from the same genre. However, this technique has some important issues that have to be considered when using it [Shardanand 1995], [Balabanović 1997]: Limited content analysis. Content-based techniques are limited by the features that are explicitly associated with the objects recommended by the system. In order to have a sufficient set of features, the content must either be in a form that can be parsed automatically by computer (e.g. text), or the features should be assigned to items manually. This can be mitigated by new information retrieval techniques that may work well extracting features from text documents or some other domains like image processing, but i

44 22 CHAPTER 2. STATE OF THE ART the problem can be important if the items to analyze are audio or video streams. Another problem with limited content analysis is that, if two different items are represented by the same set of features, they are indistinguishable, i.e. a common problem in keyword-based systems. Over-specialization. As the system can only recommend items that score highly against a user s profile, he/she is limited to be recommended items similar to those already rated. Following the films example, if Bob has no experience with "comedy" movies, no matter that the best "comedy" movie is available in the system, it would be never recommended to him as it is not similar to his profile. New user problem. Like in the collaborative filtering case, the user has to rate a sufficient number of items before the content-based system can really understand the user s preferences and present the user with reliable recommendations. As a consequence, a new user with few ratings would not be able to get accurate recommendations. Demographic These systems recommend items based on the demographic profile of the user. They assume that different recommendations should be generated for different demographic niches or life styles [Pazzani 1999]. A good example is done in Web pages that redirect users to particular sites attending to their language, country or age, recommending that way products accordingly. But other demographic parameters less public can be considered as the gender, education level, etc. While these approaches have been quite popular in the marketing literature, there has been relatively little proper recommender system research into pure demographic systems, as this kind of information is usually utilized to improve other recommendation techniques, like the collaborative filtering [Vozalis 2006]. Knowledge-based Knowledge-based systems recommend items based on specific domain knowledge about how certain item features meet user s needs and preferences and, ultimately, how the item is useful for the user. Several approaches have been done in this area using case-based [Bridge 2005] or

45 2.1. RECOMMENDER SYSTEMS 23 constraint-based [Felfernig 2011] solutions. The first uses a similarity function to estimate how much the user needs (problem description) match the recommendations (solutions of the problem). The second exploits predefined knowledge bases that contain explicit rules about how to relate customer requirements with item features. These systems tend to work better than other recommenders at the beginning of the deployment due to the initial knowledge store, but they must learn how the user behaviors to be useful in the long-term. For that reason, Knowledge-based systems have fewer problems in this regard because they do not rely on having historical data about a user s preferences. Community-based Community-based recommender systems suggest items based on the preferences of the user s friends bearing in mind the epigram "Tell me who your friends are, and I will tell you who you are". Research has pointed out that people tend to rely more on recommendations from people they trust (friends) than on recommendations from similar but anonymous individuals [Sinha 2001]. This observation, combined with the growing popularity of open social networks is generating a rising interest in this kind of systems, also referred to social recommender systems [Victor 2011b], [Groh 2012] or trust-enhanced recommender systems [Victor 2011a]. For example, in a social network like Facebook it is common for a user to be recommended about contents or products that their acquaintances liked or have previously consumed. The recommendations generated this way are based on information coming from the user s (online) trust network, i.e. a social network which expresses how much the members of the community trust each other. Therefore, trust-enhanced recommender systems use the knowledge originated from these social networks to generate more personalized recommendations: users receive recommendations for items rated highly by people in their web of trust (WOT) or event by people who are trusted by the WOT members through friend-of-a-friend trust relationships. The research in the area of social-trust data sources is still in its early phase and results about the systems performance are mixed when comparing them for example with traditional collaborative filtering approaches [Groh 2007]. However, these systems have proved to be useful to avoid or at least mitigate cold-start situations when there is insufficient information about the user s preferences to compute similarity to other users. This dissertation will provide some

46 24 CHAPTER 2. STATE OF THE ART research and results that include valuable outcomes associated to use social-trust data in recommender systems. Hybrid Hybrid recommender systems are those that combine two or more of the techniques described above to improve recommendations performance, usually to deal with the cold-start problem. By doing this, they try to combine the advantages from several techniques at the same time they avoid or fix their disadvantages. Burke [Burke 2002], [Burke 2007] identifies seven different types: Weighted. The score of different recommendation components are combined numerically to produce a single prediction of similarity [Mobasher 2004]. Switching. The system uses several recommenders (usually ordered by its accuracy or personalization level) and chooses among recommendation components to apply the best one taking into account the situation [Billsus 2000]. Mixed. Recommendations from different recommenders (every of them working better in a different situation) are merged and presented together to the user [Smyth 2000]. Feature combination. Features derived from different knowledge sources are combined together and given to a single recommendation algorithm [Basu 1998]. Feature augmentation. One recommendation technique is used to compute a feature or set of features, which is then part of the input to the next technique that uses it as a general item model [Melville 2002]. Cascade. Recommenders are given strict priority, with the lower priority ones breaking ties in the scoring of the higher ones [Burke 2002]. Meta-level. One recommendation technique is applied and produces some sort of model (e.g. user or item model), which is then the input used by the next technique [Pazzani 1999]. A typical example of hybrid system combines collaborative filtering and content-based techniques. The first ones suffer from new item problem (i.e. they are not able to recommend

47 2.1. RECOMMENDER SYSTEMS 25 items unrated). But the second ones do not have that limitation, since the recommendation is based on item s features that are usually available since the item is created in the system. This way, by combining both techniques the final recommendation process is improved Data Mining Methods Recommender systems typically apply techniques and methodologies from the data mining domain to build their core algorithms. This field studies methods capable of extracting or mining knowledge from data in order to discover meaningful patterns and rules. As a result of that, it is also possible to use them for decision making as well as to calculate similarity patterns or predict the effect of decisions. For that reason most of recommender system researchers use data mining techniques to improve the performance and accuracy of their recommendations. Following the definition proposed by Amatriain et al. [Amatriain 2011], we understand data as a collection of objects and their attributes, where an attribute is defined as a property or characteristic of an object (e.g. users age). Other names for object include record, item, point, sample, observation or instance. Finally, an attribute might me also be referred to as a variable, field, characteristic or feature. Bearing in mind these concepts, the wide classification proposed by Park et al. [Park 2012] after their study of data mining methods usage in the recommender systems research area can be followed: Clustering Clustering [Hartigan 1975], also referred to as unsupervised learning, consists of assigning objects to groups so that the objects in the same group are more similar than those in different groups. Therefore, by using these techniques it is possible to discover natural (or meaningful) groups that exist in the data. When talking about objects in the recommender systems domain, they can be both items and user, as we can gather them into groups by similarity. Doing this, it is possible to recommend items/users to a target user keeping in mind what other similar users in the same cluster have done. Similarity is determined using distance measures, e.g. Euclidean, Cosine similarity or Pearson correlation [Amatriain 2011]. No matter the distance selected, the goal of a clustering algorithm is to minimize the intra-cluster distances among while maximizing the inter-cluster distances.

48 26 CHAPTER 2. STATE OF THE ART There are two main categories of clustering algorithms: Hierarchical. They start by taking the whole set of data points to successively cluster points within found clusters, producing a set of nested clusters organized as a hierarchical tree (until a certain similarity threshold is achieved). Partitional. They divide data points into non-overlapping clusters such that each data point is in exactly one cluster. Overall clustering algorithms try to minimize a function that measures the quality of the clusters achieved. An ideal clustering algorithm would consider all possible partitions of the data to provide the one that provides the best quality function. However, in many cases this is a NP hard problem, so many algorithms resort to heuristics, like the k-means [Kanungo 2002] partitioning method. Among all clustering methods, it is of the most popular. It takes the input parameter k, and partitions a set of n objects into k clusters. Therefore, the main point is that clustering is a difficult problem for which finding optimal solution is often not possible. For this reason, the selection of the particular clustering algorithm and its parameters (e.g. similarity measure) depend on many factors, including the requirements of the recommender system scenario and the characteristic of its data. In this dissertation, clustering techniques have been used intensively and thus, more details will be explained in the next chapters. k-nearest neighbor The Nearest neighbor classifier (knn) [Cover 1967] finds the k closest points (i.e. nearest neighbors) for a given point from the training records and then it assigns the class label according to the class labels of its nearest neighbors. The underlying idea is that if a record falls in a particular neighborhood where a class label is predominant, it is because the record is likely to belong to that very same class. Although the basic idea has similarities with the clustering methods, knn makes recommendations according to the following three phases: 1. The recommender system constructs a user profile based on the users preference ratings, which are obtained either directly from explicit ratings of items or indirectly from purchases or usage information.

49 2.1. RECOMMENDER SYSTEMS The recommender system applies statistical or machine learning techniques to discover the k users, known as neighbors, who in the past have shown similar behaviors. A neighborhood is formed based on the degree of similarity between the target user and the others. 3. Once the neighborhood of the target user is formed, the recommender system makes a top-n item set that he/she is most likely to purchase by analyzing the items in which neighbors have exhibited interest in the past. Perhaps its most challenging issue is how to choose the value of k. If it is too small, the classifier will be sensitive to noise points. But if it is too large, the neighborhood might include too many points from other classes (i.e. the similarity degree is low). Despite this, knn is one of the most common approaches to collaborative filtering and therefore to designing a recommender system, as it is very related to the idea of finding like-minded users (or similar items) that is essentially equivalent to finding neighbors for a given user or item. Because of that a remarkable number of research work can be found about this technique [Desrosiers 2011]. Association rule Association rule mining focuses on finding rules that will predict the occurrence of an item based on the occurrences of other items in the transactions. This is done by discovering all the association rules that are above user-specified minimum support and minimum confidence levels. Thus, given a set of transactions in which each transaction contains a set of items, an association rule is an expression of the form X = Y, where X and Y are item sets [Lin 2002]. The support of an association rule is the fraction of transactions that have both X and Y. While the confidence of a rule is how often the items in Y appear in transactions that contain X. For example, in a supermarket scenario an association rule could be (milk, eggs = bread) with 50% support and 70% confidence. This means that half of the purchases (transactions) in the supermarket clients buy the three products and seven times per every ten purchases, when a client buys milk and eggs, he/she also buys bread. Using these rules, a recommendation system may decide to suggest some products attending for example to what products the user is adding to the cart.

50 28 CHAPTER 2. STATE OF THE ART Decision tree Most popular classification methods are decision trees [Quinlan 1986], [Safavian 1991]. These techniques are classifiers on a target attribute in the form of a tree structure. The nodes of the tree can be: Decision nodes. In these nodes a single attribute/value is tested to determine to which brand of the sub-tree applies. Leaf nodes. They indicate the value of a target attribute. As a result of this structure, using classifiers based on decision trees are inexpensive to construct and it is extremely fast for classifying unknown instances. This also implies an important advantage: they can be used to produce rules that are easy to interpret and maintain. However, it is very difficult and unpractical to build a decision tree that tries to explain or cover all the variables involved in a decision making process in complex scenarios. For that reason, they are usually utilized to model particular part of the system [Nikovski 2006]. Link analysis Link analysis discovers relations between domains in large databases. For instance, social network analysis is a sociological approach for analyzing patterns relationships and interactions between social actors in order to find a fundamental structure [Wasserman 1994]. Besides, link analysis has presented great potential in improving accuracy of web searches and for that reason, it has been used in algorithms like the PageRank [Page 1999]. Neural network An Artificial Neural Network (ANN) [Zurada 1992] is an assembly of interconnected nodes and weighted links that is inspired in the architecture of the biological brain. Nodes in an ANN are called neurons as an analogy to the biological neurons. In fact, an ANN is a parallel distributed information processing system that is able to learn and self-organize. By combining neurons, the networks achieved can be used for different applications such as predictions, non-linear regressions or classifications after they are trained with sufficient data [Ibnkahla 2000].

51 2.1. RECOMMENDER SYSTEMS 29 Regression Although regressions are not intensively used in recommender systems, they are powerful processes for analyzing associative relationships between dependent variables and one or more independent variables. It has been used for curve fitting, prediction and testing systematic hypotheses about relations between variables. Other heuristic methods Additional ad-hoc heuristic methods have been developed for recommender systems research by adding new features to existing techniques or by combining some of them. Heuristic methods also include mixture models and ontology methods Recommender Systems and Human Computer Interaction As we have seen in previous sections, researchers have deeply investigate the design of a broad range of technical solutions to achieve better predictions about what items a target user may like more among the available ones. These results could make us think that the recommendations provided in a system should speak for themselves, being the logical consequence that the user will accept them if they are correct. Nevertheless, this is clearly an overlay simplified account of the recommendation problem as other important factors are involved in the acceptance process that a user carries out when deciding to accept or not a recommendation. In practice, users need recommendations because they do not have enough knowledge to make an autonomous decision. Consequently, it may not be easy for them to evaluate the proposed recommendation and as a result these additional factors appear. Swearingen and Sinha [Swearingen 2001] were among the first to point out that the effectiveness of a recommender system depends on factors that go beyond the quality of the prediction algorithm, as the system must also convince users to try the recommended items. This will also depend on the particular Human Computer Interaction (HCI) supported by the system when the items are presented, compared and explained. From a user perspective, they found that an effective recommender system must inspire trust in the system; it must have a system logic that is at least somewhat transparent and understandable for the user; it should point users towards new, not-yet-experienced items; it should provide details

52 30 CHAPTER 2. STATE OF THE ART about recommended items (e.g. pictures, community ratings, etc.); and finally, it should present ways to refine recommendations. Hence, although these results do not diminish the importance of the recommendation algorithm, they claim that its effectiveness should not be evaluated only in terms of prediction accuracy, but also in terms of other dimensions that measure the user acceptance of the whole recommender system and its recommendations. Thus, in the next subsections the most important factors to be considered when designing recommender systems in terms of HCI are summarized. Trust and Explanations There are two different notions of trust: trust about the other users of the recommender and trust about the system s recommendations. The first is associated to the previous mentioned social recommender systems which attempt to generate more useful recommendations derived from information about user profiles and relationships between users [Victor 2011a]. They can be extracted from social networks (e.g. Facebook or Twitter) or trusted sources (e.g. public administrations or banking entities) among others. The second one (i.e. trust in system s recommendations) is actually related to the role of explanations in recommender systems. They can provide transparency and exposing the reasoning and data behind a recommendation helping the user to accept and understand the recommendation process, which increases the trust in the recommendations. This is the case with some of the explanations used by Amazon such as "Customers who bought this item also bought..."; but other more complex examples exits like "Item X was recommended because of features A and B are shared by items Y and Z, which you rated highly". Following to the study provided by Tintarev and Masthoff [Tintarev 2011], explanations can be classified into seven criteria: Transparency: Explain how the system works. An explanation may clarify how a recommendation was chosen, or at least, the recommender system may make clear for the user to understand how it works. In some scenarios, it also affects other criteria such as trust, persuasion and satisfaction [Cramer 2008]. Scrutability: Allow the user to tell the system it is wrong. Explanations may help isolate and correct misguided assumptions or steps. Thus, following transparency, a second step is

53 2.1. RECOMMENDER SYSTEMS 31 to allow a user to correct reasoning, or make the system scrutable [Czarkowski 2006]. This can be done understanding explanations as a part of a cycle, where the user understands what is going on in the system and exerts control over the type of recommendations made, by correcting systems assumptions when needed. Trust: Increase users confidence in the system. Explanations cannot fully compensate poor recommendations, but good explanations may help users make better decisions. Besides, a user may also appreciate when a system is "frank" and admits that it is not confident about a particular recommendation. For example, Amazon has shown results [Swearing 2002] that lead to consider that by increasing the level of trust, the sales are increased too. Persuasiveness: Convince users to try or buy an item. Some studies have demonstrated that users can be manipulated to give a rating closer to the system s prediction [Cosley 2003] or try/buy specifics items due to a persuasive explanation. However, it is also important to consider that too much persuasion may backfire once users realize that they have tried or bought items that they do not really want. Effectiveness: Help users make good decisions. Rather than simply persuading users to try or buy an item, an explanation may also assist users to make better decisions. Effectiveness is by definition highly dependent on the accuracy of the recommendation algorithm, but an effective explanation would help the user to evaluate the quality of the suggested items according to their own profile or preferences. This would increase the likelihood that the user discards irrelevant options while helping the system to recognize useful ones. For example, effectiveness can be measured by comparing the rating given by users to an item after receiving its explanation with the rating given after consuming it. If their opinion do not change much, the system can be considered effective [Bilgic 2005]. Efficiency: Help users make decisions faster. Given a set or list of items recommended, explanations may make it faster for users to decide which one is the best for them. Efficiency is a established usability principle, i.e. how quickly a task can be performed [Nielsen 1990]. This criterion is one of the most commonly addressed in the recommender systems literature given that the main task of recommender systems is to find needles in haystacks of information.

54 32 CHAPTER 2. STATE OF THE ART Satisfaction: Make the use of the system enjoyable. Explanations have been found to increase user satisfaction with, or acceptance of, the overall recommender systems [Felfernig 2006]. The presence of longer descriptions of individual items has been found to be positively correlated with both the perceived usefulness [Tintarev 2008], and ease of use of the recommender system [Sinha 2002]. Conversational Systems: Learning from the User Many algorithmic approaches in recommender systems present an important limitation due to the fact that they have been designed to collect all the input data only once (usually at the beginning) to generate recommendations. Sometimes this model is not effective since users may not be fully aware of their preferences until they have interacted to a certain extent with the system and roughly understand the range of alternatives. In other cases users may need a first experience with the system and the alternative items provided in order to decide which one to choose. Or there is also the possibility that the system may be initially wrong in its suggestions and the user may be willing to provide additional information that can fix these problems, causing eventually better recommendations. This line of research is commonly known as conversational recommender systems. The techniques used by these systems are diverse, but all of them try to support an interactive process where both the user and the system may query or provide additional information to the other. However, the critical issue here is how to design that dialogue (e.g. the conversational strategy or the possible stages during the interaction). Two ways of achieving it have been proposed in the literature: Critiquing-based systems. They present to the users recommended items given an initial set of user preferences and then support users in formulating "critiques" such as "Show me more like item A, but cheaper" [McGinty 2011]. Good examples can be found in the travel applications domain [Ricci 2004] as well in other like the group recommendations [McCarthy 2006]. Preference-based systems. They are similar to the previous one, but in this case they let the users to express preferences about some of the items recommended so as to refine the system representation of the user s preferences (i.e. user model) enabling the system to

55 2.2. CONTEXT-AWARE RECOMMENDER SYSTEMS 33 generate new and better recommendations [Mcginty 2006]. User Experience and Visualization In addition to the HCI issues pointed out above, the way the recommendations are communicated and visually presented to users has a big impact in their acceptance and User Experience (UX). Presentation and explanations techniques are not easily separable: a good presentation technique is also capable of explaining recommendations but also in motivating the user to make further requests. The User Interface (UI) design as a key part of the visualization is also a critical point when creating and designing a recommender system. As Miller said [Miller 2005]: "design can play a critical and even primary role in determining which products stand out". Hence having a good UI that enhances the UX is an important factor to avoid losing users after the first contact with the recommender system because a continued experience with the system is needed to learn the user tastes and increase the personalization level. One common aspect in the recommender systems UI design is the fact that recommendations are presented as a list of items. The length of this list can vary but the output of the core recommendation algorithm is normally a ranked list. However, new approaches are being proposed to replace this traditional list representation by new map visualizations [Kagie 2011]. Finally, all this aspects can completely change if we think about mobile recommender systems in which not only the visualization change, but also the UX is radically different compare to desktop applications as new issues related to ubiquitous systems and different user control paradigms appear. 2.2 Context-Aware Recommender Systems As we have seen in previous sections, the majority of existing recommender systems focus on recommending the most relevant items to individual users without taking into consideration contextual information such as time, location or user activity. Although context is considered in the item-user-transaction model (Fig. 2.1), traditionally recommender systems do not put those inputs into context when providing recommendations. However, context can be a powerful dimension to incorporate in the recommendation process in order to suggest items to users under certain circumstances or bearing in mind their current

56 34 CHAPTER 2. STATE OF THE ART situation. For example, using the temporal and location context in a tourist mobile recommender system scenario, users could be recommended with the most suitable points of interest of certain city, such as a Jazz show at night next to the hotel when the day visit has finished. If we think about doing this without contextual information, it seems difficult (or impossible). The recommender system might suggest Jazz shows, but as it is not aware of the users location, there is no way of giving priority to that show closest to the user s hotel compared with others available in the city. Bearing in mind that this dissertation presents contributions in the field of Context-Aware Recommender Systems (CARS) [Baldauf 2007], [Verbert 2010], [Adomavicius 2011]; in this section I will go into detail of this area in order to show that depending on the application domain and the available data, at least certain contextual information can be useful for providing better recommendations [Abowd 1999] Defining Context Context is a multifaceted concept that has been studied across different research disciplines, including computer science (e.g. artificial intelligence and ubiquitous computing), cognitive science or psychology. Each discipline tends to take its own perspective and definition of context that is more specific than the standard generic dictionary definition that defines it in a general way as "the conditions in which something exists or occurs" [Merriam-Webster 2009]. As a consequence of that heterogeneity, Bazire and Brézillon [Bazire 2005] present and examine 150 different definitions of context from different fields in which they observe that: "[... ] it is difficult to find a relevant definition satisfying in any discipline. Is context a frame for a given object? Is it the set of elements that have any influence on the object? Is it possible to define context a priori or just state the effects a posteriori? Is it something static or dynamic? [... ] In Psychology, we generally study a person doing a task in a given situation. Which context is relevant for our study? The context of the person? The context of the task? The context of the interaction? The context of the situation? When does a context begin and where does it stop? What are the real relationships between context and cognition?" And finally they stated that "The context acts like a set of constraints that influence the behavior of a system (a user or a computer) embedded in a given task". Nevertheless this definition is still rather broad. Since we focus on recommender systems, we are going to review the different definitions used

57 2.2. CONTEXT-AWARE RECOMMENDER SYSTEMS 35 in those fields related to the recommender systems research attending to the classification provided by Adomavicius and Tuzhilin [Adomavicius 2011]: E-commerce personalization. Palmisano et al. [Palmisano 2008] define context as the intent of purchase made by a customer in an e-commerce application. Different purchasing intents may lead to different types of behavior. For example the same customer may buy the same product for different reasons (e.g. a book for him or a book as a gift for a friend). Such contextual segmentation of customers is useful, because it results in better predictive models across different e-commerce applications. The benefits of including contextual information has been also demonstrated by Adomavicius et al. [Adomavicius 2005a]. They presented a multidimensional approach in which context is considered in combination with typical information on users and items, concluding that it helps to increase the quality of recommendations. Finally Oku et al. [Oku 2006] empirically showed that the context-aware approach significantly outperforms the corresponding non-contextual approach in terms of recommendations accuracy and user s satisfaction. Ubiquitous and mobile context-aware systems. Context is a very important factor in the area of mobile computing [Chen 2000]. It was initially defined as the user s location, the identity of people near the user, the objects around and the changes in these elements [Schilit 1994]. Other authors consider additional factors like the data, season and temperature [Brown 1997]. Dey et al. [Dey 2001b] include the user s emotional status to characterize the interaction between the user and the application. This idea is important, as some authors have defined context from the point of view of the users [Dey 2001b], while others have emphasized how context relates to the application [Rodden 1998]. Of course, hybrid techniques that combines both user and application features to define context have also appeared [Woerndl 2007]. Information Retrieval. Contextual information has been proven to be helpful in information retrieval and access [Jones 2005a], although most existing systems base their retrieval decisions solely on queries and document collections. Web searching is a good example of using context in information retrieval by considering topics potentially related to the search term [Lawrence 2000]. But this approach is not focused on long-term user tastes and preferences as the context only affects to specific queries (e.g. "find all

58 36 CHAPTER 2. STATE OF THE ART documents created during the June meeting in Barcelona"). Data mining. Context is sometimes defined as those events which characterize the life stages of a customer and that can determine a change in his/her preferences or status [Berry 1997] (e.g. job or marriage). Databases. In this area, context is understood as the information added to a database management system to incorporate user preferences in order to return different answers to database queries depending on the context in which the queries have been expressed and the particular user preferences corresponding to specific context. For example, Stephandidis et al. [Stefanidis 2008] present a context-aware extension of SQL to accommodate that contextual information and user preferences in the queries. Marketing and Management. In marketing research, the context associated to the situation in which a transaction takes place is considered crucial as it influences the customer when adopting a specific decision strategy to select one product/brand or another [Lilien 1992]. Thus, context has been defined as a task complexity in the brand choice strategy [Lussier 1979]. But in more recent definitions Prahalad [Prahalad 2004] distinguishes among three dimensions of contextual information in this domain: temporal (i.e. when to deliver customer experience), spatial (i.e. where to deliver) and technological (i.e. how to deliver). As we have seen, context can be understood from different points of view depending on the discipline. General definitions more useful to the area of recommender systems can be found, as the one proposed by Dey [Dey 2001a] in which: "Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves". This leads to the following definition of context-aware also proposed by Dey [Dey 2001a]: "A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user s task." However, to bring some order to this diversity of views, Dourish [Dourish 2004] introduces the following taxonomy of contexts:

59 2.2. CONTEXT-AWARE RECOMMENDER SYSTEMS 37 Representational view. Context is defined as a predefined set of observable attributes and its structure does not change significantly over time (i.e. it is stable). Because it is a form of information, context attributes are identifiable and know a priori and, hence, can be captured and used within the context-aware application. Thus context and activity are separable. Activity happens "within" a context. The context describes features of the environment within which the activity takes place, but which are separate from the activity itself. Interactional view. Context is a relational property that holds between objects or activities. It is not simply the case that something is or is not context. Rather, it may or may not be contextually relevant to some particular activity. Therefore, rather than considering that context can be defined in advance, this alternative view argues that the scope of contextual features is defined dynamically and for that reason it is particular to each situation of activity (i.e. it is not stable). As a result, it assumes that the user behavior is induced by an underlying context, but the context itself is not necessary observable. So, the conclusion can be that context influences activities and also different activities giving rise to different contexts Modeling Contextual Information in Recommender Systems In previous sections we have seen that the recommendation process typically start with the specifications of the initial set of ratings that is either explicitly provided by the users or implicitly inferred by the system. Once these ratings are specified, a recommender system tries to estimate the rating function R for the candidate items: R : User Item Rating (2.1) where the (user, item) pairs have not been rated yet by the users. Rating is a totally ordered set (e.g. non-negative integers or real numbers within a certain range), and User and Item are the domains of users and items respectively. When the function R is estimated for the whole User Item space, a recommender system can suggest the highest-rated items (or k highest-rated items) for each user. These recommender systems are known as traditional or two-dimensional (2D) since they consider only the User and Item dimensions in the recommendation process. In other words, in its most common formulation, the recommendation problem is reduced to the

60 38 CHAPTER 2. STATE OF THE ART Location Time Geo-position Weekday Weekend Holiday Country City Figure 2.3 : Contextual information hierarchical structure for Location context. problem of estimating ratings for the items that have not been seen by a user. On the other hand, CARS incorporate contextual information into the recommendation process to improve the prediction of user tastes. Consequently, the CARS rating model considers now not only User and Item dimensions, but also Context: R : User Item Context Rating (2.2) where Context specifies the contextual information associated with the application. If we adopt the representational view seen above, Context can be modeled as a predefined set of contextual parameters related to a given application with each of them having a well-defined structure. Following Palmisano et al. [Palmisano 2008] and Adomavicius et al. [Adomavicius 2005a], the contextual information can be defined by a set of contextual dimensions, each of them following a hierarchical structure depending on the level of granularity related to the contextual dimension under study. For example, the Figure 2.3 illustrates a straightforward example of the structure related to the location context dimension that can be understand as the combination of time and geo-position information, being as well every of them compose by several attributes representing the information that could be extracted in a specific contextual situation. Therefore attending to (2.2), if we think about a recommender system in which the contextual information is only represented by the Time, we can define a rating function R in the recommendation space R(u,i,t) : User Item Time Rating specifying how much the user

61 2.2. CONTEXT-AWARE RECOMMENDER SYSTEMS 39 Figure 2.4 : Multidimensional model for the User Item Time recommendation space [Adomavicius 2005a]. u User liked item i Item at time t Time. Following the example proposed by Adomavicius et al. [Adomavicius 2005a], we can visually represent the recommendation space using a cube representation (Figure 2.4) that stores ratings R(u,i,t) for the recommendation space where the three tables define the sets of users, items and times associated with the User, Item and Time dimensions respectively (as User and Item could be considered also dimensions in the Cartesian product resulted). In that example, the rating R(101,7,1) means that for the user with Id 101 and the item with Id 7, rating 6 was specified during the weekday (i.e. time with Id 1). Of course, this multidimensional approach for modeling context is only a way of doing it as the specific model will depend on every recommender system scenario where the relevant or useful contextual information has to be identified.

62 40 CHAPTER 2. STATE OF THE ART Obtaining Contextual Information The way the contextual information is obtained will mainly depend on the recommender system design, but several methods have been identified [Adomavicius 2011]: Explicitly. It consists of directly approaching relevant people and other sources of contextual information to gather the data either by asking direct questions or eliciting this information through other means. For example, a restaurant recommender system can ask the user for an address or specific zone in order to suggest only those restaurants closer to it. Implicitly. It consists of extracting the contextual data from the recommender environment making it transparent to the user. Following the last example, in a mobile restaurant recommender system, the application could use the device GPS capabilities to detect the current location of the user in terms of geographical position. Inferring. It is based on using statistical or data mining methods. For instance, the household identity of a person flipping the TV channels (e.g. husband, wife, son, daughter, etc.) may not be explicitly know to a TV cable company, but it can be inferred with reasonable accuracy by observing the TV programs watched. To do so, it is necessary to design a predictive model (i.e. classifier) and train the system with appropriate seed data. The representational view of Dourish implies that the decision of which contextual information should be relevant and collected for an application have to be defined in advance in the recommender system design stage, letting the retrieval process to the time when actual recommendations are provided. As a consequence, when the recommendation process is started, the system has to retrieve the contextual data values related to the current situation and apply them in conjunction with the user and item information so as to generate the final recommendation Paradigms for Incorporating Context in Recommender Systems In Section we have seen that traditional recommender system are based on input data represented by records of the form < user,item,rating >. This is graphically illustrated in Figure 2.5. It shows that that the general data input composed by information about users, items and

63 2.2. CONTEXT-AWARE RECOMMENDER SYSTEMS 41 Figure 2.5 : General components of traditional recommender systems. Figure 2.6 : Paradigms for incorporating context in recommender systems. ratings is processed in a 2D Recommender to predict ratings on items attending to a target user for which the recommendations are generated. However as we have seen in this section, the introduction of context as a new input data in the recommendation process may improve the level of personalization for the recommendations provided. Three different algorithmic paradigms for incorporating contextual information into recommender systems can be followed [Adomavicius 2011]. Figure 2.6 summarizes them.

64 42 CHAPTER 2. STATE OF THE ART Contextual Pre-Filtering This paradigm is based on contextualize the recommendation input by using the contextual information available to select the most relevant data in that specific context. After that, any traditional 2D recommender can be used to generate the final recommendation for a target user. In other words, this approach can be essentially seen as a query for selection or filtering those candidate items in which their ratings fit the contextual conditions. An example of a contextual pre-filtering recommendation for a restaurant recommendation would be: if a person wants a restaurant to have dinner in Madrid, only the restaurants rated by night in Madrid are used in the recommendation process. One major advantage of this approach is that it can be deployed in any traditional recommender system, because the pre-filtering process does not alter the input data needed for those techniques. Contextual Post-Filtering In this recommendation paradigm contextual information is initially ignored, and the ratings are predicted using any traditional 2D recommender system on the entire data. Then the resulting set of recommendations is contextualized for the target user by applying the contextual information available. Thus, in this case the list of N items initially recommended by the 2D recommender are the ones which are filtered attending to the contextual information in order to increase the level or personalization. This list adjustment can be made in two ways: Filtering out recommendations that are irrelevant in a given context. For instance, in the previous restaurant recommender example the list of items provided by the 2D recommender may contain restaurants from other cities and therefore, the filtering process would remove them from the final list suggested to the user. Ranking the recommendations of the list based on a given context. Following with the same example, this time the recommender should reorder the items to show first those that fit the contextual conditions (i.e. have dinner in Madrid). On the other hand, it is important to remark that, as many recommendation methods, both ways of performing the contextual post-filtering approach can be classified into two techniques:

65 2.2. CONTEXT-AWARE RECOMMENDER SYSTEMS 43 Heuristic post-filtering approaches, that focus on finding common item characteristics (features or attributes) for a given user in a given context and then use them to adjust the recommendations. In the filtering case, this is done by selecting only items that have a significant number of these characteristics. While in the ranking case, the recommended items are based on how many of these relevant characteristics they have. Model-based post-filtering approaches, that can build predictive models to calculate the probability with which the user chooses a certain type of item in a given context, i.e. probability of relevance, and then use it to adjust the recommendations. In the filtering case, the system filters out items that have the probability of relevance smaller than a predefined minimal threshold. While in the ranking case, the items are recommended by weighing the predicted rating with the probability of relevance. Contextual Modeling The last paradigm is based on a contextual modeling approach. It uses contextual information directly in the recommendation function as an explicit predictor of a user s rating for an item. This gives rise to truly multidimensional recommendation functions, which essentially represent predictive models (e.g. based on decision trees, regressions or probabilistic models) or heuristic calculations that incorporate context in addition to user and item data, i.e. Rating = R(User, Item,Context). A significant number of contextual modeling recommendation algorithms can be found in the literature. For instance, Adomavicius and Tuzhilin [Adomavicius 2005b] extend a traditional two-dimensional (e.g. User and Item) neighborhood-based approach by incorporating Time as a new dimension. Another good example, this time proposed by Ansari et al. [Ansari 2000], combines different information (contextual and non-contextual) about customers (users) and items into a single hierarchical regression-based Bayesian preference model that outperforms traditional collaborative filtering algorithms. Combination of Multiple Approaches Finally, by combining multiple approaches significance performance improvements can be achieved over the individual ones. The result can ensemble different paradigms or can merge

66 44 CHAPTER 2. STATE OF THE ART several models of the same type, like the combination of several contextual pre-filters described in [Adomavicius 2005a]. 2.3 Mobile Recommender Systems The International Telecommunication Union (ITU), i.e. the United Nations specialized agency for information and communication technologies (ICTs), reported in February 2013 that the global mobile penetration rate is forecast to reach 96% at the end of 2013, including 128% in the developed world and 89% in developing countries, according to their last report [Union 2013]. Even though nowadays feature phones (i.e. non-smartphones) outsell smartphones, tablets, PCs and portable PCs (i.e. laptops), in the future that is expected to change in the world. According to Gartner [Gartner 2013b] and Canalys [Canalys 2013] until 2012 feature phones still outsell smartphones. However, both analysts predict that marginally more smartphones will be sold in 2013 than feature phones, being 2016 the year in which smartphones will outsell feature phones by a considerable margin [Canalys 2013]. On the other hand, tablets which are considered as a replacement for the desktop or portable PC, could outsell them in 2014 [Canalys 2013]. As a result of this evolution to an all-mobile lifestyle based on the great market penetration of smartphones and tablets, the appearance of mobile recommender systems is a logic consequence. Mobile devices have become a primary platform for information access and when coupled with recommender system technologies, they become key tools for mobile users, both for leisure and business applications [Ricci 2010b]. Recommendation techniques can increase the usability of mobile systems providing personalized and more focused content, hence limiting the negative effects of information overload that can be even worst in the smaller mobile screens. But recommendation approaches, which proved to be successful for PC users, cannot be straightforwardly applied for mobile users. On the one hand, mobile recommender systems have to overcome the obstacles typically present in mobile usage environments: the limitations of mobile devices, the limitations of wireless networks, the impacts from the external environment, and the behavioral characteristics of mobile users. On the other hand, mobile recommender systems can exploit two peculiar characteristics of mobile information services: Location-awareness. The knowledge of the user s physical position at a particular time can be exploited as an important source of contextual information to adapt the information

67 2.3. MOBILE RECOMMENDER SYSTEMS 45 delivered by the system. The location can be retrieved using various positioning techniques. If the user s device is GPS-capable, the geo-location will be more accurate. If not, a less accurate but usually valid location can be obtained using network-based positioning technologies from the WiFi or mobile communication antennas (e.g. GPRS, UMTS or LTE) as well as Geo IP capabilities. Additionally, new sensors are being included in mobile devices such as compass, accelerometer or gyroscope, so new ways of locating the user are arisen every day. Ubiquity. The ability to deliver the information and services to mobile users wherever they are, and whenever they need. This property is related to mobility of mobile users as they can access a mobile application in different locations. This is so because the devices are portable (e.g. smartphones or tablets) and usually all of them have wireless connectivity, allowing the recommender system to connect to different sources of information Mobile Context-Aware Recommendation Systems As a result of the capabilities previously mentioned, the application of context-dependent recommendation techniques has been extensively researched in the area of mobile recommender systems as several contextual dimensions can be obtained from the usage of mobile devices (e.g. location or user activity). Ahn et al. [Ahn 2006] present an approach to mobile context-dependent recommendations that extends the classical collaborative ltering (CF) method by using information about the user and item location, the time of the recommendation and the type of the user needs. The idea of using the location of the user to tune the user-to-user similarity function has also been exploited by Horozov et al. [Horozov 2006] in their restaurant recommender system, where they assume that people who live in the same neighborhood are likely to visit the same nearby places. Hence, since people can be correlated in CF only if they have co-rated items, they infer that there is a higher probability of correlating people who live close to each other than correlating people who live further apart. In the tourism domain, we can find a good example in COMPASS (COntext-aware Mobile Personal ASSistant) [Setten 2004]. This mobile CARS adapts its services to the user s needs based on both the user s interests and his/her current context. For example, a tourist expressing an

68 46 CHAPTER 2. STATE OF THE ART interest in history and architecture is presented with information about nearby monuments built in the past centuries. The user can browse a map indicating his/her current location and a selection of nearby buildings and other relevant objects for his/her user profile. The map and the objects shown are updated when the user moves (context changes) or when his/her profile or goal varies. Additional work has been recently proposed by Gavalas et al. [Gavalas 2013] in which they review the state-of-the-art in the field, proposing a classication of mobile tourism recommender systems, providing insights on their offered services and also pointing out challenges and promising research directions with respect to mobile recommender systems employed in tourism. Other fields are also using mobile recommender systems to enhance commercial applications. For instance, Yang et al. [Yang 2008] propose a location-aware recommender system for mobile shopping which accommodates the customer s shopping needs with location-dependent vendor offers and promotions. The proposed system recommends vendors webpages that are in their neighborhood to interested customers by analyzing the customer s history and position. Thus, vendor information can be ranked according to the match with the preferences of the customer and various characteristics of mobile shopping environments Challenges Ricci also remarked the importance of UI and UX design in his mobile recommender system survey [Ricci 2010b]. He pointed out several issues that must be considered when designing a recommender system for mobile users: Small screen devices. Figure 2.7 illustrates the relative number of Android devices that have a particular screen configuration, defined by a combination of screen size and density. As we can see, most of them have a normal screen (i.e. screens that are at least 470dp x 320dp and 4 inches size in average [Android-Developer 2013b]), and a high (hdpi) or extra high (xhdpi) densitiy per inch. However, although smartphones are incorporating bigger screens and higher resolutions every day, they still cannot be compared to PCs (which are quite bigger) when performing a recommendation session. It is known that users can actually read and understand information offered by small interfaces, but the size of the display can impact on users performance [Jones 2005b]. For example, on a small screen the user may be forced to carry out extensive scrolling while browsing a list of recommended items in a

69 2.3. MOBILE RECOMMENDER SYSTEMS 47 Figure 2.7 : Screen sizes and densities in Android devices [Android-Developer 2013a]. web page or using a mobile application. The more a user has to scroll down, the smaller the chances of an item being clicked. In addition, a user on a small screen is less effective in completing an assigned task when compared to users of large screens. Novel input and interaction capabilities. Despite the fact that Ricci identified this as a "limitation" in his 2010 survey [Ricci 2010b], the technology has evolved very fast since then and the old mobile device keyboard limitations have disappeared. They have being replaced by enhanced ways of interacting like touch-screens, user gestures or voice commands. But new challenges appear related to take advantage of these interaction capabilities in mobile CARS to improve the user experience (e.g. natural language for voice commands). Limited time sessions. Whereas PC users can surf the Web for hours, mobile phone users have much shorter browsing sessions due to be less comfortable experience. Moreover, the speed of Internet connections have increased very quickly in the last years. These same

70 48 CHAPTER 2. STATE OF THE ART connections could be used by Wi-Fi capable devices, but when users are really moving outside their home or office, they need a fast mobile data connection to be on-line. These connections have become reasonably priced in most telecommunication companies, but bandwidth it is still considered a limitation in mobile devices and therefore, the recommender applications built for them have to be aware of it (i.e. it can be considered an additional contextual parameter). Limited computation resources. Despite new mobile devices have every day more powerful hardware, some limitations still appear when they are compared with PCs. Aspects like the CPU power can limit the choice of a specific recommendation technique, at the same time battery consumption associated to, for example, localize the user continuously must be taken into account when designing mobile CARS. Several solutions have been proposed to take advantage of novel smartphones capabilities at the same time the issues mentioned are overcome or mitigated in mobile recommender systems. Traditional recommendations are typically displayed as a ranked list of information items. The format is very similar to that used by search engines to display the retrieved hyperlinks. To address the limitations due to the small screen size, several techniques have been proposed to convey as much information as possible on the presented item, optimizing the display usage. The typical approach in mobile systems consists of using snippet texts (i.e. short descriptions of the hyperlink content). Conversely, mobile recommender systems, which exploit a structured internal representation of the items, display a subset of the item features that are considered as more important [Ricci 2007]. In terms of UI and UX design, maps and map-based interfaces are used as primary access method to visualize the recommended items like points of interest (e.g. restaurants, shops or cinemas), their spatial relations and information related to these points (e.g. menus, products or timetables). Consequently, map-based interfaces help to address some relevant information access problems in mobile devices. For example, users do not need to scroll as the information provided is located in the map attending to their current location. Averjanova et al. [Averjanova 2008] demonstrated with a user study that a map-based interface is more effective than a list-based interface (that is more typically used in recommender systems) to select a specific recommendation. The results also show that integrating map-based visualization and

71 2.4. PROACTIVITY 49 interaction in mobile recommender systems improves the system recommendation effectiveness and increases the user satisfaction. Finally, a novel line of research to enhance the user experience in mobile recommender systems is to become the system proactive when presenting information instead of recommending when the user explicitly requests it. Despite proactivity is reviewed in detail in the next section, a good example in mobile recommender systems is the one proposed by Church and Smyth [Church 2008]. They studied this interesting idea by proposing a map-based interface to support multi-dimensional, context-sensitive mobile search, combining context features such as location, time, and community preferences to offer a search experience that is well-adapted to the needs of mobile users. In other words, they recommend searches performed by other users in similar contexts. 2.4 Proactivity Until now, we have seen that traditional recommender systems usually follow a user requestresponse pattern, i.e. these systems only return item suggestions when a user makes an explicit request. However, as we have mentioned in the previous section, in mobile recommender systems users cannot browse easily through many search results and suffer from other usability restrictions. In CARS, user experience could possibly be improved by incorporating proactivity: the system pushes recommendations to the user when the current situation seems appropriate, without the need for an explicit user request. For example, consider the following scenario: A mobile restaurant guide running on a smartphone suggests a restaurant to the user when he/she is walking near the restaurant that fits his/her preferences adequately, while also factoring in the time of the day and other context attributes. The way these restaurants are suggested taking into account the current user environment and situation is based on adding proactive capabilities to the mobile CARS Minimizing the Costs of Proactivity Proactive recommender systems aim to automatically provide the right recommendation at the right time (i.e. a process uninitiated by the user). But this gives rise to one main challenge inherent to proactivity: identifying an opportune moment for notifying the user about the recommendation. While a particular situation can induce a well-matching recommendation, it does not

72 50 CHAPTER 2. STATE OF THE ART necessarily warrant a possibly interrupting notification for that recommendation. For example, at lunchtime the system might want to recommend a highly ranked restaurant nearby. However, to a user who is on the phone or in the middle of a conference this notification might be disturbing. This dissertation follows the Stern et al. definition of interruptability: "the current state of a user regarding her receptiveness to receive messages" [Stern 2011]. Thus, a high interruptability corresponds to an opportune moment with little interruption. In proactivity, interruptions constitute costs we aim to minimize. Witt [Witt 2008] lists two similar definitions of the term interruption. On the one hand, Van Den Berg et al. [Van Den Berg 1996] consider an interruption as "an externally generated, temporary [cessation] in the current flow of behavior, typically meant for the subject to execute activities that belong to a secondary set of actions". On the other hand, McFarlane and Latorella [McFarlane 2002] give a more compact definition as "the process of coordinating abrupt changes in people s activities". Although some researchers found evidence for the "Zeigarnik effect" [Schiffman 1992], i.e., people would recall details of interrupted tasks better than those of uninterrupted tasks (a finding that seems counterintuitive), others showed that it depends on other factors like a strong initial motivation to complete the task [Weiner 1968]. Anyhow, there is substantive empirical evidence for common negative effects of interruptions when resuming a task [McFarlane 2002]: Slow recovery. Gillie and Broadbent [Gillie 1989] conducted several experiments to investigate the effects of the length of the interruption, the similarity of the interruption to the main task, and the complexity of processing demanded by the interruption. They concluded that: "It is clear that even with strong cues, after a disruptive interruption, subjects have difficulty in retrieving items from memory". Similar findings have been published by Kreifeldt and McCarthy [Kreifeldt 1981]. Mistakes. Cellier and Eyrolle [Cellier 1992] conducted experiments on inference between switched tasks and performed a qualitative analysis of errors. They found that "interruption of one task to carry out another task increased both processing time and error rate in the second task". This is backed up for example by Latorella [Latorella 1999]. Reduced efficiency. In a series of experiments on the effects of interruptions on task performance in the commercial flight deck, Latorella [Latorella 1999] also constituted an

73 2.4. PROACTIVITY 51 impaired efficiency, i.e. interruptions. an increased performance time, especially with acoustic Perceived stress. Cohen [Cohen 1980] shows that with increasing frequency unpredictable interruptions over which people have no control can cause significant personal stress. All of these general effects also hold true in mobile proactive recommender systems. Consequently, minimizing interruptions (i.e. the costs of proactive recommendations) must be the long-term goal Processing Interruptions Not every notification necessarily results in an interruption. Latorella [Latorella 1999] created a formal stage model of interruption management comprising five possible behaviors or responses to an interruption announcement (i.e. a notification): Detection and Oblivious Dismissal. The annunciation of the interruption is undetected because the stimulus is not salient enough and the interruption is not performed. Interpretation and Unintentional Dismissal. The annunciation stimulus is detected, but the significance of the annunciation is not interpreted and the interruption is not performed. Integration and Intentional Dismissal. The significance of the annunciation is interpreted, but the user elects to continue performing the ongoing task without performing the interrupting task. Integration and Preemptive Integration. The interrupting task is initiated immediately without considering the implications of performing it at that point, and performed to completion before resuming the ongoing task. Integration and Intentional Integration. The user may actively consider the ongoing and the new task and rationally decide whether and when to integrate the new task. Incorporating elements of Latorella s model, McFarlane and Latorella [McFarlane 2002] constructed a taxonomy of interruptions that presents four categories based on how the interruption is initiated:

74 52 CHAPTER 2. STATE OF THE ART Immediate interruption. The immediate method interrupts a user at any time in a way that forces the user to immediately stop with the primary task and start to interact with the interruption task. Negotiated interruption. The negotiated method requires a negotiation sequence with the user before it interrupts him/her. In this case, the system first announces that it needs to interrupt the user but gives control to the user when to deal with the interruption. Scheduled interruption. The scheduled method interrupts the user by a restricted and predefined schedule, for example, every five minutes. Mediated interruption. The mediated method interrupts the user indirectly by taking advantage of additional sources that allow determining when and how an interruption should be presented. Hence, it relies on additional context information. Both models know stimuli that announce an interruption. Latorella s oblivious dismissal sheds light on a problem at the other end of the spectrum: if a stimulus is too subtle, it does not interrupt the user but it also does not raise attention. Hence it does not deliver the content to the user, defeating its own purpose Deciding about Notifications Given a new task or event to which the user s attention is to be drawn (e.g. a recommendation), the decision to make a notification should depend on the context. According to Kern and Schiele [Kern 2003], five situational factors constitute this context: Importance of the new task or event. A user will be more receptive to a notification when it is important to him/her attending to his/her current situation (e.g. receive a restaurant recommendation when the user is on holidays will usually be more important than receiving one when the user is at home). User activity. The activity the user is engaged in during the interruption (e.g. if the user is driving, a notification will be less appropriate compare with being walking on the street). Social interaction. If the user is interacting with others; and if so, in which way.

75 2.4. PROACTIVITY 53 Social situation. For example, if the user is on a train or in a restaurant. Location. These factors are similar to the ones proposed by Ho et al. [Ho 2005] which influence a person s interruptability at a given moment. Both cover activity, importance and social situation. But Ho et al. include: Emotional state of the user. The mindset of the user, the time of disruption, and the relationship the user has with the interrupting interface or device. Frequency. The rate at which interruptions are occurring. Modality of interruption. The medium of delivery, or choice of interface. Task efficiency rate. The time it takes to comprehend the interruption task and the expected length of the task. Authority level. The perceived control a user has over the interface or device. Response pattern. The type of pattern the user follows when an interruption occurs. The user, however, is not the only person that can be interrupted. Hansson et al. [Hansson 2001] also address the problem of disturbing the environment. While, for example, a user might not mind being notified in a public library, others are likely to feel disturbed. A situation can therefore be classified on a two-dimensional grid of personal and social interruptability Notification Cues Situations with different levels of personal and social interruptability call for well-adjusted announcement stimuli. As stated before, we focus on mobile scenarios. Given the pervasiveness and ubiquity of mobile devices nowadays, this constitutes a very common and realistic setting. Based on the work of Kern and Schiele [Kern 2003] we can identify several notification cues for today s mobile devices (e.g. smartphones or tablets): vibration, beep, ring, etc. In fact, the design space proposed in [Kern 2003] can be generalized to three groups attending to their intensity and therefore, their impact in the environment and the user:

76 54 CHAPTER 2. STATE OF THE ART Visual notifications Visual cues are generally the least intrusive ones in either dimension. No cue in this group is likely to grab attention in the social dimension. The level of personal interruption is subject to other context factors like the user s activity: a flashing screen can only attract attention if the device is in plain sight of the user (although in some special cases such as watching a movie in the cinema, it could be more disturbing). Text alerts like pop ups or notifications in the status bar are only detectable if the device is currently in use but are then hard to miss. Tactile notifications Haptic or tactile cues have a greater efficacy than visual cues while still avoiding social obtrusiveness in most environments. However, in situations that are very sensitive to social interruptions, the acoustic byproduct of vibrations can still have a negative impact on the environment. Acoustic notifications Auditory cues offer the highest potential for raising awareness in any dimension. The extent can be determined by adjusting volume, length, and frequency of the tone. Depending on the situation, a short and gentle beep can notify the user without negative impact on the environment, while a 30-second melody inevitably attracts the attention of the surrounding environment Timing a Notification Often, the time a new recommendation with a high score emerges does not coincide with a good time for a notification because of low personal or social interruptability. It is therefore desirable to hold off on a notification instead of canceling it if the situation does not warrant it at that time. However, context-sensitive recommendations are volatile in nature: if the context changes to a certain extent, a recommended item might no longer match that context. Hence, notifications cannot be held back indefinitely. The challenge is to delay a notification for just the right time or start the recommendation process only when the time (situation) for recommending is suitable. One approach is to consider episodes of mobile phone activity as small context changes. Fischer et al. [Fischer 2011] investigated whether the end of an episode of interactions with the

77 2.4. PROACTIVITY 55 mobile device can serve as an indicator of opportune moments to deliver notifications. In their experiments they found that participants accepted and replied to notifications significantly more quickly after such an episode than at random other times. Another angle to tackling this challenge is to increase awareness over time by using cues with rising levels of obtrusiveness Adapting Notification Modalities to User Preferences Cohen [Cohen 1980] pointed out that the stress participants perceived on account of interruptions in his experiments was due to two factors: interruptions are unpredictable and uncontrollable. This is in line with two factors that influence a person s interruptability as mentioned in [Ho 2005]: the authority level (i.e. the perceived control a user has over the device) and the personal response pattern of a user. To alleviate the negative impact of interruptions, we can offer certain controls to the user and adapt to the user s preferences, i.e., the personal response patterns. For example, the user should be empowered to disable obtrusive notification cues (permanently or in specific situations). It is also important to let the user provides negative feedback that is incorporated into a personal notification model for future notification processes Proactivity in Recommender Systems In his survey on mobile recommender systems Ricci remarks proactivity as one of the most interesting research topics in the field [Ricci 2010b]. He concludes that "none of the existing reviewed systems is capable to proactively interrupt the user activity with unsolicited but relevant recommendations" and "[proactive recommendations] can revolutionize the role of recommender systems from topic oriented information seeking and decision making tools to information discovery and entertaining companions". A broad variety of work exists on recommender systems in different domains, but only a few have proactive character. For example, Hong et al. [Hong 2009] proposed an agent-based framework for proactive personalization services. This approach proposes a model according to which a user profile is deduced from user s context history. The model enables proactive recommendations in the future. However, training time is very important in their model and that suppose an important issue to generate recommendations. A more recently architecture of

78 56 CHAPTER 2. STATE OF THE ART context-aware proactive recommender systems was proposed by Al Tair et al. [Al Tair 2012]. Their system utilizes context information such as time and location to recommend hotels and restaurants for a user s trip. The focus in this work is on the inference of suitable items. After the user has selected the trip details, the system may send notifications to remind a user about upcoming events or deal with changed plans. Hence, this system does not investigate in fact the question when to generate a proactive recommendation. In terms of usability, Modsching et al. [Modsching 2007] evaluated the effectiveness of a tourism mobile recommender system. They compared a proactive recommendation of personalized tours against a pull service presenting context-based information on demand. The findings showed that tourists often do not take advantage of such capabilities and use both pull and push applications in very similar ways, thus leading to comparable effects on behaviors. This means that users need to be more explicitly educated about the capabilities of a proactive system, by using novel user interfaces far away from traditional methods, so as to show a perceivable difference for them. In the ubiquitous system domain, Aritoni and Negru [Aritoni 2011] described an ambient intelligent recommender system that uses context-aware to achieve energy-savings in households. The goal of this system is to change the user behavior and not to recommend a priori unknown items to mobile users. Regarding interruptability, it has been only covered in very specific scenarios for proactive recommendations. For example, Puerta-Melguizo et al. [Puerta Melguizo 2007] proposed a proactive recommendation system for writing that aims for reducing disruption in the process of composing a scientific paper. In two experiments, the efficacy of recommendations during planning and reviewing was examined. For recommenders on mobile devices, as early as 2003, Hudson et al. [Hudson 2003] studied the general feasibility of predicting interruptability with sensors. Stern et al. [Stern 2011] focused their research on sensors embedded in mobile devices. For that, they used GPS-based location information and calendar entries. Although GPS recordings proved to work accurately enough for interruptability calculation in many situations, the computed interruptability value did not correspond to the users own perception of interruptability. Leiva et al. [Leiva 2012] studied the effects of interruptions during interactions with a mobile application. Their findings reveal that while these interruptions rarely happen, they may introduce a significant overhead. More

79 2.5. RELATED RECOMMENDER SYSTEMS RESEARCH: APPLICATION FIELDS 57 general studies on good timing for mobile interruptions were conducted by Fisher et al. [Fischer 2011]. Contrary to evaluate self-reports of participants, endings of episodes of mobile interaction proved to be opportune moments for interruptions by quantitative empirical analyses. 2.5 Related Recommender Systems Research: Application Fields Although numerous recommender system research works from different fields have been mentioned during this chapter, in this section I want to review in more detail two specific fields in which proactivity features are not yet widespread: banking and e-learning. I have selected them because proactivity can play a major role helping users of these systems to be aware of all the possibilities at their hand in scenarios in which the underlying data evolve very quickly and the number of items to analyze is overwhelming. Moreover, these domains are closely related to the scenarios in which this dissertation has been validated, so the next sections will help to understand and contextualize the contributions provided following the design science methodology Banking The current all-mobile lifestyle based on the great market penetration of smartphones has become mandatory for companies to use mobile systems to allow customers to access their services in a ubiquitous way. Furthermore, developing a mobile system is also strategic to achieve a huge target market as everyday new mobile users come on the scene. Accordingly, traditional E-Commerce applications have evolved in the last years due to the growth of the mobile environment, creating a new research area known as U-Commerce [Watson 2002] which appears as a combination of M-Commerce and E-Commerce [Junglas 2003]. Bank entities are a good example of companies that have adapted their services to this new mobile environment because they may enhance, as well as make more comfortable and accessible the services offered to their customers. On the other hand, in the recommender system field we have seen that the more information is available from a user and his/her contextual situation, the more personalized will be the suggestions provided. However, as Yujie and Licai stressed in [Yujie 2010] one of the most important challenges for CARS is the lack of public data sets available to conduct experimental

80 58 CHAPTER 2. STATE OF THE ART evaluations on the methods developed, as well as to improve the quality of commercial systems before they are running in real scenarios. If we think about the banking domain, these entities have millions of records in their databases plenty of rich information about customer purchases and behavior, client profiles or economic trends that usually are utilized in internal data mining process focused on generating mined useful knowledge for bank managers [Ataee 2005], helping them to make decisions about customer segmentation [Ren 2010] or economic products, as well as to enhance their customer relationship management. Only few research work on recommender systems in the banking domain exist, and most on them is focused on recommending banking products to their customers. For example, Guzmán et al. [Guzmán 2005] defined a Coherence function between user actions and preferences in a recommender system to build a correspondence between the relevance a user gives to a specific personal situation and his/her emotional state. They applied that function in the recommendation of banking services scenario to adapt the banking products or services recommended to the client profile (e.g. conservative or innovative). Asosheha et al. [Asosheha 2008] studied several models for recommender systems acceptance in retail and banking services by evaluation real users from bank entities in Iran. They considered several factors (i.e. encouraging customers, retail facilities, ease of system usage, customer environment and attitude of customer) when recommending products like personal loans or capital rising investment to their customers. A more recently work proposed by Tangphoklang et al. [Tangphoklang 2010] describes a multi-criteria recommender system architecture for mobile banking business to permit inexpert users to choose unfamiliar mobile banking services without disturbing normal banking service transactions Learning Educational platforms associated to the e-learning domain may present problems related to finding the most suitable learning objects for a specific user among all the items available. Moreover, when these kinds of platforms store a huge number of learning objects, it is difficult for users to difference between high and low quality pedagogical content. Sometimes the learning objects are gathered by categories using taxonomies or folksonomies [Dahl 2008], but it is still hard to find the best learning objects inside those sets as the number of them to check is commonly overwhelming.

81 2.5. RELATED RECOMMENDER SYSTEMS RESEARCH: APPLICATION FIELDS 59 For example, by the time this lines are written, Ariadne repository i has 827,090 learning resources and Merlot ii has 40,538. As a consequence, the application of recommendation techniques to avoid those problems seems to be a good solution, as they have been solved, or at least mitigated, in other areas related to the recommender systems research field that we have reviewed in this chapter. Attending to the survey of recommender systems in Technology Enhanced Learning (TEL) presented by Manouselis et al. [Manouselis 2011] the main feature these systems offer consists of recommending learning resources [Recker 2001], [Tang 2005], [Manouselis 2010]; but people [Recker 2001] and activities [Verbert 2011] that may be important in the learning experience are also suggested in many of them. These functionalities are usually applied in TEL environments like learning networks [Koper 2005] and teaching communities [Drachsler 2008], [Fazeli 2012], as well as personal learning environments [Modritscher 2010]. For instance, García et al. [García 2009] proposed a recommender system that uses iterative association rule mining and collaborative filtering techniques in order to help teachers to maintain and continuously improve their courses by analyzing other teachers and experts with a similar profile. According to Drachsler et al. [Drachsler 2007], recommender systems in e-learning have to be adjusted to the specific character of learning. It is often not possible to take one recommender system from one context and transfer it to another context or domain. The same conclusion is reached by Manouselis et al. [Manouselis 2011], declaring that in TEL, careful analysis of the targeted users and their supported tasks should be carried out. A great number of user attributes, domain characteristics, and intelligent methods can be engaged to provide personalized recommendations, e.g. user learning goals, targeted competence levels, etc. However, although multiple attributes are often considered in traditional TEL recommender systems, additional context dimensions can be incorporated to improve the level of personalization and accuracy of the recommendations, specially when mobility plays an important role (i.e. mobile learning). In the learning domain, the application of CARS was recently surveyed by Verbert et al. in [Verbert 2012] wherein a context framework for TEL is also proposed containing several dimensions that are relevant for them: i ii

82 60 CHAPTER 2. STATE OF THE ART Computing. Mainly researched by the pervasive and mobile research community, and especially by the mobile learning area, it refers to the contextual information obtained from the network, hardware and software categories. Location. It includes not only the current geographical location of the user, but also his/her proximity to objects within a space, the communicative ability and the orientation. Time. It includes date and time information. Physical conditions. It describes environmental conditions where the system or user is situated, and commonly includes measures for heat, light, noise, etc. Activity. It reflects the task, objectives or actions of the user. Resource. It captures relevant characteristics of physical or virtual learning resources, like the general description of the resource, its educational characteristics or its relations with other resources. User. This contextual dimension has been extensively researched in the learning domain, and several parameters can be taken into account such as basic personal information (e.g. name or age), prior knowledge of the learner, learner interests (e.g. biology or maths), etc. Social relations. They describe social associations, connections or affiliations between two or more users (e.g. relations between teachers or peer learners in a community). As it is shown in [Verbert 2012], a great variety of research and practical applications exist in CARS for learning in relation with each dimension mentioned above, as well as combination of several. A good example of this is MOBIlearn [Lonsdale 2004], a mobile CARS that uses contextual information about the topic selected by the user, the time spent in every learning resource, the user current activity and relations between the user with both resources and other users, to generate recommendations of both relevant resources and peers who are nearby in a museum. A more recently work, in which the analysis of social relations and user activity context (among others) are incorporated, is the one proposed by Stern et al. [Stern 2010]. They developed a context-aware recommender system to suggest courses, learning resources and peers based on users roles.

83 2.5. RELATED RECOMMENDER SYSTEMS RESEARCH: APPLICATION FIELDS 61 Finally, as regards proactivity in CARS for learning, it has not gained much attention yet and only few researches exist. For instance, Ruiz-Iniesta et al. [Ruiz-Iniesta 2009] present a proactive recommender system in computer-supported learning that works on repositories of LOs and adapts to the student s profile. The system recommends learning objects to the student who can enter a conversational process to refine the proposal.

84 62 CHAPTER 2. STATE OF THE ART

85 Chapter 3 An Architecture for Social Mobile CARS This chapter proposes a new architecture for building mobile context-aware recommender systems in ubiquitous scenarios with rich social data. It allows the combination of different social sources and type of mobile clients in order to obtain contextual information to enhance the recommendations provided. Thus users can easily access the system utilizing their smartphone or tablet; at the same time the system can analyze aggregated social information coming from social networks or third parties that also store significant social or behavioral data. To validate this approach the architecture was implemented in a real banking scenario related to a research project carried out with the Spanish bank Bankinter. Details about its implementation and the results obtained after the evaluation performed among bank customers are also provided. 3.1 Introduction The important irruption of social networks in Internet in the last years due to the incredible growth of platforms like Facebook or Twitter has changed the way people treat and consume information. Nowadays users do not surf the Web isolated as in the past. Rather they constantly share their experiences with others through these social platforms. This new way of living the Internet has given rise to new methods of analyzing users behavior and aspects like "trust" have radically changed from being provided by "third party well-known entities" to evolve to a "social-trust" way in which users support their decisions bearing in mind what other peers have done. This evolution has also influenced how recommender systems using these social data are designed. As we reviewed in section 2.1.3, the popularity of social and trust-enhanced recommender systems have grown in recent years. They recommend items that similar users (e.g. friends or people akin in terms of social aspects) have previously liked or consumed. In this rich social data scenario it is has to be considered that there are economies of scale in recommender systems: The bigger the set of users, the more likely I am to find someone like me. However, having a huge amount of social information to process in a traditional recommender

86 64 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS system (e.g. collaborative filtering) may cause significant problems such as delays or problems with the algorithms used. The architecture I propose in this chapter addresses this idea but from the point of view of CARS. The social information will be treated as an additional contextual dimension that may change over time and will be independent from other contextual dimensions to avoid complexity in the recommendations process. This social context will be generated by aggregating social information from different social sources. The rest of context dimensions will be obtained from the information provided by the user s mobile device as the system is intended for ubiquitous scenarios keeping in mind the current all-mobile lifestyle. As a result, I designed a novel mobile CARS architecture following this approach with the aim of being the foundations to include proactivity in next iterations, following this way the design science methodology. As part of it, the architecture was implemented and validated in the Perdidos en la Gran Ciudad i (Lost in the big city) project, a work supported by the Spanish bank Bankinter ii, the entity that acts as the social-trust data provider in the recommendation process. The system resultant allows users to request context-aware recommendations about places related to where the bank customers have paid with their credit cards, like restaurants, supermarkets or shops. Section 3.2 shows the main objectives of this contribution. Section 3.3 gives details of the recommendation model and the architecture designed, with description of every component and their different functionalities. Section 3.4 shows an implementation of this architecture in a real environment supported by Bankinter. Section 3.5 presents the results achieved from the evaluation carried out among users. Section 3.6 reminds the main contribution in this chapter. Finally, the last section provides concluding remarks of this work. 3.2 Objectives This contribution is two-fold: firstly, it addresses the design of a new architecture for building mobile CARS with rich social data. Secondly, it presents the development and implementation of a real banking recommender system that follows it. Thus, the contribution deals with the following objectives defined in the introduction of this dissertation: i ii

87 3.2. OBJECTIVES 65 To identify which elements are needed for designing mobile context-aware recommender systems with rich social data. Here I describe those general elements that are used in mobile CARS. To propose a novel architecture valuable for building mobile context-aware recommender systems capable of using contextual information from different social sources as well as different mobile devices. Considering the elements needed, I describe the details of the architecture that integrates them. To implement and test the proposed general architecture in a real scenario. As a result of this contribution I explain how the architecture was implemented and how it has been used in the context of the Perdidos en la Gran Ciudad project. This chapter basically aims to give guidelines to resolve current problems in different aspects of this contribution: 1. Mash-up of several social sources for recommendation. This architecture follows a centralized topology for allowing the integration of different social data sources. 2. Social data analysis available at recommendation time. This architecture and its recommendation model are designed to be able of analyzing social data without affecting the response time for a user requesting a recommendation. 3. Privacy. All raw user data coming from the social sources will be treated after applying an anonymization process in order to destroy tracks or electronic trails on the data that would lead to eavesdropping on its origin. 4. Multi-device and Cross-platform. The architecture delegates the communication between the recommender engine and the mobile clients to a general application program interface (API). It provides independence between client and server technologies and allows communication between the recommender and third-party applications. 5. Novel contextual recommendation model. This architecture is based on a new recommendation model based on contextual pre-and-post filtering which integrates social, location and user context.

88 66 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS 6. Avoid cold start problem. This architecture avoids the cold start problem related to traditional recommender systems by taking advantage of the initial information from the social sources retrieved from a user. 7. Validation. The whole system has been implemented and tested as part of a National research project. 3.3 Design The work I will explain throughout this section is based on a new architecture for building mobile CARS in scenarios which rich social data. To understand how this architecture was designed, first I will present the recommendation model behind it to clarify what are the inputs and outputs that have had a direct consequence in the architectural design. Hence the main goal of this section is to present the design of both the architecture and the recommendation model associated to it by describing the elements involved in each one, detailing this way several artifacts created following the design science approach Recommendation Model To handle recommendations in a context-aware mobile recommender system based on rich social data, I propose the three-phase model illustrated in Figure 3.1. It analyzes the current context and calculates a personalized recommendation that determines the best item(s) in a given situation for a user request. In this dissertation I follow the definition of context proposed by Dey [Dey 2001a] reviewed in section He defined it as any information that can be used to characterize the situation of an entity, being an entity a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and application themselves. Attending to this, the contextual dimensions in which the system is based on are Social, Location and User context. The following sections describe every of them corresponding to one of the model phases illustrated in Figure 3.1. The reasoning for this sequence is to make them independent from each other, in order to make possible the application of the model in special situations in which some contextual dimension are not available for some reason.

89 3.3. DESIGN 67 Figure 3.1 : Model for generating context-aware recommendations using social data in mobile recommender systems. Phase I: Social Context Generation This phase deals with generating the social context corresponding to a user by analyzing all the user profiles and transactions related to the items that will be recommended. In other words, the three kinds of data knowledge sources that we saw in Figure 2.1 are utilized here. For example, in the Facebook domain when a user likes a picture, a transaction between the user and the picture is established. Thus the social data source will provide this kind of information to the recommender engine as an input. Social context can be understood as the links or social relationships among users that allow us to gather them into groups by similarity. Two users are similar when their behavior, interests or consumption trends are alike. Similarity can be also seen in terms of demographics like age, gender, job position, studies, etc. The social context is generated by a data mining process over the input data divided into three steps (Figure 3.2). These steps are not constricted to a real-time execution because all of them are carried out before the recommendations are requested by the user. Therefore, this phase may be executed with low frequency (e.g. once a day during the night), because the social context does not change continuously, being this the main reason to be the first phase of the model. Therefore, the result of it is social knowledge that will be used at user-request recommendation time.

90 68 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS Figure 3.2 : Steps to generate the social context. The phase begins with the system taking the user profiles provided so as to apply a clustering segmentation to them. As Figure 3.2 depicts, the main idea behind this process consists of gathering similar users into social clusters. Similarity can be obtained by calculating distance measures among user profiles. A user profile can be represented by some feature vector in an n dimensional space composed by a n-tuple describing the information relevant to the recommender system extracted from the user profile model. In the implementation section an example of the n-tuple defined for the user profile in the banking scenario is presented 3.2. Keeping in mind that the features of this n-tuple may correspond to different domains (e.g. numerical or textual), to calculate the similarity between users it can be needed an ad-hoc distance measure that combines several types of similarity methods, being every one of them appropriate to the different existing user profile attributes. Hence, the distance measure for calculating the similarity between users is defined as: D user (x,y) = i w i D i (x i,y i ) i w i (3.1)

91 3.3. DESIGN 69 where x i and y i are the i th attributes of the user profiles x and y respectively, and w i represents the weight (impact) of every attribute in the similarity calculated. As a result, by using the appropriate distance metric in a clustering algorithm the social clusters can be generated. The specific algorithm selected will be domain-dependent as several methods exist (see section 2.1.4), being each one targeted for solving different problems. Thus, a trade-off between the quality of the clusters achieved and the computational time consumed to generate them has to be considered. Then the system calculates the clusters trends map by considering the relationships established between the users belonging to every cluster and the items they have interacted with in the platform. To do this, every transaction generated by a user interacting with an item is analyzed. The type of transactions will also be domain-dependent. For instance, in the Facebook scenario a transaction would be "like" or "comment", while in the banking scenario it would be "pay" or "buy". To do so, we assume that this model will be applied in scenarios in which there is an unequivocal relationship between a transaction, the item related to it and the user who made the interaction. The result of this process is a map or set of items for every cluster indicating the items that users belonging to that cluster have interacted with in the past, noticing this way the "consumption" trends of every social cluster. In the last step (Figure 3.2), the user s cluster discovery process is activated when the target user enters for the first time to the system (i.e. registration). The system checks the information profile extracted from the user s account in order to assign him/her to any of the existing social clusters. This is done this way because as we will see in the architecture section, the social data analyzed have been previously anonymized to assure privacy. Therefore the system is not aware about which social cluster every user belongs to at the beginning, as the data managed by the recommender is aggregated. Once this phase is completed, the system knows the social context of the target user because he/she has been assigned to one of the social clusters previously created. Every cluster has a common consumption model represented by the clusters trends map and thus, the system knows which items are candidates to be recommended to the user. In other words, this phase corresponds to a contextual pre-filtering process (section 2.2.4) in which the initial set of items available in the platform is contextualized attending to social aspects related to the target user This minimizes the number of candidate items to a restricted set of them

92 70 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS which are the most relevant for that kind of user. Phase II: Location Context Filtering Location is currently one of the most important context parameters, especially in ubiquitous systems [Abowd 1999] in which users can access the system from different places and at different moments in time. It is usually for end users to look for recommendations in their immediate locality (e.g. good restaurants nearby). The use of mobile context device information as an input for the recommender system allows to personalize recommendations and make them more accurate attending to the current user s location. Location context can be understood as a combination of temporal (e.g. current time) and geographical information (e.g. position), as well as other parameters like the user s language, etc. Information like the time or user s language can be obtained from the system (e.g. the mobile operative system). For the geographical position, it can be retrieved by using various location methods delivering different quality of service: A-GPS for very accurate positioning but slow response time in outdoor environment or location inferred from network signals for fairly accurate positioning in every kind of environments and fast response time such as IP address, RFID, Wi-Fi, Bluetooth MAC addresses and GSM/CDMA cell IDs, as well as user input. The recommendation model itself is agnostic of the underlying location information sources. Thus, once the system is aware of the user s location, it is applied as a new input to perform a contextual post-filtering process (section 2.2.4) over the user s cluster trends map (i.e. the result of the phase I). This way a geo-located user s cluster trends map is obtained. It only contains those items that are suitable for the user in terms of location context. For instance, if a user of a mobile restaurant recommender is requesting a suggestion for having lunch in the city of Tokyo, the system would filtering out those restaurants candidates in his/her social cluster that are irrelevant in such context (e.g. restaurants in Kyoto for having dinner). Phase III: User Context Filtering The final phase to achieve the personalized recommendation takes into account the user context. We understand this context as a set of parameters like the current user activity inferred from sensor data, e.g. by utilizing the user s velocity the system might identify if he/she is walking or driving, and therefore extend or decrease the area considered in the recommendation). Apart from this

93 3.3. DESIGN 71 inferred contextual parameters, input preferences given by the user are also considered as user context, such as the item category he/she wants to be recommended (e.g. restaurant, supermarket or cinema). For instance, if the user wants a restaurant recommendation (category input), the mobile application would use the current activity (e.g. walking) to filter the geo-located user s cluster trends map, considering only those restaurants that fit these conditions. Following the example, the user would see a ranked list of the closest restaurants to his/her location that other users belonging to the same social cluster have visited most at lunch time in the past. To summarize: this phase can be seen as a contextual post-filtering process (see section 2.2.4) in which the candidate items resulting from the phase II are shown as a ranking. This ranking is generated by showing first those items that fit the contextual conditions better. User feedback After the personalized recommendation is provided to the user through the mobile user interface of the client application, he/she can optionally give feedback on the items recommended. The feedback is a value that can follow any rating paradigm (see section for examples), representing a positive or negative opinion about an item. The feedback is added to the user personal profile to allow the system learn about the user tastes for future recommendations. These ratings can be used to increase the accuracy of the filtering processes in order to filtering out those items from the user s cluster trends map that are similar to those that have been assigned with a bad rating or have been explicitly rejected by the user. On the other hand, items which are similar to those with good ratings may be risen in the final ranking. In addition to this, a limit situation triggered by a continuous rejection by the user of the items recommended could cause a new cluster assignment. In other words, when the user shows a behavior corresponding to other social group it could be better to move her/him from one cluster to another, more accurate with his/her current tastes. Thus, it allows a system evolution in terms of user personalization.

94 72 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS Contextual information Clients User feedback Request recommendation Display recommendation REST API Application Manager Target user profile Personalized recommendation Recommender User profiles Transactions Items Data Anonymization Social Data Source 1 Social Data Source 2 Social Data Source 3 Social Data Source N Figure 3.3 : General architecture for building mobile context-aware recommender systems based on social data Architecture Keeping in mind the recommendation model, Figure 3.3 shows now the general architecture for building mobile CARS with rich social data I propose. This section describes all its components, which can be divided into five parts: Social Data Sources One of the main features of the architecture proposed is that it is designed to merge social data provided from different sources. The social sources utilized and the data format provided by

95 3.3. DESIGN 73 them will be scenario-dependent. For instance, in a recommender system for a banking scenario the different sources might be several bank entities, each of one giving information about their customers and their payments or bank transactions. Whereas in a scenario with Facebook and Twitter as social data sources, the information provided would be for example related to transactions such as "like" (in Facebook) and "favorite" (in Twitter) actions over the items shared. Data Anonymization The way the data is provided by the social sources is not known by the system itself because an intermediate module is responsible of performing a data anonymization process to ensure privacy: by anonymizing the raw data provided, it would be impossible for a malicious attacker to track a information about a user using the user profile information stored in the recommender databases. Therefore, the result of this process is a set of n-tuples containing information about user profiles, transactions and items. Recommender This module follows the model presented in the previous section. It takes as input the anonymized data from the social sources and the target user profile provided by the client when the user registers in the system. Once the user requests a recommendation during execution time, the current context is sent to this module by the client and a personalized recommendation is generated following the steps illustrated in Figure 3.1. Additional input data can be received if the user gives feedback on the items recommended. On the other hand, attending to the recommendation model behind this module, the cold start problem is avoided because a new user can request recommendations since he/she has registered in the system. This is so because when a user registers in the system, the recommender assigns him/her to one of the existing social cluster, and consequently, a set of candidate items is known. Application Manager As we can see in Figure 3.3, the recommender engine is isolated from the client side as only communication through the application manager is allowed. This module is the one responsible of the application business logic (e.g. registration, log in, etc.), as well as managing the applications users profile history, ratings provided by them and so on.

96 74 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS Table 3.1 : Summary of HTTP methods available for the REST API resources. URI GET POST PUT DELETE /users /users/{uid} /users/{uid}/recommendation /users/{uid}/ratings /users/{uid}/ratings/{rid} /items /items/{iid} Furthermore, it is responsible of receiving the recommendation requests to adapt the contextual information given by the client to the format accepted by the recommender and process the personalized recommendation generated to be displayed in the client. Application Program Interface It is the connection between the application manager and the clients. By using it the architecture makes the clients independent from the underlying recommendation logic, providing this way the multi-device and cross-platform feature defined as an objective. Client applications using this API should authenticate all these requests, but the mechanism to do it will depend on the scenario and the implementation of the application manager. This API is based on a REST methodology [Fielding 2000]. Two different resource representations are managed through this API that are accessible using HTTP requests: Users. This resource represents the end users of the recommender system. Ratings. A user will have a set of ratings corresponding to all the items for which he/she has provided feedback. This resource represents them. Items. This resource represents the items that can be recommended by the system. Table 3.1 shows a summary of the actions that can be performed over these resources, being uid, rid and iid the unique identifiers of user, rating and item respectively. Examples of JSON representation of these resources can be found in the next section for the banking scenario.

97 3.4. IMPLEMENTATION 75 Clients This component represent any end-user or third-party application developed to be responsible of allowing the target user to request a recommendation, as well as displaying the result provided by the recommender. It is not restricted to any technology or platform. Therefore, it is possible to build different kind of clients like desktop or mobile, as well as native or web-based applications. The only requisite is that the client has to be able of using the above REST API to communicate with the server side. 3.4 Implementation The implementation of the architecture proposed in the context of the Perdidos en la Gran Ciudad project supported by the Spanish bank Bankinter is described in this section. First, I describe the banking scenario and the motivation associated to the project. Then, details about how the previous architecture was particularized, implemented and deployed are explained attending to the elements depicted in Figure 3.4. This figure also summarizes the flow of the data involved in the recommendation process in seven steps that are going to be explained in the following subsections Scenario Bank entities have millions of records in their databases plenty of rich information about customer purchases, client profiles or economic trends. Though they are not commonly used to provide a direct benefit to the end user. In fact, it is also important to note that usually the projects related to a banking data mining process are focused on generating mined useful knowledge for bank workers, helping them to make decisions about customer segmentation or economic products, as we can see in [Ataee 2005] and [Ren 2010]. Nevertheless, we cannot find research work in which the banking data is used to generate suggestions about non-economic or banking products to end users after that data mining processes. If this goal is achieved, the bank could provide real benefit to their clients. Sometimes this is so because the privacy and security policies related to these data are complex to manage. In other cases, the challenge is associated to data mining scalability problems because of the huge data available to be processed.

98 76 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS Bearing this in mind, the emerging of recommender systems in this environment in response to these problems is a direct outcome. Moreover, due to the capabilities of modern mobile devices (such as smartphones or tablets), and considering the bank costumers as the target of the recommendations in the current ubiquitous world, building a mobile system which considers the user s context was a key requirement to enhance the power of the recommendations in the banking scenario. An additional main idea behind the use of this architecture by a bank entity to create a mobile CARS was the confidence on the recommendations generated perceived by the users. As [Sinha 2001], [Tintarev 2008] and [Victor 2011b] shown, one of the key goals of every recommender system is achieving the trust property to increase the users confidence in the system recommendations. When we use regularly a recommender system, we can think about several ways of falsifying or distorting the reality associated to the items recommended. For example, the score of a restaurant recommendation from Google+ Local i is based on different user opinions. Thus the final recommendation comes from subjective evaluations of several users, and in some cases, the recommendation might not correspond to the reality (e.g. the owner of a restaurant and his friends might give high ratings far away from the real quality of the place). In conclusion, sometimes you may not trust recommendations because of the doubtful data origin. However, by applying the architecture and the recommendation model proposed in the banking scenario that goal is accomplished in three ways: Firstly, the system inspires confidence as the data used for recommending are real data provided by a bank (i.e. Bankinter) that is based on credit card purchases that cannot be falsified. Secondly, the recommendations takes into account what other similar users from the bank consumed in the past. Finally, as Gorgoglione et al. shown in [Gorgoglione 2011], a CARS provides a good balance of accuracy and diversity of recommendations that result in the increased levels of sales and trust. For these reason, I adapted the aforementioned architecture to the Bankinter scenario so as to be able of recommending places. A place is any entity where bank clients have paid with their credit cards: restaurants, stores, cinemas, supermarkets, etc. i

99 3.4. IMPLEMENTATION 77 Figure 3.4 : Architecture deployed for the banking scenario and its recommendation process flow.

100 78 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS Banking Data Anonymization The first step consists of generating the social data that is going to be used by the recommender system. To fulfill security and privacy requisites and complying with Bankinter policies, the module in charge of generating the anonymized data is in the banking side. This way, the security of raw data is delegated to the bank entity. Following the Phase I of the recommendation model (Figure 3.1), three data sets have to be provided by the social data source. In the banking scenario they are: banking client profiles, credit card transactions and places related to those purchases. Therefore, after the anonymization process the data managed are represented by several n-tuples. The banking client profiles (3.2) are represented by a unique identifier for every customer in the bank, his/her gender (translated to a numerical value to compute the similarity in conjunction with the other features), age and average expense in credit card transactions per year. Pro f ile := pro f ileid, gender, age, avgexpenseperyear (3.2) Every credit card transaction (3.3) is represented by the profileid which informs about the client who made the credit card transaction, a place identifier that informs about where the purchase was made, the payment amount and the time and date related to it. Transaction := pro f ileid, placeid, paymentamount, time, date (3.3) Lastly, the places (3.4) are represented by the placeid, its category (e.g. restaurant, supermarket, cinema, etc.), name, address, latitude and longitude to locate it and an approximate average price of the place considering all the existing payments related to it. Place := placeid, category, name, address, postalcode, townname, lat, lng, avgprice (3.4) To conclude this step, the anonymized data received from the banking side have to be cleaned before the clustering process starts: Each record containing incorrect data (e.g. missing values, etc.) is ignored in order to avoid inconsistencies. bad format,

101 3.4. IMPLEMENTATION Recommender The recommendation engine follows the three-phase model presented in Figure 3.1. Accordingly it is responsible for generating the personalized recommendation using banking and context data. I implemented it using Apache Mahout i in order to take advantage of the scalable machine learning and data mining algorithms provided by its Java libraries to construct a customized recommender system using a selection of such algorithms. In addition to this, I used a MySQL ii database to store the social clusters generated and the candidate places to be recommended in each of them (step 2 in Figure 3.4). I selected from the Mahout libraries the k-means clustering algorithm [Kanungo 2002] to generate the social clusters. It can be described by (3.5) in which given a set of observations (x 1,x 2,...,x n ), where each observation is a d-dimensional real vector, k-means clustering aims to partition the n observations (i.e. the banking client profiles) into k clusters (k n), being S = {S 1,S 2,...,S k } so as to minimize the within-cluster sum of squares. In other words: each point belongs to the cluster with the nearest mean. argmin S k i=1 x j S i x j µ i 2 (3.5) where µ i is the mean of points in S i. In the banking scenario each point can be thought of as being represented by some feature vector in a d dimensional space, d being 3 corresponding to the gender, age and avgexpenseperyear features defined in (3.2) to describe a client profile. The k-means implementation used follows these steps: 1. The algorithm randomly chooses k points in the space. These points serve as the initial centers of the clusters 2. All points are each assigned to the center they are closest to by calculating the distance between every of them and the designated k centers. 3. For each cluster a new center is computed by averaging the feature vectors of all points assigned to it. The old k centers are replaced by the new ones computed. i ii

102 80 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS 4. The process of assigning points (step 2) and recomputing centers (step 3) is repeated until the process converges. The algorithm can be proven to converge after a finite number of iterations. However, this clustering method suffers from several issues. On the one hand, the problem complexity is NP-hard in general Euclidean spaces [Aloise 2009] (like the one we have for the banking environment), and it depends on parameters like k, n, the complexity of the distance measure selected and the number of iterations needed to converge. The higher each of them, the higher is the computational time needed to perform the process. On the other hand, there is a risk when choosing the k value and the initial centers. If k is chosen small to decrease the level of complexity, the results might be very poor or less accurate to be used in the recommender system. But if it is chosen big, the complexity increase. At the same time, if the initial centers are chosen inappropriate (as they are selected at random), the number of iteration might be too much high, increasing this way the time needed to converge. To mitigate this issues, I decided to use a pre-clustering process in order to decrease the computational time needed. In fact, when k (number of social clusters to generate) and d (dimension) are fixed, the problem can be exactly solved in time O ( n dk+1 logn ) [Inaba 1994], where n is the number of banking client profiles to be clustered in our case. Taking into account that d is known (i.e. its value is 3), only k has to be calculated in the pre-clustering process. Then, to reduce the complexity of the clustering process I first applied the Canopy unsupervised pre-clustering algorithm [McCallum 2000] also available in the Mahout libraries. It is intended to speed up clustering operations on large data sets, where using another algorithm directly may be impractical due to the size of the data set. To achieve it, the algorithm cheaply partitions the data into overlapping subsets (called canopies) to allow after a more expensive clustering, but only within these canopies. Again, in this process all client profiles are represented as a point in a multidimensional feature space following the n-tuple (3.2) in which every feature is represented by an integer value which is weighted to determine the importance of every feature in the clustering process (i.e. in the banking scenario the most influential feature is the average expense per year). The algorithm uses a fast approximate distance metric and two distance thresholds C1 > C2 for processing. I selected the Manhattan distance (3.6) to calculate the similarity among client profiles as the computational time required to process it is low.

103 3.4. IMPLEMENTATION 81 d Manhattan (x,y) = x y Manhattan = The Canopy algorithm proceeds as follows: n i=1 x i y i (3.6) 1. It begins with the set of points representing the client profiles in which one is removed at random to create a canopy containing this point. 2. Then it iterates through the remainder of the point set considering that at each point if its distance from the first point is < C1, then the point is added to the canopy. If, in addition, the distance is < C2, then the point is removed from the set. This way points that are very close to the original will avoid all further processing saving computational time. 3. The algorithm loops until the client profiles set is empty, accumulating a set of canopies, each containing one or more points and keeping in mind that a given point may occur in more than one canopy (i.e. the consumption trend of a banking client may be a combination of several existing in various social clusters). By starting the user profile clustering with this initial Canopy pre-clustering process the result is a set of k canopies smaller than the initial banking client profiles point set. The next step consists of applying k-means over these canopies as the number of more expensive distance measurements can be significantly reduced by ignoring points outside of the initial canopies. The distance measure chosen in the k-means clustering is the Euclidean (3.7), as the number of points per canopy is lower compare to the whole set analyzed. Hence, it can be used a more complex distance metric to increase accuracy in terms of similarity among client profiles. d euclidean (x,y) = x y euclidean = n (x i y i ) 2 (3.7) i=1 Finally, after the combination of both algorithms the result is a set of clusters based on the similarity of the banking clients. They are called social clusters because they gather together banking clients with similar profiles, forming social groups where the consumption model or tastes are related. Following the recommendation model (Figure 3.1), after that the transactions assignment process is carried out by associating the credit card transactions (3.3) to the clusters generated. To

104 82 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS Table 3.2 : Context information used in the recommendations process. Contextual parameter Time Position Description The current time in which the user requests the recommendation. The geographical location of the user in terms of latitude and longitude. Activity Idle, walking or in transport (e.g. in a bike, car or bus) activities are considered in order to sort the places by their distance to the current user location. Category The category of the place the user wants to be recommended (e.g. restaurant, supermarket, cinema etc.) do this, the unequivocal relationship between a transaction and a client profile through the profileid feature is used. Then, every transaction is translated to a place (3.4) using the relationship among them provided by the placeid feature. As a consequence, the candidate places for every social cluster are stored in the database (Figure 3.4, step 2) so as to be available at execution time (Figure 3.4, step 4). Then, the places associated to a cluster are those which have been consumed in the past by the users belonging to that social cluster When a user registers in the system, his/her user profile is analyzed in order to be assigned to the most similar social cluster (Figure 3.4, step 3). After that, when the user requests a recommendation, the Phase II and III of the recommendation model (Figure 3.1) are carried out in real time regarding the contextual information provided (Figure 3.4, step 4). Table 3.2 shows the contextual parameters used in the banking scenario to generate the personalized recommendations consisting of a ranking of places. The next subsection provides examples of how this information is sent through the REST API.

105 3.4. IMPLEMENTATION Application Manager and API The application manager is a Java application developed following the Spring i framework that acts as a wrapper for the recommendation engine. It offers a JSON ii REST API in charge of receiving data from the client and provides the personalized recommendation generated in step 5 by the recommender. Apart from all this recommendation-related-features, this module also manages the users of the application, i.e. registration, authentication, rating history, etc. But I will focus on how the different resources are managed in the implementation of the API presented in Table 3.1 for the banking scenario. The first resource is user. It represents the users registered in the system. Below we can see a user representation in JSON: { "user": { } "uid": 25, "username": "thanos", " ": "thanos@malkav.com", "password": "********", "gender": 1, "age": 28, "avgexpenseperyear": 2127, "socialclusterid": 9 } It gives information about its identifier (uid), account information (username, and password), the user profile attributes following the n-tuple (3.2): gender (1 for male or 0 for female), age (an integer value) and average expense per year in credit card transactions in euros. Moreover, the representation also stores the identifier of the social cluster assigned to the user obtained in the user s cluster discovery process (Figure 3.4, step 3). The second resource is rating. It represents the feedback a user can give about a place recommended. In the banking scenario the binary rating method was chosen, so for every place rated two possible values exist: like or dislike. An example of a JSON rating representation i ii

106 84 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS would be: { } "rating": { "rid": 6, "ownerid": 25, "iid": 1985, "value": 1 } It offers information about its identifier (rid), the identifier of the user who generated that rating (corresponding to his/her user id), the identifier of the item rated (iid) and the value given: 1 for like or -1 for dislike, being 0 the default value for an item recommended without any feedback. The third resource is item. In this scenario it represents the places. We can see the JSON representation below: { } "place": { "iid": 1985, "mcccategory": 5812, "name": "Subiendo Al Sur", "address": "Calle de Ponciano, 5", "postalcode": "28015", "townname": "Madrid", "latitude": " ", "longitude": " ", "avgprice": "2" } In this case the representation gives information about its identifier (iid), as well as the place details like name, address, coordinates and so on. Regarding the average price of the place, the banking entity provided a number between 1 and 3, being 1 the value corresponding to the cheaper places. Lastly, for the category attribute I used a subset of the Merchant Category Code i (MCC), a four-digit number to determine reportable payment card transactions assigned to a business by MasterCard or VISA when the business first starts accepting one of these cards as a form of i

107 3.4. IMPLEMENTATION 85 payment. It is used to classify the business by the type of goods or services it provides. For instance, the MCC 5812 that appears in the example corresponds to "Eating Places, Restaurants". Finally, though it is not a resource, when a user requests a recommendation through the REST API, the client application has to perform an HTTP request in which the contextual information is sent as parameters of the URL. An example of this kind of communication (Figure 3.4, steps 4, 5 and 6) would start with: GET /users/25/recommendation?time= t12:28:25&lat= & lng= &activity=walking&mcccategory=5812 HTTP/1.1 Headers: [Content-Type: application/json] [Authorization: Basic ZGdhbGxlZ286Z2FsYWN0dXM] The response would have the next structure: HTTP/ OK [Content-Type: application/json] { "placesrecommended":[ { "iid": 1985, "mcccategory": 5812, "name": "Subiendo Al Sur", "address": "Calle de Ponciano, 5", "postalcode": "28015", "townname": "Madrid", "latitude": " ", "longitude": " ", "avgprice": "2", "distance": 36, "people": 193 }, { "iid": 1703, "mcccategory": 5812, "name": "Restaurente SIAM", "address": "Calle San Bernardino, 6",

108 86 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS "postalcode": "28015", "townname": "Madrid", "latitude": " ", "longitude": " ", "avgprice": "2", "distance": 110, "people": 167 }, { "iid": 2108, "mcccategory": 5812, "name": "Rey de Tallarines", "address": "Calle de San Bernardino, 2", "postalcode": "28015", "townname": "Madrid", "latitude": " ", "longitude": " ", "avgprice": "1", "distance": 160, "people": 115 } ] } Mobile Client As regards the mobile client, I developed an Android i application targeted for smartphones and tablets. I chose it because it is an open platform that allows free distribution of applications outside Google Play ii. Thus, it was very easy to distribute the prototype among the bank clients that tested the system during the evaluation process (see section 3.5). The application allows banking clients to use the recommender system. The user profile needed to assign them to a social cluster is provided by Bankinter at registration time. Then the user can request a recommendation at any time by specifying only the place category wanted (e.g. restaurants or supermarkets). The rest of contextual parameters (time, position and activity) i ii

109 3.4. IMPLEMENTATION 87 Figure 3.5 : Smartphone and tablet mobile applications showing a restaurant recommendation. are automatically retrieved by the mobile application itself. The user activity is inferred by analyzing the velocity a user is changing his/her position over time: idle when the user does not change it, walking when the user is moving about 5 kilometers per hour and in transport when the user is moving faster. Hence, the application needs to retrieve the user position periodically. Figure 3.5 shows the application running on a smartphone and a tablet. The first one depicts the results for a restaurant recommendation requested at lunch time. It provides a ranking of restaurants (representing by the category icon that is used to represent the place in the map view), the distance from the current user location, the average price (representing the 1 to 3 scale by euro symbols) and the number of people in the user social cluster that have previously had lunch in that place. To allow user feedback of the places recommended, every item has a thumbs up and thumbs down button representing the "Like" and "Dislike" options. When the user presses any of these two buttons, his/her explicit rating is sent to the recommendation engine to be taken into account for future recommendations (step 7). I chose this feedback method considering the results provided by Sparling and Sen [Sparling 2011], in which they reported that a thumbs scale has highly acceptance by users when rating products.

110 88 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS 3.5 Evaluation and Results Description and Objectives To evaluate the system implemented, the application was deployed in a real environment belonging to our Spanish bank partner called Bankinter Labs i. It allows to test new researches and projects created in the bank in order to be able to collect feedback from a set of bank clients registered in this environment before launching them as commercial products. The objectives of the evaluation were two: First, evaluate the suitability of the social context generation process designed by applying the methods proposed to real banking data. Second, evaluate the user acceptance of real banking clients using the application during a period of time to check whether a mobile CARS based on social data is valuable for end users Demographics and Data Collection The data provided by Bankinter to create the social clusters consisted of more than 2.5 million credit card transactions made during the year 2010, providing information on 222,000 places and 34,000 anonymous customers profiles related to the previous transactions. Attending to the client profiles, 57% were men and 43% women. The age distribution was from 15 to 90 years old, with an average of 51.2 and a standard deviation of years old. Their expense in credit card payments per year was from a minimum of 0 to a maximum of 60,000 euros, with an average of 11,719 and a standard deviation of 12,521 euros. Finally, the transactions and places information analyzed were restricted to those made in Spain. As regards the user acceptance evaluation, I analyzed the feedback provided by 100 bank customers using an online survey available in Bankinter Labs in which they gave their impressions after testing the application in their daily life during several weeks Results Figure 3.6 illustrates the 11 social clusters emerged after the clustering process over the banking data. As we can see, the average credit card expense in one year, the average age and the size of every social cluster (given by the diameter of the circles) is shown. i

111 3.5. EVALUATION AND RESULTS 89 Figure 3.6 : Social clusters distribution by average expense in credit card per year, age and size. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 1 (strongly disagree) 2 (disagree) 3 (neutral) 4 (agree) 5 (strongly agree) Figure 3.7 : Application survey results.

112 90 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS For the user acceptance evaluation, in the online survey the test users were asked to judge several statements related to some properties of the recommender system using a Likert scale [Likert 1932], where the possible values goes from 1 (strongly disagree) to 5 (strongly agree). The statements were like this: "The application is [property evaluated]". Figure 3.7 shows the results. Finally, the users had free text inputs fields to make comments and annotations Discussion Analyzing first the distribution of customers along the social clusters depicted by Figure 3.6, the results confirm the intuition: the clusters with less people are the clusters who spent more money in credit card transactions because high economic class people are more infrequent than medium and lower economic class people. Whereas, the bigger clusters (those around the average expense calculated from the sample data) contain clients who spend less money and are composed by older people that are less used to pay with credit card than younger people (a situation that frequently occurs in Spain). The evaluation of the application deployed showed that users appreciate this kind of ubiquitous systems as they revealed overall a very positive attitude (see Figure 3.7) towards this system in which data from trust sources combined with mobile contextual information are used to increase the confidence in the recommendatios generated. This feature provides an essential advantage compared to other recommender systems which have the aforementioned problem of being based on non-reliable data. Attending to the way the system manages the explanations in our recommender system, it achieves some of the most important criteria set out by Tintarev and Masthoff in [Tintarev 2008]. Transparency (i.e. explain how the system works) is achieved due to the explanation provided for the places recommended: the application informs the user about how the recommendations have been generated considering the purchases of other bank customers similar to him/her. Regarding the reliable property, almost 90% of the users selected agree or strongly agree, supporting in this way the trust requisite (i.e. increase users confidence in the system). Effectiveness (i.e. help users make good decisions) and satisfaction (i.e. increase the ease of use or enjoyment) criteria were achieved if we consider the high values of the effective (41% agree and 13% strongly agree), useful (43% agree and 23% strongly agree) and user friendly (43% agree and 30% strongly agree) properties respectively evaluated in the survey (Figure 3.7).

113 3.6. CONTRIBUTION 91 The statistical outcome is also supported by the comments wrote by the test users during the survey process. Some of them were: "I like to have a recommender system in my smartphone available anywhere, anytime for searching this kind of places.", "I really trust in the results as they come from real purchases of my own bank" or "I will appreciate to have such a kind of application in my mobile phone in my daily life.". However, some of them remarked the privacy issues related to deploy this system into a real commercial exploitation with comments like "The system is really interesting, but I hope that the banking data are used in an aggregated way because I do not want to share my personal information.". As I have shown during this chapter, by using anonymous client profile data at the same time the back-end is isolated from the client side through the REST API, the privacy requirement is assure. Lastly, from the point of view of the banking entity, the extra value provided to its clients was essential as this application was an advantage in terms of market competition, because at the moment of carrying out this project in 2010/2011 none of the Spanish banks offered a similar service to their clients. It is also important to point out that using these banking data span across a wide domain range of recommendations categories, whereas most prior work on recommender systems tends to be more narrowly, often focused on a single product or a small set of them. Hence opportunities arise for cross-domain recommendations because of the richer social context that is possible to generate using banking data. 3.6 Contribution This chapter presents two research artifacts: a general architecture to create mobile CARS in scenarios with rich social data and the recommendation model behind it. I have explained the different elements involved in it, paying special attention to the recommendation model which utilizes social, location and user context information to generate personalized recommendations. This model is capable of analyzing social data without affecting the response time for a user requesting a recommendation because the social context generation process is separated from the other contextual dimensions analyzed, as it does not change so quickly over time as compared to ubiquitous properties. By taking advantage of this social context, the system avoids the cold start problem because it generates suggestions to a user without being needed an initial learning process as the items consumed in the past by similar users can be recommended since the beginning. The architecture takes into account the

114 92 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS possibility of using several social data sources to generate cross-domain recommendations without jeopardizing privacy. Additionally, it also provides a novel REST interface to request recommendations making the system independent from the client technologies and type of devices that use it. Details about the implementation of the architecture in the Perdidos en la Gran Ciudad research project are also provided in this chapter. I have described how it has been adapted to that scenario in which the social data source is the Spanish bank Bankinter. By providing examples of how the anonymized data is managed, as well as how the communication between the recommender engine and the clients is achieved through the API, I have presented a validation of the architecture proposed. As a result, the system described offers a mobile application for smartphones and tablets that allows banking clients to request recommendations on any kind of places (e.g. restaurants, supermarkets, shops, etc.) in which credit card payments have been done. It uses not only the social context information generated thanks to the data provided by the bank, but also contextual information extracted from the mobile application (i.e. time, category, user position and activity). In addition to this, the system is able to collect feedback on the places recommended to learn about the user s tastes in order to improve future recommendations. 3.7 Conclusions Considering that I have followed a design science methodology to contribute to the area of proactivity in mobile CARS, the architecture presented here can be seen as the first step of my research, as it is a good foundation to build mobile CARS in different recommendation scenarios. Actually, I have shown an innovative way of implementing it using current technologies (i.e. Android, Mahout, Spring, etc.) and the results from the user evaluation proved that these kind of systems are demanded by end users. In addition to this, if we keep in mind that users of these systems always have their mobile devices with them, the idea of enhancing the traditional user request-response pattern for recommending to become the system proactive is an interesting challenge. Does a user need to select the specific moment in time to be recommended or it can be selected by the system by analyzing the current user s situation and his/her necessities? Additionally, if we take into account that the current situation of a user might be obtained by analyzing contextual information, why not incorporating proactivity into the previous recommendation model which in

115 3.7. CONCLUSIONS 93 fact is context-awareness? If we attend to the general architecture proposed, it is valid for that proactive scenario because it is only required to modify the recommendation model (i.e. the recommender module in Figure 3.3), keeping the rest of the architecture as it is.

116 94 CHAPTER 3. AN ARCHITECTURE FOR SOCIAL MOBILE CARS

117 Chapter 4 A Model for Proactivity in Mobile CARS A proactive recommender system pushes recommendations to the user when the current situation seems appropriate, without the need for an explicit user request. This is conceivable in mobile scenarios in which rich contextual information is available to assess the current situation of users. In this chapter I will present a novel general model for proactivity in mobile context-aware recommender systems. The model relies on domain-dependent context modeling in several categories. The recommendation process is divided into two phases to first analyze the current situation and then examine the suitability of particular items. An example of the application of this model in the e-learning scenario is described to incorporate proactive recommendations in authoring tools. 4.1 Introduction If we try to simplify the purpose of recommender systems to its minimal expression, we may say that they are in charge of determining: 1. Which item(s) to recommend. 2. When to make a recommendation. 3. How to show a recommendation. As we have seen in chapter 2, the first point has been extensively studied and applied in numerous scenarios (ubiquitous or not) using different methods. In traditional recommender systems which follow a user request-response pattern, the second point is straightforward: they only recommend when a user makes an explicit request. Hence, the moment to recommend completely depends on the user decision, no matter what his/her current situation is. In the third point HCI issues take part. We will study these implications in the next chapter. On the other hand, attending to the challenges for mobile recommender systems reviewed in section 2.3.2, this kind of applications present some important differences such as small screen

118 96 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS devices that difficult users to browse through many recommendation results in an easy way. In mobile environments, having the user not to submit any request or query to get a recommendation could possibly improve the user experience. Proactivity means that the system pushes recommendations to the user when the current situation seems appropriate. Proactive recommender systems have to not only determine which item(s) to recommend, but also when to make a recommendation. In this chapter I propose a new model for mobile CARS that incorporates proactivity into the recommendation process. By integrating it into a traditional recommender system, the situation of a user can be assessed by analyzing contextual information to decide if a recommendation that may cover the user s needs is suitable. This chapter is organized as follows: section 4.2 describes the objectives of this dissertation covered by this contribution. Section 4.3 goes through the details of the general model proposed. In section 4.4 a possible application of the model to generate proactive recommendations in e- learning authoring tools is presented. Section 4.5 summarizes the main contribution in this chapter. Finally in section 4.6 I detail the conclusions drawn from the work and the new challenges opened. 4.2 Objectives This contribution provides a new model for proactivity in mobile CARS that is in line with the following objectives of this dissertation: To identify open challenges related to generating proactive recommendations in mobile context-aware recommender systems. This chapter shows the main issues that have to be considered when designing a model for proactivity in these systems. To propose a general model for proactivity in mobile context-aware recommender systems. As a result from the previous study, this contribution explains the functionalities achieved by the proposed model. This objectives can be divided into several tasks: 1. Design of a general model for proactivity that can be integrated in any traditional recommender system. Here I will explain the details of the model based on a contextual

119 4.3. DESIGN 97 modeling recommendation paradigm. It has been designed to be useful in scenarios where a traditional mobile recommender system is working. 2. Relationship between situation and items. The model proposes a relation function between the appropriateness of a situation and the suitability of the items to recommend. 3. Applicability. The model has been used to design a system for proactive recommendations in e-learning authoring tools in order to check its validity and usefulness. 4.3 Design To handle proactivity in mobile recommender systems, i.e. evaluate whether a recommendation is suitable in a given situation, I propose the following two-phase model (Figure 4.1). It analyzes the current context and calculates a score that determines not only the best item(s) in a given situation, but also whether the situation warrants a recommendation at all Challenges and Requirements Before designing the model to incorporate proactivity into mobile CARS, first I considered the following issues to be addressed: Generality. The model should be as general as possible to be integrated into any mobile CARS which already has the item recommendation logic implemented. Proactive and request-response recommendations supported. The model should support both recommendation paradigms in order to incorporate proactive recommendations without eliminating the user request-response approach. This is a key requirement in order to be possible of incorporating proactivity in existing mobile CARS. Relationship between situation and item appropriateness. The model should increase the suitability of items when the situation is more appropriate (and vice versa). Feedback. The model should provide feedback mechanisms to support a learning process about what situations are considered most suitable by the recommender system s users. Periodicity. The recommendation application using this model should be executed periodically in the background so as to assess the changing contextual situation of the user.

120 98 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS Figure 4.1 : Model for proactivity in mobile context-aware recommender systems Context Consider a general scenario similar to the one proposed in the last chapter, but this time adding proactivity: a mobile recommender system running on a smartphone suggests a place to the user when he/she is walking near the place that fits his/her preferences adequately, while also factoring in the time of the day and other contextual attributes. By taking also into account the context definition proposed by Dey [Dey 2001a], I utilized the following categories for the model design: User context, e.g. the current activity of the user such as "walking" as inferred from sensor data, but possibly also the state of the mobile device, e.g. "flight mode". Temporal context, e.g. current time. Geographical context, e.g. distance to available points of interest. Social context, e.g. whether the user is alone or not. In each of the categories, several context attributes can be modeled and utilized, although it is not mandatory to use all of them at the same time or in all the cases (i.e. it will be

121 4.3. DESIGN 99 scenario-dependent). In the model the attributes are evaluated using a score on a range from 0 to 1. The higher the score for a context attribute, the higher the indication that a proactive recommendation could be useful. For example, if the current time is right around when the user usually has lunch, the corresponding temporal context attribute will be close to 1. Each attribute is weighted depending on the relative importance of the parameter to the recommendation process. The context attributes and weights are domain-dependent and have to be predetermined or learned for each application scenario. In fact, the context categories can be others (with respect to the ones presented here) if we consider different application domains Process Overview Figure 4.1 illustrates the two-phase proactivity model. In the first phase, the system determines whether or not the current situation warrants a recommendation. The second phase deals with evaluating the candidate items. If one or more items are considered good enough in the current context in the second phase, the recommender system communicates it to the user. The first phase is executed periodically in the background or when relevant context attributes have changed, e.g. the user has moved according to the GPS or other sensors. The second phase is only executed when the first phase indicates a promising situation and the corresponding score exceeds a threshold. The point of time when the system displays the recommendation does not necessarily have to be immediately after the recommendation generation. For example, the notification of a recommended restaurant on the mobile device could be delayed until the user finishes his/her current application usage, e.g. ending a phone call Phase I: Situation Assessment This phase is in charge of answering the key question "When to make a recommendation?" To do so, the system calculates a score S1 which is a number between 0 and 1. Attending to Figure 4.1, it can have several outcomes based on the value of S1: If the current situation does not warrant a recommendation, no matter how high a particular item would score, S1 is set to 0 and the recommendation process is aborted without considering items for recommendation. For instance, a situation in which the user does not want to be interrupted and has set his/her device to "flight mode".

122 100 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS If S1 exceeds a threshold T 1, the second phase will be initiated. This will be the normal operation on the recommendation process. If S1 = 1, the highest possible value, then a recommendation will be triggered in any case. This could be used to "force" a recommendation, e.g. when the user is requesting it. Consequently, the model can be used to recommend not only in a proactive way, but also via traditional user request-response approach. Note that this phase does not take properties of single items into account, but does consider general properties of the set of candidate items (e.g. availability of restaurants in the vicinity as part of the geographic context). Furthermore, the score S1 has an impact on the threshold T 2 of the second phase: the higher S1 is, the lower T 2 is set. Therefore, the threshold T 2 is a function of S1 in the form: T 2 = 1 S1 (4.1) This means that when the situation is considered appropriate for a recommendation, S1 is high and it is more likely that at least one item score S2 in the second phase reaches the required threshold T 2, being such item recommended to the user. On the other hand, if the situation assessment leads to a mediocre score S1, phase II might still be initiated but only an extraordinary high rated item might score good enough to be recommended. Summarizing: the first phase can trigger an abort of the process, force a recommendation or yield to a score S1 between 0 and 1 that either initiates phase II or not, depending on the threshold T 1. The threshold T1 has to be configured a priori attending to the specific domain and can be adjusted afterwards according to user feedback Phase II: Item Assessment The second phase evaluates the suitability of particular items. To do so, any recommender algorithm based on predicted ratings can be used (e.g. collaborative filtering or content-based). This is a remarkable property of the model designed as the contextual dimensions involved can be used not only to assess the suitability of a situation for a proactive recommendation, but also to evaluate the candidate items to recommend. However, in the first phase the contextual information is used to define the situation, not the items, and therefore it is possible to integrate

123 4.3. DESIGN 101 this single phase in traditional recommender systems, corresponding the second phase to the item recommendation algorithm, which does not need to follow a context-aware recommendation paradigm. The result of phase II is a score S2 for each item in the candidate set. S2 represents the predicted rating of the recommendation algorithm selected. It is again a number normalized to [0,1], with S2 = 1 being the best possible score. An item can be immediately eliminated from the recommendation process (by setting S2 to 0) if for example a restaurant is closed at the moment of the recommendation. The candidate items will be ranked according to S2 and tested against the threshold T 2. If S2 > T 2 for an item, then that item is finally considered for recommendation and the user is notified. Depending on the application scenario, the best k items above the threshold will be displayed, but it would be managed by the user interface. If no item score S2 exceeds the threshold T 2, then no item is recommended, the process is aborted and restarted with phase I at the next configured interval. If the score S1 from the first phase is 1, the best-ranked item will be proposed in any case, since the threshold T 2 is 0. This phase allows for taking the suitability of particular items into account. For instance, if the time for lunch is not perfect (resulting in a lower score S1), but the user is walking by a really suitable restaurant (according to phase II), the system might still generate a recommendation for this restaurant despite the rather low S1. Apart from this, to determine the item score S2 it is possible to include a combination of contextual and non-contextual recommendation techniques in a hybrid approach (see section 2.1.3). In this case, the system calculates a ctx-score by evaluating the item against context attributes and categories, as explained above. In addition, if we for example follow a collaborative filtering approach, the algorithm predicts the rating of an item factoring in ratings of other users (cf-score). Then, the integration can be then done as follows using a linear combination with a weight ω: S2 = ω ctx-score + (1 ω) cf-score (4.2) with 0 ω 1

124 102 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS Of course, this is a general formula that can be used to combine two or more recommendation algorithms in order to answer the key question "Which item(s) to recommend?" User Feedback After the recommended items are communicated to the user, he/she can optionally give feedback on the recommendation. The feedback is a rating for an item that can be utilized when assessing the relevance of the item in phase II. In addition, the user can give feedback on the point in time of the recommendation to clarify its suitability (e.g. recommending during work time may be annoying). In this case, the feedback influences the thresholds T 1 and T 2: a negative feedback on the point in time results in higher thresholds and thus decreases the chance of a proactive recommendation in the future. Initial values for T 1 and T 2 have to be set by the system designer in advance, e.g. based on tests in the application area or in evaluations carried out with target users. 4.4 Application to E-Learning Authoring Tools Typical scenarios for applying the model proposed are those related to commerce, tourism, smart city guides, gas station recommendations, etc. In other words, scenarios in which places or points of interest are recommended and where the user s geographical position and his/her activity play an important role. However, different scenarios can be taken into account to show the adaptability and usefulness of the model. In this section I will explain how to use it to be applied in the e-learning domain to recommend proactively educational resources in mobile authoring tools Motivation A key question for an educator that wants to create a whole lesson or a Learning Object (LO) related to a specific topic is how to find the most suitable contents among all the resources available. In the area of e-learning, authoring tools can help educators to repurpose digitized resources or create complex LOs using existing contents from third-party learning repositories. An authoring tool can be defined as a software application that allows authors to create their own content and deliver it to the end users. As a general rule in the case of an e-learning authoring tool, the authors are teachers, the end users are students and the content is a learning resource

125 4.4. APPLICATION TO E-LEARNING AUTHORING TOOLS 103 created following a learning object content model (e.g. the LOM standard [Hodgins 2002]). These tools usually present an overwhelming variety of resources, causing a problem related to identifying what are the best ones considering the personal needs of the teacher. Whereas in previous approaches in the area of Technology Enhanced Learning (TEL), such as learning networks, this problem has been solved by using recommender systems [Fazeli 2012], in the authoring tool field the use of such kind of systems has not been exploited yet. Authoring tools usually do not take into account the teacher s background and current context while the LO creation process is carried out. Moreover, the recommendation should consider the history of the user in the current process so as to recommend similar resources or the suitability of these resources to be consumed in mobile devices. For these reasons, the application of a mobile CARS could improve the teacher experience because sometimes simple suggestions following a userrequest pattern are not enough when teachers do not know exactly what type of resources are available or when it is possible to request them in the creation process. In this scenario, a proactive recommender system can play an important role in the decision of which educational contents are more appropriate for a given situation. By analyzing context-awareness information related to the user s needs, like the topic of the LO (i.e. physics) or the target audience (i.e. students level for a school teacher), the system could suggest suitable resources without the need for an explicit user request. Therefore, the user would discover the resources at the same time as the requirements appear during the creation process. Bearing in mind the previous scenario, I present a new general model to achieve proactive context-aware recommendations in mobile e-learning authoring tools. It covers several use cases related to common situations involved in the use of authoring tools to create new LOs based on existing educational resources Scenario: Use Cases In order to maintain the generality of the model I consider the scenario illustrated in Figure 4.2. It consists of a teacher accessing to the online authoring tool with the aim of creating a new LO for his/her students about a certain field. The requirement of being online is considered due to the necessity of connecting the authoring tool to third-party educational content repositories, as

126 104 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS well as additional general content providers (e.g. YouTube i or Flicker ii ) that can provide valuable materials related to the topic the teacher is interested in. Although this is not mandatory (as several existing authoring tools do not work this way), I consider the integration of different online providers the best way of having access to a significant number of up to date learning resources so as to cover all the possible areas of knowledge, using not only specific educational contents but also any kind of multimedia resources available in non-specific learning platforms. Despite LOs can be used in learning authoring tools to create new and more complex ones forming a hierarchy [Noor 2011], from now on for simplicity and clarity I will use the term learning object (LO) to refer the result produced by using the authoring tool, whereas the general terms resource or content will refer to the materials provided by the educational content repositories or the general content providers (e.g. images, videos, audios, etc.) used to create the LO. The last module of our scenario is the recommender system. It is responsible of providing the proactive recommendations based on analyzing the current context-aware information retrieved from the user activity during the creation process in the authoring tool. Additionally, it has its own database to store information about what are the most common resources that have been historically utilized in the authoring tool by all the teachers using the system, so as to be able of knowing what are the most relevant contents related to every topic. Apart from this, in order to look for the candidate resources to be recommended, this module has connections with both, the third party educational repositories and the content providers. It is important to notice that no user profile or social information is needed about the user. The recommender only analyzes the current user s situation and the contents available in the different sources. It is clear that by including social or personal information about the users, the recommendations could be improved even more, but the scenario I propose here tries to be the most general possible in order to avoid including constraints such as being only valid for authoring tools supported by social learning communities. As a result, several uses cases can be considered to recommend proactively attending to its temporary nature from the point of view of the user utilizing the authoring tool: i ii

127 4.4. APPLICATION TO E-LEARNING AUTHORING TOOLS 105 Figure 4.2 : Scenario for recommending in mobile e-learning authoring tools. 1. Recommending when the user is starting the creation process. By allowing the user to provide initial input information (e.g topic keywords or students target level) at the beginning of the creation process, the system could show an early set of resources related to it. In this situation, the recommender can provide in a proactive way topic-oriented resources taking into account what have been consulted previously by people interested in the same topic, as well as the most relevant resources in that field. For example: a teacher that selects at the beginning of the creation process biology as the main topic and K-12 as his/her target students level could be provided with the most trendier materials used by other teachers of the system that have created K-12 LOs focused on biology. 2. Recommending while the user is creating the learning object. By learning in real time about the resources an educator is using during the creation process, the system could refine continuously the recommendations provided to decide if new proactive recommendations are suitable to support the LO creation. Following the last example, if the user concentrates the LO creation on the organs of the human body by choosing images about the heart and the

128 106 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS lungs, the recommender should be able of generating more accurate suggestions regarding that specific topic, providing resources (e.g. images) about the pancreas or the liver. 3. Recommending novel resources when reviewing or editing learning objects. The authoring tool could recommend brand new resources to improve a LO previously created or being in a draft state in order to allow educators to enhance them with novel learning contents. To conclude with our example, if our teacher reviews or edits in the future the human body organs LO created using the authoring tool, the system could recommend for example a new video published on YouTube or a new educational resource available in one of the repositories that has become relevant in the area because other users have recently utilized it intensively for their LOs associated to the same field. Finally, it is important to remark that the appropriateness for recommending proactively in each situation set out in these use cases should be real-time calculated to be aware of the level of interruptibility allowed by the user. Thus, the system should avoid disturbing the user if he/she is doing an important task Model Adaptation The adaptation of the general proactivity model (Figure 4.1) to the aforementioned scenario is presented in Figure 4.3. It relies on context-awareness information to generate proactive recommendations about educational resources in authoring tools. First, I will define what I mean by context in this scenario and then I will explain the different phases associated to the model proposed. Context This model is based on using the following context categories to recommend proactively relevant educational content related to the LO creation process the teacher carries out in the authoring tool: User context. The current activity of the user, e.g. idle or checking educational content like a video.

129 4.4. APPLICATION TO E-LEARNING AUTHORING TOOLS 107 Figure 4.3 : Model for generating proactive context-aware recommendations in e-learning authoring tools. Educational context. The information related to the educational resources the teacher needs for creating a new LO (e.g. topic, language, target age or target device). As we can see, contextual dimensions like social, geographical or temporal context are replaced by educational contextual information, more related to this specific e-learning scenario. Initial Input The model begins with an optional step consisting of providing initial input about the main educational context values related to the LO the teacher wants to create. The general topic (e.g. biology), the target level of his/her students (e.g years old), the language (e.g. English) or the target device where the LO will be consumed (e.g. mobile device) would be examples of this initial input information. Although it is frequently to have this initial setup in e-learning authoring tools (sometimes following metadata standards like LOM [Hodgins 2002]), not all of them present it when the LO creation process starts. That is the reason why I consider it to be optional. However, having such kind of data since the beginning would help the system to focus the recommendations sooner, achieving this way the Recommending when the user is starting the creation process use case. On the other hand, this initial input can be used also in the Recommending novel resources

130 108 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS when reviewing or editing learning objects use case presented before. When a teacher reviews a LO previously created or edits a LO in a draft state, all the resources used on it are considered to generate an initial educational context input. This allows the recommender to look for novel resources in the same area that did not exist or maybe were not considered relevant in the past. Resource Profiling This is the first step of the 3-phase loop illustrated in Figure 4.3. It is in charge of gathering all the metadata related to the resources used during the LO creation process in the authoring tool in order to answer the question What kind of content has been used?. This set of metadata conforms the educational context of the LO the teacher is creating. The more information the system knows about the resources the teacher is using in terms of topics (e.g. biology, human body or heart), resource types (e.g. image, audio or video), languages and so on, the more accurate would be the recommendations provided in the third phase. As a result the educational context is generated and sent to the next phases. Situation Assessment This phase tries to answer the question When to make a recommendation?. To do so the system calculates the score S1 which is tested against a threshold T 1 as it was explained in section Note that it does not take properties of resources into account (i.e. the educational context previously generated). However it considers the current user context represented by the teacher s activity in the authoring tool. For instance, a situation would be more appropriate for a proactive recommendation if the user is idle or is browsing resources in the system, compared to a situation in which the teacher is viewing a resource (e.g. a video) to decide if it is suitable or not for his/her interests. This appropriateness factor can be derived by the level of interruptibility allowed by the users in every situation involved in proactive systems (see section for more details). Hence, the system should avoid disturbing the user if he/she is focused on other important task. The contextual information related to the user is needed as a prerequisite to calculate S1. In the model, the user context is provided by the platform through the connections between the authoring tool and the recommender system (Figure 4.3). The specific parameters related to this user context are domain dependent, and have to be studied for each specific scenario. Finally, the relationship between T 2 and S1 remains the same, i.e. it follows (4.1). This way,

131 4.4. APPLICATION TO E-LEARNING AUTHORING TOOLS 109 when a situation is really appropriate for a user, it is easier to find a suitable educational resource to recommend. For instance, if the user is idle in the authoring tool, almost any recommendation related to the topic in study would be interesting for him/her as the system is not interrupting a user s task. Resource Assessment This step corresponds to the second phase of Figure 4.1. It evaluates the suitability of particular resources trying to answer the question Which resources to recommend?. To do so, any recommender algorithm based on predicted ratings that takes into account the educational context information provided is valid. For example, content-based filtering [Pazzani 2007] would be a good option because this algorithm recommends items that are similar to those that a user has utilized or liked in the past, or as in our case, has selected in the current LO creation process. This way, various candidate resources would be compared with other previously used by the user and the best-matching resources are recommended. This can be improved by adding the information store in the recommender data base (Figure 4.2) that allows the system to increase the weight of those resources that have been used intensively by other teachers, meaning their relevancy in that area of knowledge. The result must be a score S2 for each resource in the candidate set. S2 corresponds to the predicted rating of the recommendation algorithm selected according to the explained in section 4.3. The candidate resources would be ranked according to it and tested against the threshold T 2. Only those educational resources with S2 greater than T 2 would be considered for recommendation. If no resource score S2 exceeds the threshold T 2, then no one is recommended, the process is aborted and restarted when the condition to loop is met again. Loop After the recommended items are communicated to the teacher, he/she might select one of them or might not (i.e. by accepting or rejecting the recommendation). This occurs also with the resources the teacher looks for in the authoring tool (as they can be suitable or not for his/her interests). In Figure 4.3 this is represented by the loop linking the last phase with the first one. It takes into account all the resources (i.e. recommended and searched) to be evaluated by the used resources analyzer module. Each time a new resource is added to the LO the teacher is creating, the analyzer

132 110 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS fires a new loop that initiates the model again (as new resource information is available for the first phase). As a result, the Recommending while the user is creating the learning object use case is achieved because the loop is continually repeated while the previous condition is reached (i.e. a new resource is used for the LO creation). Discussion The model described presents several advantages to be implemented in traditional online e-learning authoring tools. The first one is a straightforward outcome: approaches for proactive recommendation in authoring tools have not been proposed yet. For a teacher this could be an important help when looking for educational content, as it would be the system the one in charge of suggesting resources without being needed an explicit user request. Moreover, the model has been designed for a general scenario to avoid complex requisites so as to be implemented in existing e-learning authoring tools. The recommender system works separately from the authoring tool. Hence only some communication between them are mandatory (i.e. to retrieve the context-aware information), but a full integration is not needed. This way, it could be possible to use a single recommender system to provide recommendations to several e-learning authoring tools at the same time, taking advantage of the information gathered in the recommender s database for all the users, no matter what authoring tool they are using. To do so, only a general API should be defined between the recommender system and the authoring tools, in order to use a standard communication protocol for sharing information, request/provide recommendations, etc. On the other hand, a limitation associated to the necessity of being online exists in order to allow accessing different content sources. Despite the fact that there are many commercial authoring tools in the market that work offline using their own local repositories, it is reasonable to bet on a near future all-connected because the majority of current platforms and applications tend to be online more and more due to the importance of Internet in our daily lives. Regarding the use cases initially proposed for recommending in authoring tools, I have shown that the model addresses all of them. But of course new use cases can be thought. Recommending when the user has finished the creation process could be for instance an interesting one: Think about a teacher that has just finished the design process of the LO. It could be good for him/her to be recommended about similar LOs previously created by other teachers in order to discover

133 4.5. CONTRIBUTION 111 different ways of explaining or focusing the same field so as to improve his/her own. Recovering the example I used above in this section, when our teacher has finished the LO about the organs of the human body, the system could suggest other LOs related to the human body like one about the circulatory or respiratory system. In fact, this idea is very common nowadays if we think about platforms like YouTube of SlideShare i in which once you have finished the view of a resource the system usually recommends you similar contents. To do it, the authoring tool would need a repository to store the LOs created by all its users in order to be analyzed by the recommender system. 4.5 Contribution This chapter proposes a novel model for proactivity in mobile context-aware recommender systems. The main idea is to first assess the current context of a user to determine whether a recommendation is warranted at a specific point of time. In the second step, the candidate items are examined to finally decide if the system should make a recommendation and which item to suggest. In other words, the model is designed to assess the current situation of an user to decide when to make a recommendation without the need for an explicit user request; being the second phase a general one in which several recommendation techniques can be used (contextual or not) to determine which item(s) to recommend. The model also defines a relationship between the appropriateness of a situation and the way the best items are finally chosen among the existing candidates: the more appropriate is a situation for a proactive suggestion, the more items will be considered suitable for the final recommendation as the user is more receptive to accept them. In addition to this, to allow the recommender system learns from the user behavior the best situations to recommend proactively, it also provides feedback mechanisms. Furthermore, the model has been designed to support both proactive and request-response recommendations, so as to allow its integration in existing traditional mobile CARS. To show the utility and flexibility of the general model proposed, I have adapted it to design a recommendation model for recommending proactively educational resources in mobile e-learning authoring tools. It addresses several use cases for achieving these kinds of recommendations i

134 112 CHAPTER 4. A MODEL FOR PROACTIVITY IN MOBILE CARS attending to the common necessities a teacher may have during the process of creating a new learning object while using an authoring tool. 4.6 Conclusions As a result of this work, a general model for proactivity is now available to be used in different recommendation scenarios. In fact, keeping in mind the results achieved in chapter 3, to add proactive recommendations to the architecture proposed (Figure 3.3) it is only needed to integrate both models into a single one. However, before doing that it is necessary to answer the third key question for recommender systems I laid out at the beginning of this chapter: "How to show a recommendation?". This reaches even more importance in proactive recommender systems as not only the moment in time to recommend is going to be crucial, but also the way the recommendations are notified to the user in the application. This key aspect encouraged me to study the impact of proactivity in mobile CARS in terms of user experience.

135 Chapter 5 Proactivity Impact in Mobile CARS User Experience In the previous chapter, I have shown how proactivity can be incorporated into mobile context-aware recommender systems in terms of recommendation model. Nevertheless, as the recommendation process is completely different from the traditional user request-response pattern it is necessary to investigate the impact of proactive recommendations in the user experience. Evaluating whether users would accept proactive recommendations, how to properly notify them and how to present recommended items are important research questions. In this chapter I present the scenario related to a context-aware restaurant recommender for mobile devices which follows the model proposed in chapter 4. Two solutions to achieve proactivity in mobile recommender systems have been designed, as well as the mobile user interfaces needed for visualizing the items recommended and allow users giving feedback on the recommendation process. Therefore, to study the impact of proactivity, in this chapter I analyze the results achieved after the evaluation of the mobile application developed among users through an A/B testing methodology which compares both proactive approaches. 5.1 Introduction The field of recommender systems sometimes suffers from being too much focused on improving algorithms and its accuracy for selecting the most suitable items to recommend, instead of attending to the user perspective and motivation to use such systems. During many years, researchers have underestimated the importance of the user experience (UX) when designing a recommender system. But an evolution from research concentrated purely on algorithms to research concentrated on the rich set of questions around the user experience with the recommender has recently appeared [Konstan 2012]. The way a user interacts with a system is most times even more important than having a recommendation algorithm capable of improving the accuracy of the recommendations generated. In fact, no matter how good is a recommendation method if the user does not feel comfortable

136 114 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE with the application, causing that he/she will not return. Although a recommendation could be perfect for a user (in terms of accuracy), additional important factors are involved in the acceptance process that a user carries out when using a recommender system. Miller [Miller 2005] says that every technology product and service has to be "focused on the user", in order to lead great experiences to users because aspects like design, accessibility or social issues can play a critical, and even primary, role in determining which products stand out. As a consequence, these ideas have been studied in the last years in the field (see section 2.1.5), demonstrating that aspects like explanations, user interface (UI) design or interruptibility (in proactive systems) are key factors that have to be taken into account when designing a recommender system. For that reason, if in the last chapter I focused on designing a recommendation model in charge of determining when to make a recommendation in a proactive way, as well as which item(s) to recommend; in this chapter I study how to show proactive recommendations in terms of UX in mobile CARS. Keeping in mind that proactivity in recommender systems is a really novel feature for common users, in this chapter I want to validate this concept by means of a system that offers proactive recommendations to them. To do so I evaluated among users a mobile application built following the proactivity model proposed in chapter 4. It offers two UI options to achieve proactivity, as well as a new UI to recommended items and allow for user feedback that combines list and map visualizations. The rest of the chapter is laid out as follows. First, section 5.2 shows the objectives of this contribution. Section 5.3 describes the design and implementation of the mobile application created following the proactivity model proposed in the last chapter. Section 5.4 presents the evaluation carried out among users utilizing the mobile application and the results obtained. Section 5.5 sets out the findings by discussing which of the two proactive solutions analyzed is the best, and how the result visualization is accomplished. Section 5.6 summarizes the contribution in this chapter. Finally, the last section provides some concluding remarks. 5.2 Objectives The UX study associated to this contribution addresses the following objective of this dissertation:

137 5.3. DESIGN AND IMPLEMENTATION OF THE MOBILE APPLICATION 115 To evaluate the impact and suitability of proactive recommendations in terms of user experience in these systems. This chapter provides the results of the evaluation among user performed to determine which one of the solutions proposed is the best way of recommending proactively in mobile CARS, along with its UX implications. The objective can be divided into several tasks: 1. Design novel user interface methods to generate proactive recommendations in mobile CARS. Here I will propose new ways of providing proactive recommendations to mobile CARS users. 2. Develop a mobile application following the previous design. I will summarize the main details of the Android application in which the proactive methods proposed have been implemented. 3. Empirical evaluation of the mobile application. I will provide a first validation of the proactivity methods proposed by evaluating the mobile application developed among users. 4. Outcomes of proactivity impact. By analyzing the results achieved, I will extract important outcomes associated to the use of proactivity in mobile CARS. 5.3 Design and Implementation of the Mobile Application Instead of developing the mobile application from scratch, I reused the one described in chapter 3 as the foundation to incorporate proactivity following the recommendation model proposed in chapter 4. Therefore I will provide first some design guidelines, as well as the scenario which motivated it. After that, I will describe how the proactivity is achieved in terms of UI through two possible solutions. Then I will explain how the result visualization of the items recommended is carried out Design Guidelines for Proactive Notifications Keeping in mind the models we reviewed for processing interruptions in section 2.4.2, I considered two design guidelines for proactive recommendations: 1. Recommendations must be announced with a notification that catches the user s attention and negotiates an interruption.

138 116 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE 2. Notifications are announcement stimulus and must not become interruptions by themselves. As proactive recommendations are context-aware, the same context information that is used to identify suitable items can be used to identify appropriate moments for the announcement. This way, notifications are driven by negotiation (i.e. the user should negotiate if he/she wants to be interrupted or not by the system) and mediation (i.e. the system takes advantages of contextual information to determine when and how the interruption should be presented). On the other hand, attending to the necessity of adapting the notifications to the user preferences (section 2.4.6), additional design guidelines were considered: 3. Different notification approaches must be available to allow the user chooses between more or less obtrusive solutions. 4. The notifications must include a method to let the user provides negative feedback that is incorporated into the user model for future proactive notifications Scenario To evaluate the impact of proactivity in the UX of mobile CARS I particularized the general scenario proposed in chapter 3 to the restaurant recommendation domain: A mobile restaurant guide running on a smartphone suggests a restaurant to the user when he/she is walking near the restaurant that fits his/her preferences adequately, while also factoring in the time of the day and other context attributes. I chose this domain for two reasons: firstly because in the field of mobile recommender system, recommending geo-located points of interest is a well-known use case and therefore it is easier to generalize the outcomes achieved. Secondly because using restaurants as items recommended is simple to understand for any user, making easier the recruitment of test users for the evaluation process Technological Decisions To develop the mobile recommender system I chose Android because it allowed me to test two different new ideas of having proactivity in mobile systems. As in the Perdidos en la Gran Ciudad project explained in chapter 3, I also considered Android because it is an open platform which

139 5.3. DESIGN AND IMPLEMENTATION OF THE MOBILE APPLICATION 117 allows free distribution of applications outside Google Play. Consequently, it facilitated me to distribute the application among the users who tested the system during its evaluation (see section 5.4). Attending to the ideas presented in chapter 3 for implementing the mobile clients, I designed the current Android application to be agnostic from the underlying recommendation logic. To achieve it an Android service is in charge of the communication with it. In Android, a service i is defined as an application component that can perform long-running operations in the background and does not provide a UI. This service is started when the application is installed and it will continue to run in the background even if the user switches to another application. The aim of this service is to periodically request a recommendation to the recommender engine following the architecture depicted in Figure 3.3 and the API described in Table 3.1. However, in this case the result of requesting a recommendation can be a "negative" response if the current situation is not appropriate for a proactive recommendation (when S1 < T 1 as we saw in the last chapter). On the other hand, when the current situation deserves a recommendation, the response would contain the recommended items (i.e. restaurants in this scenario) selected by the recommendation engine to be relevant in the current context. Consequently, the communication between the mobile application and the recommendation engine remains simple in order to avoid complex communication protocols. The recommendation logic is executed on the server side, while the mobile client is only in charge of informing the user about the available recommendations and presenting the results. In addition to this, in order to comply with the proactivity model (Figure 4.1) and the design guidelines mentioned above, the mobile application has to allow users two ways of providing feedback: Feedback on the time of the proactive recommendation: a "not now" option that will tell the system that the point in time selected for a proactive recommendation has not been considered appropriate by the user. Feedback on the recommended items: "like" or "dislike" options that will tell the system if the items recommended are considered suitable by the user. i

140 118 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE Finally, as regards the implementation of the application itself and taking advantage of previous developments, I evolved the mobile application for the banking scenario presented in chapter 3 to include the new features associated to proactivity, as well as some modifications to the existing UIs Mobile User Interfaces for Proactive Recommendations Status Bar Notification The first solution I proposed to offer proactivity is based on Android status bar notifications i. This type of "push" notifications adds an icon to the Android system s status bar with a tickertext message (Figure 5.1a) informing the user about an event generated by one of the applications installed. When the notification is expanded by a drag down action, a detailed message in the notification drawer is shown (Figure 5.1b) with more information about the event. Furthermore, in order to help the user noticing the new recommendations available, I added sound and vibration to this recommendation notification. According to the notification cues classification presented in section 2.4.4, these status bar messages are a combination of the following notifications: Visual: there is a minor change in the screen (as it corresponds to a small zone of the whole mobile device screen). Acoustic: the user hears a sound produced by the notification. Tactile: the user feels the vibration produced by the notification. Attending to the application screenshot which Figure 5.1b illustrates, the notification informs the user about the temporal category of the restaurant recommendation. To do this we have defined four types (i.e. breakfast, lunch, snack/tea and dinner) corresponding to the different restaurant recommendations that can be generated during a day. This is temporal context on our model. Apart from this, to improve the application usability, a color code is used to identify every type in order to let the user be aware of the recommendation just with a glimpse. I use orange (breakfast), i

141 5.3. DESIGN AND IMPLEMENTATION OF THE MOBILE APPLICATION 119 Figure 5.1 : Proactive user interface based on status bar notification. Notification icon and message in the status bar (a), and expanded notification (b). green (lunch), blue (snack/tea) and violet (dinner) colors. This makes it easier for the users to associate every color to every type of recommendation. The notification also provides the number of places that are recommended at this time. Then, with one click the user can reject the proactive recommendation by pressing the "Not now" button, or accepting it by pressing the button of the category ("Lunch" in Figure 5.1). With these actions the system collects user feedback to discover if the point of time to generate recommendations has been appropriate or not. This information is sent to the recommendation engine to be taken into account for future recommendations as I explained in chapter 4. Finally, when the status bar notifications are not expanded by the user, they may disappear or change due to new context conditions, acting in a dynamic way.

142 120 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE Figure 5.2 : Proactive user interface based on widgets. Widget Notification The second solution for proactive recommendation I proposed is based on Android app widgets i. A widget is a miniature application view that can be embedded in other applications such as the Home screen of the mobile device (this is our case) and receive periodic updates. These updates are provided by a service running in the background like the one explained above. On the contrary to the status bar notifications, widgets were not conceived in Android to notify the user per se. Notifications in mobile devices are usually strong attached to acoustic and tactile stimuli. For that reason I wanted to compare both solutions taking into account that attending to the notification cues classification presented in section 2.4.4, widget notifications are based only on visual stimuli because every time a new notification is available there is a significant change i

143 5.3. DESIGN AND IMPLEMENTATION OF THE MOBILE APPLICATION 121 in the home screen: a widget takes up a bigger space in the screen than a status bar notification, meaning that the user is more aware of changes on it regarding visual inputs. Figure 5.2 shows a screenshot for a lunch recommendation following a widget notification. The widget is always active in the Android device s home screen so as to inform the user anytime he/she unlocks his/her smartphone, noticing this way if a recommendation has been generated by the system since the last time the user saw the home screen. In order to maintain the usability as much equal as possible, I used the same buttons and color code as in the status bar approach to design the notification information, allowing the user to see the results from the recommendation by pressing the type button or rejecting the recommendation by pressing the "Not now" button to inform the system that the time chosen for the proactive recommendation is not desirable for his/her. Again, this feedback information is sent to the recommendation engine to be considered for future recommendations. Finally, if the user does not interact with the widget and the context changes (e.g. the lunch time is over), the widget does not notify any recommendation until a new one is considered suitable by the system in the current situation, keeping that in such situation the user does not interact with the system (i.e. implicit user feedback) User Interfaces for Visualizing Recommended Items Ranking The first view the user sees when the recommendation button is pressed in any of the two proactive options presented ("Lunch" in both screenshots) is the one shown by Figure 5.3a. This list-view shows the items ordered by a ranking criterion that is based on a combination of the different places attributes (e.g. distance to current user s position or average price) and the current context. This is done by the recommender system in the second phase of the proactivity model (Figure 4.1) according to the score S2 calculated for every item. Every element of the list has a cuisine category map icon that represents its cuisine attribute bearing in mind the type of food offered (e.g. cafe, bar or pizzeria). This icon is then used to represent the place in the map view (Figure 5.4) in order to make it easier for the user to localize every restaurant. Additionally, every element has a brief description of the most important details related to it (i.e. name, distance and average price). Furthermore, to allow user feedback related to the place recommendation, every item has a

144 122 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE Figure 5.3 : Ranking user interface: initial view (a) and after giving feedback (b). thumbs up and thumbs down button representing the "Like" and "Dislike" options. When the user presses any of these two buttons, his/her explicit rating is stored in the recommendation engine to be taken into account for future recommendations. As I explained in chapter 3, I chose this feedback method considering the results provided by Sparling and Sen [Sparling 2011], in which they reported that a thumbs scale has highly acceptance by users rating products. Moreover, I added a new feature in this ranking view compare to the mobile application described in chapter 3. By pressing the "Like" button the corresponding item rises in the ranking dynamically, whereas by pressing the "Dislike" button the place disappears from the list and a new item is added (if there are more items available in the list generated by the recommender). An example of this situation is illustrated in Figure 5.3. In Figure 5.3a the user likes the Hofbräuhaus bar and dislikes the Dallmayr cafe for having lunch. As a result, in Figure 5.3b the

145 5.3. DESIGN AND IMPLEMENTATION OF THE MOBILE APPLICATION 123 Figure 5.4 : Map user interface: map visualization (a) and place details (b). Hofbräuhaus raises to the first place of the ranking and a new place (Berni s Pizzeria) appears to replace the disliked one. This user s preferences are also communicated to the recommender system in order to take this information into account in future recommendations. Map Once the user has given feedback that may influence the ranking provided by the recommender engine, by pressing the map button shown in Figure 5.3, the map view illustrated in Figure 5.4a appears. It is in charge of representing the different restaurants selected by the user in the ranking view. To do so, I integrated Google Maps in the application to localize the places in a map, as well as to have the possibility of creating routes from the user s current location to any of the places. The map icons are the same as in the ranking view to represent the restaurants easily.

146 124 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE The current user location is represented by an Android icon that can be personalized using other images. Finally, Figure 5.4b shows the detailed information that it is shown when a user presses one of the restaurant icons. The idea of combining the ranking and map visualization to represent the items recommended was based on the results provided by Averjanova et al. [Averjanova 2008]. They demonstrated with a user study that a map-based interface is more effective than a list-based interface (which is typically used in recommender systems) to select a specific item. On the one hand, the ranking visualization (list-based) is a clearer and quicker way of allowing users giving feedback because the users can see all the items recommended without being necessary a navigation across the map. On the other hand, the map view shows, among others, the geographical details of the recommendation as regards the user location, which is probably one of the most important factors to make a final decision when choosing a restaurant in the surrounding. This way, I separated the feedback process from the item selection process, taking as a result the advantages of both solutions. 5.4 Evaluation and Results Description and Objectives To evaluate several UX factors related to use the mobile application described above I designed a user evaluation with two parts. The objective of the first one was focused on comparing the widget solution with the status bar notification interface so as to determine which of both proactive approaches was considered the best by users. The second part aimed to analyze the result visualization and the recommendation feedback process, in order to check if the combination of list and map-based UIs, as well as the feedback methods, were accepted by users. This was done by collecting subjective measures of the UX perceived by participants in an online survey that presented some scenarios related to the usage of the mobile application. These scenarios describe daily situations in which the users could need a restaurant recommendation. Apart from letting the users test the application itself, in the survey the scenarios illustrated by Table 5.1 had also screenshots and enough previous information about the UIs usability to understand them properly. Following an A/B testing methodology [Dixon 2011], I split up randomly the test users into

147 5.4. EVALUATION AND RESULTS 125 Table 5.1 : Survey scenarios for proactive resturant recommendations. ID S1 S2 S3 S4 S5 S6 Description On the way from home to work in the morning. You have not had breakfast and a recommendation is available. Like the scenario S1, but you have had breakfast at home. On the way from work to home during the evening. You are not in a hurry and a recommendation is available. Like scenario S3, but you are in a hurry to arrive home. At your hotel during a business trip. It is lunch time, the day is rainy and you have not had lunch when a recommendation is available. On a tourist weekend walking during the lunch time along the street. You have not had lunch and a recommendation is available. two test groups: the α users evaluated first the status bar notifications and then the widget-based solution. While for the β users the evaluation order was inverse (first widget, then status bar). This was done to compensate any learning effect, i.e. users opinion about the status bar notification could be better or worst depending on if they have evaluated before the widget-based solution or not Demographics and Data Collection Of the 87 people who began the survey through a publicly available website during the month of July 2011, 58 completed it. The test subjects were recruited from two different contexts via following a snowball sampling technique [Goodman 1961]. The first one was composed by people (i.e. professors and PhDs students) from computer science and engineering departments at the Universidad Politécnica de Madrid and the Technische Universität München. The second group was composed by people from a Spanish theater group not related to the university or technological issues in order to achieve different ways of thinking. Both groups did not have any experience with the scenarios and the research topic in advance, so as to collect unbiased responses. The majority (72%) was male, and

148 126 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE Table 5.2 : Scenarios responses for the status bar notification. ID Group Ignore (%) Not now (%) Expand (%) S1 α β S2 α β S3 α β S4 α β S5 α β S6 α β the age distribution of the subjects was from 22 to 58 years old, with an average of 29.73, a median of 27.5, a mode of 26 and a standard deviation of In addition, 76% of them owned a smartphone (e.g. Samsung Galaxy S, Nexus One, iphone, etc.) and asked about how often did they check the device for notifications or updates, 23% said "several times per hour", 40% said "every hour", 28% said "several times per day" and 9% said "few times per day" Results Status Bar Notifications The scenarios in Table 5.1 were the same for both options (status bar and widget), but in the online survey the detailed scenario descriptions related to status bar notifications were adapted considering that the users were aware of the notifications by a vibration and a sound produced by their smartphones, as we explained in section Table 5.2 shows the evaluation subjects answers taking into account the two groups I mentioned before (α and β). The possible responses for these scenarios were: Ignore (i.e. ignore the notification), Not now (i.e. expand the status bar notification and press the "Not now" button) and Expand (i.e. expand the status bar notification and consult the recommendation details). After that, the test users were asked to judge some UX properties related to the solution provided (i.e. convenient, desirable, efficient, useful and user friendly), using a 5-point Likert

149 5.4. EVALUATION AND RESULTS % 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 1 (strongly disagree) 2 (disagree) 3 (neutral) 4 (agree) 5 (strongly agree) Figure 5.5 : Evaluation results of status bar notification. scale [Likert 1932], where 1 means strongly disagree and 5 strongly agree. illustrated in Figure 5.5, separated for α and β groups. The results are Widget Notifications Using the same scenarios described in Table 5.1 but this time adapted to the widget-solution in which the users notice the recommendations by seeing the widget when they are, for instance, checking their or calling someone; we can see in Table 5.3 the subject s responses. Again, the possible answers were: Ignore (i.e. ignore the widget), Not now (i.e. press the "Not now" button) and Expand (i.e. press the type button to expand the recommendation details). Then the test users were asked to judge some properties related to the solution provided using the same Likert scale as in the previous proactive solution. The results are illustrated in Figure 5.6. User s Assessments in Comparing both Solutions In addition to the individual evaluation of both solutions previously described, I included in the survey a section focused on comparing them in a direct way. To do so, the test users were asked

150 128 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE Table 5.3 : Scenarios responses for the widget notification. ID Group Ignore (%) Not now (%) Expand (%) S1 α β S2 α β S3 α β S4 α β S5 α β S6 α β to judge some statements related to compare both solutions using a 5-point Likert scale, where 1 means totally disagree and 5 totally agree. In this case, and considering that the results from α and β groups were very similar, I have aggregated the statistical results in Table 5.4 and the graphical results of users opinions in one bar chart (Figure 5.7) for clarity. For calculating the P-values as a result of the test of significance, I have considered as the null hypothesis (H 0 ) that there is no difference between the widget and the status bar notifications. On the other hand, as alternative hypothesis (H a ) I have considered for each case the statement illustrated in the first column of Table 5.4. Taking into account that for tests about a population mean from a population with a normal distribution or for any sample with large sample size (i.e. n > 30 for which the sample mean will follow a normal distribution by the Central Limit Theorem), if the standard deviation (σ) is known, the appropriate significance test is the z-test, where the test statistic is defined as: z = x µ 0 σ n (5.1) Then, considering the Likert scale an interval data type with µ 0 = 3, meaning that there is no difference between widget and status bar (i.e. Ho), the p-values shown in Table 5.4 can be calculated as P(Z > z) for H a.

151 5.4. EVALUATION AND RESULTS % 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 1 (strongly disagree) 2 (disagree) 3 (neutral) 4 (agree) 5 (strongly agree) Figure 5.6 : Evaluation results of widget notification. Table 5.4 : Statistics related to the comparison between widget (W) and status bar (SB) notifications. Feature evaluated Mean Median Std. Deviation P-value W more easy to use than SB W less annoying than SB W saves more time/clicks than SB W more comfortable than SB Overall, W better than SB Recommended Item Visualization For the second part of the survey focused on the visualization of the recommended items and the user feedback related to them, I assumed that the users wanted to see a "Lunch" recommendation (like the one shown in Figure 5.1 and 5.2). Bearing this in mind, the subjects were asked about their user experience related to the ranking (Figure 5.3) and map (Figure 5.4) recommendation interfaces. On the one hand, in the ranking view (Figure 5.3) the users were asked to assess first the use of the "Like" and "Dislike" buttons as a feedback method about the items recommended. 86% of

152 130 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% W more easy to use than SB W less annoying than SB W saves more time/clicks than SB W more comfortable than SB Overall, W better than SB 1 (totally disagree) 2 (disagree) 3 (similar) 4 (agree) 5 (totally agree) Figure 5.7 : Comparison between widget (W) and status bar (SB) notifications. participants answered that their functionality is intuitive and it is also a good way to give feedback about the results. While 11% preferred to have only the "Like" button and 3% preferred to have only the "Dislike" one. As regards the map category icons, 86% of users supported that they are a good way to know quickly which kind of cuisine category corresponds to every place, making easy to find the place in the map view. 9% preferred the use of text format instead of icons to show the type of cuisine (e.g. bar, pizzeria, etc.) and 5% did not like to know about the cuisine information in this view. Furthermore, the users were asked about the quantity of information provided in every recommended item in the ranking view. 60% liked the current way this is achieved. However, 14% thought that it was too much information and 26% thought that is was too few. Finally, the test users were asked to judge the previous set of UX properties (i.e. convenient, desirable, efficient, useful and user friendly) using the same Likert scale. Figure 5.8 illustrates the results for the ranking visualization UI. On the other hand, regarding the map view (Figure 5.4), the users were asked about the way of representing the items recommended. 67% of them thought that it is a perfect way to understand

153 5.5. DISCUSSION % 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Convenient Desirable Effective Useful User friendly 1 (strongly disagree) 2 (disagree) 3 (neutral) 4 (agree) 5 (strongly agree) Figure 5.8 : Evaluation results of ranking recommendation visualization. easily what and where the places shown by the ranking view are and also, consult their details by just clicking on them. 23% considered it good, but too simple and 10% considered it poor, needing a redesign to improve it. To conclude, Figure 5.9 shows the results provided by the test users after assessing the map visualization UI referred to the same UX properties mentioned above. 5.5 Discussion Limitations of the Study One of the most important limitations of this study could be that I designed the mobile application only for Android. This could lead us to think that the results achieved might not be general for mobile users. But attending to the results of the first quarter of 2013 corresponding to the worldwide smartphone market share by operating system provided by Gartner [Gartner 2013a], Android has a 74.4%, ios a 18.2%, BlackBerry a 3% and Windows a 2.9%, corresponding to others only a 1.6% of market share. Consequently, the propagation of Android is relevant enough to consider valuable the results obtained. Apart from this, after the elaboration of this research Apple launched notifications and limited

154 132 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Convenient Desirable Effective Useful User friendly 1 (strongly disagree) 2 (disagree) 3 (neutral) 4 (agree) 5 (strongly agree) Figure 5.9 : Evaluation results of map recommendation visualization. widgets (available since ios 5). This would allow us to apply the same proactivity methods presented here to the most extended smartphone platforms (i.e. Android and ios), which is a representative number of the worldwide smartphone population as we have seen. On the other hand, it can be also thought that having only 58 test subjects for a user evaluation is a small number. Nevertheless, attending to the results described by Nielsen [Nielsen 2006], when collecting usability metrics, testing 20 users typically offers a reasonably tight confidence interval. Therefore the sample was appropriate for a quantitative study Proactivity Impact Starting with the results related to the two proactive mobile UIs proposed, first of all I am going to analyze the users responses in the different scenarios. Table 5.2 and 5.3 show that in the scenario 1 the majority of the users (71% in the worst case) would have interacted with the system (i.e. they chose the "Not now" or "Expand" responses). Although not everyone wanted to know the recommendation available, at least they gave temporal feedback with the "Not now" button. This is an important factor that leads the system to learn about user s habits and improve the proactivity property. In the scenario 2, the "Expand" rate decreases compare to the scenario 1. This confirms

155 5.5. DISCUSSION 133 the intuitive hypothesis in which users do not want to see the recommendation details when they do not need it. In scenario 3, I found that when users were not in a hurry, the majority of them consulted the recommendation (between 54% and 65%). On the contrary, when the users were in a hurry (scenario 4) the majority (between 50 and 65%) of them decided to ignore the application without significant differences between status bar and widget results. As a conclusion we can state that the time pressure factor (that may be derived from the user context) is a good indicator to know when a proactive recommendation is reasonable or not, because in these situations users give less feedback. In scenarios 5 and 6, the users mainly (between 82% and 96%) checked the recommendation available without remarkable differences if the scenario was related to a tourist or a business situation. Thus, we can state that both proactive recommender methods work in the same way with typical scenarios already tested in traditional non-proactive recommender systems. Finally, one of the most important outcomes of this research is that the widget notification is considered a better way to achieve proactivity compared to the status bar-based solution. I am going to explain this result in more detail. Figure 5.5 shows the first indication based on the different results gave by α and β groups. Users who evaluated first the widget notification (β group) gave a lower mark in average to the status bar method compare with the users that evaluated it first (α group). This means that when users evaluated the status bar method after having evaluated the widget method, their perception about the status bar solution was worse. In addition, if we analyze Figure 5.6, the results are quite similar: the α subjects scored with better marks the widget notification in the "effective", "useful" and "user friendly" properties, despite being tested before the status bar option. Secondly, if we study now the results illustrated by Table 5.4 and Figure 5.7, we can see that when both solutions are directly compared, the widget proactive notification has a better qualification in all the statements that were evaluated. First, all the average scores are above 3 (i.e. "similar"). Moreover, the median values corresponding to the features two, three, four and five can be noted because they mean that at least half of the sample study subjects consider better the widget-based solution because they are above average. There is another unequivocally result attending to Figure 5.7 which confirms that the users considered the widget notification a better solution to achieve proactivity compared to the status bar: the users agree (41%) or totally agree

156 134 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE (9%) with the statement "Overall, the W is better than the SB", whereas only 18% disagree and 10% totally disagree with it. To conclude this point, we can also confirm that these results are statistically significant because attending to the p-values obtained (Table 5.4), the null hypothesis can be confidently rejected in favor of the alternative hypothesis in all the statements evaluated: The p-values are less than 1% of significance level in all the cases except for the last one, which is only less than 10% (that is still an acceptable grade of significance). This statistical outcome can be also supported if we pay attention to some of the comments the test users wrote in the survey free text inputs during the evaluation process. For example: "I personally prefer the widget application because I don t like apps that put themselves in the notification area.", "The crucial difference between the two interfaces is that a status bar notification can be more annoying." or "Status bar notifications are more proactive but maybe more annoying.. As we can see, despite the status bar notification is considered a good method to achieve proactivity (as we have demonstrated by comparing Tables 5.2 and 5.3), the problem of being a more annoying solution was crucial when users had to choose between one of them regarding UX issues. To conclude the discussion related to proactivity, a last comment has to be made if we keep in mind the information provided by the test users on their smartphone checking habit. Despite the fact that the widget solution is considered better, if only 63% of users check their smartphones within a period of an hour, this may be against the widget solution, as it depends on the checking behavior to inform them about the proactive recommendations available. Users checking their devices only several or few times per day might lose some of the widget recommendations due to a context change as this solution does not interrupt the user. Nevertheless, I think that the rapid evolution and spreading of smartphones in our society in conjunction with the grow of high-attention-demanding applications, like social networks, is causing that people are every day more and more aware of checking their smartphones continually. This would avoid the previous problem when using widget proactive notifications. This is in line with the smartphone usage results provided by Falaki et al. [Falaki 2010] in which they show that users interact with their phones times a day on average. Or the recent results provided by Oulasvirta et al. [Oulasvirta 2012] in which they conclude that checking habits are particularly characteristic of smartphone usage because they are use most of times to check something or to acquire the stimulus for diversion or entertainment in dynamic content portals (e.g. Facebook).

157 5.5. DISCUSSION Recommendations Visualization If we analyze first the results associated to the ranking visualization, we can see that the majority of users were mainly satisfied with the way the recommended places are presented. The use of the "Like" and "Dislike" buttons, a well know paradigm of user experience in the Social Web for rating (e.g. YouTube), was easy to understand by users. Their functionality as a feedback method related to a recommender system was also understood intuitively by them, confirming the results provided by Sparling and Sen [Sparling 2011] that lead me to use it. In this way, some of the users comments emphasized these kinds of social features as an important factor to decide which place to go. For example, one participant commented: "It would be interesting to have some information about other users opinions, for example a karma mechanism". Therefore, apart from utilizing these ratings to let the system learn the user s tastes, it could be interesting to show other users ratings within the item description currently shown so as to let the target user be aware of how similar users have rated it in the past. As regards the use of the map category icons and its relation with the map visualization, the majority of users supported this solution, but some of them said: "I would like to know what the rank of each place in the map view is. Perhaps, using a color scale, different sizes or attaching a number to the icon could be good solutions". This is a good feature that should be included in future versions. Another significant outcome achieved related to the map visualization is that despite users considered it a useful way of visualizing recommendations, some of them recommend us to work on a more sophisticated interfaces with features like the previous one described. This may be cause because the map interface designed is in line with current utilization in other mobile application, and thus users demand novel usability map-based paradigms. Last but not least, a great majority of test users liked the application look and feel. As mentioned before, design can play a critical, and even primary, role in determining which products stand out [Miller 2005]. In this case it is an important factor to avoid losing users after a first contact with the application because of a bad user experience. The system needs from users a long experience with it so as to learn their behaviors and tastes to personalize the recommendations as much as possible. Therefore, that feature is currently achieved by the application according to the high scores achieved in the "user friendly" property evaluated (see Figures 5.8 and 5.9).

158 136 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE 5.6 Contribution In this chapter I have proposed two novel ways of using current mobile user interfaces (i.e. widget and status bar notifications) to achieve proactivity in mobile CARS which can be implemented in popular mobile platforms. I have validated these methods in terms of user experience by evaluating their impact and acceptance among 58 users utilizing an Android mobile application which implements both. The results have shown that the widget notification is better than the status bar notification. Despite the fact that both mobile solutions are considered good to achieve proactivity, the second one is considered by the users more annoying as regards user experience. The results have also shown three significant outcomes for the field of proactivity: Proactive recommendations are not consumed when users do not need them (like in the case of non-proactive ones), but at least users normally give feedback about their active rejection in these situations. As a result, in proactive scenarios it is possible to gather better feedback on users behavior. Time pressure situations lead to poor user feedback on the proactive recommendations received, i.e. the majority of users ignore them. In consequence, this factor has proved to be important information related to the user context for proactivity. In favorable situations corresponding to traditional user request-response recommendation scenarios, proactive recommendations have also high acceptance. Thus, proactivity can be used in conjunction with user request-response recommendations without diminishing the user acceptance; a feature which the model I propose addresses (refer to chapter chapter:proactivity-model). As regards the results related to the user experience, they suggest that the combination of the ranking and map visualizations are useful and efficient for users. Moreover, users approved the "Like"/"Dislike" scale to provide feedback about the items recommended, as they consider it intuitive and easy to use. Therefore, the combination of these visualization methods has shown to be a good choice for mobile CARS recommending geographical points of interests.

159 5.7. CONCLUSIONS Conclusions As a result of this work, the three key questions related to design a proactive mobile CARS I set out previously have been answered, i.e. when, which and how to recommend. The proactivity model proposed in chapter 4 addresses the first two issues, while in this chapter I have investigated the last one. Actually, although the widget notification has been considered better by users, the idea of combining both could be the best choice in a real commercial exploitation of these ideas. For example, it would be completely viable to integrate these methods in the banking mobile recommender system described in chapter 3. Even more if we take into account that the mobile application explained in this chapter is an evolution of that mobile client. Therefore, by using the widget notification for low suitable situations (i.e. when S1 is only a bit higher than T 1) and the status bar notification only in high suitable ones (i.e. when S1 is quite higher than T 1), we could merge the advantages of both solutions into a single one: the user would be interrupted with status bar notifications only when the situation is really appropriate for a proactive recommendation, using the less annoying widget solution for the rest of the cases. As a consequence of the results achieved here, a new important research question comes out. We have observed that the situation appropriateness depends on several contextual aspects (e.g. when a user is in a hurry or busy). Thus, research on defining a user context model for proactive scenarios in ubiquitous systems is suitable, as well as defining methods to calculate such appropriateness for specific situations.

160 138 CHAPTER 5. PROACTIVITY IMPACT IN MOBILE CARS USER EXPERIENCE

161 Chapter 6 Methods to Incorporate Proactivity into Mobile CARS In this chapter I present methods to incorporate proactivity in mobile context-aware recommender systems by proposing a new recommendation model designed as a combination of the models proposed in chapters 3 and 4. Details about how the appropriateness of a situation can be calculated are provided. Furthermore, this chapter explains how to perform the final decision on the items to suggest in a proactive recommendation. To validate this approach and generate a user context model valuable for other researchers investigating proactivity, I also show results from the application of these methods into a social learning network scenario related to a European project in which their validity, as well as the factors influencing the appropriateness calculation have been evaluated among users. 6.1 Introduction During this dissertation I have presented different contributions starting with a general architecture for building mobile CARS (chapter 3), following with a novel model for proactivity in these systems (chapter 4) and concluding in the previous chapter with a study about the impact of proactive recommendations in the user experience. Therefore, this chapter presents a combination of the previous contributions and the methods needed to do so in order to build a proactive mobile CARS and validated it on a real scenario. In this chapter I present the details of applying all these ideas in the e-learning field as part of the real educational platform called Virtual Science Hub related to the GLOBAL excursion European project. It is focused on knowledge sharing among teachers and scientists. In this platform the aim of the recommender system is to generate proactive context-aware recommendations of both educational learning objects and peers so as to help teachers to build enhance educational material for their students. To facilitate the understanding of the methods and solutions proposed to develop a proactive mobile CARS, I will use this scenario as the common thread of this chapter. For each phase of

162 140 CHAPTER 6. METHODS TO INCORPORATE PROACTIVITY INTO MOBILE CARS the recommendation process I will describe first the general methods and then how they have been applied and evaluated in the context of the Virtual Science Hub scenario, paying special attention to how the appropriateness of a situation is calculated to decide if it warrants a proactive recommendation. As a result, the structure of this chapter is the following: section 6.2 describes the objectives of this contribution. Section 6.3 presents the new recommendation model resulting from the combination of the models proposed during this dissertation. Section 6.4 describes the Virtual Science Hub scenario and the challenges related to it are described to understand the decisions taken. In the following three sections, the different general methods designed for each phase are detailed, and the results from the evaluations carried out after applying them to the real scenario presented. The outcomes achieved are discussed in section 6.8. Then, section 6.9 provides examples of how the previous outcomes have influenced the way proactive recommendations are displayed in the system developed for the learning scenario. Section 6.10 reviews the main contributions in this chapter. Finally in section 6.11 I conclude the validation of the contributions proposed by encouraging other researchers to try my outcomes for further research. 6.2 Objectives The objectives of this contribution in the context of the present dissertation are: To provide general methods for incorporating proactivity into mobile context-aware recommender systems. Here I will present the methods associated to analyze and calculate the appropriateness of a situation in order to generate a proactive recommendation taking into account different contextual dimensions. To validate the feasibility of the research approach. In order to assess the methods proposed as a result of the combination of the different contributions presented in this dissertation, all of them are applied and evaluated in a real scenario. These objectives can be divided into several tasks: 1. Include proactivity in the recommendation model for mobile CARS presented in chapter 3. I will explain how to combine the recommendation models presented in Figures 3.1 and 4.1 to incorporate proactivity in such general architecture.

163 6.3. RECOMMENDATION MODEL Define context-aware methods to calculate the appropriateness of a situation. The methods presented in this chapter consider social, location and user context to determine if a specific situation is suitable for a proactive recommendation. 3. Validation. I will provide details on how the whole system has been implemented and evaluated as part of a European research project. 6.3 Recommendation Model As I mentioned in chapter 3, to improve the recommendation process by including new features like proactivity it is only needed to replace the recommendation model (Figure 3.1) by a new one. In fact, the only requirement to comply with the architecture for mobile CARS presented is that the new model should use the data from users, transactions and items, as well as the contextual information provided by the client side to maintain the original properties. On the other hand, according to the proactivity model proposed in chapter 4, we saw that the second phase (Figure 4.1) in charge of assessing the items to recommend was designed as general as possible to allow different recommendation methods (contextual-based or not). Consequently, by merging both models into a single one, it is possible to include proactivity in the original contextual recommendation process bearing in mind that two main conditions have to be met: 1. A score S1 has to be calculated using contextual information related to the situation of the user in order to decide if that situation deserves a proactive recommendation. 2. No matter what kind of item recommendation algorithm is selected, it has to calculate a score S2 for every item, taking into account that the threshold T 2 against it will be compared to will depend on S1, i.e. T 2 = 1 S1. Figure 6.1 illustrates the new general recommendation model resulting after considering these requirements. Attending to the contextual paradigms for incorporating context in recommender systems (refer to section 2.2.4), phase I is based on a contextual pre-filtering, while the phase III is based on a contextual post-filtering. Phase II, as we saw in chapter 4, it is based on a contextual modeling process. To generate proactive recommendations the model utilizes the following context categories:

164 142 CHAPTER 6. METHODS TO INCORPORATE PROACTIVITY INTO MOBILE CARS Figure 6.1 : Model for generating proactive context-aware recommendations in mobile recommender systems. Social context. It is the result generated by the first phase (i.e. user s cluster trends map). It represents the links (e.g. common interests, related profiles, etc.) among users in the platform that allow us to gather them by similarity in order to know what items are consumed by each kind of user (i.e. social consumption trends). Location context. It is divided into temporal (e.g. current time) and geographical information (e.g. position, nationality or language). User context. It represents the current activity of the user in the platform (e.g. browsing) that includes the proactive recommender system. In the first phase the system generates the social context related to a user by analyzing all the user profiles, transactions and items that exist in the platform. Apart from gathering the users into clusters by similarity, the clusters also store information about the items that the users belonging to the cluster interacted with in the past. As a result, information about the trends of items usage in every social cluster is achieved. This phase is executed with low frequency (e.g. once a day during the night) because the social context does not change continuously. The second phase determines whether or not the current situation warrants a proactive

165 6.4. SCENARIO: THE VIRTUAL SCIENCE HUB 143 recommendation considering location and user context information. This phase is executed periodically in the background (e.g. several times per hour or when the platform wants to check if the current situation deserves a recommendation). The third phase deals with evaluating the candidate items to be recommended. If one or more items are considered good enough in the current context, the recommender system would communicate it to the user. This phase is only executed when the second phase indicates a promising situation and the corresponding score exceeds a threshold. Finally, the user has the possibility of giving feedback about the recommendation provided in order to allow the system to take that information into account for future recommendations, influencing not only the way a situation is considered suitable or not by the user, but also the type of items he/she prefers (as I explained in detail in chapter 5). 6.4 Scenario: The Virtual Science Hub The scenario in which the previous model have been applied is the Virtual Science Hub i (ViSH), a social e-learning network related to the GLOBAL excursion ii (Extended Curriculum for Science Infrastructure Online) European project. GLOBAL excursion s aim is to provide educators across Europe with a range of e-infrastructures and access to expert knowledge by connecting teachers from schools and high-schools to scientists. ViSH is the platform where all GLOBAL excursion activities take place. It allows educators to share their knowledge in a social way and students to have a joyful exploration of e-science. It is open source and has been completely developed by the project members following a participatory design process [Holocher-Ertl 2012]. ViSH has been built using the latest technologies on top the social network framework Social Stream [Tapiador 2012] which provides features such as following/follower relationship mechanism, content repository, private messaging or a wall to share contents with other users (e.g. educational resources). In addition to this, ViSH offers an authoring tool to create enhanced learning objects (LOs) and complete lessons by using resources from a selection of e-infrastructures or LOs uploaded by users to the ViSH repository [Gordillo 2013]. i ii

166 144 CHAPTER 6. METHODS TO INCORPORATE PROACTIVITY INTO MOBILE CARS Motivation: Requirements and Challenges ViSH is a web platform which has been designed to be accessible not only from desktop web browsers, but also by mobile web browsers and native mobile applications. Thus, different contextual information is available based on the device used by users to access ViSH. Considering that one of its main objectives is to help educators in the creation process of new LOs by providing them with the most suitable resources attending to their needs in every moment, integrating a proactive mobile CARS in ViSH becomes direct consequence to make it possible. In addition to this, according to the description of work of the GLOBAL excursion project, one of the features was the integration of recommendation capabilities. Even more because during the participatory design process teachers reported and insisted that they had many difficulties finding adequate resources for their everyday teaching so this feature increased its importance. This way, considering the tasks proposed by Manouselis et al. [Manouselis 2011] that every recommender system for Technology Enhanced Learning should comply, I divided the initial project requirement into several challenges to overcome during the design and development process of the ViSH recommender system: 1. Find (all) good items: the system should recommend a list of LOs suitable for the user attending to his/her profile and necessities. 2. Annotation in context: the system should generate recommendations while the user carries out other tasks in the platform by considering his/her current context in order to predict the relevance/usefulness of recommending specific LOs attending to the situation. 3. Passive recommendations: the system should recommend the user while he/she is browsing the platform. 4. Build a credible recommender: the system should recommend during the initial exploration/testing phase (e.g. after registration) of the platform to encourage the user to use it, and as a result increase his/her confidence in the recommendations. 5. Find novel resources: the system should consider new or novel items so as to be up to date in the recommendations provided.

167 6.5. PHASE I: SOCIAL CONTEXT GENERATION Find peers: the system should recommend not only items, but also relevant people attending to their similarity and relationships in the social network. As a consequence, to address these requirements I implemented the architecture presented in Figure 3.3 in this scenario. In this case, ViSH acts at the same time as the social data source and the application manager, whereas the recommender module follows the recommendation model presented in Figure 6.1. The next sections detail not only the general methods needed to achieve each phase, but also how they were applied and evaluated in the ViSH scenario. 6.5 Phase I: Social Context Generation Method User profile clustering As Figure 3.2 depicted, the main idea behind this process consists of gathering similar users into social clusters. Similarity can be obtained by calculating distance measures among user profiles. A user profile can be represented by some feature vector in an n dimensional space composed by the following n-tuple (6.1) that describes the information relevant to the recommender system extracted from the user profile modeling in ViSH: U :=< areas_o f _interest, languages, target_age, country > (6.1) where: areas_of_interest: informs about the topics a user is interested in. This feature works as a folksonomy because it can store several topics that the user can generate during the utilization of ViSH (e.g. a teacher could be interested in biology and nanoscience at the same time). languages: describes the languages the teacher uses in his/her classes by selecting languages from an available taxonomy. This is important when considering the LOs consumed by every user, as a teacher will need for example resources that their students will be able to understand.

168 146 CHAPTER 6. METHODS TO INCORPORATE PROACTIVITY INTO MOBILE CARS target_age: identifies the range of ages corresponding with the students a teacher works with. It can be represented by a closed integer interval, i.e. [minimum age, maximum age]. country: the country in which the users habitually works. The areas_of_interest feature was considered (by requirement after the participatory design process) the most important profile information to recommend in ViSH. Hence the first challenge that appeared was related to using a folksonomy when calculating users similarity. Real folksonomies exist in a non-geometric space, over which commonly used numerical similarity metrics [Amatriain 2011] fail to compute. Therefore, to calculate the similarity between user profiles I designed an ad-hoc distance measure (6.2) that combines several types of similarity methods, being each one appropriate to the different user profile attributes mentioned above. It is defined as: D ViSH (x,y) = i w i D i (x i,y i ) i w i (6.2) where x i and y i are the i th attributes (components) of the user profiles (6.1) x and y, respectively. In addition, w i represents the weight of every attribute in the similarity calculated. As regards the areas_of_interest feature, I selected the Levenshtein distance [Levenshtein 1966] as a measure of similarity among the folksonomy tags representing the areas of interest: D 1 = D areas (A x,a y ) = min{lev(a i,a j )} (6.3) where A x and A y are the sets of areas of interest corresponding to the user profiles x and y. a i A x and a j A y are every single area (i.e. tags from the folksonomy) in the sets. Lev is the Levenshtein distance between two tags that calculates the minimum number of edit operations (i.e. insertion, deletion, or substitution of a single character) that are necessary to modify the tag a i to obtain the tag a j. To measure the distance among languages I calculate the intersection between the sets of languages L x and L y corresponding to the user profiles x and y. In other words, I calculate the number of languages shared by both users.

169 6.5. PHASE I: SOCIAL CONTEXT GENERATION 147 D 2 = D languages (L x,l y ) = L x L y (6.4) To measure the distance related to the target ages I measure the intersection between the target age intervals corresponding to every user profile. min { i + x,i + } { y max i x,i } y = I if > 0 D 3 = D ages (I x,iy) = I x I y = 0 if I 0 (6.5) where I x and I y are the closed integer intervals corresponding to the user profiles x and y, being I x = [i x,i + x ] and I y = [i y,i + y ]. Finally, for the country similarity I follow the straightforward method: 1 if c x = c y D 4 = D countries (c x,c y ) = (6.6) 0 if c x c y where c x and c y are the countries corresponding to the user profiles x and y. Once we have the ViSH distance completely defined, we can move on to the clustering method. Considering the ViSH scenario particularities, I decided to modify the Canopy clustering algorithm [McCallum 2000] in order to gather the users by similarity avoiding heavy processing. I have called this new version Folk-Canopy, as it is intended to be applied in scenarios in which the most important features corresponding to the vectors analyzed are represented by a folksonomy and not by a numerical value. The algorithm uses the ViSH distance metric to calculate the similarity and also two distance thresholds C1 > C2 for processing (empirically chosen). Social networks follow a scale-free network pattern [Barabasi 2009]. These kinds of networks are those whose degree distribution follows a power law: the network expands continuously by the addition of new users, and these new users attach preferentially to other users that are already well connected (i.e. hub users). Bearing this in mind and the follower/following relationship available in ViSH between users, the Folk-Canopy algorithm proceeds as follows: 1. It begins by studying the power law distribution of users in ViSH related to their number of

170 148 CHAPTER 6. METHODS TO INCORPORATE PROACTIVITY INTO MOBILE CARS followers. As a result, the first step is considering the hub users as cluster centers, instead of picking them at random like the classic Canopy does, because this assures that the most "relevant" users will be the center of the social clusters generated. 2. When the first user is taken (and removed from the users pool), it is cloned to create a "centroid", i.e. a virtual user that represents the average profile values in the social cluster, starting with the first user s areas of interests related to the folksonomy, the languages, etc. Then the centroid becomes the center to create the cluster, and the user is added to the cluster s users list. 3. Then it iterates through the remainder of the point set. At each point, if its distance from the centroid is < C1, then the point is added to the cluster. If, in addition, the distance is < C2, then the point is removed from the sample set and their areas of interest are added to the centroid s profile if they are among the "ViSH top areas of interest". This is done this way because the tags related to unmodified real-world folksonomies also follow a power law distribution [Quattrone 2011]. For that reason, the Folk-Canopy only adds to the centroid s profiles those additional tags that are "top/trendy" in the platform to avoid noise in a cluster produced by tags only belonging to a single user. Consequently, by removing those points at a distance < C2 (i.e. points that are very close to the cluster centroid) I avoid all further processing saving computational time as they will not be candidates for other canopies. With regard to the less important profile attributes (languages, target age and country), average profile values are calculated for the centroid in order to have a centroid as much representative as possible in relation with the users in the cluster. 4. The algorithm loops until the source of users is empty, accumulating a set of social clusters, each containing one or more users that are similar among them. A given user may be in more than one cluster, representing those users with similarities to more than one group. Apart from this, during this process the traditional grey sheep problem (refer to page 21) is mitigated because all the grey users (i.e. users that do not have filled in their profile with their areas of interest, languages, target ages, etc.) are gathered into a grey cluster. Thus we have those kind of users separated from the others to apply them special recommendation rules (i.e. more based on their current contextual information than in their specific profile or interests).

171 6.5. PHASE I: SOCIAL CONTEXT GENERATION 149 Learning objects assignment The second step presented in Figure 6.1 consists of assigning a set of items to each social cluster previously generated. To do so, the transactions between items and users are analyzed. In ViSH these items are LOs and thus, the transactions between a user and a LO can be: Created. Those LOs that the user has uploaded to the ViSH repository or has generated by mashing up several resources into a composed one. Utilized. Those LOs that the user has employed to create a composed LO such as presentations [Gordillo 2013], flash cards [Barra 2012a], educational games [Barra 2012b], etc. Bearing this in mind, all the LOs created or utilized by users in the cluster are assigned to it. Once this step is completed, the system knows which LOs are candidates to be recommended in every social cluster as similar users usually consume similar items. This set of candidates LOs is ranked considering how many times a pedagogical material has been requested and by whom, so as to recommend first the items that are trendier in the user s social cluster. User s cluster discovery From the last steps, a set of clusters with their educational trends are generated and stored in ViSH so as to be available at execution time. Thus, when a new user enters the platform (i.e. the target user in Figure 6.1), the user s cluster discovery process is initiated to calculate the similarity between the target user and the different social clusters. After this, the target user is assigned to one of the clusters and as a result, the social context for that user is generated in real-time as we know who the similar users are and which LOs that users like him/her have consumed in the past are Evaluation and results Description and objectives The overall objective of this evaluation experiment was to quantitatively verify the applicability of the methods previously proposed when generating the clusters needed to know the user s social context. Additional objectives were to identify the distribution of users and their LOs compared

172 150 CHAPTER 6. METHODS TO INCORPORATE PROACTIVITY INTO MOBILE CARS c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11 grey # users in cluster # learning objects in cluster Figure 6.2 : Distribution of users and learning objects in the social clusters generated. to the grey users in terms of cluster size and resources assigned, as well as the percentage of users and learning objects present in more than one cluster. Demographics and data collection 280 users registered in ViSH and 721 LOs uploaded by them to the repository were involved in the evaluation process. The users were mainly teachers of schools and high schools from several European countries (i.e. Spain, United Kingdom, Germany, Austria and Hungary), as well as some scientists from institutions like the University of Cambridge, the European Schoolnet, the Computer and Automation Research Institute of the Hungarian Academy of Sciences or the Institute for Biocomputation and Physics of Complex Systems. The data was automatically collected by the recommender system. Hence, no explicit user intervention was necessary as the system used the information provided by ViSH at June Results After applying the methods proposed above, the recommender system generated 12 social clusters. Figure 6.2 shows the distribution of users and LOs per cluster, being the cluster labeled as grey

173 6.6. PHASE II: SITUATION ASSESSMENT 151 Figure 6.3 : Context model. the one related to the grey users (i.e. those with undefined profile). The results also shown that 16.91% of users belong to more than one cluster, 34.45% of LOs are assigned to more than one cluster and 73.57% of overall ViSH users correspond to the grey cluster. 6.6 Phase II: Situation Assessment Method Attending to the definition of context I have been using during this dissertation [Dey 2001a], in section 6.3 when I described the three-phase model (Figure 6.1) I pointed out that several context dimensions are evaluated to determine whether or not the current situation warrants a recommendation. Figure 6.3 summarizes the context model I use to achieve proactivity. The social context is provided by the first phase and it has been fully described above. In this section I am going to concentrate on how the location and user context are retrieved and analyzed, because they are the most influential context dimensions involved in assessing proactivity. Therefore, this phase is executed periodically in the background as the location and user context change quickly over time (in contrast to the social context). Determination of Appropriateness One central question when analyzing how to be proactive is to determine if a recommendation would be appropriate for a given user context. Attending to the model presented (Figure 6.1), the system has to calculate a decision score S1 that will be tested against a threshold T 1. Only if