Cascading Information for Public Transport Assistance 2014/WEBIST... · The Citymapper application addresses many of the crucial, common issues of public transportation and is appealing.

Cascading Information for Public Transport Assistance

Christian Samsel1, Shirley Beul-Leusmann2, Maximilian Wiederhold1,Karl-Heinz Krempels1, Martina Ziefle2 and Eva-Maria Jakobs2

1Information Systems, RWTH Aachen University, Aachen, Germany2Human-Computer Interaction Center, RWTH Aachen University, Aachen, Germany

fsamsel, wiederhold, [email protected], [email protected], [email protected]

Keywords: Context-Awareness, Gamification, Travel Information, Mobile Applications, Usability.

Abstract: Over the last years, public transport has become both more prominent and more diverse. Because of the com-plex structure of today’s public transport networks, an electronic guidance is effectively required. Usuallydifferent transport modalities and service providers offer their own application to which the traveler has toadapt after changing between services. Additionally a current trend in mobile applications is the customiza-tion of GUI elements which leads to appealing looks but usually also to cluttered presentation of information.Both these problems cause a high cognitive stress on the traveler using the mobile application, especiallywhile conducting other activities at the same time. Our approach to mitigate these issues is to create a mo-bile application applying the Gamification principle Cascading Information Theory to simplify the usage andadditionally to use a back-end which allows to integrate data from various services hereby unifiying the pre-sentation. A prototype of the application was evaluated in an initial user test for comparing our approach tothe most popular mobile travel application in Germany.

1 INTRODUCTION

Global trends like urbanization, climate change, andpeak oil enforce and accelerate the change of peo-ple’s mobility; the focus shifts back from individualtransport to public transport. Traditional public trans-port networks, like subways and bus networks, havegrown in size and new forms of transport systems likecarsharing have been introduced. Consequently, thenumber of potential itineraries from one point to an-other raises, each with specific features, e.g., differ-ent prices and comfort levels. To use public transportefficiently, meaning to decide on the most suitableitinerary and to follow it closely, the traveler requireseffective electronic assistance. To do so a large num-ber of more or less appropriate travel information sys-tems have been established. Such travel informationvary from traditional web platforms used for plane ortrain ticket booking to modern mobile applications forsharing rides.

1.1 Motivation

From our continuous work on travel information, in-door navigation, diversity, and mobile applications we

recognized that most current mobile applications forpublic transport are flawed in terms of usability un-der cognitive stress. Current applications (see Sec-tion 2.1) shine with a fancy Graphical User Interface(GUI), many configuration options and a high amountof information. Such applications perform well in sit-uations where the traveler can direct all of her cogni-tive capacity to the application, but fall back in termsof usability in stressful situations. Stress can be in-troduced by noise, time pressure, unknown surround-ings, or required multitasking (e.g., walking and usinga device at the same time).

To improve the usability under stress we wantedto create a concept and a prototype which simpli-fies mobile travel assistance compared to already ex-isting applications. While creating a concept basedon our experience in indoor navigation (Heiniz et al.,2012) we realized that the initial GUI layout and in-teraction pattern is strongly related to archetypicalMassively Multiplayer Online Role-Playing Games(MMORPGs) like World of Warcraft (Corneliussenand Rettberg, 2008). World of Warcraft, for example,uses non-intrusive, still useful indicators/descriptionsfor the next waypoint in a quest. The user has accessto exactly the required information she needs to ful-

411

fill the given task (e.g. travel to a specific location)at one glance. This principle of providing exactly therequired information in the current context is calledCascading Information Theory. We wanted to trans-fer this principle to a real world application.

1.2 Cascading Information Theory

In his 2010 blog entry1, Erick Schonfeld issuedhis company’s “playdeck” of game dynamics termswhich included most if not all of the currently em-ployed elements of gamification. Gamification is aterm which was coined by Nick Pelling in the early2000’s. Since then many different interpretations ofthe term have surfaced, making its exact meaning hardto conceive. Recently, there have been efforts by sev-eral researchers to reach a mutually agreed on defini-tion. One of the more elaborate and most cited ver-sions originates with (Deterding et al., 2011). Theydefine gamification as: “The use of game design ele-ments characteristic for games in non-game contexts.”Elements of games are components or interaction pat-terns that, in combination, create the game experi-ence. By abstracting these elements from their gameimplementation and employing them in another con-text (e.g. business software etc.) the developer makesuse of people’s play instinct. If a user is familiar withthe ported game element there is a high probabilitythat she will associate it with its original purpose andtherefore be able to correctly utilize it.

Along with well known Gamification componentslike achievements, Schonfeld lists the principle ofCascading Information Theory. Cascading Informa-tion Theory suggests to unveil information about thegame in as small amounts as possible to ensure theuser’s focus exactly on the desired objective. Thereby,confusion and misdirection of players by providingexcess information is prevented and each iteration ofnew data can be applied directly.

The remainder of this paper is structured as fol-lows: In Section 2, existing applications and relatedresearch are discussed. Section 3 describes our ap-proach to the problem on an abstract level, whereasSection 4 demonstrates the actual prototype imple-mentation. The evaluation is presented in Section 5and Section 6 concludes the paper.

