Identified Problems 7

Midterm delivery from:

The Trafikanten group.

21.03.2007 Table of contents

TIMELINE...... 3 MEETINGS...... 5 Trafikanten Meeting...... 5 DIS Meeting...... 6 IDENTIFIED PROBLEMS...... 7 USER STUDIES...... 8 Overall Goal...... 8 Past...... 8 Present...... 8 Future...... 9 FUTURE DIRECTIONS...... 9 Prototyping...... 9 Testing and Evaluation...... 9 THEORY...... 10 RESOURCES...... 13 SUMMARY...... 14 To begin with...... 14 To move on with...... 14 Present and future...... 14 Timeline

The group was established on 24th of January and we held our first group meeting on 4th of February. So far, the group has had 7 meetings.

We met with Trafikanten on 20th of February and proposed three different problems to be addressed: ticketing, real-time information and “while you wait”. Trafikanten found the latter two interesting and we decided to continue working with real-time information and “while you wait”.

In the meeting with the DIS team on 28th of February we got some useful feedback to use further on in the project.

external activity Group meeting Project delivery

9. feb. 23. feb. Wondering document 24. jan. 7. feb. 20. feb. Fotosession Course start Decided up on two articles Meeting with trafikanten

24. jan. 27. feb. Group meeting #1 Group meeting #3 4. feb. 19. feb. Group meeting #2 Group meeting #4 12. feb. 26. feb.

28.02.2007 Presentation 28.02.2007 20.03.2007 21.03.2007 Article and Project Meeting with DIS team User survey Midterm report

27. feb. 27. mar. Group meeting #5 Group meeting #6 Group meeting #7 05.03.2007 12.03.2007 19.03.2007 Meetings

Aside from our group meetings on a weekly basis, we have also had the opportunity to meet with two other stakeholders around our project: Trafikanten and the Design of Information Systems group at Ifi.

Trafikanten Meeting On the morning of Tuesday February 20th, we met together as a group with two of our Trafikanten contacts: Jarl Eliassen, who is the Managing Director, and Thomas, who is currently in charge of the real time information project (SIS) at Trafikanten. During this meeting, Jarl provided us with some general background information about Trafikanten and the projects it is currently involved in. Afterwards, Thomas went through a slide- show presentation of their SIS or Real Time Information project. The following is a summary of the meeting.

Introduction According to Jarl, Trafikanten was started as a joint-venture “information provider” service between three other transport providers:  Oslo Sporveier (PTA)  Stor-Oslo Lokaltrafikk (PTA)  NSB (National Railway) Trafikanten is currently involved in multiple ITS projects (Intelligent Transport Systems), with a focus on one of the following: 1. Topp: which is a travel planner for internet, mobile phone, SMS and WAP, with the intention of making it easier for users to plan their travel and create itineraries. 2. SIS: which is about providing real time information (about temporal distance of the public transport) to the users

Presentation According to Thomas, Trafikanten has now deployed the SIS service into their Website. Users can now go online and choose their line (of public transport) and station (which station they will be leaving from) and get a prognosis for the next departure. Additionally, based on the feedback they get from their customer support line, they have found out that users are not interested in delay information. Rather, they are simply eager to find out when the next bus/tram is going to arrive.

One important issue related to SIS is signal crossing, or what they refer to as Active Signal Priority (ASP). Basically, this has to do with the signals the bus or tram driver receives, informing him/her of whether s/he is delayed or ahead of the schedule. The bus/tram driver can then adjust his/her speed accordingly. It is interesting to note that according to internal policy, Trafikanten prefers the bus or tram to be delayed rather than ahead of its planned schedule. Therefore, least “crossing” priority is given to the bus/tram that is ahead of its schedule.

Thomas further expanded on the types of displays they use for providing real time information to the passengers. There are 2-3 different kinds of displays deployed at the stops/stations. But additionally, as mentioned earlier, they also provide real time information on their Website, as well as via SMS and/or WAP. One difficulty they are experiencing with providing real time information via SMS has to do with the names for buses and trams. They currently have short names for all buses and trams, but it is hard to expect the users to know these short names when requesting real time information on a particular bus or tram using SMS or WAP. The alternative, typing the entire long name, is obviously not a very attractive solution. Our contacts believe this is a training as well as a marketing process which is going to take some time.

