Main Page

From Real-Time Context-Aware Recommendations for Mobile Users

Contents 1 iPhone application for CBR :: Context Based Recommendations 1.1 Application Properties 1.2 Research Hypothesis 1.3 TODO 1.4 DONE 2 Technology 3 Meetings 3.1 2010-03-17 UI 3.1.1 Main application 3.1.2 If context changes 3.2 2010-03-25 UI and architecture 3.2.1 User interface 3.2.2 System architecture 3.3 2010-04-06 UI XCode 3.4 2010-05-07 3.4.1 Logging 3.4.2 Protocol 3.5 2010-05-18 3.6 2010-05-28 3.7 2010-06-03 3.8 2010-06-22 4 Restricted Area

iPhone application for CBR :: Context Based Recommendations

The research activity is within the scope of ReRex and Adapte projects that aim to advance the state of the art in recommender systems developing an effective methodology for supporting users in context-dependent real-time revision of personalized, but not contextualized, recommendations. The visit to a city will provide the application scenario, here the users, citizens and tourists, will be supported to adapt (revise) their itinerary to the current context, during the itinerary execution. In the usage scenario we assume that a user has built, or downloaded from a tourist information repository on her mobile device, an itinerary (a set of selected points of interest – POIs). During the execution of the itinerary, the user will receive context-dependent suggestions, in the form of itinerary revision, and the corresponding explanations for such revisions. The scientific and technical challenges of this project are related to the development of techniques (extending collaborative filtering, conversational recommenders, explanation generation) to: a) model the (statistical) influence of contextual data on the rating of POIs and on the recommendation algorithm; b) enable a recommender system to adapt a previously defined recommendation list in real time according to the changing contextual conditions; c) explain and motivate such changes, in the light of new information and with respect to the user’s previous choices; d) enable the user to express her feedback/opinion on the system’s revision suggestions in the form of critiques; e) enable the system to incorporate the critiques into the recommendation algorithm and produce a new set of recommendation revisions

Application Properties

• Context dependent
• user is interacting with the system
• explanations are provided
• users preferences are acquired
• push recommendations are done

Research Hypothesis

• Increase user satisfaction for the service
  • user study
• Increase user decision making satisfaction (refine what i mean)

TODO

• design the GUI in XCode
• make a usage scenario
• define architecture of the system (just a big picture) - where to compute things?
• define functional requirements
• define data set
• define simple model (rule based ) for RS
• check categories
• aspect ratings
• context model

DONE

• set up SVN
  • cbr-iphone.unfuddle.com
• search for an iPhone emulator for Windows
  • there exists an iphone emulator, called MobiOne, by which one can create a limited iphone GUI and emulate it: www.genuitec.com/mobile
    The designed GUI cannot be integrated in XCode, therefore the emulator is not useful for creating an iPhone application.
• get a Macbook
• getting started with XCode and iPhone development (first little application with basic controls)

Technology

The project will be developed in Objective C - Cocoa Touch.

Meetings

2010-03-17 UI

The meeting was about user interfaces.

First revision of the user interface: Media:IPhone_UI_1.jpg

Main application

When the application starts, a list of recommendations is shown with an small image beside. At the bottom, there is the standard iphone menu. On the top, in the title bar, there are icons for the enabled context (only some are shown). By tapping on an item in the list, a user can see its detail page and also a short description why this item was recommended. The amount of items, shown in this list has to be fixed. It may be a small number (maybe 5), to not overload the user. Tapping on the + in the bottom menu, a user can add additional recommendations. The bottom menu forsees also an entry for switching to "map view". In this view, all places of recommended items are shown on a map (Google API). Maybe it's also possible to connect all items, so that the user can see an itinerary. User preferences and context preferences are also two entries in the bottom menu. User preferences are for example: age, sex, reason of trip, new visitor. By the context preferences the user can enable or disable given context. If a context-item is switched off, it will not be considered in the generation of the recommendations.

If context changes

Surely the main feature of the application are the push notifications. If context changes, the ranking of the recommendations may change and in this case, the user will be informed by a sms like "push message". This message will also appear, if the application is currently not running. The message describes shortly that context/ranking has changed and proposes to start the application for getting more details. When the application opens, changes are shown by images. The user has the possibility to tap on "why" for getting a text description and for knowing what happened. Additionally he must accept or decline the change in the ranking. Then a revised list of items is shown, maybe with some images attached why and what has changed.