2 RELATED WORK

This section lists popular related applications and re-cent research.

1http://techcrunch.com/2010/08/25/scvngr-game-mechanics/

Figure 1: The DB Navigator application includes all tripdata plus additional texts and various buttons in one viewwhich impedes traveler orientation.

2.1 Public Transport Applications

The following part exhibits commonly used and highrated mobile applications for public transportation inGermany, not only explaining the benefits but alsoelaborating on flaws and drawbacks of the individualapplication, in order to convey the motivation for anew interface design. We considered only Europeanapplications because travel information applicationsare only meaningful applicable in the area for whichthey are created.

DB Navigator

Figure 1 shows a screenshot of the most popular(Statista GmbH, 2012) application for public trans-port in Germany, the DB Navigator. The DB Naviga-tor is developed by HaCon AG on behalf of DeutscheBahn. Therefore the assumption that its prevalence isdue to the fact that its publisher is the main Germanprovider of inter-regional public transportation sug-gests itself. The application also features fully com-patible intermodal trip planning and supports real-time information about delays and arrival times. Inaddition to these functions there is also support forrudimentary walking directions and direct online pur-chase of tickets.

Despite its vast amount of features, the decent ap-pearance, and the possibility of providing the com-pany’s own data the application has a few drawbacks.

WEBIST�2014�-�International�Conference�on�Web�Information�Systems�and�Technologies

412

Figure 2: The London Citymapper is a very advanced ap-plication which is specifically adjusted to the needs of theLondon inhabitants.

The trip view shows the complete trip information inone tabular environment which requires the travelerto scroll vertically if the trip involves more than onechange. To get walking directions the traveler has topress the button which resembles a map. The highnumber of GUI elements, the inconsistent coloringand required interaction complicate the interpretationand filtering of the needed information for the travelerand might delay the usage especially in a high stresssituation.

Citymapper

The Citymapper application (London version tested)is well-known in England. The application includesa broad range of features such as generating inter-modal trip plans using real-time information. Hav-ing selected the departure and destination locationsthe application suggests a variety of different possi-bilities to reach the desired spot. In addition to the in-termodal route suggestions the user is presented withvariations like routes only involving buses or rain safeones and information about the current context suchas the weather at the destination. The route detailview consists of a large map view displaying the se-lected trip itinerary and a table below it listing the in-dividual parts of the journey (see Figure 2).

The Citymapper application addresses many ofthe crucial, common issues of public transportationand is appealing. However, it is specifically designed

to match the London network transportation. Thisis a major drawback, adapting to a different applica-tion based on the whereabouts requires cognitive re-sources. This issue is exacerbated by the quantity offeatures which might be difficult to comprehend in ashort amount of time.

2.2 Existing Research Work

This section presents recent work in the area of pub-lic transportation and mobile navigation systems andaims to give a short insight into the current state ofresearch.

An attempt to create a multimodal routing servicewith directions for pedestrians is made in (Yu andLu, 2012). In addition to evaluating travel modesby the criteria of distance, time, fare, and transfer,they use dynamic information about real-time and his-toric traffic data to enable accurate estimations. Thecomputation of transit routes is aided by a high pri-ority mode expansion strategy which incrementallygenerates parts of the most suited path. Similarly,the sophisticated algorithm developed by (Zheng andXie, 2011) allows for accurate generic and personal-ized recommendations solely based on the analysis ofuser GPS traces. By correlating the travel behaviorof users with their locations they are able to estimateuser interests.

(Baus et al., 2002) introduce their concept of apedestrian navigation system with a hybrid solutiontitled Project REAL. Already accurately predictingthe evolution of personal navigation systems (“Per-sonal navigation systems that extend beyond today’suse in cars will play a major role in the future.”) theypresent their approach featuring a combination of in-door and outdoor navigation. The system is capableof automatically adapting to location changes and pre-senting directions to the traveler on a variety of differ-ent devices.

Since the primary instruments for outdoor naviga-tion are geolocation services, accomplishing indoornavigation is an incomparably more difficult task be-cause exact positions are hard to determine. Never-theless, considering the topic is crucial for any at-tempt at implementing a complete navigation system.In (Rehrl et al., 2005) a solution for the guidanceof pedestrians inside transport interchange buildingsis proposed which relies on generating a hierarchicalmodel of the complex and providing instructions aug-mented with map views. (Chowaw-Liebman et al.,2010; Heiniz et al., 2012) present a turn-by-turn ap-proach to manage navigation inside large, compli-cated buildings using landmark representations fororientation rather than street names. The work is

Cascading�Information�for�Public�Transport�Assistance

413

based on the idea that pedestrians mostly rely on land-marks as navigation cue (May et al., 2003).

The TransitGenie project (Biagioni et al., 2009)aims at implementing a public transportation naviga-tor with a transit tracking service which consists ofan activity classification algorithm to determine usercontext as well as trajectory matching to enhance ve-hicle tracking. In their later work, (Biagioni et al.,2011) further pursue the automatic real-time trackingof transit traffic and the computation and predictionof arrival times.