We were also shown the computer “package” that has been located on every single bus and tram, composed of two computers that communicate with each other (Mona and Lisa), as well as a mobile phone device and a GPS embedded in the package. The computers run on a Windows XP Operating System. At every signal crossing, the bus/tram knows where it is based on GPS reading, but more exact is the meter readings of the odometer. The GPS is used more as a way to correct and calibrate the information derived from the odometer readings. The tram dispatchers are even more reliant on the signal system (Mobile CAD/AVL) than the bus drivers, due to a general lack of flexibility in the tram routes.

Findings During the meeting we learned that:  Our contacts at Trafikanten would prefer if we concentrated our project on something that would provide them with valuable insight. Given the short time- span of the project, they do not expect us to come up with an entirely unique idea or a new solution that can be implemented. Rather, they would prefer something that provides them with useful ideas and information.  Related to the above point, a project that has to do with ticketing does not really interest our contacts, as ticketing does not fall under the umbrella of Trafikanten (rather it is the territory of one of the PTA’s, Stor-Oslo Lokaltrafikk).  During the implementation of the SIS system, it was difficult for Trafikanten to conduct user studies due to both time and budget limitations, and also because of a lack of familiarity of users with the concept. However, now that the system has been (partially) implemented and used by Oslo’s public transportation users, Trafikanten is interested in collecting users’ opinions about the system.

DIS Meeting This meeting was organized by Jo Herstad as a workshop where one Masters student in the process of finishing his Masters Thesis, a group of Masters students in the initial phase of forming a collaborative Masters Thesis, as well as our group got the opportunity to present our projects/ideas/findings to each other and to a group of faculty (part of the DIS group). What connected the three different projects was their focus on IT in public transportation. The agenda of the workshop was to inform others about each of these ongoing projects and to hopefully receive some feedback and/or suggestions.

For our part, we presented a quick overview of our findings about two potential (problem) areas we could work on: Real Time ‘Mobile’ Information and While U Wait (see next section for details). We showed videos of two scenarios we had put together in order to visually demonstrate what we meant by these problems/ideas. We further proposed the below questions that have been concerning us:  The problems or ideas that we identified were not based on a detailed user study. Rather, we came up with these ideas based on our personal experience with Oslo’s public transportation and some initial observations and informal conversations with friends. How important is it to investigate the validity of our assumptions before moving on to designing a solution?  What is the best methodology for investigating these assumptions?  Should we concentrate solely on the users of public transportation, or should we also try to include non-users in our investigation?

We received very positive comments from the participants about our brief presentation and particularly our scenarios. One of the solutions depicted in one of the scenarios (While U Wait), however, was rightly criticised in that: 1. It potentially violated people’s perception of privacy and security; 2. It was based on the assumption (not yet validated) that people want (or need) to kill time while waiting; 3. It possibly violated bus stop “norms”.

The overall feedback from this meeting was that we are on the right track. We should definitely conduct some user studies as a means to investigate the validity of our assumptions before moving on to designing a solution. User studies are also helpful with investigating passengers’ rate of use of and satisfaction with the existing SIS or Real Time Information service provided by Trafikanten. Also, it might be beneficial to try to define what a bus stop (or tram stop) is and what kinds of norms apply there.

Identified problems

As mentioned in “Timeline” we identified 3 problem areas; ticketing, real-time information and “while you wait”. Ticketing was discarded by Trafikanten as this was not so related to their area of operation.

Real-time information (SIS) Trafikanten are using GPS and odometers on board most of their vehicles to calculate the estimated time of arrival to the stops along the vehicles routes. This information is then displayed on a display at the stops, and the passengers waiting can see when the next transportation (bus, subway or tram) is expected to arrive. We want to find out whether this information is used by the passengers, and in which extent it is used. Do they find it accurate and do they rely on it? Some early observations indicate that some people are still using the timetables at the stops, even though the stops are equipped with SIS information displays. A possible reason could be that people want to memorize the schedule, or they just want to make sure the real-time information provided by the SIS is matching. It also seems like delays in traffic is not reflected good enough by the SIS information display.

