=Paper=
{{Paper
|id=None
|storemode=property
|title=Planning and Navigational Assistance for Distributed Events
|pdfUrl=https://ceur-ws.org/Vol-786/paper5.pdf
|volume=Vol-786
}}
==Planning and Navigational Assistance for Distributed Events==
https://ceur-ws.org/Vol-786/paper5.pdf
Planning and Navigational Assistance for
Distributed Events
Richard Schaller
Embedded Systems Initiative, Univ. of Erlangen-Nuremberg
Department Computer Science 8 (Artificial Intelligence)
Haberstr. 2, 91058 Erlangen, Germany
richard.schaller@cs.fau.de
http://www8.cs.fau.de
Abstract. In this paper we describe our work on developing and eval-
uating systems for providing assistance to visitors of distributed events.
The range of required assistance is very broad: providing the user with
information about the available events, user-specific event recommenda-
tions, support for planning a good sequence of events and finally assisting
the user on his tour, taking into account his context. The developed mo-
bile application was evaluated by about 200 users during the Long Night
of Music 2011. We gained valueable insights from the logged user-system
interactions, which showed us the strengths and weaknesses of our design.
Keywords: Navigation, Routing, Assistance, Recommendation, Smart-
phone, Events, Round trip, Orienteering Problem
Introduction
The past decade has seen a massive increase in what we call distributed events;
in which multiple cultural or scientific institutions work together to organize and
market one evening dedicated to a single theme, e.g. museums. Participating in-
stitutions usually extend their opening hours far into the night. The ticketing
is simplified to one ticket for all locations and contains, in most cases, access to
the local public transport provider, as the locations are usually spread all over
the city. In some cases, even special bus lines are run to cover remote locations
or to simplify the public transport usage for those that are not used to it.
The outreach of such a distributed event is far bigger than what each institution
can achieve on its own, mainly due to reaching new customers and the social
happening atmosphere. Examples are the Long Night of Museums in Berlin1 ,
Long Night of Science in Erlangen-Nuremberg2 , Night of Heritage in Cebu3 ,
Nuit Blanche in Paris4 and Cocktail Tour in Erlangen5 . The numbers of partic-
1
30,000 visitors in January 2011 (see http://archiv.lange-nacht-der-museen.de/28/)
2
25,000 sold tickets in 2009 (see http://www.nacht-der-wissenschaften.de/2009/)
3
1,700 visitors in 2010 according to the blog http://megaphilippines.blogspot.com
4
1,500,000 visitors in 2006 as reported by http://www.paris.fr/english/visit/highlights/
nuit-blanche/rub 8208 stand 34123 port 18969
5
see http://www.cocktail-tour.de/calender/view/565/
2 Planning and Navigational Assistance for Distributed Events
ipants vary but larger ones have up to a few hundred offered events at different
locations and tens of thousands of vistors.
Due to the sheer number of events and the limited time available the visitor
faces the problem of selecting a small subset of events of interest to him. This
selection will depend heavily on the location of the events because long travel
times between events should be avoided. Bringing the events into a particular
order can be challenging as not all events share the same opening hours. While
taking a tour the visitor has to find his way to bus stops, some of which may be
difficult to recognize, especially if they are only temporarily set up for the night.
Similarly, event locations may also be unknown. To make things worse there is
a continuing trend whereby the number of included events has been rising from
year to year. Even simply reading the event booklet is a huge task in its own,
with many over 100 pages in length.
The magnitude of problems the visitor is faced with creates a need for semi-
automation and assistance. But are these really the problems the visitors expe-
rience? What problems can they easily solve on their own? For which problems
do they need assistance and what form should this assistance take?
To answer these questions we have developed a system and analyzed how users
interact with it. Furthermore we interviewed visitors and asked them if and how
they plan their evening.
In this paper we first define the problem domain we want to tackle: we list dif-
ferent properties which can be used to categorize the different distributed events
which illuminates the problem domain from the perspective of the software de-
signer. To cover the aspects of the human computer interaction we performed
a task analyis. Then we move on to the desciption of the implemented system
and how the user might interact with it. This section also covers our approach
to tackling the necessary context-awareness, which is unique compared to usual
mobile navigation systems as we abstain from using GPS for saving power and
its inaccuracy indoors. In the User-Study section we present our findings from
logging interaction data we obtained from the users of our application during
the Long Night of Music 2011. In parallel we conducted a interview during the
Long Night with several visitors which we present in the section thereafter. Our
paper is concluded by discussing related work and what future work is needed
to give better assistance to visitors of distributed events.
Problem Domain
Categorization
Although most distributed events have a very similar name – mostly ”Long Night
of ...” – their structure can differ which can have serious consequences for the
design of assistance systems. We have identified the following main differences:
– Public transport available:
Is public transport included in the ticket price? This has huge implications
on the planning algorithms involved.
Planning and Navigational Assistance for Distributed Events 3
– Type of public transport:
If public transport is included, is it the regular public transport, special bus
lines or both? Special bus lines usually adhere to no fixed timetable but are
scheduled regulary (e.g. about every 10 min). The type of public transport
dictates whether a time-dependent variant of the planning algorithms have
to be used or not.
– Preferred bus stops:
Is there a preferred bus stop associated with every event location? The or-
ganizer selects one bus stop for each event to help the visitors find the right
bus stop. This also simplifies the needed planning algorithms. Sometimes the
footpath from the bus stop to the event is marked to further assist visitors.
– Type of event visits:
Can events be visited and left at any time (within their opening hours) or
are there fixed dates given? In the former case (e.g. an exhibition) a visiting
duration has to be determined (either estimated or given by the user). The
later case (e.g. a movie presentation) tolerates no delays in the tour execution
and therefore the system must ensure that a visitor adheres to the plan or
is informed about the consequences.
– Number of events:
Can the visitor to quickly get an overview of all available events, or is the
number of events too high to read through all of them in a realistic time?
In the later case, a system is needed that gives the visitors assistance in
exploring the offered events, e.g. filtering events by certain criteria or even
recommending events based on user profiles.
– Multiple events at one location:
Are there multiple events at the same location or is there only one event
per location? In the former case, a local guidance system might be needed
such as an indoor navigation system, to help the visitors to get to their
chosen event. This can be an enormous amount of work as detailed maps
are required for every event location and, in the case of indoor navigation, a
robust indoor localization technique must be used as GPS is very inaccurate
indoors.
– Theme of the distributed event:
The theme of the distributed event has serious implications on what visitors
it has and how they can best be assisted. In the easiest case a simple genre
can be associated with each event, e.g. the music genre on a Long Night of
Music or the field of science on a Long Night of Science. But if the topic is
broader it becomes much more difficult to represent an event in a way to
easily query and recommend events.
Long Night of Music 2011
In this paper we concentrate our focus in the Long Night of Music 2011, which
took place on Saturday 28th of May in Munich between 6pm and 3am. We
worked together with the organizers Münchner Kultur GmbH who provided all
4 Planning and Navigational Assistance for Distributed Events
data in a machine readable format. In the categorization scheme given above the
Long Night of Music 2011 has the following properties:
– Public transport available: Yes, included in the ticket price
– Type of public transport: 4 special buslines with busses every 10 minutes
– Preferred bus stops: Yes, one bus stop associated with every event location
– Type of event visits: Both – Visit and leave at any time and fixed dates
– Number of events: 234 events, 110 pages long booklet
– Multiple events at one location: Yes, 124 event locations vs. 234 events
– Theme of the distributed event: Music, multiple music genres for every event
Task Analysis
From informal interviews we performed with visitors on previous nights and from
our own experience on distributed events we know that visitors spent a lot of time
in preparation for the evening. This caused us to wonder if a recommendation and
assistance system can be developed to relieve people from this work. Since these
events are visited in leisure time, people want to make optimal use thereof. Before
building a system we analyzed which tasks a user typically performs before and
during his visit to the Long Night of Music. These tasks were later a foundation
for our system and interaction design. The overall visit of a distributed event
can be decomposed into the following tasks:
– Event overview and pre-selection:
Most visitors get an overview of the offered events by either reading the
booklet or browsing the webpage. In any case they mark the events they
are interested in by a dog-ear or by putting them in a electronic cart. As
we have learned through the previous informal interviews, the visitors have
events they want to visit in any case (must-have events) and events they
would only visit if they have enough time (some-interest events).
– Event selection and ordering:
The next step is to generate a tour out of the marked events. In most cases the
number of marked events is much greater than is actually possible to visit in a
single evening. Consequently, the users selection is related to the ordering of
the events, as long travel times should be avoided. Additionally the opening
hours of the events have to be incorporated into the tour planning. Some
people do not plan a tour beforehand but start selecting events adhoc while
on tour. This spreads the selection and ordering process over the whole
evening and greatly simplifies the process. As only local decisions are taken
into account, the ordering of this procedure is likely to be suboptimal.
– Getting to the events:
When the visitor knowns where he wants to get next, he has to plan a route to
the next event. This planning may involve multiple means of transportation,
however we concentrated on the two main ones as most visitors either use
special buslines or walk [1]. During the trip to the next event the usual
navigational questions may arise [2]: where is the bus stop? When do I have
to leave the bus? Where is the destination? These questions are usually
solved by referring to the booklet.
Planning and Navigational Assistance for Distributed Events 5
– Information about the current event:
Whilst visiting an event, the visitor might be interested in additional infor-
mation about it. In the simplest case the visitor can look up the current
event in the booklet, however there might be information needs that the
booklet can not satisfy, e.g. what discography has the current band?
– Replanning the next events:
During the evening the need to replan the tour might arise due to internal or
external factors. An internal factor might be that the visitor wishes to stay
longer at a specific event and therefore must skip another event. External
factors are mostly due to differences between what was announced before-
hand and what happens in reality. For example an event might be closed
despite the booklet postulating otherwise or a bus may take longer than
expected.
– Finding interesting events nearby:
As events are skipped and reordered there might be the possibility to insert
previously unnoticed events into the plan. Finding events that fit into an
already existing plan and matching said events to one’s own interests is a
difficult task in itself because it is highly related to replanning task.
The tasks can be split up into two different phases as suggested by [2]: a planning
phase and a navigational assistance phase. The first phase takes place before the
evening starts and might be assisted by a PC program or website while the user
is still at home. The second phase is during the evening when the user is on a
tour and might be assisted by a mobile application on a smartphone. As visitors
might join the Long Night of Music spontaneously it is desirable to let phase
one also be performed on a smartphone.
The System
The task analysis showed the need for two software components: a webpage
which covers phase one and a mobile application which covers both phases. This
causes an increased effort as phase one has to be implemented twice. To reduce
this effort it was decided to only implement assistance for the first task – getting
an overview and marking events of interest – twice. Assistance for the second
task of phase one – selecting a subset and ordering the events – is implemented
soley on the mobile device. We consider the overview task being the one which
benefits most from the larger screen real estate.
Webpage
The webpage part of the system is implemented as a Java EE application running
on a Jetty Webserver. It is implemented in a similar manner to webshops where
users can browse through the available items, events in our case, which should
be quite familar to most internet users. An event is presented to the user with
its title, description, music genres, the location it takes place at, a picture and
6 Planning and Navigational Assistance for Distributed Events
its opening hours. Comfort features like searching for events are also provided
(the used topic-based search engine used is described in [3]). For every event the
user can select between three options which will be later used to recommend a
round trip:
– ”I’m not interested” – denoting that the event will not be visited
– ”I’ve some interest” – denoting the above mentioned case that the event will
only be visited if it fits into the plan (some-interest event)
– ”I must visit this event” – denoting to visit the event in any case; the round
trip planer will ensure that this event is included (must-have event)
The user can save these event ratings to his online account in order to later
synchronize them with his mobile device.
Mobile application
The mobile software is implemented as an Android application which has cur-
rently the largest smartphone market share (see [7]). The software provides assis-
tance for all the identified tasks. In figure 1 a schematic overview of the different
screens and how the user can navigate through them is given. On first use a
short setup process is started, shown in the upper right corner. First we ask
the user for permission to log his interaction with the application. The second
step in the setup process is a small questionnaire, which asks for the user’s age
and how often he has visited the Long Night of Music before. The third screen
lists all music genres present on the evening and prompts the user to declare
his interest in them (see figure 2a). These genres are later used to generate rec-
ommendations. This concludes the setup process and leads the user to the web
profile loading screen where he is taken directly on subsequent application starts.
On this screen the user may optionally load the interest profile which was saved
before on the website. Next comes the main screen of the application: a map
with routing instructions at the upper screen border if a route has already been
calculated (see figure 2b). On this screen the user has multiple options:
He may browse the available events like on the webpage (see figure 2c). The user
may filter the available events by busline, by genre or by a given search term.
For each event a detailed information can be viewed and the user may indicate
his interest in it with the same three options as on the website.
Another option is the recommendation of a tour with a single event. The user
may want to only plan the next event visit and request guidance to it. In this
case the user must select a starting point and a starting time. The system then
recommends five events which are both nearby and similar to the user’s pre-
ferred music genres, taking into account the opening hours. If the user is not
satisfied with the recommendations, he still has the option to browse the events
and select an event by hand. In both cases the system then calculates a route to
the selected event and presents it on the route overview screen which leads back
to the map.
A third option is the recommendation of a round trip, which is only available
Planning and Navigational Assistance for Distributed Events 7
Fig. 1: The overall application layout
if the user has already marked some events for being interesting to him. The
system then asks the user to provide a starting and ending point and starting
and ending time. The planning of the round trip is based on an Iterative Deep-
ening Algorithm for solving the Orienteering Problem With Time-Windows as
described in [5] where it was used for tourist guidance. The adaption for plan-
ning events with fixed dates and also taking into account must-have events is
shown in [6]. After the calculation is finished the round trip is shown on the route
overview screen. From there the user can switch to the route editing screen (see
figure 2d). Route editing allows the user to change the route in the following
ways:
– Increasing or decreasing the duration at an event
– Removing an event
– Shuffling the order of events by drag and drop
– Inserting an event at a position in the tour
These operations are only permitted if the resulting tour is still valid, e.g. all
temporal constraints are still fulfilled. Insertion of a new event behaves basically
the same as the recommendation of a tour with a single event: the recommended
event is recommended based on the distance to the previous event in the tour
and the similarity to the user’s preferred music genres. The user may either
choose one of the recommended events or select any other event. Once the user
has finished route editing he can return back to the route overview.
On return from the route overview the map shows the first routing instructions
8 Planning and Navigational Assistance for Distributed Events
(a) Genre Profile (b) Map (c) Event Browser (d) Route Edit
Fig. 2: Screenshots of the Application
on the upper screen border. The user may navigate through the routing instruc-
tions by tapping arrows to the left and right of the instruction. The routing
instructions are of one of three types: walking, travelling by bus or visiting an
event. On leaving an event and switching to the next instruction by tapping the
right arrow, the user is asked whether he has visited the event. This information
is used to mark an event as visited which is necessary in subsequent round trip
calculations. When there are no more routing instructions the user is invited to
calculate his next route. In this way the user can alternate between tours with
multiple events and single event recommendations.
User-provided Context The context of the user plays an important role in
any assistance system – especially a navigational one – by providing the user at
any time with the right guidance [4]. Android Smartphones offer a huge number
of available sensors for measuring the exogenous context like position sensors
(GPS), acceleration sensors, rotation sensors and light sensors. Of these the
most interesting sensor for navigational assistance is the GPS sensor which has
two severe drawbacks: Its accuracy in indoor environments and street canyons is
strongly reduced and the power consumption is high. The Long Night of Music
starts between 6pm and 7pm and runs well beyond 2am. Thus a system de-
pending on GPS positions would be highly problematic because especially older
Android Smartphones would run out of power if using too much of it. Another
problem is that most events are indoor which makes positioning with GPS un-
usable.
These causes us to design a system which is independent of positioning technolo-
gies. Instead we let the user provide the application with contextual information:
for tour recommendation the system asks for the starting and ending points.
The navigational guidance is in complete control of the user as he can navigate
through the routing instructions himself. Thus the system is completely func-
tional without using the GPS sensor but if the user needs to know his current
position he can activate the GPS sensor to indicate his position on the map.
Planning and Navigational Assistance for Distributed Events 9
User-Study
In order to evaluate the system use we conducted a naturalistic user study.
Our aim was to find out how visitors interact with our application and how it
changes their behavior on the Long Night of Music. To answer these questions we
worked together with the organizers of the Long Night of Music and developed
the offical smartphone application ”Long Night App – The mobile companion”
as described above. The application was promoted in the booklet and on the
offical webpage. It asks the users for permission to recorded all their interactions
with the system and 191 users confirmed. Log data was recorded when users
switched between screens, selected events to visit, requested a route, edited the
route and many more. The data also include additional meta information about
each interaction, e.g. what the input parameters for the route planning were.
The results of the questionnaire at the beginning of the application is shown in
figure 3. Users of the application were slightly younger than the average Long
Night of Music visitor as reported by a user survery in 2010 [1] as shown in figure
3; despite both having a median of 30-39 years. The number of previous visits is
especially interesting as over 60 percent of users were first time visitors which is
surprising, given that the event has taken place every year since 2000. In order
to keep the questionnaire short (and increase the willingness to fill it out) these
two questions were the only demographic data acquired. A second questionnaire
for getting feedback about the application was presented to the user on quitting
the application. Unfortunately this questionnaire was not filled out by many
users since most users switched to other applications without quiting the app
and let the android system quit the application automatically later on. The
Fig. 3:
Left: Age distribution of the app users, the visitors in 2010 and the interviewees
Right: Previous visits to Long Night of Music of the app users
recorded interactions were transfered every 15 min to our server. Multiple issues
were encountered with the interaction recording, resulting in some data loss.
For example: Smartphones running out of power, users exiting the application
while being in a dead zone and some technical problems with the logging itself.
Fortunately we can spot these positions in the logged data and can treat them
10 Planning and Navigational Assistance for Distributed Events
as application exits.
A very rich information source on how the users behave is the resting time
on each screen. As some users even left the application running over night we
assume after two hours of no interaction, that they have left the application.
This seemed to be a sensible value as confirmed by manual analyis. We filtered
out all users quiting the application after less than 10 minutes of usage (20.9%
of all users) as these users were most likely faced with some problem, however
further investigation is needed. The remaining 151 users used the system on
average for 167 minutes with a maximum usage time of 639 minutes. Table 1
shows the screens these users spent most time on. The high percentage for the
Table 1: Resting time on each screen
Map 48.2% Event Details 12.8%
Event Browser (by tour) 11.2% Route Overview 3.9%
Event Browser (by genre) 10.4% Change Preferred Genres 1.4%
Event Browser (search) 1.2% Web Profile Loader 1.8%
Event Browser (recommendation) 2.2% Route Edit 1.0%
Event Browser (marked by user) 1.1% Other 4.8%
route overview screen lead us to manually analyze the data. We found that some
users did not return to the map after calculating a route but stayed on the route
overview screen. This was not intended but suggests that there may be a need
for more than simply a map as a main screen. Other investigations showed us
that users were not using the arrow buttons for navigation through the routing
instructions but instead switched regulary from the map to the route overview.
This again underlines the need for providing a route overview as part of the main
screen.
Users calculated 70 round trips with an average of 9.8 selected events for inclusion
of which 6.0 events on average were included in the recommended tour. As
expected the distribution of selected events is zipf-like (exponential decay) with
only few people selecting a lot of events and most most people selecting only
few events. We conclude that a lot of users do not have the time and will to
go through all the events in order to rate them, therefore the application could
assist these users in recommending the inclusion of further events based on the
few already rated events, e.g. via collaborative filtering [12]. Unfortunately we
were not able to reconstruct the events the users actually visited as only a few
users used the facility to navigate through the routing instructions and we have
no additional positional data.
Another interesting finding we did not expect is the usage of the event search:
of the logged search terms 84.4% are proper names – the name of the event
location or the name of a band – and thus are not covered by the topic search
we implemented. In the next version of our software we will automatically detect
proper names in the data and provide suggestions to the user while he is typing.
Planning and Navigational Assistance for Distributed Events 11
These suggestions could be selected and ranked by the edit distance between the
already typed letters and the available proper names. This will also reduce the
number of letters the user has to type on the touchscreen.
The Interview Results
At the start of the Long Night of Music 2011 we conducted 36 interviews with
individuals or groups of visitors to get insights on what we should consider the
for subsequent events.6 We positioned ourself in front of the starting concert and
spoke to people waiting for others. Our aim for the interview was to find out
how visitors plan and behave before and during their visit and why. The age
distribution of the participants is not as representative as with the application
(compare figure 3): 14.2% below 18 years, 54.2% 18-29 years, 10.3% 30-39 years,
13.5% 40-49 years, 3.9% 50-59 years, 3.9% above 60 years (median is 18-29 years
old). Also the high number of first time visitors of 76% shows that the location of
the interviews had a huge influence. We asked the interviewees to estimate how
many events they predict to visit and most of them answered with an interval
which was on average between 4.1 and 5.2 events. This number is highly valuable
to us as it means that visitors plan to stay longer at events as we have predicted
(30 min). The most important question was about their evening preparations:
33% did not make any plans and decided completely spontaneously where to go
next without even knowing the available events in advance. 53% marked events
of interest to them but did not built up a plan. 14% planned at least partly a
sequence of event visits. We are surprised about the large number of spontaneous
visitors – some did not even have a ticket yet – and need to rethink about the
assistance we can provide to this group of visitors. The system might need to give
recommendations with little to no user input to support this type of user. This
type of cold start problem can be solved by a collaborative filtering approach
as described in [12]. The other users might build on this initial recommendation
and spend additional time on rating events to improve the recommendation.
Related Work
To the best of our knowledge no other research on the field of assistance to
distributed event visitors have been done yet. But there are several research
projects working on tourist guidance which is a similar problem if the system
generates tours with multiple Points of Interest (POIs).
In [11] a personalized electronic tourist guide for the city of San Sebastian is
described: first the user has to choose between four interest profiles. Depending
on the chosen profile a score is given to every POI. Based on these scores the
6
Actually these interviews should be performed before the development of the appli-
cation starts but the Long Night of Music only takes place once a year. Thus we
have more of an iterative improving process than a sequencial development pipeline.
12 Planning and Navigational Assistance for Distributed Events
system then generates a tour taking into account additionally constraints spec-
ified by the user. In a third step the user may modify the calculated tour. The
system focuses on the generation of the route which also uses an iterative local
search algorithm similar to the one used in this work. Rudimentary assistance
during the tour is provided by a detailed summary screen and a downloadable
pdf. The interaction with the system is described but not evaluated yet.
The Dynamic Tour Guide [8] is a tourist guide for the city of Görlitz. Each
available POI is assigned to one or more semantic classes of an ontology. The
system estimates the score for each POI by a semantic matching between the
interest the user has specified and the POIs classes. A selection of individual
POIs or the selection of POIs as “must-have” is not possible. The tour is then
calculated using an approximation algorithm based on a depth first search. It
remains unclear if opening hours are taken into account. Assistance during the
tour is provided by a separate navigator program, which guides the user from
one POI to the next. Additionally the system tries to adapt to the users behav-
ior and replan accordingly. However, a manual modification of the tour is not
possible. An extensive user study was performed and has shown the usefulness
of the system to improve the diversification of tourist flows.
In [9] Kurata presents another approach to relieve the user from the burden of
having to specify his interest in each sightseeing attraction in advance. Instead,
Kurata develops the concept of a computer-aided interactive tour planning sys-
tem: The system recommends not one, but multiple plans at once each based
on a different potential user preference vector (art, nature, etc.) and therefore a
different “character”. The user can then select the one which he likes best which
updates the users preference vector accordingly. The next iteration of interac-
tion starts with the system again suggesting multiple routes based on the new
preference vector. The approach sounds very promising for desktop computers
but might be quite confusing for mobile users as multiple routes might not fit
on a small screen.
A comparison of further tourist systems and their features is given in [10].
Conclusion and Future Work
As shown in this paper it is possible to provide mobile assistance to visitors of
distributed events, however the large number of recommendation and assistance
tasks makes it an absolute must to think about how interaction with the system
can be made more intuitive. We have shown how this can be accomplished in a
first iteration of an design and evaluation process. Nevertheless, the recordings
of the users interaction have shown us how the system must be improved in
the next iteration to increase the overall user experience. Furthermore the sys-
tem provided us with information about how the users behave on a distributed
event. This knowledge is enriched by the information we gained from the inter-
views which not only tells us how, but why users behave in a certain way.
Based on this information we plan to make a number of improvements to the ap-
plication. The collected data hints that users are not aware of the more advanced
Planning and Navigational Assistance for Distributed Events 13
features available in the application and in which way to make use of them. We
therefore plan to guide the user through the steps needed to accomplish the
planning and navigational tasks; namely the rating of events, the starting of the
route planning, the editing of the tour and the navigation through the routing
instructions. All this has to be implemented in a noninvasive way since willing-
ness to spend time on preparation of a distributed event varies largely between
users. We also plan to integrate more explanational texts in the application itself
and want to provide suggestions to the user on how to proceed, e.g. giving hints
on how the user can improve a sparse tour by selecting additional events. As a
lot of users are spontaneous visitors we plan to improve the possibilities to pre-
dict user ratings for events based on the user’s interest profile and by the usage
of collaborative filtering techniques. Additionally we want to research how we
can best adapt our system for other distributed events and how visitor behavior
differs between those.
Acknowledgment This work was supported by the Embedded Systems
Initiative (http://www.esi-anwendungszentrum.de).
References
1. Münchner Kultur GmbH: Die Lange Nacht der Musik – Besucherbefragung, 2010
2. B. Ludwig, M. Hacker, R. Schaller, B. Zenker, A. V. Ivanov, and G. Riccardi: Tell
me your needs: assistance for public transport users. ACM SIGCHI on EICS. 2011
3. J. Schrader, B. Zenker, R. Schaller: ROSE - Auf dem Weg zur mobilen Assistenz.
Journal: Knstliche Intelligenz - KI , vol. 24, no. 2, pp. 153-157. 2010
4. B. Zenker, R. Schaller, J. Schrader: Opportunities for Leveraging Context in Pedes-
trian Navigation. CAIA 2010. In proceedings.
5. P. Vansteenwegen, W. Souffriau, G. Vanden Berghe and D. Van Oudheusden: Iter-
ated Local Search for the Team Orienteering Problem with Time Windows. Com-
puters & O.R. 36. 2009
6. R. Schaller: Entwurf und Implementierung eines Algorithmus zur Planung be-
sucheroptimaler Rundreisen bei konkurrierenden und terminabhängigen Veranstal-
tungen. Diploma Thesis. University of Erlangen-Nuremberg. 2009
7. NielsonWire: Android Leads in U.S. Smartphone Market Share and Data Usage.
http://blog.nielsen.com/nielsenwire/?p=27793. May 31, 2011
8. R. Kramer, M. Modsching, K. Ten Hagen: A City Guide Agent Creating and Adapt-
ing Individual Sightseeing Tours Based on Field Trial Results. IJCIR. 2006
9. Y. Kurata: CT-Planner2: More Flexible and Interactive Assistance for Day Tour
Planning. ENTER 2011. Information and Communication Technologies in Tourism
2011
10. W. Souffriau, P. Vansteenwegen: Tourist trip planning functionalities: state-of-the-
art and future. ICWE’10. 2010
11. A. Garcia, O. Arbelaitz, M. T. Linaza, P. Vansteenwegen, W. Souffriau: Personal-
ized tourist route generation. ICWE’10. 2010
12. G. Adomavicius and A. Tuzhilin: Toward the next generation of recommender
systems: A survey of the state-of-the-art and possible extensions. Knowledge and
Data Engineering, IEEE Transactions on, 17(6):734749, 2005.