The UbiBus project started an attempt to create anubiquitous system for public transport assistance us-ing context information (Vieira et al., 2011). The au-thors incorporated access to an intelligent transporta-tion system application in buses as well as web ser-vices and smart phone apps, so that passengers areenabled to receive information about the progress oftheir bus. (Pessemier et al., 2013) proposed a frame-work which is capable of extracting high-level in-formation about user context. Initially the systemrecognizes and collects very basic data to create afoundation. Complex user activities are then bro-ken down into smaller parts and connected via con-ditional relationships which are afterwards matchedwith the previously recorded basic contexts. If a com-plex context is identified this way, an application iscapable of requesting detailed activity recommenda-tions from a central server using a four-part scor-ing model. (Christoph et al., 2010) proposed an in-tegrated context-detection service architecture whichcombines information from different approaches.

(Keller et al., 2011) observed that creating an idealrepresentation of public transit trip information on amobile device is a difficult task. Using paper pro-totypes, the authors compare different approaches todisplay intermodal travel chains.

3 APPROACH

While working on public transportation informationsystems we identified parallels between real worldnavigation and navigation in, e.g., MMORPGs. Nav-igation elements in games are usually lean and unob-trusive as to not distract the player from her main task,but still are easy to comprehend. In a real world envi-ronment full of distractions, noise, and confusion thetraveler’s concentration can rarely be focused entirelyon operating her mobile device. When traveling ona bus, entering a rail station, or even just walking to-wards a bus stop the traveler needs to be capable ofchecking her itinerary as quickly as possible. There-fore, an assistant application is required to be uncom-

plicated and easy to use. In order to minimize theamount of cognitive resources needed by the naviga-tor, the user interface needs to be plain and respon-sive, similar to navigation elements in MMORPGs.

Following the general principle of Cascading In-formation we divided and analyzed information pre-sented by mobile travel information applications re-garding necessity. We only considered essential in-formation for inclusion in our GUI concept. For ev-ery piece of essential information we assigned a timespan at which it is required, and an order of priority(results in Section 3.3). Information will be presentedif and only if it is required at this particular point intime and is shown in descending order of priority.

This is achieved by creating a turn-by-turn-likeinteraction. Travelers continuously progress throughthe trip by steering from intermediate target to targetand ultimately arrive at the destination. Only infor-mation required to reach the next intermediate targetis conveyed to the user. The design of the GUI is in-tended to noticeably enhance users’ public transportnavigation experience in comparison with existing ap-plications. It is supposed to aid the traveler’s naviga-tion and make processing routing information as easyas possible. Device-independent mockups presentedin Figures 3(c) and 3(d) show an early stage of design.

3.1 Planning the Trip

A trip is the journey from a specified starting point(usually in the vicinity of the traveler’s current loca-tion) to a destination point in a previously set timeframe, using one or several different modes of travel.Although it is possible to add numerous other param-eters to the plan, they are not included in the appli-cation for the sake of simplicity. Conceivable ad-ditional options for planning the trip, although in-creasing complexity, include specifying the desireddate/time of arrival instead of departure, preference ofdirect connections or favored traveler profiles. Usersof public transport navigation aids often are in need ofpublic transit information regarding their current lo-cation, such as to quickly return home from a friend’shouse or when to take the train to get to university.Therefore incorporating the latest position update as alocation parameter for the trip request is deemed ap-propriate.

Figure 3(a) shows the first depiction of the ini-tial planning view to input the desired trip parame-ters. The time of departure is shown in a textual rep-resentation and changeable by using a mechanism orby input via a (virtual) keyboard. Finally, the modesof travel are to be chosen using a multiple-selectionsegmented control which lists all possibilities and in-


414

(a) Planing view. (b) Trip list view. (c) Trip view (bus). (d) Trip view (walking).

Figure 3: Early development sketches.

dicates their selection state. The bottom-most buttonlabeled “Search” will then issue the request and fetchone or more trip plans. One reasonable improvementto the interface might be the use of meaningful iconsinstead of the textual description of the travel modesin the segmented control. This is due to the fact thatreading a piece of plain text usually takes longer thanrecognizing a commonly used icon.

3.2 Selecting a Trip

After submitting the trip inquiry, the traveler has tobe presented with the trips suggested. The mockupin Figure 3(b) depicts an early version of a tableview whose rows each contain one of the provideditineraries. The times of beginning and arrival of thejourney are mandatory attributes for people to judgethe expediency of a proposed trip plan. Especiallyif there are multiple possibilities for the modal com-position of a route, displaying the different transportmodes during the selection progress distinguishes anyunique features of the trip. Displaying icons unam-biguously depicting the travel modes not only savesscreen space but also makes it easier to comprehendthe complete routing process at a glance. In additionthe starting and destination locations which the trav-eler had previously specified are presented on top ofthe table.

3.3 Assisting the Trip

The trip view shown in Figures 3(c) and 3(d) repre-sents the most significant component of the interfaceand is also where the traveler is likely to spend thehighest amount of time while actually using the ap-plication. Being the main source of detailed informa-tion about the journey, the trip view needs to fulfillcertain requirements. Most importantly, all requiredinformation needs to be quickly accessible and easily