More than half of the members on our group were not aware that Trafikanten offers real- time information on their website, www.trafikanten.no. Even more unknown to the group members was the fact that the WAP-version of Trafikanten’s website also provides this information.

There are obviously a lot of things to examine in the area of real-time information.

“While you wait” This area is concerning the time passengers spend at the stop waiting for their transportation to arrive. Even if they are provided with real time information about the next arrival/departure, passengers who receive that information when already at the stop will have to spend some time waiting. We are interested in finding out if the perception of time waiting for transportation can be changed, and in best case shortened, by introducing some kind of entertainment or service at the stops.

User studies

Overall Goal Our overall goal with the user studies is to establish a clearer view of potential users of a future system and existing users of Trafikantens real time information system.

Past Members of the group have made observations of users in usage situations. These observations range from users that make no obvious use of SIS where it is installed (instead consulting the time table), to what users do when they wait. These observations have helped establishing some basis and domain knowledge needed in our project.

Trafikanten has also been very helpful and have provided us with several documents with studies from other cities, reports and information about SIS.

Present Currently we are preparing an online survey in corporation with Trafikanten. We wish to use this survey as a basis for further deep interviews with selected users and prototyping. The survey will also further pinpoint the direction in the project by letting us see what concerns the users. Future We wish to proceed with deeper interviews after getting results from the survey. The interviews are meant to further elaborate upon the issues we will deal with. The form of the interviews has not been determined, but most likely there will be both ordinary interviews and in-situ interviews with testing of prototype(s).

Other forms of user studies are also possible, such as scenario techniques, use cases and workshops.

Future Directions

Prototyping Our part of prototyping will be done in two steps, and the work ahead will be based on the survey that we are going to conduct. The survey will hopefully give us enough information to work out a list of objectives, requirements, and constraints. The first part of prototyping, we are going to follow the paper prototyping method. This method is typically done in four steps: 1. Concept design 2. Interaction design 3. Screen design 4. Screen testing Normally in this type kind of prototyping, both the users and developers meet to create the prototype. In our case, we consider ourselves also to be users. In the concept design part, everyone meets to discuss possible approaches to the problem, and to see if any of the ideas can meet the requirements for the problem. The interaction phase, will consist of grouping related information together and giving each group a name. The last task in this part would be to review the aspects of the task to simplify it.

The screen design phase will basically consist of a brainstorming, where each screen will be sketched out. The last point on this list is the screen testing. In this phase the paper-prototype is taken out to the end user for “testing”. This testing phase could be fetched either from interviewing the user, or letting the user think-out-loud. The data collected from this phase will most likely be used in the second phase of the prototyping. In the second part, if time allows it, we switch to rapid prototyping method. This model is based on having a “working” prototype with which a small group of end users gets hands-on experience. The developer gets feedback from the user, and will correct and/or improve the prototype accordingly. Testing and Evaluation In this phase the group will come together after the paper-prototyping and reform the design before developing the initial working prototype. To evaluate and test we see two different approaches. 1. Recruit a small group of users for testing the prototype 2. Meet with the end users at the [bus/tram/subway]stops, and let them try the prototype Typically at this stage, the user must evaluate the different use-cases found in both step two and three in the paper prototyping model. The feedback from this part will be taken back to the developer for improving the prototype. Of course, in rapid prototyping there is room multiple iterations. Theory

This project as has been described before is done in conjunction with Trafikanten, and through some meetings and discussions with them, we have agreed on some of the interesting aspects being the “While U Wait” and the “Real Time ‘Mobile’ Information”.

The concept of “While U Wait” starts from some assumptions described in the meetings with Trafikanten united to our initial possibilities of interesting subjects to undertake. As we said before, Trafikanten has not done deep user studies. The customer support however reveals that users are more interested in knowing when their bus/tram is coming and not so concerned with the information regarding the delays. Users want to know if the bus or tram is coming or not.

With the “Real Time ‘Mobile’ Information” part of the project, the idea is to look at it from possibly different approaches, not necessarily relying on improving the precision of the gadgets that they already have in place, but to make users aware that such systems exist and suggest complimentary ideas to support them.

