On-the-Move Interactive Decision Support for Recommender

Download Report

Transcript On-the-Move Interactive Decision Support for Recommender

MobyRek:
A Restaurant Recommender
for Mobile Phone Users
Quang Nhat Nguyen
(Presented in the course “Mobile Services”)
Faculty of Computer Science
Free University of Bozen-Bolzano
May, 2007
Content

User problem

Usage scenario

System architecture

Midlet-side components

Server-side components

Common components

Hints for design of mobile applications
MobyRek: A Restaurant Recommender for Mobile Phone Users
User problem

User uses a mobile phone to find his/her desired
restaurant for lunch or dinner

A huge number of restaurants in a city
• different types
• different characteristics
• different locations

How a user can find the restaurant that best suits his/her
needs and preferences??
 The user needs the system support
• by means of the system recommendations
• to browse the recommended restaurants, to evaluate and
criticize them, and finally to select a desired one
MobyRek: A Restaurant Recommender for Mobile Phone Users
Recommender systems

Recommender Systems

decision support tools that suggest to users those products and
services which best suit their needs and preferences in their
particular situation and context

very useful in case users are overwhelmed with alternatives to
consider

Based on a number of techniques including, for example,
information filtering and retrieval, decision theory, machine
learning, adaptation and personalization, user modeling, etc.

Successfully applied in a number of domains, such as books,
news, movies, CDs, travel products, etc.