comprehensible. A traveler should be able to capturethe information which is necessary for her naviga-tion at one glance without any interaction. Followingthe principle of Cascading Information introduced inSection 1.2, it is assumed that the traveler does notrequire the complete trip information during her nav-igation process. Therefore, the whole trip plan canbe subdivided into small entities containing only thefeatures of a single step along the route. Using thisdistinction allows displaying these entities individu-ally. A type of view is needed which enables comfort-able progression through the route and is easy-to-use.Consequently, the interface will not feature a verti-cal scrolling view. Instead, it is intended all the datanecessary for the corresponding stage of the trip arevisible at once, eliminating any need to perform time-consuming repositioning of screen elements or goingthrough all the information to find the respective pieceof information.

Using Context Awareness

To present exactly the required information for thecurrent situation, respectively the current step, knowl-edge about the current situation is required. The mul-titude of sensors included in current mobile devicesallows for precise determination of user contexts andtheir surroundings, and therefore the situation of thetraveler. By using the context data, e.g., time anddate, the location and the type of transportation ve-hicle the application is enabled to ascertain whethera user has entered the vehicle she was headed for onher itinerary. Using this information we can automat-ically deduct which step of the planned route shouldbe presented.

Since one step in the plan has a variety of at-tributes, which are potentially subject to change, thepossibilities of how to visualize them are manifold.In general one can distinguish between purely textual


415

and graphical representations of data. As depicted inFigure 3(d), the mockup GUI contains a combinationof both methods in order to take into account differentuser habits. Independent of the type of transport thegeneral interface layout stays the same. The informa-tion is always displayed at the same area to enable thetraveler to recognize relevant information at a glance.

Textual Elements

There are a few characteristics which are essentialto the navigation procedure and therefore any majorchange to them is improbable. If the step requiredpublic transportation, the required characteristics, indescending order of priority, are (also shown in Fig-ure 3(c)):

Departure and Arrival Stations. Naturally, thetraveler needs to know the stations of the transitvehicle she intends to travel by. The descriptionof the stop should not only include its name,but also some kind of information about whichplatform to enter. This holds especially truefor large buildings like central stations or coachterminals.

Vehicle Information. Public transport vehicles areusually identified by a line number and directionheadsign. Both are displayed to enable the trav-eler to find the vehicle easily.

Departure and Arrival Times. Knowing the re-spective departure and arrival times is a crucialfactor for the traveler to catch the vehicle andleave it at the right time.

When providing on-foot navigation important charac-teristics include (shown in Figure 3(d)):

Direction. Walking navigation thrives on supplyingthe traveler with the direction she is supposed towalk in. While people usually tend to use relativedirections like “left” or “slightly right” absolutedirections based on points of the compass are apossible alternative.

Distance. Information about how long the currentstep will take is generally of great interest to atraveler. Since the individual walking speed maydiffer significantly between people, the better al-ternative is displaying the distance that has to betraveled.

Street Names. The traveler requires identifiers to ex-actly recognize the planned walking route she issupposed to follow. This is most easily accom-plished by providing either the name of the streetor an identifier of a nearby junction or a well-known public place.

Also, the final destination of the journey should al-ways be visible so that the traveler is reassured she istraveling in the right direction. The top area providessufficient space to display a text which slightly resem-bles the head sign of a bus or tram and therefore seemfamiliar to the traveler.

Graphical Elements

The graphical representation of trip data is primar-ily performed by a map view which displays the sur-roundings of the traveler and her route using an onlinemap service as data source. All of the steps which aretransmitted in the planned route are marked on themap and a path overlay approximately indicates thetrack that will be traversed during the journey. Thetraveler’s progress on the route is shown by highlight-ing the map marker which corresponds to the currentstep. A compass is shown on the map to add an addi-tional easy to follow navigation cue. For the travelerto always be aware of her advancement we added aprogress bar at the bottom of the display. To preventdistraction, all graphical elements should be kept sim-ple and lean.

3.4 Back-end Requirements

Since the application is to be extensively evaluatedin a user study, it would greatly benefit from realfunctionality instead of mockup-like dummy behav-ior. Therefore, the decision was made to employ areal back-end service capable of providing intermodalrouting information for public transportation. Ideally,this service needs to include a variety of differenttravel modes as well as the possibility of extendingthe system. Most importantly the server is required toallow effortless import and use of own map and tran-sit data in a standardized format so that user testingmay be performed regionally with the appropriate in-formation.

4 IMPLEMENTATION

This section describes the actual implementationbased on our previously introduced approach. We be-gin with the process of drafting and assembling theprototype, including detailed explanations of the GUIfollowed by a brief description of the used back-end.

In the following we address the realization of theviews of the prototype GUI. Since there was relativelylittle time between the creation of the mockups andthe implementation of the application, and also be-cause of the sophistication of modern mockup tools,


416

(a) Plan view. (b) Selection view. (c) Assistance view (bus). (d) Assistance view (walking).

Figure 4: Screenshots showing the prototype implementation.

the differences are not always apparent. Because ofits popularity, stability, and the great amount of well-written documentation, Apple iOS 6 became the plat-form of choice for the development of the applicationprototype. In order to fully ensure compatibility witha real device, the application was also regularly testedon an iPhone 4.

4.1 The Planning View