Possible changes in the item list:

• items swaped places
• items are replaced
• items are added
• items are deleted

2010-03-25 UI and architecture

The meeting was about user interface and system architecture.

User interface

In addition to the list of recommended items (5), there could be a wish list of items, like favourites, which the user can maintain by itself (add, remove items).

If context changes, changes in the item list should only be:

• items are added
• items are deleted

This we defined, because swapping and replacing of items gets the project more complex.

System architecture

For the development of a push application for iphone, one has to use the APNS (Apple Push Notification Service). This is a service, provided by Apple which allows the iphone to get messages at any moment in time. Other communication between the iphone and the data provider (server) does not happen by push messages, but by network connections.
Picture: Media:IPhone_architecture_1.jpg

A problem to solve is, where to store items. Surely it's not possible to store the whole database on the iphone, since this is a huge amount of data, which changes over time. But recommended items or items in the wish list should be stored locally, because it's a mobile application and there might not always be a network connection. If things would only be stored on the server a persistent network connection must be available on the phone and this cannot be guaranteed for mobile devices which often change their location. If the phone has a network connection at a moment, it should request updates by the server (new recommendations). For getting new recommendations/items the user profile, which is also stored locally on the phone will be transmitted to the server. Since this are only a few bytes it should not be a problem.
I think that all the communication between client (phone) and server should happen by a HTTP web service. The reason is the following: HTTP is a stateless protocol: a connection is opened, a request is made, the response will be sent and then the connection will be closed. This has a big advantage for mobile application (where not huge amount of data will be sent), because a phone might lose very often the network connection and therefore a persistent socket connection, or frameworks like CORBA or RMI are not so good.

2010-04-06 UI XCode

The first Version of the GUI, implemented in XCode was shown.

2010-05-07

Logging

For generating precise recommendations several things have to be logged on phone and server:

• recommended items
• wish list
• context
• user preferences
• other decisions (push messages, ratings of items, etc)

We decided that we don't log all the clicks a user makes, because some are not relevant (ex: showing something on a map)

Protocol

For data exchange between client (phone) and server a protocol has to be defined: Media:IPhone_logprotocol_1.jpg This picture gives just a rough overview but contains also the communication of logs.

2010-05-18

We decided that items can be rated, giving 1 to 5 "stars" to them. In addition we said that items in the itemlist should be deletable.

2010-05-28

• TODO
• DONE
  • give to Linas XML of full state
  • add messages (maybe check if possible to use images) when
    • when change occurs (after change)
  • add ">" to context configurationg
  • item description (pages with nice scrolling)
    • 1st page only picture, rating, short description, add to wish list, delete from the list
    • 2cond page picture and long description
    • 3rd google maps
  • Connection to server with threads
  • you should always ask the user if he wants to accept the change or reject the change

2010-06-03

• TODO

• DONE
  • Wishlist and Suggestions in Map with different symbols
  • Categories
  • First time the wishlist will be loaded -> show info message

2010-06-22

• TODO
• DONE
  • send messages to server:

1. every 10 minutes
2. when user changed the preferences or context
3. when user changes wish list
4. when clicks refresh

• • messages
    • wish list commenting (suggestion to change the list). > add, delete item. User is given with options to accept the proposed change, or reject
    • context changed (msg from server) > accept or reject. On accept regenerate suggestion list
  • parsing, server connections with threads - activity indicator
  • don't ask me again for any change (always reject changes)
  • versioning: xml protocol, application have to be of the same version
  • reset and configuration for the app.
    • reset to 0 state (send to server maybe this info that it was reseted)
    • put server URI
  • added compatibility for iOS 4
  • arrow for navigation back
  • GPS
    • current position
    • send GPS coordinates when application is in background (multitasking on iOS 4)
  • rating view of an item. put that user can rate an item in 1/5 star scale.
  • interface
    • user feedback on item
    • star in wish list
    • new interface for the item view (overview)
  • SOAP and other XML messaging
    • iPhone part, what is supported -> SOAP not supported -> we do XML parsing manually
    • Server side (which server to install)

Restricted Area

Access to the Restricted Area is only allowed for people, who are involved in the project.