To understand in detail about Recommender Systems, you
may go to the “Advanced Topics in Information Systems”
course (http://www.inf.unibz.it/~ricci/ATIS/index.html)
MobyRek: A Restaurant Recommender for Mobile Phone Users
Usage scenario
requests
selects
browses
criticizes
afor
restaurant,
the
adesired
restaurant
restaurants
restaurant
or quits
shows shows
new recommendations
best candidates
MobyRek
initializes
adapts thethe
query
queryrep.
rep.
stores the
rec. case
Knowledge
sources
MobyRek: A Restaurant Recommender for Mobile Phone Users
A recommendation session
• starts when a user requests the system to find some desired restaurants
• ends when the user either selects a restaurant or gives up the current session
• evolves in cycles (in each cycle, a set of recommended restaurants are
shown to the user)
User’s initial
conditions
and
contextual
constraints
Initialization of
the user query
representation
Computation of a
recommendation list
Recommended
restaurants
Adaptation to
new preferences
Critique to a
restaurant
Storage of
current case
Recommendation session
case base
MobyRek: A Restaurant Recommender for Mobile Phone Users
System architecture (1)
MobyRek
midlet
HTTP connection
MobyRek
server
(MIDP 2.0 / CLDC 1.0)
GPS
receiver
Local stores
Back-end database
MobyRek: A Restaurant Recommender for Mobile Phone Users
System architecture (2)
Midlet-side components
User pos.
detection
Search
initialization
Display of
recommendations
Management
of Travel Notes
Logging
user actions
User critique Rating sel.
management restaurant
Display of
restaurant details
Management of
user opinions
Management of
local stores
User access
authentication
Similarity
& ranking
Management of
user def. pref.
Transfer of
type-defined data
Recommendation
session management
Server-side components
Initialization of
user query representation
Computation & filtering
on location data
Transfer of
type-defined data
Data transfer
User query
execution
Service request
controllers
Back-end database
communicators
Handling
exceptions
Common components
K virtual machine (KVM)
Java HotSpot virtual machine
OS for mobile devices (e.g., Symbian)
OS for computers (e.g., Windows)
MobyRek: A Restaurant Recommender for Mobile Phone Users
Package diagram
The MobyRek package consists of 115 classes
MobyRek
client
ui
Local
Store
Exception
client
server
data
package
Feature
ValueRep
UserModel
GeoInfo Query UserPref
Access Data
Prelimin
Manage Manage RepInitiali
Control Control
aryRep
ment
ment
zation
Similarity
Computation
util
Data
Exchange
client server client server client server
MobyRek: A Restaurant Recommender for Mobile Phone Users
Midlet-side components (1)

Design of the graphical user interfaces
• Examples of the GUIs: displaying the list of recommended
restaurants, displaying restaurant details, reading/writing
opinions about restaurants, etc.
• Types of the GUIs:

The MobyRekMIDlet root screen is a subclass of
javax.microedition.midlet.MIDlet

The other GUIs are subclasses of either
javax.microedition.lcdui.Form or
javax.microedition.lcdui.List
• For time-consuming tasks, always show a screen explaining
what the system is doing
• On every screen, always provide a Back/Home command to
return to the parent/root screen
MobyRek: A Restaurant Recommender for Mobile Phone Users
Midlet-side components (2)

Design of the user navigation/interaction structure
• Each system’s function (e.g., showing the recommendation list)
has a separate (i.e., own) screen
• Every screen is reachable from the MobyRekMIDlet root screen
(the root screen)
MobyRekMIDlet
Screen for initializing the search
...
...
Screen for showing rec. list
...
...
...
Screen for showing restaurant details
...
...
Screen for viewing value of a feature
...
Screen for criticizing the feature value
MobyRek: A Restaurant Recommender for Mobile Phone Users
Midlet-side components (3)

Detection of the user’s current position
• Did not exploit the Location API package
(javax.microedition.location), because no mobile phones, at that
time, implemented this API
• The midlet communicated, via bluetooth, with a GPS receiver
• Exploited the Bluetooth API package (javax.bluetooth)
• Read the GPS data from the GPS receiver. If the data is available
and reliable, get the latitude and longitude in the NMEA0183
format
– (lat: <DD><MM.MMMM><N/S>, long: <DDD><MM.MMMM><E/W>)
– e.g., (lat: 4605.2094N, long: 01107.2941E)
– Defined by the National Marine Electronics Association (NMEA) in the USA
– The only standard Input/Output message format in the GPS industry (both
for GPS Hardware and for GPS Application Software)
MobyRek: A Restaurant Recommender for Mobile Phone Users
Midlet-side components (4)

Management of local stores in the mobile device’s storage
• There are 4 local stores (using the RecordStore class)
– TravelNotesStore: the user’s selected products and services
– UserSettingsStore: the user’s default preferences (e.g., non-smoking rooms)
– CustomerOpinionStore: the user’s opinions about restaurants
– LogDataStore: the log of the user’s navigation history (i.e., session-scoped
sequence of time-stamped actions)
• Each record is a structured (i.e., typed) object, stored as a bytes array
(i.e., byte[]) in a RecordStore
– E.g., each record in the CustomerOpinionStore local store represents an object
of the CustomerOpinionRecord class
– Advantages: compact storing and very fast reading (e.g., compared to
reading/writing comma-separated string data)
• Exploit the javax.microedition.rms package, and the
java.io.DataInputStream, java.io.ByteArrayInputStream,
java.io.DataOutputStream, java.io.ByteArrayOutputStream classes
MobyRek: A Restaurant Recommender for Mobile Phone Users
Server-side components (1)

Service request controllers
• Java servlets that serve the service requests from the midlet
• Exploit the javax.servlet package
• A service request from the midlet is identified, and served
appropriately, based on the request id/code
e.g., STARTING_REC_SESSION
• A service response code (i.e., to the midlet) may indicate
 OK_HEADER
 the service request was served successfully
 CONNECTION_ERROR_HEADER
| DATABASE_ERROR_HEADER
 errors occurred in serving the request
MobyRek: A Restaurant Recommender for Mobile Phone Users
Server-side components (2)

Back-end database communicators
• The service request controllers (i.e., servlets) do
not exchange data directly with the back-end
database
Service request
controllers
• This data exchange is managed by the back-end
database communicators
• Connection to the database through JDBC (e.g.,
jdbc:oracle:thin:@<dbms_host>:<dbms_
port>:<db_schema>)
• Database connections are managed by a
connections pool, instead of creating new
connection per request
• Requests that modify data in the database (e.g.,
insertion) are performed in transactions
Database
Communicators
Back-end
database
 A database transaction is a set of database
operations that should be done as a whole
MobyRek: A Restaurant Recommender for Mobile Phone Users
Common components

Data transfer between the midlet and the server
• Via HTTP connection
• Support sending/receiving data at both the midlet-side and the serverside
• Data is exchanged in either the primitive types (e.g., byte or int) or
the types defined by the MobyRek application (e.g.,
CustomerOpinionRecord)

Handling exceptions
• Midlet-server communication exceptions
• Database access exceptions
• RecordStore access (i.e., midlet-side) exceptions
MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (1)

Early and carefully define the target mobile devices
• Which device classes?
e.g., mobile phones, PDAs, or tablet PCs?
• Which device configuration?
e.g., CDC, CLDC v1.0, or CLDC v1.1?
• Which device profile?
e.g., MIDP v1.0, MIDP v2.0, or MIDP v2.1?
MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (2)

Always keep in mind that mobile devices are limited,
especially in screen size and computing power
For example …
Small screen, enough for
showing
only makes
3 restaurants
Small screen
it
difficult
to show
all thethe
 We have
to divide
restaurant
Not
enoughdetails
spacelist
tointo
show
recommendation
pages
a feature’s value
MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (3)

Always put time-consuming tasks in separate threads
 to avoid blocking the user interface
• For example, in the MobyRek system the following tasks are
implemented to run in separate threads
– User authentication (i.e., log-in)
– Detection of the user’s position
– Retrieval of the pre-defined list of landmarks (i.e., from the server)
– Computation of recommendation lists
– Retrieval of a restaurant’s picture and routing guide
– Saving/reading user opinions about restaurants
– Saving the user’s critiques in the server database
– Saving the user’s recommendation session
– Computation of the distance from the user’s position to a given restaurant
– Uploading the user’s actions log to the server
–...
MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (4)

Always display a
notice/explanation
during the execution
of a time-consuming
task

Always provide the
user a menu
command to
pause/discard the
running task
MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (5)

Handling exceptions
• Precisely and exhaustively capture all exceptions that may
occur, especially in midlet-server communications
• Provide the user some ways to get over the problem, such as

to retry the failed task

to roll back to the previous state

...
• Use the finally clause of the {try/catch/finally}
exception handling framework to do some important tasks (e.g.,
closing the open connection) in case an exception occur
For example...I►
MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (6)

Test with real mobile devices, not just with emulators,
especially for:
• Midlet-server communications, or data transfer (i.e.,
disconnected, interrupted, incomplete data transfer, etc.)
• Display of graphical user interfaces (different devices
displays GUIs in different looks and feels)
• User-system interactions (# of buttons, buttons’ positions
on the device, menu organization of the device, etc.)
MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (7)
• Different in the layout
and rendering
Emulator: caption and
content are in the same
line
 Phone: caption and
content are separated in
two lines

• Different in the
organization and order
of menu commands
Emulator: contextual
menu is located on the
right
 Phone: contextual menu
is located on the left

MobyRek: A Restaurant Recommender for Mobile Phone Users
Hints for design of mobile applications (8)
• Different in navigation
between the objects on
the screen
Emulator: static objects
are traversable
 Phone: static objects are
not traversable

• Different behaviors
regarding the internal
state of interactive items


Emulator: a
ChoiceGroup item’s
internal state does not
change if the user clicks
twice on the same option
Phone: the internal state
changes
MobyRek: A Restaurant Recommender for Mobile Phone Users
Thank you for the attention!
MobyRek: A Restaurant Recommender for Mobile Phone Users