The trip planning view presented in Figure 4(a) con-sists of from and to text fields, a date selector, and aPlan! button. Upon beginning text input a virtual key-board is displayed alongside several possible text but-tons. These buttons include a green position markerwhich resembles the traveler’s position. By tappingit, the traveler starts a positioning process which usesthe current geolocation, coordinates supplied by thedevice sensors to look up the current address usingreserve geocoding. This trip planning may be usedin two different scenarios: Either a traveler wants tomake a request for an entirely new route, or she is-sued the command to reschedule an active trip. In thefirst case, the next step in the navigation chain is dis-playing the list of feasible itineraries provided by thebackend server. If, on the other hand, a reschedule issupposed to happen, the application skips displayingthe trip list and selects the first itinerary, optimisticallyassuming that it embodies the temporally closest pos-sibility.

4.2 The Selection View

After receiving a response from the back-end serverthe trip information needs to be conveyed to travelersusing the selection view in Figure 4(b). The showntable contains a variety of information; on the top ofthe list, the full description of both the origin as wellas the destination location is presented. Each follow-ing row sums up the trip, containing on the left hand

side the time of departure and arrival. Furthermore thefull duration of the trip is written below. Next to thetimes the utilized modes of transportation are listed inan array of icons. Below the icons the line identifier(e.g., line number) is shown. To maintain consistencythe icons from the planning view are reused through-out the application. By reducing the icon size afterreaching a certain threshold an overflow is prevented.

4.3 The Assistance View

Presenting the stages of the trip to the traveler was oneof the main challenges in designing and implement-ing the prototype GUI. Therefore drafting it includeddevising the functions which had to be employed inorder to satisfy user needs while keeping a plain pro-file. The view grew in functionality and its featuresmatured during the process of implementation.

Since the trip is split into several parts, a similargraphical representation is an obvious consequence.The trip plan is segmented into a number of stepswhich have to be subsequently completed in order toarrive at the destination. These steps are visualized onthe map view by adding a position marker to the maplayer at the geographical coordinates of the startingpoint of each step.

In addition to showing the route path and progresson the map, a compass was incorporated into the view.Using a rotatable image of a green arrow in the up-per left corner, the traveler ought to always be awareof the direction in which her destination lies. This isachieved by computing the angle (i.e., the bearing)between the traveler’s location and her destination.Utilizing iOS ability to not only monitor the positionbut also the heading, the application uses the bear-ing and the travelers heading to create and apply anaffine transformation to the arrow image, thus rotat-ing it. As a result, travelers are able to discern thecorrect direction of their destination at any given mo-ment which is especially beneficial for walking direc-


417

tions. The concept of this orientation aid is derivedfrom games, which often provide navigation instruc-tions by displaying a compass. As the compass is onlyrelevant for walking directions, it is disabled for othermodes of transportation.

The part of the GUI displaying the textual rep-resentation presents either a step of the walking di-rections or a transit stage of the trip and contains anumber of labels and one image view for depictingthe current mode of the step, again reusing the modeicons from the planning view. If the step is part ofthe turn-by-turn walking directions it includes infor-mation about the absolute and relative direction, thestreet the traveler is supposed to follow, and the dis-tance that will be traversed during this part of the jour-ney (shown in Figure 4(d)). If, on the other hand,the view shows a transit stage, it contains details re-garding the type of vehicle, the transit route, departuretimes and station as well as arrival time and name ofthe destination (Figure 4(c)).

At the bottom of the view, a progression indicatoris placed which uses a bar style and is filled accordingto the progression in the trip. However, merely iter-ating over the steps does not accurately resemble theprogression through the trip plan, because the route isgenerally not of a linear nature. Instead, the variousparts of the journey each consume different amountsof time and therefore the advancement of the progressview was adjusted to precisely mirror the traveler’sprogress.

4.4 Back-end Realization

In order to generate some real functionality for the ap-plication prototype an existing routing solution wasrequired. The optimal candidate in this scenario isan open source complete planning service to serve asa back-end which is capable of autonomously com-puting a route between two arbitrary locations. Alsofavorable are the possibilities of freely integrating avariety of maps sources as well as a fully compatibleAPI to address the back-end server.

The OpenTripPlanner (OTP) project2 is an opensource platform which has developed a rather largecommunity since its launch in 2009. While still indevelopment, it already features intermodal trip plan-ning with special support for bikes, allows the importof several internationally popular data types and of-fers a RESTful web API. OTP is mainly Java-basedand consists of a server which performs routing andsupplementary services, and a basic but effortlesslyextensible web application enabling users to searchfor a route via their web browsers. Furthermore, the

2http://opentripplanner.com

RESTful API is able to provide the same experienceusing either XML or JSON formatting, enabling ac-cess to the service with mobile clients.

The project employs the established A� searchalgorithm for path finding when walking and theMOA� algorithm for intermodal trips after the pro-vided raw map data has been indexed by OTP’s ownmap builder application. By default, all maps are ob-tained from the well-known OpenStreetmap (OSM)project, which distributes very up-to-date maps on anopen source basis. To ensure compatibility, the devel-opers use Google’s General Transit Feed Specifica-tion (GTFS)3 format for moving and importing transitdata. The project includes a graph builder tool whichis capable of analyzing any provided GTFS data feedand determining the required map excerpt, and auto-matically downloading the corresponding data fromOSM. Afterwards, the program computes a largegraph object containing all the correlated data readyto be used by OTP.