The While U Wait concept comes from the idea of a different approach to the current problem. Back in the 1900s, when skyscrapers where being built by the bunch in New York City, the developers confronted a common complaint from the users. They complained that the elevators in the new tall buildings were too slow. The developers were concerned and discussed it with the engineers, who in return came up with different sorts of solutions and tests for trying to speed up the elevators, but still the users’ perception was that the elevators were taking too long time.

A different approach was taken by an engineer whose main idea was restructuring the question. The initial question being:

Why are the elevators going so slow?

Was reworded to: Why do people perceive that the elevators are going so slow?

With this new question they looked from a different perspective for the whole case. They were able to analyze that when a normal user gets in an elevator, he/she usually gets bored easily just staring at the walls and concentrates his/her thoughts on the security of the elevator. The user then exaggerates in the sense of time it takes for the elevator to take him/her to a certain floor.

After having this new perspective, the stakeholders began to look at different ways they could distract the users, and looking to why the users perceived the elevators as going slower than they really were. This led to the idea of giving users something to do, while waiting in the limited space of the elevator.

Then came the idea of using mirrors where the users could look at themselves, concentrate on their appearance, try to fix their ties, hairstyle etc.. This solution showed in interviews done afterwards that the users were focusing their thoughts on other aspects that made them stop considering the speed or safety of the elevator. The mirror provided more positive thoughts and also in following surveys they commented how much faster the elevator was going.

For our project the concept and problem approach with the elevators seems related with the “While U Wait” idea. Since the bus and tram transportation system already has several real time displays in place, an alternative approach suggests trying to change the perception of time by the customers waiting in the bus or tram stations. After the surveys and interviews we will have a clearer picture of what this problem more specifically entails.

The theoretical background in the course is also valuable as to understand how the implementation of new mobile technologies can be understood.

Looking at this idea from the framework of relation between architecture, practices and institutions [Agre, 2001], can help better analyze this problem and also look at the alternative solutions. It gives us building blocks to understand the problem and a possible labeling for the parts involved and how the possible solution will come in.

The framework considers the analysis of the three relations between architecture, practices, and institutions:

Architecture: related with the built in environment, and focused on fixed structures such as buildings, walls, hallways, doors, windows and the other physical objects confined to a single place. In our case this can be confined to the bus or tram stop, related also to how it’s divided from other surrounding buildings and constructions, and the type of weather protection it has. Practices: these are the embodied routines that have been created by a particular community of people around how something is done. In our case this relates to common activities that passengers might be taking or not, a passenger might know he/she has to look at the schedule in a specific location of the bus stop. A passenger might be used to complain, or not trust real-time info displays based on previous experiences. A user might have as common practice to evaluate the mode of transportation. For example: if he/she sees the tram coming from a distance, he/she will take the tram instead of waiting for the bus.

Institutions: the persistent structures of human relations, or social roles and rules constituting those relations. In our case this can be the existing norms and relations among passengers at or around a bus/tram stop.

The paper describes that these aspects form a ‘sandwich’, with architecture and institutions creating the outside boundaries for practices.

With our project we can first try to further understand or define the ‘norms’ around a bus/tram stop. According to the above framework, this would fall under the institutions umbrella. As a second step, we can identify the rigid and flexible architectural features of the bus/tram stop. These norms and physical features of the stop can provide a framework within which we can place our solution, in the form of a new practice enabled by a piece of technology at the bus/tram stop. It would be interesting to see how this new practice, in the long run, might change the norms and institutions around the stop (e.g. norms around waiting, or the institution of ‘time’ itself).

Another article we found relevant to our project(s) is Kakihara & Sørensen’s Expanding the ‘Mobility’ Concept. In this paper, the authors identify three dimensions of mobility: spatial, temporal and contextual.

Spatial Mobility: this means that a lot of things are mobile: human beings, objects, even information, symbols and space itself. This type of mobility is very much relevant to our project as we are dealing with mobile people using mobile transportation systems with a potentiality of accessing mobile information (e.g. bus schedule or even real time information via WAP or SMS or via Internet on their PDA’s).

Temporal Mobility: This refers to time itself being mobile by 1) being open to interpretation and ambiguity (“structural” vs. “interpretive” aspects of time); and 2) the possibility of doing more than one thing at a time (simultaneity or “polychronicity”). Again, related to our project, we are dealing with a system that is supposed to run on an objective and structural definition of time (specific temporal locations with a specific order and recurrence), yet its actual performance is open to subjective interpretation (even if the bus is always on time, which in reality it isn’t, different people might perceive the wait time differently).

