In this paper we describe our work on developing and evaluating 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-speci c event recommendations, support for planning a good sequence of events and nally assisting the user on his tour, taking into account his context. The developed mobile 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.
The past decade has seen a massive increase in what we call distributed events; in which multiple cultural or scienti c institutions work together to organize and market one evening dedicated to a single theme, e.g. museums. Participating institutions usually extend their opening hours far into the night. The ticketing is simpli ed 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 partic1 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/ ipants vary but larger ones have up to a few hundred o ered events at di erent 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 nd his way to bus stops, some of which may be di cult 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 semiautomation and assistance. But are these really the problems the visitors experience? 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 rst de ne the problem domain we want to tackle: we list different properties which can be used to categorize the di erent distributed events which illuminates the problem domain from the perspective of the software designer. 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 ndings 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.
Although most distributed events have a very similar name { mostly "Long Night of ..." { their structure can di er which can have serious consequences for the design of assistance systems. We have identi ed the following main di erences: { Public transport available:
Is public transport included in the ticket price? This has huge implications on the planning algorithms involved. { 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 xed 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 organizer selects one bus stop for each event to help the visitors nd the right bus stop. This also simpli es 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 xed 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 o ered events, e.g. ltering events by certain criteria or even recommending events based on user pro les. { 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 eld of science on a Long Night of Science. But if the topic is broader it becomes much more di cult to represent an event in a way to easily query and recommend events.
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 Munchner Kultur GmbH who provided all 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 xed 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
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 o ered 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 simpli es 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 [
Whilst visiting an event, the visitor might be interested in additional information 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 speci c event and therefore must skip another event. External factors are mostly due to di erences between what was announced beforehand 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 t into an
already existing plan and matching said events to one's own interests is a
di cult task in itself because it is highly related to replanning task.
The tasks can be split up into two di erent phases as suggested by [
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 e ort as phase one has to be implemented twice. To reduce this e ort it was decided to only implement assistance for the rst 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 bene ts most from the larger screen real estate.
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
its opening hours. Comfort features like searching for events are also provided
(the used topic-based search engine used is described in [
The mobile software is implemented as an Android application which has
currently the largest smartphone market share (see [
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 ve events which are both nearby and similar to the user's preferred music genres, taking into account the opening hours. If the user is not satis ed 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
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
Deepening Algorithm for solving the Orienteering Problem With Time-Windows as
described in [
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 [
These causes us to design a system which is independent of positioning technologies. 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 functional 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.
In order to evaluate the system use we conducted a naturalistic user study.
Our aim was to nd 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 o cal smartphone application "Long Night App { The mobile companion"
as described above. The application was promoted in the booklet and on the
o cal webpage. It asks the users for permission to recorded all their interactions
with the system and 191 users con rmed. 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
gure 3. Users of the application were slightly younger than the average Long
Night of Music visitor as reported by a user survery in 2010 [
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 con rmed by manual analyis. We ltered 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 Map Event Browser (by tour) Event Browser (by genre) Event Browser (search) Event Browser (recommendation) Event Browser (marked by user) 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 ltering [
Another interesting nding 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. 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.
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 nd 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 gure 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 rst time visitors of 76% shows that the location of
the interviews had a huge in uence. 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 ltering approach
as described in [
To the best of our knowledge no other research on the eld 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 [
In [
A comparison of further tourist systems and their features is given in [
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 rst 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 system provided us with information about how the users behave on a distributed event. This knowledge is enriched by the information we gained from the interviews 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 application. The collected data hints that users are not aware of the more advanced 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 willingness 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 predict user ratings for events based on the user's interest pro le and by the usage of collaborative ltering techniques. Additionally we want to research how we can best adapt our system for other distributed events and how visitor behavior di ers between those.
Acknowledgment This work was supported by the Embedded Systems Initiative (http://www.esi-anwendungszentrum.de).