5 EVALUATION

For evaluating the prototype a user-oriented evalua-tion was applied.

Figure 5: Participant interacting with application prototype.

5.1 Methodology and Test Participants

The prototype application and the DB Navigator wereevaluated in a lab user test (see Figure 5) in orderto identify usability problems and have an insight inprospective users’ assessment. The test encompasseda leading scenario and three tasks which had to besolved by interacting with the applications. The pur-pose of the leading scenario was to give the test tasksa contextual framing for supporting test participantsin understanding the whole point of the test.

3https://developers.google.com/transit/gtfs


418

Scenario:You are a student in Aachen and you havea student ticket, which allows you to use allpublic transportation in your state. For thisreason, you are a frequent user of Aachen’spublic transportation. You own an iPhone anduse trip assistant apps to inform yourself aboutdeparture times.

After reading this, test participants were given thetask instructions which focused to test the app’s mainfunctionality routing. To reduce the cognitive loadand concentrate on the task processing, instructionsfor the next task were handed out after finishing thecurrent one.Task 1 was about routing from the actual location to abus stop:

It is 09:18 a.m. at the 3rd of August 2013.You are running through an unknown street.You have to go to the Audimax, a universitybuilding, to write an exam. The exam willstart at 10:00 a.m. Use your app to find in-formation about a bus ride to your exam. Usethe integrated functionality to find your actuallocation.

Task 2 was about routing from a bus stop to an ad-dress:

It is 03:03 p.m. at the 3rd of August 2013.Your performance during the exam was moreor less successful. You are having a late lunchwith your girlfriend Claudia and have to plan atrip from the Pontstrasse, Aachen to the homeimprovement store because you have to buymaterial for fixing a shelf for Claudia. Thehome improvement store is located in Roer-monder Strasse 177, Aachen. You are againpressed for time because later you have an im-portant appointment. Use your app to reachyour destination by bus as quick as possible.

Task 3 was about routing from one address to another:It is 5:13 p.m. at the 3rd of August 2013.After you have carried out all tasks you havepromised to Claudia you have to go quicklyto your family for helping them to preparea birthday party. At the moment, you areat Claudia’s place in Oppenhoffallee 143,Aachen. Your parents live in Burtscheid, asuburb of Aachen, in the street Birkengrund10. Aachen. You have to be there at 06:00p.m. to set up a pavilion for the guests. Youhave to hurry to do this because the weatherforecast has announced 88% rain probability.Use your app to reach your destination by busas quick as possible.

The experimental design was varied for controllingposition effects: Half of the test participants carriedout the test tasks first with the prototype and thenagain with DB Navigator, the other half of test partic-ipants vice versa. During the test the test participantswere instructed to apply the thinking aloud methodwhich means to comment on their interaction withthe apps. Verbal comments were recorded via au-dio and video. In addition, the interaction with theapps was recorded by a screen record software. Thefeedback of participants was collected with a ques-tionnaire consisting of six sections:Section 1 Demographic Data. Age, gender, profes-

sion, education.Section 2 Mobility Profile. Possession of driver’s li-

cense, use of means of transportation.Section 3 Technology Use. Possession of electronic

devices, frequency of use of devices, perceivedease of use of, electronic devices, experience withtrip assistant apps.

Section 4 Assessment of the Prototype. Positiveand negative comments, Additional questionsabout icons, size of map, visualization ofprogress.

Section 5 Final Rating. Application preference.Ten test participants took part in the user test. Fivewere male, five female. Their age was M = 23:9years, SD = 3:03 years. All of them were students.About their daily mobility profile they stated to go byfoot (10), to ride the bus (5), to cycle (2), and to usethe train (1). They were all using a smartphone (sixiOS, one Android, one unknown, two others). Con-cerning mobility apps, nine used the DB Navigator,eight Google Maps, and three Navigon. Participants’experience with the DB Navigator was assessed asproblematic because it impacts results of performancetests. However, this experience with several mobil-ity apps could also be helpful for assessing the proto-type’s quality and utter specific optimization propos-als.

5.2 Evaluation Results

The expenditure of time for solving tasks varied (seeTable 1). According to the measured data, the pro-cessing of the tasks with the application prototypetook longer than with DB Navigator. As mentionedbefore, nine of ten participants know and use DB Nav-igator and have learned to use the application to a cer-tain extent. Therefore the result of the final rating forone app was predictable: seven participants preferredDB Navigator, two the prototype application, one nei-ther of both apps.


419

Table 1: Mean of required time for solving tasks.

Application Task 1 Task 2 Task 3

DB Navigator 1:13 2:44 4:22Prototype 2:26 3:24 5:55

5.3 Participant Feedback