Contextual Mobility: According to the authors, contexts are inherent to human action. Just as the ‘where’ and ‘when’ of an action are important to consider when designing a new technology, the ‘how’ or ‘in what way’ of the action matter too. And just as one can participate in various activities or be in different places (real or virtual) at the same time, one can be mobile across multiple contexts as well. Additionally, information and communication technologies can influence and be influenced by context(s). So in our case, it is important that we take into account the various contexts surrounding the use of public transportation when designing a new solution. Particularly, in designing something that could manipulate users’ perception of wait time at the bus/tram stop, an interactive solution might be worth considering here. As in the authors words, “what has been and will be further mobilized is not just human movement but more importantly interaction among people”.

Resources

Below is an overview of resources we have gathered so far for our project.

1. Documents received from Trafikanten

Trafikanten has supplied us with several documents on the SIS-system (Sanntidsinformasjon for kollektivtrafikken i Oslo og Akershus), and on the study of a real-time information system for the local public transport company, HTM, in The Hague, Netherlands. Among these documents are valuable reports, such as a Cost-benefit analysis (CBA) for SIS and a before-after study on the added value of Real-time information and effects to customer behavior (HTM).

2. The Civitas Initiative (http://www.civitas-initiative.org/main.phtml?lan=en)

The Civitas (CIty-VITAlity-Sustainability) Initiative is an EC program which aims to:

"[..]generate a decisive breakthrough by supporting and evaluating the implementation of ambitious integrated sustainable urban transport strategies that should make a real difference for the welfare of the European citizen"

"The Civitas Initiative helps cities to achieve a more sustainable, clean and energy efficient urban transport system by implementing and evaluating an ambitious, integrated set of technology and policy based measures."

The Civitas' homepage contains extensive information on initiatives from cities all around Europe which have implemented systems for:

 Real time travel information  Traffic information  Vehicle location based services

3. "Multimodal Interfaces for Mobile Multimedia". A PowerPoint-presentation by Jürgen Scheible of the Media Lab at the University of Art and Design Helsinki, Finland, presented at the Wireless Cities 2006 Conference in Oulu, Finland. Summary

To begin with To begin with, we had identified three different projects we wanted to further investigate; “While U Wait”, “Real Time ‘Mobile’ Information”, and a ticketing system working through mobile devices. The idea was to first get our own independent opinions on what we wanted to work on, before we got to any influenced meetings.

Our main goal for the “While U Wait”-project was not making the system more precise, but to make the users aware of complimentary ideas to support them. The process of waiting is about if the users perceive the time as going slow or fast, and not the amount of minutes they have to wait.

Likewise, in the “Real Time ‘Mobile Information”-project, our goal is not to optimize the current system. This project is about making the current system more usable for the users. Helping the users fit the system with a mobile device.

To move on with After our brainstorming session, we planned a meeting with Trafikanten. This meeting gave us some background information about the company, and they presented the different projects they had going on, and this combined with the answers to our pre-made questions helped us deciding where to put our focus. They gave us detailed information on how the real-time-information works, and further informed that the ticketing issue was not a part of Trafikanten, which gave us the inspiration to move on with the following projects; “While U Wait” and “Real Time ‘Mobile’ Information”.

Later on we had a meeting with the DIS-group of the faculty (Design of Information Systems). Their feedback revealed a lack of user-validation in our assumptions, and the need for a user-study for identifying the real problems shined through.

Present and future So far, our knowledge was based on our own personal experience with the public transportation system. The value of this was good enough to make assumptions of problems, but not good enough to validate the assumptions. Therefore we started working on a survey, as a basis for further user elaboration including most likely deep interviews and prototyping.

With the survey as background, we have hopefully identified some new problems. In the prototyping-evaluation-cycle, we will try to make possible approaches of the problems, and sketch out a paper-prototype which will be taken out to the end-users for “testing”. After enough iterations has been done, and better ideas have been evolved. Then, there is time for making and testing higher fidelity prototypes.