Participants gave very detailed feedback about theprototype visualization and features. They assessedpositively that prototype was clearly and simply de-signed. For them it seemed to be easy to manage.No unnecessary gimmicks or icons were integrated.Furthermore, they appreciated the presentation of themap and the step-by-step support during the wholetrip. The choice of means of transportation by mark-ing icons was also a pro argument for the protoypeapplication. Negative comments were predominantlyrelated to missing features or information. For in-stance, participants missed the feature for defining thetime of arrival/departure, choosing a bus stop from aselection, and a default setting of the territory, whichshould be considered (e.g. data for town, not forwhole country). Moreover, information such as de-tails of vehicles (e.g. bus number) was absent.

Technical problems were mentioned in connectionwith the GPS-based definition of the actual location.The range of participants’ assessments concerning thesize of the map was from “too small” to “ok”. Alsozooming was a little challenging for test participants.In general, the quality of icons rated as comprehen-sive. Two icons, bus and train, were named as toosimilar. The visualization of process progress withinthe app was also questioned. Three participants optedfor page control dots, seven for a progress bar, twofor displaying the percentage (multiple answers pos-sible). Two participants stated that it was not clear,which kind of progress was visualized in the proto-type distance, time, or steps within the step-by-stepassistance.

5.4 Discussion

Based on the presented results our prototype appli-cation can be considered slightly inferior to the refer-ence application DB Navigator. This outcome was ex-pected; the majority of the test subjects had previousexperience with the DB Navigator application. Whilethis allows for potentially increased competence inoperating the applications, it may have caused a bi-ased outcome of the evaluation. The feedback high-lighted the core usability issues of the interface, whichseverely influence the performance and satisfaction ofusers. While any problems identified by users during

the tests are unfortunate, designing a flawless user in-terface right from the start is close to impossible. Lastbut not least, the employed lab test enviroment missescongnitive stress, which we believe will change theoutcome.

6 CONCLUSIONS AND FUTUREWORK

This section discusses options of extending the proto-type and the research topic in general and afterwardsdraws the conclusion of this paper.

6.1 Future Work

The presented mobile application is the foundation fora possibly holistic mobile application. However, thedeveloped application is merely a prototype and there-fore does not aspire to be complete or even a validcompetitor on the market. During the process of im-plementation and beyond, many opportunities for ex-tending and improving the design as well as the ap-plication itself were discovered or proposed by oth-ers. This section presents the most promising ideasand the circumstances of a possible realization.

Context Awareness

Although an approach to employ automatic contextdetection was described in this work, it was not in-cluded in the prototype. Instead, we opted for a man-ual selection of the current waypoint, respectively thecurrent context as the focus of this work lies on thepresentation of information. To reach the goal ofa full-fledged mobile travel assistance solution, inte-grating an existing framework for automatic context ishighly desirable. This would spare the user the needto manually select the next step of the journey by per-forming input on the device.

Indoor Navigation

A transit trip plan usually consists of many differ-ent stages with a multitude of varying transportationmodes and changes of location. People often travelwith one transit vehicle to a certain station and after-wards have to transfer to another vehicle. This hap-pens especially often at stops in large facilities likecentral train stations or airports. Depending on thesize of these buildings, the number of different transitmodes they support travelers may be overwhelmed bytheir complexity. Users who visit the station in ques-tion for the first time are particular at risk of going


420

astray in the building complex and therefore missingtheir connection. As GPS positioning is only avail-able outdoors, the traditional means of locating theuser fail to operate properly. In addition to this, thereusually is no map data available for indoor navigation.Therefore we plan the incorporation of our previouswork supporting pedestrian indoor navigation into theprototype.

Social Networking

Social networking is an aspect which increasinglyfinds its way into many everyday activities and of-ten manages to make ordinary tasks more appealing.By adding social components like interaction withfriends by e.g., sharing, commenting or recommend-ing itineraries, the application might enhance the userexperience and consequently create a new incentivefor repeatedly using it.

Real-time Transit Data

Because the application is supposed to aid the trav-eler during her trip and guide her through problematicsituations, using and providing real-time informationabout transit schedules is a crucial extension. By in-cluding this data in the application it would becomepossible to inform travelers of any unforeseen circum-stances like delays or even cancellations. Using theapplication, the traveler could then react to the delayand try to search for an alternative way.

Field Test

After discerning and correcting a large amount of thedesign errors during the first user test in the labora-tory, the logical consequence is a new iteration of us-ability testing. The initial user study was mainly in-tended to be a first step towards adjusting the appli-cation to user needs. However, the testing environ-ment was unnatural considering the performed tasks,because people normally use public transit navigationeither on the road or before starting a journey.

In order to further evaluate the application proto-type more realistically a field test will be performed,which requires users to actually embark on a real trip.During this pre-planned journey the users and theirreactions will be closely monitored in order to deter-mine the amount of cognitive capacities that is actu-ally consumed by using the application for orientationin a realistic scenario.

6.2 Conclusion

This paper presented the attempt to design a novelGraphical User Interface for planning and routingthrough multimodal transit trips. The interface proto-type was designed to alleviate the issues of travelersand guide them while they embark on their journey.The first draft of the GUI was produced employing theprinciple of cascading information and classic user in-terface design methods, determining the scope of thiswork.

Based on the derived concepts and drafts, a pro-totype mobile application was developed for AppleiOS. The trip planning was based on a backend serverrunning OpenTripPlanner. The developed applicationwas finally evaluated in a laboratory test user studyin order to obtain information about usability, designissues and the comparability of the prototype with es-tablished applications for public transport navigation.The results of this study revealed the crucial usabil-ity problems and provided detailed feedback aboutthe aspects of the GUI. While the prototype lacks thedevelopmental stage of a commercial application andoffers room for improvement, the positive user feed-back showed that presented approach is reasonableand worth further attention.

ACKNOWLEDGEMENTS

The authors would like to thank Teresa Schmidt andChristian Paul for conducting the user study and theirformer colleague Paul Heiniz for productive discus-sions and his work on indoor navigation. The authorswould also like to thank ASEAG AG and IVU TrafficTechnologies AG for supplying the required timetabledata.This work was supported by the German Federal Min-istry of Economics and Technology4:(Grant 01ME12052 econnect Germany).

REFERENCES

Baus, J., Kruger, A., and Wahlster, W. (2002). A Resource-Adaptive Mobile Navigation System. In Proceed-ings of the 7th International Conference on IntelligentUser Interfaces (IUI 2002), pages 15–22, New York,NY, USA. ACM.

Biagioni, J., Agresta, A., Gerlich, T., and Eriksson, J.(2009). TransitGenie: a Context-aware, Real-timeTransit Navigator. In Proceedings of the 7th ACM

4Bundesministerium fur Wirtschaft und Technologie(BMWi) http://www.bmwi.de/


421

Conference on Embedded Networked Sensor Systems(SenSys 2009), pages 329–330, New York, NY, USA.ACM.

Biagioni, J., Gerlich, T., Merrifield, T., and Eriksson, J.(2011). EasyTracker: Automatic Transit Tracking,Mapping, and Arrival Time Prediction using Smart-phones. In Proceedings of the 9th ACM Conference onEmbedded Networked Sensor Systems (SenSys 2011),pages 68–81, New York, NY, USA. ACM.

Chowaw-Liebman, O., Christoph, U., Krempels, K.-H., andTerwelp, C. (2010). Indoor Navigation ApproachBased on Approximate Positions. In Proceedings ofthe International Conference on Indoor Positioningand Indoor Navigation (IPIN 2010), pages 15–17.

Christoph, U., Krempels, K.-H., von Stlpnagel, J., and Ter-welp, C. (2010). Automatic Context Detection of aMobile User. In Proceedings of the International Con-ference on Wireless Information Networks and Sys-tems (WINSYS 2010), pages 1–6.

Corneliussen, H. and Rettberg, J. (2008). Digital culture,play, and identity: A World of Warcraft reader. MITPress.

Deterding, S., Sicart, M., and Nacke, L. (2011). Gamifica-tion. using game-design elements in non-gaming con-texts. Extended Abstracts on Human Factors in Com-puting Systems, pages 4–7.

Heiniz, P., Krempels, K.-H., Terwelp, C., and Wuller,S. (2012). Landmark-based Navigation in ComplexBuildings. In Proceedings of the International Con-ference on Indoor Positioning and Indoor Navigation(IPIN 2012), pages 1–9.

Keller, C., Korzetz, M., Khn, R., and Schlegel, T. (2011).Nutzerorientierte Visualisierung von Fahrplaninfor-mationen auf mobilen Gerten im ffentlichen Verkehr[User-oriented Visualization of Train Schedule Infor-mation on Mobile Devices for Public Transportation].In Mensch & Computer 2011, pages 59–68. Olden-bourg Wissenschaftsverlag GmbH.

May, A. J., Ross, T., Bayer, S. H., and Tarkiainen, M. J.(2003). Pedestrian navigation aids: information re-quirements and design implications. Personal andUbiquitous Computing, 7(6):331–338.

Pessemier, T., Dooms, S., and Martens, L. (2013). Context-aware recommendations through context and activ-ity recognition in a mobile environment. MultimediaTools and Applications, pages 1–24.

Rehrl, K., Leitinger, S., Bruntsch, S., and Mentz, H.-J.(2005). Assisting orientation and guidance for mul-timodal travelers in situations of modal change. InProceedings of the 8th International IEEE Conferenceon Intelligent Transportations Systems (ITSC 2005),pages 407–412.

Statista GmbH (2012). App Monitor Deutschland Novem-ber 2012. Technical report, Hamburg.

Vieira, V., Caldas, L. R., and Salgado, A. C. (2011). To-wards an Ubiquitous and Context Sensitive PublicTransportation System. In Proceedings of the 4th In-ternational Conference on Ubi-Media Computing (U-Media 2011), pages 174–179.

Yu, H. and Lu, F. (2012). Advanced multi-modal rout-ing approach for pedestrians. In Proceedings of the

2nd International Conference on Consumer Electron-ics, Communications and Networks (CECNet 2012),pages 2349–2352.

Zheng, Y. and Xie, X. (2011). Learning travel recom-mendations from user-generated GPS traces. ACMTransactions on Intelligent Systems and Technology,2(1):2:1—-2:29.


422

Cascading Information for Public Transport Assistance 2014/WEBIST... · The Citymapper application addresses many of the crucial, common issues of public transportation and is appealing.

Documents