Interactive travel‐ and ticket information 

        

Final report  

Asad Fattahi, Ernad Fajkovic, Farah Khan and Subaranchan Thanagopal  

   

University of Oslo ‐ Department of informatics INF4260 ‐ Human‐computer interaction (HCI) 

  

  

 

Contents  

1.  INTRODUCTION ......................................................................................................................................... 1 

1.1 PROJECT GROUP ....................................................................................................................................................... 1 1.2 PROJECT BACKGROUND ............................................................................................................................................. 2 1.3 PROBLEM AREA ........................................................................................................................................................ 2 

1.3.1 Questions..................................................................................................................................................... 3 

2.  UNDERSTANDING THE USERS .................................................................................................................... 3 

2.1 UNIVERSAL DESIGN ................................................................................................................................................... 3 

3.  DATA GATHERING ..................................................................................................................................... 4 

3.1 BACKGROUND DATA ................................................................................................................................................. 4 3.1.2 Consistency .................................................................................................................................................. 5 

3.2 USER DATA ............................................................................................................................................................. 5 

4.  TECHNOLOGY ............................................................................................................................................ 5 

4.1 WIRELESS INTERFACES ............................................................................................................................................... 5 4.1.1 Mobile ticketing .......................................................................................................................................... 5 4.1.2 Wireless travel information ......................................................................................................................... 6 

4.2 TOUCH SCREEN INTERFACES ........................................................................................................................................ 6 

5.  PROTOTYPES ............................................................................................................................................. 7 

5.1 HOW WERE THE PROTOTYPES MADE? ........................................................................................................................... 7 5.2 PAPER MOCKUP ....................................................................................................................................................... 7 5.3 PROTOTYPE VERSION 1 .............................................................................................................................................. 8 5.4 PROTOTYPE VERSION 2 .............................................................................................................................................. 8 5.5 PROTOTYPE VERSION 3 .............................................................................................................................................. 9 5.6 PROTOTYPE VERSION 4 (FINAL) ................................................................................................................................. 10 

6.  EVALUATION ............................................................................................................................................ 12 

6.1 EVALUATION APPROACHES ....................................................................................................................................... 12 6.1.1 Field study ................................................................................................................................................. 13 6.1.2 Heuristic evaluation .................................................................................................................................. 14 6.1.3 Usability testing ........................................................................................................................................ 15 

7.  FURTHER WORK ....................................................................................................................................... 17 

7.1 FURTHER WORK ON THE PROTOTYPE (FROM VERSION 4 AND BEYOND) .............................................................................. 17 

REFERENCES ...................................................................................................................................................... 18 

APPENDIX A: TESTING OF THE FLEXUS SYSTEM .................................................................................................. 19 

APPENDIX B: M‐TICKETING ................................................................................................................................ 22 

APPENDIX C: WIRELESS TRAVEL INFORMATION [6] ............................................................................................. 25 

APPENDIX D: TRAVEL INFORMATION ................................................................................................................ 27 

APPENDIX E: TOUCH SCREEN INTERFACES ......................................................................................................... 30 

APPENDIX F: INTERVIEWS ................................................................................................................................. 32 

APPENDIX G: USABILITY TESTING ...................................................................................................................... 38 

APPENDIX H: PROTOTYPES ................................................................................................................................ 50 

  

 

1. Introduction This project is about the travel‐ and ticket information that is made available at the public transportation stations in Oslo. The main focus has been on the metro stations, specifically Blindern, but we have also mentioned some of the other stations as well (such as the bus and tram stations). Our objectives have been as follows: 

1) Understanding the design space and the users • Gathering background data • Gathering user data 

2) Prototyping • Creating a design • Developing a prototype 

3) Evaluating • Evaluating the prototype through interviews and usability testing 

 In order to better understand how we would create the design, we needed to have more information about the current technologies and solutions. We started by gathered large amounts of background data, including: various ticketing solutions, the future ticketing solution in Oslo (Flexus), the currently available travel information on the stations, and various technologies that are available for improving the current solutions. To get a better picture of how the ticketing system works, or how it is supposed to work, we decided to test and evaluation the Flexus system. All this background data gave us the information we needed in order to come up with new ideas and solutions. The next step was to create a design, based on the information we had gathered and our own perception of what the users need. After agreeing on a final design, we created a simple paper‐based mockup of the design. After several improvements, we ended up making a software‐based prototype in HTML (HyperText Markup Language). This prototype was then printed out on paper and “tested” during interviews with users. The prototype was then improved and extended with more functionality, so that it could be used in usability testing. After gather more user data from the usability test we only had time to do one last refinement of the prototype. 

Illustration 1.1: Model of the lifecycle model that was used 

1.1 Project group The project group consists of four students: Asad Fattahi (asadf@ifi.uio.no) Ernad Fajkovic (ernadf@ifi.uio.no) Farah Khan (farahk@student.uio.no) Subaranchan Thanagopal (subarat@ifi.uio.no) 

 1

 

 We ended up working together after the first lecture, where we were asked to sit in groups of four and talk about our reason for taking the course and our expectations of it. We have had group meetings every Wednesday. In addition, we used e‐mail, SMS and Google Groups to communicate. 

1.2 Project background How can travelers find the travel‐ and ticket information they need when they are located on one of the many stations that are placed around the Oslo city? The typical solution used on the stations today is usually a picture of the line map and timetable for the station. This solution offers general travel information that you rarely get the benefit of. For those who know the system and the logic behind it, it is not difficult to find what you need, but for those who rarely make use of these solutions it is not quite so simple. This applies especially to new users, foreign speaking travelers, tourists and elderly people. These user groups usually need help to understand the ticket‐ and travel information on the stations, as they may experience difficulties when for example purchasing tickets or searching for other travel information. We wanted therefore to look at existing solutions and how these could be modified to disclose the information in a more understandable and intuitive manner. Our goal was to give users an interactive system that they can use to find the information necessary for them when and where they need it. 

Illustration 1.2 

 We have looked at existing solutions and examined how user‐friendly, learning‐friendly and usable they are. Furthermore, we have examined how we can design an interface for different user groups (adults, children, elderly, foreign speaking, blind, deaf, etc.) and also the technologies that can be used to resolve this (touch screens, physical buttons, mobile devices, audiovisual, wireless, etc.). 

1.3 Problem area Our experiences with the current user interfaces on the traffic stations are that they are not usable enough. A problem which is well known is when the train is delayed 5‐10 minutes. The delay announcement is only hearable in the metro station, not other stations. It is not possible to read, see or search these messages on the station. This is one of the issues that has been a daily problem for many passengers. People who are waiting for the buss don’t have access to information about traffic problems, such as: why the bus was delayed, when the next buss is arriving, what the alternative routes are, etc. People who can’t wait in a queue to buy a ticket don’t have any alternative to avoid queues. A good and modern interface must be able to serve people who want access to information. There is no system which can support this function in a traffic station in Oslo today. In addition; older people, tourists and those who are disabled or have impaired motion, vision or hearing, need more support than other users. 

 2

 

1.3.1 Questions There have come up many questions since the very beginning of the course. They started pouring in even before we knew what we wanted to write about. Here are some of the questions we were trying to find answers to in the area of ticket‐ and travel information: • How can we design interfaces for different user groups? • What technologies are available today to create such interfaces? • Can cell phones be used to buy tickets or to find travel information? • How do visually impaired travelers buy tickets and how do they obtain travel‐ and ticket 

information? • If people don’t hear the important announcements over the loudspeakers on the stations, 

then how can they obtain that information? • When the traveler leaves the station (for example to board a train), how can he/she resume 

the process of finding the information that they started on the station? • People are often in a hurry when they are traveling, so how can we limit their many public 

transportation options down to the best and quickest one from where they are currently standing? 

 As seen above, there were many questions to answer. We didn’t of course have time to answer all of them, but they were good inspiration during the project and they definitely deserve further exploration. 

2. Understanding the users Designing usable interactive products requires considering who is going to be using them, how they are going to be used, and where they are going to be used. Another key concern is understanding the kind of activities people are doing when interacting with the products. Designers need to know many different things about users, technologies, and interactions between them in order to design for effective user experiences. Identifying needs and establishing requirements for the user experience is an important point to start a good design. There are some principles that can lead to designing a useful and easy to use system. These principles [1] are: 

‐ Who are the users? ‐ What are their needs? ‐ When do they use the product? ‐ Where can they use it? 

 The users are the people who interact directly with the product. Our users are all those who are at the Blindern station, in other word all passengers. Identifying needs depends on the environment and time. The needs can be changed over time. There are no direct questions to ask people what they need. Identifying needs is possible by understanding the characteristics and capabilities of users, and how they try to achieve their goals more effectively. 

2.1 Universal design We tried to include all user groups as final users in our project using today’s technology. Using multiple languages in the solution can help tourists and people who cannot read and write 

 3

 

Norwegian. We have used mobile solutions to support people who have difficulties seeing or hearing.  These user groups can use mobile devices to access information which is accessible to other users by using mobile phones. They can also use it to buy or update a mobile‐ticket. Using m‐ticket for these types of users could be more comfortable, because of better accessibility, consistency and integrity. One advantage of using a mobile phone is that the blind, or visually impaired, users have control over what they do and therefore don’t have to depend on help from other people. Another alternative to support the blind in the traffic station is to use a so called sound shower. This technology creates focused and directional audio output that can deliver messages to an intended spot without disturbing people in the surrounding environment. The user can use the touch screen interface, supported by a sound shower that transforms every activity, text, message, error, etc. to sound. The disadvantage of this method is that blind people don’t know where the support device is and will therefore need help to find it. 

3. Data gathering As a part of the preparation process to this project we started by gathering information. This was an important step in order to get an early overview of what is out there so that we could get a better understanding of the complicated world of travel. This process has answered many of our early questions and brought forth new questions and ideas. Our starting point on the information gathering has been to study the earlier course projects (specifically from the autumn of 2007 [2]). This was important for two main reasons; so that we don’t repeat the same work that has already been done, and in order to learn from the previous projects.  There were two types of data that we needed to gather for this project: 

• background/research data about travel, ticketing and technologies • user data 

3.1 Background data The background data that we are referring to in this chapter is all the information that we have gathered about existing ticketing solutions, technologies, evaluation of existing solutions (Flexus), HCI‐theories, etc..  Existing ticketing solutions We have looked into solutions from other cities and countries in order to understand the problems they have encountered and the solutions they used to solve the problems. Germany and China are among the countries that we have looked into.  Evaluation of existing solutions (Flexus) Flexus is the new electronic ticketing system for public transport in Oslo and Akershus, introduced by NSB and Ruter. We used heuristic evaluation to test and evaluate this solution in order to discover usability problems in the system. We chose to evaluate this solution instead of the older ticketing system because it was more relevant to our project (e.g. use of touch screen interface).    

 4

 

Technologies Some of the technologies we have gathered information about for this project are the following; wireless, touch screen, mobile devices, mobile‐ticketing, audio/sound showers.  Travel information We have looked at how information is currently made available on the stations [Appendix D]. This data was obtained through interviews of passengers on different stations. 

3.1.2 Consistency Consistency is mainly about ease of learning. Consistency is saying that the same action will have the same effect irrespective of the context. Action effect consistency is the main contribution of the user guide [7]. If a system is not consistent the same action may have another effect in another place of the system. It can be difficult for the users to learn the system when they don’t know which effect will be affected by the action. A typical problem that new users come across is with the use of the stamp machines. If they use the tram or bus, they can stamp the ticket when they get on the tram/bus. But there are no stamp machines on the metro trains. This often confuses new users when they try to find the stamp machine after boarding the metro train. This is just one example of inconsistency in the public transportation system. A consistent system should be a mode free system. By this we mean that the same color, font, button, text, etc. should be used for the same operation, ticket, logo, etc. Another example is that the ticket stamps in Oslo are different on the bus, train and metro. A user can’t read what is printed on the ticket. One rule of consistency is that similar tasks should require similar sets of actions. A good example for that is to use only one type of ticket for transport (on train, bus, city bike, etc.). 

3.2 User data We have discussed several alternatives within the group for gathering user data. The ones that we believe where most appropriate in our situation, where the following: interviews [appendix F] on the stations and usability testing [appendix G]. 

4. Technology 

4.1 Wireless interfaces In this chapter of the paper we are trying to explain how we can design an interactive wireless interface which is able to perform intended tasks using the system. Wireless interfaces are divided into two sections: Mobile ticketing (M‐ticketing) and wireless travel information. A user can get access to information about traffic and buy or update an m‐ticket using a mobile device. 

4.1.1 Mobile ticketing The mobile phone, which originally was intended to be used for phone calls, has developed into a mini computer that the user can take anywhere. These small devices are going to be more integrated in our daily lives so it could be much easier to use a mobile device to solve problems. In our case mobile devices are helpful to buy, store, show and read m‐tickets. A ticket machine can serve only one person at the time. The queue is a normal drawback with a ticket machines. M‐ticketing can solve the queue problem for passengers. Many users can access the system at 

 5

 

the same time to buy or update an m‐ticket. Another advantage of m‐ticketing is that the passengers can save time and money. They don’t need to go to a ticket machine/clerk office to buy a ticket. It can be cheaper for NSB/Ruter and other traffic organizations to use m‐tickets instead of other versions of tickets because of fewer employees. This solution will help passengers to buy or update m‐tickets with a mobile device using WiFi, Bluetooth or other wireless protocols which are supported by the system. There are two ways to do m‐ticketing: [appendix B] 

1. Barcode m‐ticket 2. SIM card m‐ticket 

 The common point in these two methods is that a user can use a mobile device to buy or update an m‐ticket and she/he can use the mobile phone to validate the m‐ticket. The main point is to use mobile and wireless networks anywhere to get an m‐ticket and use it in a station, bus and train without using ticket in others versions. Both these two methods can use mobile network or a WiFi network to access the m‐ticketing system. 

4.1.2 Wireless travel information As we mentioned earlier in this paper there are a few number of usable and interactive interfaces at the stations in Oslo. A central database with web services is required for web based client system to search information about real‐time table, delays etc. Today’s WAP and SMS applications which are in use in Oslo are outdated and not usable enough. Mobile browsers like Safari, Opera Mini, Skyfire and Nokia S60 had a great progress and have been developed into full value browsers. With these browsers a user can search anywhere on the web. [Appendix C] 

4.2 Touch screen interfaces A touch screen interface provides a very flexible design space, where the designer has the freedom to create and change the graphical user interface (GUI) in any way he/she wants. In comparison to paper interfaces, a touch screen interface can be altered and expanded with large amounts of information without taking up more physical space than it already does. This makes it an excellent piece of technology for solving many of our questions. [Appendix A]  There are many advantages to upgrading to a touch screen interface: • It is easy and more cost efficient to make changes in the data • It is easy and more cost efficient to upgrade and add new data and functions • It saves physical space since all the information fits on one single screen • It is easier for users to use and understand • It can be customized for different users (e.g. language, text‐size, etc.)  Disadvantages with a touch screen interface: • It is expensive to maintain the machines and to repair damages to the machines 

 6

 

5. Prototypes The prototypes we have developed in order to test our ideas and solutions. This chapter explains how we created the prototypes, what kind of prototypes we created and how the users were involved in the development, refinement and testing of the prototypes. 

5.1 How were the prototypes made? We started first with the idea: a touch‐screen device for travel information and ticketing. We then had a brainstorming session within the group in order to generate more ideas on how to achieve this (see list in appendix E). These ideas were then transformed into a low fidelity paper mockup (illustration 6.1). The mockup was later revised several times before resulting in the first prototype (illustration H.2). Our intention was to have a more visually appealing, yet low fidelity, paper prototype that we could bring with us when talking to the users. We figured that the quickest way to do this was to use HTML to create the prototype as if it was a web‐page. Then we could easily continue improving the HTML prototype until we had a dynamic prototype of higher fidelity which could be tested in a web‐browser. Up to this point we had no contact with the users, other than each other. Now it was time to get some feedback to find out exactly what kind of information people are interested in having on a station and to see what they have to say about our prototype. We gathered the first set of feedback through interviews on different metro stations. Before we started with the interviews, we sat down one last time to discuss the prototype and to decide on all the last minute changes before interviewing. This resulted in a second HTML prototype (illustration H.3) which we used during the interviews. A total of 38 people (with different cultural backgrounds, language, gender and age) were interviewed. The results of these interviews led to the development of the third HTML prototype (illustration H.4). This was the first interactive prototype of much higher fidelity than the previous versions. This version was then tested by half a dozen students in order to find out how users would respond to the actual use of the product. Based on their feedback we did one last refinement of the prototype (illustration H.5). 

5.2 Paper mockup Most of us have difficulties with telling exactly what we want, but once we see an example and get to use it, we can easily see the flaws. We found it therefore difficult to come up with the right questions to ask people, since most people don’t know what to say on the spot. In order to get more specific feedback from users, we thought a better approach would be to have an initial example, or design, that we could use when talking to them. But to create a design we had to gather data to get more knowledge about technology and users. After a lot of research and testing of existing systems, we had several discussions on how some of the main issues in the public transportation system can be solved with the use of touch screen interfaces. We proposed several ideas about this (appendix E). Then we needed to try out our ideas by building 

Illustration 6.1: Paper mockup 

 7

 

prototypes and iterating through several versions. Prototype is a limited representation of a design that allows users to interact with it and to explore its suitability. To start with we preferred low‐fidelity prototyping. This kind of prototype won’t look like the final product, but instead it will be useful because they tend to be simple, cheap and quick to produce. This means also that they are simple, cheap, and quick to modify when it’s needed. So we produced our first paper‐based mockup (illustration 6.1).  As you can see, this prototype shows intended functions and buttons, their positioning and labeling, and the overall shape of the device. But of course none of the buttons works. This mockup was very helpful during discussions within the group and worked effectively. This encouraged reflections in the design, as described by Schön [9].  We have included several of the initial ideas (see appendix E) in this mockup, including: 1. Tickets, information about tickets and buying tickets 2. Line map, which shows where the transportation vehicle is located right now on a dynamically 

changing line map  3. Phone nr. , a list of important telephone numbers (e.g. police, fire, ambulance, taxi,…)  4. Delays, important announcements 5. Weather forecast, for the current day and for the rest of the week  6. Map, shows a street map of the local area, other areas of the city and the entire city  7. Language options 8. Calendar  Besides clarifying the requirements, the purpose of prototypes was also to do some user testing and evaluation. When we got this first sketch produced and got something to see, we soon knew what we don’t want from this sketch. After all, this first sketch was a result of a brainstorming. With this we had an opportunity to investigate scenarios of use and to decide, whether buttons are appropriate and the function sufficient.   We realized immediately that “city bicycle” and “On foot” are unnecessary for this type of purpose/system. Soon after these corrections we created an electronic / web based picture of this sketch, much more like high‐fidelity prototyping without any functionalities.  

5.3 Prototype version 1 Iterating to this version gave us a look of the screen that looks much more like the final product. We needed software to create this one, we simply used Word, Photoshop, HTML, JavaScript for this. This time we could clearly see the symbols/icons. We had more discussion around this, which was the basis for next iteration/prototype version. 

5.4 Prototype version 2 We had a discussion within the group if the symbol of “Delays” and “Phone” would lead to confusion since these symbols are used in the car traffic. So we decided to change these symbols to more common symbols, to avoid such confusions. And the “Delay” button got moved next to “Ticket”, because of its importance.  So people could catch this immediately we colored it red.  Otherwise we made some changes in the way buttons are organized. We still focused on the importance and organized the buttons in that order. 

 8

 

 We felt that still something was missing, that was of course help‐information. There are almost no systems without that. These are obvious things to include. We separated in two different buttons, one just for “Information” (i), and another for helping purpose like frequently asked questions and so on.  We also put the name of the station in the top left corner, like the Flexus system does, nice to have it. 

5.5 Prototype version 3 The data we received from the interviews has led us to do some changes in the prototype, and made us to develop a high fidelity prototype for further testing. We will describe the changes bellow.  • Added text under the menu‐buttons 

This is because more than 50 % of the users said that the buttons are not self‐explanatory. Especially because we also wanted to make a prototype that is understandable for foreigners and tourists also. They might never have seen the icons that Trafikanten use on their website.  

Before  After 

Illustration 6.2: “Tickets” button 

 • Changed the “Delays” button to a more understanding one. 

This is because the interview concluded that almost none of the users understood the purpose of the delays button. An icon will also appear near the bottom of the screen if there are any delays, and you can just touch it to get information about delays. 

Before  After 

Illustration 6.3: “Delays” button  • Added a home‐button near the bottom of the image (illustration 6.5) 

 • Changed the language‐selection icon 

The flag icon in the bottom right corner was supposed to show which language was currently being used (e.g. Norwegian in illustration 6.4) and it was also meant to work as a button that one could press in order to choose another language. This means that if you press the flag‐icon you will get a list of language choices, when you then choose another language the main‐menu will appear and the flag (illustration 6.4) will change to the appropriate one. But having both the language selection and language status as the same button was confusing for many. So we changed the language selection icon to display many smaller flags to indicate that there are multiple languages. Then we added 

 9

 

a small flag in the upper right corner to show the language status (illustration H.4), to display which language is currently selected.  

Illustration 6.4: Bottom panel (before)  

Illustration 6.5: Bottom panel (after) 

5.6 Prototype version 4 (final) Below is a list of changes that have been made from version 3 (illustration H.4) to version 4 (illustration H.5), and a short description of the changes.  • The text under the menu‐buttons was changed from regular to bold 

Some of the participants mentioned that the text under the menu‐buttons could be clearer. The white text‐color on top of the light‐blue background made it difficult for the text to stand out. Since they pointed out that it should be only slightly clearer, we agreed that it was enough to change the text from regular to bold. 

Before  After 

Illustration 6.6: “Delays” button 

 • The name of menu‐button “Real‐time” was changed to “Arrival times” 

Two of the six test participants had difficulties understanding what the Norwegian word for real‐time (“Sanntid”) meant (appendix G). This resulted in them having to go through all the menus in order to complete the assignment, which was to find the arrival time for a specific train. We concluded that this was enough evidence to change the name of the function from “Sanntid” to “Ankomsttider”, and we also changed the English words from “Real‐time” to “Arrival times”. We believe that this will be more understandable for most travelers, especially for foreigners, tourists, older generations and other travelers who might not be very technology oriented.  

Before  After 

Illustration 6.7: “Real‐Time” button 

 10

 

• “Weather” button was removed Almost all of the participants answered “weather” when asked if there was any unnecessary information. Some of them pointed out that they didn’t quite understand what weather had to do with travel and ticketing. 

 • Added a new button, “Route Planner” 

This was not a request from the users. We added this feature because we had planned on doing so from the beginning, but we didn’t have time to complete it earlier. This feature is meant to calculate the quickest route to your destination. You just type in where you want to travel from and where you want to end up, then the program does the rest. The “from” field contains by default the name of the station where the device is located. It should of course be possible to change the text in the “from” field to whatever you want (the final prototype however does not let you do that because of the short time we had to develop it). The input fields have a distinct background color that indicates which field is currently in focus (illustration 6.9).         

 Illustration 6.8: “Route planner” button 

Illustration 6.9: Route planner page 

       • Rearranged the menu‐buttons 

After removing the weather item and adding the route planner, we had to rearrange the buttons in a more logical and meaningful order. The three items “Tickets”, “delays“ and “arrival times” are on the top of the menu. This is because we consider them to be the three most important features. Next in line are “route planner”, “line map” and “map”, which also are important, but not quite as important as the first three. The last two items (“phone numbers” and “help”) are for other information and help. These are last because they will rarely be used and have therefore less priority.  

• Added more line maps We altered the line map feature so that it is possible to change between different line maps (metro, tram, bus and ferry). Although this feature works in the final prototype, it does not display the maps correctly. By this we mean that the maps are too blurry, this makes them very difficult to read. This is again because of the short time we had to develop it. 

 

 11

 

  

Illustration 6.10: Line maps    

• Altered the language button The language button didn’t look like a button, so some of our participants tried to click on an individual flag in order to change the language, which was a bit confusing for some. That’s why we altered the button so it would look like one big button instead of several small ones next to each other.  

Illustration 6.11: Bottom panel (before) 

Illustration 6.12: Bottom panel (after)  

6. Evaluation Evaluation is a part of design process which collects information about users and their experiences when they interact with a prototype or computer system to improve the design. The evaluation focuses on the users’ experience, and usability of a system. Designer can measure usability, efficiency and determine usability problems in the system to improve the design in new versions. Our goals to do evaluation in this project are: • Identify the users need.  • Identify usability problem to improve better design. • Include users in decisions by participating in interview, survey and usability testing. • Identify the best representation of metaphor on which the design will be based. • Identify how understandable our interface is for users when they interacting with that. 

6.1 Evaluation approaches There are three main evaluation approaches: 1.Field studies 2.Usability testing 3.Analytical evaluation. We have chosen field study, heuristic (Analytical approach) and usability testing as our approaches to evaluate the prototype and Flexus ticket system. The reason that we have chosen usability testing method was to include end‐users in the evaluation phase. In this way 

 12

 

users have been involved in the design phase. The point is that users will not be forced to use an unwanted product. Instead, they come to enjoy with a product that they need in a traffic station. As we mentioned in appendix A, it was difficult to find users for Flexus system because the system is in a test‐period. There are only a few users (Test‐Users) who use Flexus system, therefore we use heuristic evaluation method to evaluate Flexus ticket system. We know that some of people are using public transport daily and because of that, field study approach has been chosen as evaluation approach to evaluate the third version of prototype.  

6.1.1 Field study Field studies are done in natural settings with the aim of understanding what people do naturally and how products mediate their activities. To evaluate the second low‐fidelity prototype (illustration H.3) we chose a field study evaluation approach. We interviewed 38 random users on different stations around in Oslo. In this way, we received responses from a representative selection between the age of 16 and 50, these also included 8 English‐speaking users.  Data gathering for field study evaluation by interviewing users There are two interview types: 

• Closed questions which have a predetermined answer format  • Open questions which does not have a predetermined format. 

 We have chosen closed questions, with predefined checkboxes, because closed questions are quicker to fill out. That way we would get as much data as possible before the traveler had to leave the station. The interview is split into two parts, the goal of the questions in the first part is to map the current situation for the traveler, and to find out if there is need for changes/improvements concerning travel information, ticket purchasing and services we can offer to the users from mobile phones. The other part is to evaluate our low‐fidelity prototype. Here we want to find out if the buttons are self explanatory, if people can imagine using such a system if it exists, and whether anything more should be added to the prototype.  The way we interviewed was by having the steps described by Sharp, Rogers and Preece. We stopped random users and gave them an introduction of ourselves and the project showed them the prototype that was printed out, and then asked if they could take some time to answer our questions to the prototype. We started with easy and general questions from the first part of the interview and then specific questions from the prototype. To get people to respond, we made the questions short and had few questions to not take so much of their time. And we ended the interview with thanks to the interviewee for their time. [Appendix F]  Conclusion of the field study evaluation As a result of the interview (Appendix F), we have drawn up some points; mainly most of the users find travel information on the Information board at the station, which they think is an okay way. Therefore we have to include the same information that is on the board at the station, in our prototype, or else we have to let the boards on the station stay in addition to the new system. This is because there are so many users who make use of this and think it’s a great way to find information. Moreover, using the real‐time to get information, we have included that in our prototype already. The majority of respondents are experiencing delays often, and 

 13

 

some experience it very often. Most of these people are not updated for these delays. This is data that got us to be even more secure that it was good to select delays information in our prototype. The last part of the interview shows that most of the respondents don’t think the buttons are self explanatory, but that they would use such a system if it existed today. Moreover, it is also desirable with mobile‐ticket instead of physical tickets. The reason we chose to only have buttons without text below was because we thought they were intuitive and because we used the same buttons that are on the Trafikanten site. But as we can see from the interview results, this is not the case, so therefore we have to make some changes so that users understand what the different buttons means. 

6.1.2 Heuristic evaluation Heuristic evaluation is most popular for usability inspection methods. The goal of heuristic evaluation is to find the usability problems in the design. Heuristic evaluation is performed by having each individual evaluator inspect the interface alone. Only after all evaluations have been completed, then the evaluators allowed communicating and have their findings aggregated.  Heuristic evaluation is to examine the interface and judge its compliance with recognized principles (heuristic principles [8]). We have used heuristic evaluation to evaluate the Flexus ticketing system. 

 Ticketing system (Flexus) Techniques such as interviews, questionnaires and observations is something we couldn’t use for the new ticketing system because it is not yet adopted and has thus no users. There are some test users, but it has been difficult to find them and do the study in cooperation with them. Since we are short on time, we have chosen to test and analyze the system on our own. We are in a way users ourselves. As users, we know perfectly well what users want and what they need.  It is important to talk with and ask people in the user group that are going to use the system,. Therefore, we interviewed different users in the user group, and they tested our system while we were observing them. In this way we got feedback from them.  In order to develop the prototypes, we have chosen to evaluate the Flexus system by ourselves first.  

For this observation and evaluation of results we used some of general principles for user interface design by Jacob Nielsen: 1) User control and freedom 2) Consistency and standards 3) Error prevention 4) Flexibility and efficiency of use 5) Visibility of system status 6) Match between system and the real world 7) Recognition rather than recall 8) Aesthetic and minimalist design 9) Help users recognize, diagnose, and recover from errors 10) Help and documentation  

 14

 

Conclusion of heuristic evaluation 1) User control and freedom 

This means that users can quickly go from not knowing the system to do any work. We think it will vary how easy it is for individuals to learn the Flexus system. Users who are used to technology in their daily life will probably not have many problems with using the Flexus system. But other users, such as elderly people, may have greater difficulty using it. One of the main reasons is the touch screen technology, which is not very widespread today. Although the Flexus system has a relatively easy interface, which means the users will be able to easily learn it, but it depends on the end user. We think that there should be a manual, either implemented in the interface or as a physical label on the ticket machine, to make it easier for those who are not used to the technology. 

 2) Consistency and standards 

This means that users with low usage rate may return after a period of inactivity without having to learn everything over again. We tested the system once again after a while, and it was much easier to complete the steps to buy the ticket. Of course, this will depend on who the user is. For someone who does not use computers in their daily life, it will be very difficult to remember the steps next time he or she wants to buy a ticket. It is often easier to remember icons rather than text, and in the Flexus system there is not much text, something we liked about the system. 

It is also easy to remember the system if the graphical components are in the right order. We don’t think the components of the interface are located entirely in the best possible order. When we tested the system, we didn’t feel that it was intuitive enough to understand the steps of operation. This can be improved, and will probably help to ensure that it is much easier to remember the task next time. 

 3) Error prevention 

Which means the users do not make many mistakes, and that these mistakes are not disastrous (and that one can easily correct them again). As mentioned in appendix A, we experienced some errors during the testing that could have been avoided. The error that caused the system freeze was something we tried to provoke again as it is very serious, but we didn’t succeed. So we think it is an uncommon fault, but it should be solved before the system is put in use. 

4) Flexibility and efficiency of use We had a feeling that the system was a bit chaotic when we tested it. It was in no way comfortable to use. The touch screen was also difficult to use, because we had to touch the screen several times to get it to respond. [Appendix A] 

6.1.3 Usability testing Usability testing is an approach that emphasizes the property of being usable. The testing is a technique used to evaluate a product (or prototype) by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system.    

 15

 

Users We selected six random users at Oslo University College, all of them were students, age between 20 and 32 years, 3 women, 3 men and all of them speaking Norwegian. One of them has been just a few months in Oslo and she said that she cannot much about public transport in Oslo. A weakness of this test was that we did not have the opportunity to include all user groups as elderly people, blind, deaf and etc in our test. The reason was little time and resources. It was impossible to move our equipment in the usability room to another location to include additional user.   Usability room We have used a room at Oslo University College P48, 3.etg as usability room (appendix G). A digital video camera was mounted and took video recording of user activity on the computer screen. Two group’s member noted everything was done and said by the user. The user was informed that the video recording will be used only for evaluation of usability testing and the data will be stored anonymous.  Discussion  After the implementation of the tests [Appendix G] we started to analyze the data. We found that the users do not like the word “real time” for the function and they wanted to replace it. We had three questions which are about the users' needs (questions 3, 4 and 5). We had respect for users' opinions and feedback, and we think that they have been a part of our design group with their comments. Things that were observed during testing have been noted and in addition we took video record of the computer screen. Some users had problems with going back to the main menu after going into a submenu. We discussed to create a button (go back) on all the pages, but since in that version of the prototype user can click only one time and home button is available in all the pages, so we agreed not to create the back button in the new version of the prototype. Users can use home button to go back to the main page.   Conclusion of the usability testing 

"Measuring user performance speed, error rates, and user satisfaction separately is important because sometimes users may be satisfied by an elaborate graphical interface even if it slows them down substantially." Ben Shneiderman 

 We've tried to select questions pertaining to the user's needs in a traffic station and used usability principles as described by Jacob Nielsen to measure the usability of the prototype in a usability room. The goal of the testing was to estimate the system's effectiveness and identify the usability problems.  The results of tests and questions show us that people liked the prototype and they think that it is something they need in traffic stations. Using the system confirmed that the user could find information in the system very easily. At the same time, we found usability problems in this version that is explained in the document. We are going to fix the problems mentioned in a new version of the prototype.  After testing, analysis and discussion of collected data and feedback from users, we came to consensus to remove the Weather button and use the word arrival times (In Norwegian section) instead of real‐time to a new version of the prototype. [Appendix G]  

 16

 

7. Further work Further work consists of gathering user data, designing prototypes, testing the prototypes and improving the prototype designs.  A user survey can help us to understand more about the users and their experiences with today’s information‐ and ticketing system. It is very important to have good communication with the users before creating any prototype. The user can be part of the design group by participating in user surveys, and making decisions will be a cooperation between users and designers in the practice.  

7.1 Further work on the prototype (from version 4 and beyond) If we had more time to work on this project, we would continue improving the prototype by going through the process of iteration (testing and refining). We would continue to improve the product by going through this process until both we and the test participants were happy with the final product. There are several things that we didn’t have time to implement in our prototypes. These include: 

• Expanding the submenus for tickets, so that one could click on a ticket‐name and get information about that specific ticket. And also adding submenus for ticket purchase, both with cell phone and with cash/card. 

• Fixing a few errors in the route planner (e.g. it’s currently not possible to write in the “from” field) and expanding the route planner so that one can fill out two station names and get directions. 

• Improving the line maps to make them more simple, clean and easy to read • Adding animation to each line map so one can see where the different transportation 

vehicles (busses, trains, ferries, etc.) are located. • Altering the street map to show the locations of the closest metro, tram, bus and ferry 

stations   

 17

 

References [1] Y. Rogers, H. Sharp, J. Preece (2007): “Interaction Design: Beyond human‐computer 

interaction”. 2nd Edition. New York: Wiley. ISBN: 0‐470‐01866‐6. p 1‐410  [2] Course projects from the autumn of 2007 

http://www.uio.no/studier/emner/matnat/ifi/INF3260/h07/ [20.10.08]  [3] Flexus homepage. 

www.flexus.no [22.10.08]  [4] Web‐site with a large amount of information about bar codes, biometric technologies and 

lists of barcodes and biometric products and solutions. http://www.barcode.ro/ [22.10.08] 

 [5] Press release from Nokia (June 13, 2008): “RMV, T‐Systems, Nokia, and Venyon set mobile 

ticketing to a new level of convenience” http://www.nokia.com/A4136002?newsid=1227654 [22.10.08] 

 [6] Marko Hännikäinen, Antti Laitinen, Timo Hämäläinen, Ilkka Kaisto, Kimmo Leskinen 

“Architecture of a Passenger Information System for Public Transport Services”  [7] “Noddy's guide to consistency” 

Andrew Monk, University of York, UK., A.Monk@psych.york.ac.uk  

[8] “Usability Engineering” Jacob Nielsen, Addison‐Wesley 1993  

[9] “Learning, reflection and change” Donald Schön (1983)  

[10] Jakob Nielsen's Website http://www.useit.com/   

 

 18

 

Appendix A: Testing of the Flexus system  The testing of the Flexus [3] ticketing system was performed by two group members. They had direct observation in the field. They tested the system, while also noting the experiences. They took also several photos of the testing.  The Flexus card can contain several types of tickets, but we have only tested the 30 days ticket, which is the only option that is available in the system per today. The system uses a touch screen interface.  Purchasing To start with, we were wondering about the welcome‐picture of the castle (illustration A.1) which was too large in relation to the text below. It took all of our attention, even though it has nothing to do with the ticket purchase. But in relation to the rest of the screens it was just fine that it all starts with a picture. Under the picture there is text which says “Please touch the screen to get ticket reservation”. This is also considering tourists, because it's in English. But it could be other language options too.  The colors which have been used are blue and white which symbolizes Sporveien. This contributes to consistency in the system since the color combination is followed throughout the process. The buttons are blue with white text. This again is similar to the colors used by Sporveien. That’s positive. The ”look and feel” of the interface is not that appealing, it could have been more expressive with the use of more icons, pictures, etc.. 

Illustration A.1:Welcome screen 

 The first touch brought us forward on the process where we got two alternatives: 11) Information 12) Flexus ‐ tickets  Payment‐options are already visible as pictures of coins and bankcard at this stage on the right side of the screen. We wondered if we had to make this decision already at this stage, but when we tried to do so we found out that they were inactive. Confusing and not so intuitive! It should at least have been some describing text for this, so it could have spared us the time we used to answer the questions that emerged and the number of touch that we used for this. 

 19

 

The text below (illustration A.2); ”Menyknapper til venstre, resten er hurtigvalg” (eng.: “Menu buttons to the left, the rest is shortcuts”) was a bit confusing since we couldn’t see these shortcuts. Only the buttons on the left were visible. We consider that this text is meant for future use. If so the text shouldn’t have been there anyway or a more suitable text could have been used. Otherwise the date, time and the name of the station follows throughout the process, which are nice to have. 

Illustration A.2:Main menu Another thing which is worth noting is that the touch‐screen didn’t work properly. We experienced this several times. We had to touch harder and several times to get it to respond.   To continue on the process from here we had to insert the Flexus card. It wasn’t that intuitive which way to insert the card. Although the card has arrows on one side of it, the machine is able to read both sides. We don’t see the point of the arrows.   With the card inserted, the ”Information” button gives information about the card, like  its validity and the amount left on the card. Actually we hoped that this “Information” button would give us general information about the different types of tickets, prices, how to use the system, help and tips, etc. We miss this kind of information on the system. This same screen shows also the text (illustration A.3) ”Trykk på en av de blå knappene for mer informasjon om hver billett” (eng.: “Press one of the blue buttons for more information on each ticket”). But there are no such blue buttons, we assume this will updated before the system is put in use. Anyway the text could have been clearer. By clicking on the button “Tilbake” (eng.: “Back”) from this screen (illustration A.3) it prompts to print out the card content. 

Illustration A.3: Information menu

 

 20

 

We are now back to the screen (illustration A.2) with the alternatives “Informasjon” (eng.:“Information”) and “Flexus billetter” (eng.: “Flexus tickets”). This time we selected “Flexus tickets” where the only ticket we can select is the 30 days–ticket. This is the only option that is available in the system per today. For this type of ticket we get the opportunity to select whether it’s for a child, youth, adult or pensioner (illustration A.4). When we selected Adult, we got the price and the payment‐options were activated (shaped as buttons). We selected to pay with a bankcard first and then we wanted to go back to change this option. The system didn’t work properly and it crashed. It didn’t display any error messages or anything that told the cause of the problem. The feedback should be improved here. When a system requires users to carry out too many steps to perform a task, only to discover a mistake and to start all over again, it causes user frustration. So we had to cancel the whole process and do everything over again. It means that you can’t change the payment‐option once you have made the selection. The only way to change this is to cancel the whole process and do everything from the beginning. Finally when we reached the moment for purchasing, the screen referred to the bankcard terminal. The bank terminal lights up to indicate that it’s now time to pay for the ticket. Like we told earlier it’s possible to pay with coins and bankcards, but we miss the opportunity to use banknotes. The new machines should have this option, like the current ticket machines do. Speaking about the current system, they have a nice line map on it, which is missing on the new one. 

Illustration A.4: Ticket menu

 When we were done with the ticket purchase we examined the validator as well (illustration A.5). Each time you go on board at the bus, metro or tram you have to validate the card with the validator. You just have to hold the card over the validator. It will show either a green, yellow or red light. Green light indicates the ticket is valid. Yellow light indicates the same, but it displays a warning that the card is almost empty. The red light indicates that you don’t have a valid ticket. A good thing with the validator is that it can read the card any way you hold it. It is very good because people are often in a hurry when they go on the tram, bus or the metro. If the validator only read one side of the card, it would create unnecessary frustration for people. 

Illustration A.5: validator

 21

 

Appendix B: M‐ticketing  1 Barcode M‐ticket In barcode m‐ticketing a user can send a request to a server by a mobile device. A mobile device can be a mobile phone, PDA, or a laptop. The architecture model will be a server – client model. One way to install a server application is using a ticket machine as a server for the station. This server could be used only in a local area or on the web. A wireless protocol (Bluetooth) utilizing short‐range communications technology facilitating data transmission over short distance can be an alternative as a communication protocol. Other wireless communication protocols can be WiFi for short distance and WiMAX for long distance. Server processes the request and validates the submitted data. After data processing and validating mobile payment a response will be sent to the user. The response can be an error message or an m‐ticket. This m‐ticket is an image of a barcode which includes stored information about user, date, etc. If you are using a mobile phone you can store the image on the phone and use it as a normal ticket in the bus or train station. The way to validate this m‐ticket is to scan the image on the mobile phone by a scanner as illustration B.6 shows.  

Illustration B.1: Scanning an m‐ticket on a phone  Illustration B.2: Barcode ticket on a mobile phone If passengers use other devices to download the ticket they can print it out and use it as a paper ticket version. The scanner machines will be able to scan both images on paper or on the screen. Next generation ticket system in Oslo does not support m‐ticketing and it could be a weakness of the system. The solution is to develop the scanner machines to enable scanning of both SIM Card tickets (chapter 2: SIM card m‐ticket) and barcode tickets. They can also use a barcode scanner beside the first one.  This system is quite easy to use. The m‐ticket system can reduce the costs, improve customer service and validation of tickets. This will make the m‐ticket to an attractive alternative. 

 22

 

 1.1 Choosing the best barcode for M‐ticketing There are a large number of barcodes to choose depending on what the m‐ticketing system needs and what the abilities the system has. Here we try to explain some of the barcodes and possibilities of using those codes in the system. More information about barcodes is available on the barcode web page [4].  1.1.2 Linear barcode The common barcode which is used in many places as a paper version of tickets is linear barcode. These codes will be large on the screen if the code must contain more information. Mobile devices have limited screen size and it is not possible to use these barcode on mobile screens.  

Illustration B.3: Linear barcode 

The other problem is the start and stop areas of the barcode that indicate where the information is contained. These areas are located on the outer edges, leading to scanning problems.  1.1.3 PDF417 The symbol is rectangular, the shape of the symbol can be adjusted to some extent by setting the width and allowing the height to grow with the data. We can see the same problems in linear barcode as in these codes also.   Illustration B.4: PDF417 

 1.1.4 QR Code The size of these images can be compatible with a mobile screen and the capacity of stored information on these codes is quite good. The problems with scanning of these images are that a white space around the code is required before reading of code and the finder patterns are on the outer edges, which can lead to difficulties when reading from an electronic display. 

Illustration B.5: QR code 1.1.5 Aztec The symbols are square overall on a square grid with a square central bull’s‐eye finder. It supports industry standard escape sequences to define international code pages and special encoding schemes. The Aztec Code is used for small item marking applications using a wide variety of printing and marking technologies. The error correction makes Aztec the best choice for m‐ticketing. 

Illustration B.6: Aztec 1.2 Requirements The only requirement to use these codes is a 2D barcode scanner to convert the barcode to readable text. An application which is installed on the scanner machine can validate the m‐ticket and inform the user of the validation result.  

 23

 

1.3 Buying/updating Using this solution is very easy for most user groups. The users can buy or update their m‐ticket using a mobile device or a computer. When buying an m‐ticket by sending an SMS, an image (MMS) barcode will be sent to a registered phone number after a submitted e‐payment transaction. It is possible to download the m‐ticket on your laptop if the user is on the web. A printed m‐ticket can be scanned and validated by an m‐ticket scanner. All types of  m‐tickets (monthly, daily, etc.) are available for users. This is an easy way for tourists to use m‐tickets when they are in Oslo. Updating can be available for all types of tickets.  2 SIM card m‐ticket The new generation of ticket system in Oslo is based on scanning information which is stored on a plastic card, which is equipped with a RFID chip. It is possible to develop this system by using either only one RFID SIM card on a mobile phone as both a SIM card phone and traffic SIM card or one extra SIM card which is pasted on the back of the mobile device. The first alternative of this method has been installed and implemented in Germany in 2006 by Nokia [5]. The public transport authority of the Frankfurt Rhein‐Main region (RMV), T‐Systems, Nokia and Venyon have announced the next phase for RMV mobile ticketing at the international NFC Forum meeting in Frankfurt Main in Germany. The new mobile ticketing solution based on Near Field Communication (NFC) will offer a wider variety of mobile tickets as well as improved user experience. This kind of m‐ticketing could be a good solution to avoid using an extra card in your wallet. This technology could use the same SIM card which will be used in the new ticket system in Oslo. That way there are no extra requirements to use this type of m‐ticket by the system. Buying and updating the m‐ticket will be available using SMS, WiFi by a mobile device or using web by a computer. Scanning and validating m‐ticket on a mobile is like to scan a ticket card and the only different is that the user is scanning a SIM card which has been installed in a mobile phone. Buying and updating can be available for mobile users using SMS or WiFi on the web.  2.1 M‐ticketing and more support Handicapped people can use their own special mobile device which is designed for handicapped to buy or update an m‐ticket. Support for English language as an international language is required both for SMS and on the web. It is a good idea to have a free number (800xxxxx) to access purchase or updating of an m‐ticket. A user could be able to buy or update an m‐ticket by calling to a free phone number and submit e‐payment transaction over the phone.  

 24

 

Appendix C: Wireless travel information [6]  In order for the traveler to carry on with the information gathering process even after he/she has left the station, one could introduce the use of mobile devices that can accomplish the same tasks. If a person has found information on the station, then they will need a way of bringing that information with them. It would be very difficult to remember a route that involves more than 2‐3 transitions, departure times, locations, station names, etc. A simple way to solve this could be to store the information on a mobile device or print out the route on paper.   The challenge is to design a good three tier architecture model: data, logic and business layer and implement it as an information system for traffic stations. Each bus/train will be an object in this application. Theirs positions are caught by GPS or other wireless technologies and the data can be transferred to databases. A simulation application will display the objects on the screen. Every movement must be updated in the databases and on the screen. A search engine must be able to respond to the requests which have been sent from the users. A map application can be useful for tourists who are at the station and will look at the map on the mobile screen.  Illustration C.1 shows a model of possible services and relations between them for an information system at the stations.  

Illustration C.1: A model of possible services and relations between

 25

 

 These services must be available on the web to serve information to the passengers. In addition to the wired network a WLAN using WiFi or other technologies like Bluetooth are required to serve the passengers who are at the station and want to access the information. The authentication to the wireless network in the traffic station must be open. After detecting a mobile device at the station an invitation must be sent to the client to get connection. After a successful connection the server can offer information (and support applications). The key point with wireless interfaces is that a user can use applications and information without standing in a queue. Users at the station can use wireless connection to search information on the web, send query requests to the server and run map or other applications which are available for the mobile devices.  SMS search engine  Today’s SMS search application is difficult and not usable enough. Users can only get one response for each SMS and it is not possible to browse the output data and choose the best alternative. Our experience with Trafikanten’s SMS service confirms that the response can be sent to the user a few minutes after sending the request. The example which is published on Trafikanten’s homepage (www.trafikanten.no) is: 

“Send FRA BLINDERN TIL GARDERMOEN 1500 til 2050”  The response was: 

“fra Sennerud 1741 buss 845; til Sprumsand 1744; fra Sørumsand 1751 tog 460; til Lillestrøm 1815 Flytog‐‐; til Gardermoen flyplass1827”  

The query for next and previous timetable is: ”Send NESTE eller FORRIGE til 2050.”  

These queries are very difficult to user and there is no support for tourists and international language. There are no queries to search in the timetable with SMS. It should be possible to request a timetable for a bus/train by SMS. The response can be an MMS if the capacity of SMS is too small to send the data. Users should have access to search much more information like alternative routes, timetables, maps and delays by SMS. The map server could be able to serve maps as MMS images to users if they send request via SMS. The SMS server should be able to perform multiple queries. An experience with traffic stations that everyone can have is delays. In this case the user will search for alternative routes or next departures. An SMS server should respond with extra information to the user if delays are recognized by the system in the traffic after sending a request to the SMS server.  

 26

 

Appendix D: Travel information  The travel information that is currently available on many of the stations in Oslo consists mainly of a line map, a timetable, a price table and in some cases a map of the local area. This information is usually pasted on a blue information panel, like the one we see on the picture below. The information panel on the picture is from the Blindern metro station. Blindern metro station also has a map of the University area.   

Illustration D.1: Information panel at Blindern metro station  Line map The line maps are usually geographically incorrect maps that show information about all the routes and stations for a specific transportation vehicle.  

 Illustration D.2: Line map for the metro 

 27

 

 Timetable The timetables show the departure times for a route on a specific station. Each station has a unique timetable for each route that goes through the station. The timetable on the picture below (illustration D.5) is for Blindern metro station, and it shows the departure times for line number 5 towards Vestli. This timetable shows all the departure times for all the days of the week, including a visual presentation of the previous and next stations on that route. This visual representation shows how many minutes it takes to travel from the current stations, which in this case is Blindern, and to all the other stations on that route. By using the timetable below, one can find when train number 5 is supposed to arrive at Blindern station, and one can also see how many minutes it will take to travel from Blindern to Vestli. Once you have studied and understood the logic behind the timetable, it can be very useful. However, there is one more criteria that needs to be met in order for the timetable to be useful, namely that the train is on time. If there are delays or other deviations in the departure times, then the timetable is more or less useless.  

 Illustration D.5: Timetable for metro line number 5 towards Vestli

 Map of the local area The local area map shows all the public transportation options in an area as well as other relevant information, such as where one can buy tickets, which metro stations that are manned and which stations that have ticket machines. Below is an example of a local area map. This map is of the Blindern area. 

 28

 

Illustration D.6: Map of the Blindern area 

Illustration D.7: Explanation of map symbols 

 

  Summary The information that is currently available on the stations offer general travel information that you rarely get the benefit of. It doesn’t show the information you need right then and there. 

 29

 

Appendix E: Touch screen interfaces  Here we have included detailed discussions on how some of the main issues in the public transportation system can be solved with the use of touch screen interfaces.  Announcements Important announcements that are said over the speakers on the metro stations are only available at the moment that they are said. If someone arrives at the station a few minutes later, they will not receive the important message until the next announcement is made (if it is made at all). Even those who are at the station when an announcement is made might not catch what is said (e.g. because of noise on the station). There is already a solution for this, but it is only available on Trafikanten’s homepage (www.trafikanten.no), which means you have to have internet access and a device that can read the HTML page (e.g. laptop, PDA, cell phone, etc.). This could be very easily applied to all the stations with the use of touch screen devices.   A cure for boredom Usually people are very bored while they are waiting on the station. This boredom can be cured by introducing an information device that people can interact with. A system that reacts to our commands can be surprisingly interesting and fun. Even though one is just exploring the device of sheer boredom, it can very quickly become a fun experience. While interacting with the device, the user could also get some useful information about the train he/she is waiting on. The first impression is therefore very important in the success of such a device. A good first impression increases the chance of approval among the users. Another very effective way of curing boredom is by introducing fun games to the device. This would be very entertaining, but it could also cause people (especially younger people) to crowd in front of the device, which would discourage other travelers to use the system (who probably need it more). The idea of creating such a system is so that people can get the information they need right then and there in a shortest possible time. Another possibility for such a device could be to use the screen area to display animated advertisements when it hasn’t been used for a period of time. That would be another economic reason for creating such a device.  Other ideas We have come up with many ideas and possibilities for an interactive touch screen device. Here are some examples: • It can show where the transportation vehicle is located right now on a dynamically changing 

line map (versus the static paper map that is currently in use). This map should only show the transportation vehicles for that specific route or station, otherwise the map would be overcrowded and not very useful at all. 

• It could find the quickest and cheapest way to reach ones destination (this could later be linked with public transportation systems outside of the city area) 

• Implement a dynamically changing calendar that can show the timetables for holidays and other special occasions. 

• Show what the weather forecast is for the current day and for the rest of the week 

 30

 

• Provide a list of important telephone numbers (e.g. police, fire, ambulance, taxi,…) and the ability to search for phone numbers (in the white and yellow pages) 

• Show a street map of the local area, other areas of the city and the entire city • Show a map of the university campus and give directions to campus buildings • Provide address search, show the search results on a street map and get directions to the 

locations (either on foot or with a transportation vehicle). One could for example choose to get the quickest route, the cheapest route or to travel only by train (or bus, tram, boat, etc.). 

• Show the latest ticket prices, and how/where one can buy them • Provide the ability to contact the information office (much like the current analog 

information boxes) • Provide a search for the closest POI (point of interest). Such as hospital, taxi, police station, 

drugstore, grocery store, etc. And get directions, either with a transportation vehicle or on foot 

 

Illustration E.1: Pay Kiosk’s Internet Terminal

Here is an example (illustration E.1) of a new generation touch screen and wireless information terminal which is already in use on many places. This technology is available already today.  

 31

 

Appendix F: Interviews  The interview form  Age:     Gender:        Male        Female Language:        Norwegian        English  

PART 1: Travel and ticket information  1) How do you find travel information when you are on the station? 

 Route Booklet   Information panel   Internet   Cell phone  Kiosk   Information desk   Information 

number  Real‐time sign 

 2) What do you think about this way of finding information?       All right        Difficult        Very difficult    3) How often do you experience delays?       Never        Rarely        Often        Very often  4) Are you informed about the delays when you are on the station?       Yes        No        Don’t know     

PART 2: Prototype 1) Are the buttons self explanatory?       Yes        No        Don’t know    2) Er det noe du savner eller ikke trenger her, i så fall hva?     3) Would you use such a system if it existed today?       Yes        No        Don’t know    4) Do you want the same information on your mobile phone?       Yes        No        Don’t know    5) Mobile‐Ticket is a type of ticket that can be purchased with a mobile phone and used on the phone instead of cards. Do you wish to use Mobile‐Ticket instead of keeping an extra card in your pocket if the technology was available?       Yes        No        Don’t know   

 32

 

Results of the interviews – PART 1  

    Question 1 

 Diagram F.1  On this question there are multiple choices. The answers to this question were different depending on the age of those who were asked. Oldest users who were interviewed preferred route booklet and board at the station, and the younger users use internet more to find travel information. This question shows that mainly most users in our sample use board on the station to find travel information, followed by real‐time signs.       

 33

 

Question 2 

Diagram F.2  30 of the users find it easy to check information in this way, which tells us that today’s solutions for finding travel information is quite straight forward for users. This tells us that it’s important for us to include the same information as on the board at station and real‐time information, in our prototype. Because the new solution can’t exclude something that so many users find as a great way to find information.  Question 3 

 Diagram F.3  The majority of respondents experience delays often, and some experience it very often. These responses were not surprising for us, because all of us in the group agreed in advance that the delays are a major problem. Most of those respondents who answered that they experience delays rare also said that they rarely take public transportation.    

 34

 

Question 4 

Diagram F.4  23 users of the respondents are not updated for delays, which tell us that the need for such service is required in our prototype. This is a fallow up question from the previous and shows clearly that some actions must be made to update users on delays. It is not acceptable that as many as 23 persons of the respondents are not updated for delays.  Results of the interviews – PART 2  Question 1 

Diagram F.5  22 people don’t think that the buttons in our prototype (illustration H.3) are self‐explanatory. Although we have used the same buttons as Trafikanten use in their systems, more than 50 % of the respondents tell us that they don’t understand the buttons properly. This applies to certain buttons more than others, there was hardly anyone who understood the meaning of the “Delays” button, while “Weather”, “Phone” and “Information” buttons was more self 

 35

 

explanatory for most of the users. Regardless of these responses, it tells us that we have to make changes in the prototype for the buttons to be more intuitive.  Question 3 

Diagram F.6  Although shown by the previous question that the buttons are not intuitive, still 28 people will choose to use such a system today, if it exists. It was a very large variation in responses by age of the respondents. Most young users would love to use the system if it existed today, while the oldest was more critical for using such system, most likely because of the technology.  Question 4 

Diagram F.7  As part of our project, we wanted to show the same information on the mobile phone, as on the actual machine. The most of people were positive to have the same information on mobile phone, even though few people know about using mobile devices in this way. That is a god response to start a project. Most of the people who responded “no” to this question were elderly people. This is normal, as we know some people in this user group are afraid to even 

 36

 

send or read SMS, MMS. Young people were eager to have the same system on mobile phone. The users know that using mobile devices to get access to transport information system is more comfortable, easer and they do not need to stay in the queue in the station to get access to information. Using mobile devices can give access to users anytime and anywhere. Unfortunately we could not include deaf and blind in our survey. Mobile phones which support these user groups could be interesting for these user groups.   Question 5 

 Diagram F.8  Most of the people in our range are very keen to drop the extra card, and use mobile‐ticket instead if it is possible in the future. This is a good feedback to our project. It can show us that what people need. Everybody has a mobile phone and some card in their pocket. It’s difficult to have many cards in your pockets. People are looking for a way to get rid of some of their cards. They understand that using mobile‐ticket is the way to reduce the number of cards in their pockets.   

 37

 

Appendix G: Usability testing  

Illustration G.1: Prototype version 3  

 

Illustration G.2: Usability room  Assignment Users were informed that all data will be stored anonymously and the data will be used only for evaluation of the testing. This text was announced on the top of the assignments page: "The project is about how travelers can find travel and ticket information when they are located in underground stations in Oslo. This is an anonymous test, no personal information about participants will be registered!” 

 38

 

 Situation: You are at Blindern subway station (towards downtown). 1) Can you find when the first train to Mortensrud arrive the station?  2) Can you see if there are any delays in traffic?  3) A tourist comes to you and asks you which subway going to Vestli. How do you find this information?  4) A pensioner asks for help to buy a ticket. How you can help him to do this?  5) Imagine that you are a tourist from England and cannot read Norwegian. How do you will find information in this system?  Follow up questions:  1) What was your first impression?  2) Was the icons understandable?  3) Is there any information that is missing?  4) Is there something you feel is not necessary?  5) Do you have any idea about how the solution can be done better?  Results of assignments  Assignment 1 Can you find when the first train to Mortensrud arrive the station?   Diagram G.1 shows the number of seconds users have using to do the task, and the sum and average of those times. Diagram G.2 shows the number of wrong clicks per user to do a task.   

 

 Illustration G.3: “Real‐time” button 

Diagram G.1    

 39

 

 

 

Diagram G.2    Four of the six users have clicked on the correct button and it was only two users who used a long time to find the button to do the task. They have clicked on other buttons, and they were uncertain how to find information. Some of users could not understand the meaning of the real‐time (The Norwegian word), which was written under real‐time button. They believe that people can be misunderstanding by using of that word. The usage time on average was large. The reason is that two users spent a long time to find information, but the rest of the users were able to solve the task relatively in god time. The user who spent the longest time to do the exercise said that she is being just a few months in Oslo and She uses the bike to and from school.  Assignment 2 Can you see if there are any delays in traffic?   

 

 Illustration G.4: “Delays” button 

Diagram G.3   

 40

 

 

 

 

Diagram G.4    The result shows that all users could do the task in the relative god time. The graph shows no errors in the result and time was also low. Users believed that the delay is a problem that they meet frequently and it is important to get the message about the delays to be able to choose alternative transport. Participant No: 5 did something that we did not expect, he solved the problem without going back to the menu and in to "delays". It is marked in real time table, the lines that are delayed, as he pointed only at the bar that was marked "delayed" and commented that it was missing how much the train was delayed. Users were satisfied with the use of color, and the image of the button and they commented that the yellow color means the warning messages, and with time can means delays.  Assignment 3 A tourist comes to you and asks you which subway going to Vestli. How do you find this information?  

 41

 

 

 Illustration G.5: “Line map” button 

Diagram G.5    

 

 

Diagram G.6    Diagram G.5 shows that users are able to do the exercise in relatively good time. Only one user has failed to select the right button. Minimum time of 5 seconds and a maximum time of 15 shows that the line‐map button is known for almost all users. No user had major problem with this task. Users have commented that the key is known for them but additional information in the line‐map was a request from a user. He said it will be more user‐friendly if people have possibility to click on the stations button on line‐map to be able to choose more information about the selected stations. Another user said, "It should be possible to select the line‐ map for other transport like bus and tram when you come into the line‐map page."  Assignment 4  A pensioners asks for help to buy a ticket. How you can help him to do this?  

 42

 

 

 Illustration G.6: “Tickets” button 

Diagram G.7    

 

 

Diagram G.8    Error diagram G.8 shows that only one user had problem with finding the ticket‐button, 5 of six users made the task flawlessly. Average time of 10 seconds is a good result. User No. 3 with 18 seconds spent the longest time to do the task. The summary of the results of this task can confirm that the ticket‐button is known for more than 90% of users. Almost all users like this function and they think that it is important to be able to buy tickets in this way at the stations.  Assignment 5 Imagine that you are a tourist from England and cannot read Norwegian. How do you will find information in this system?  

 43

 

 

 Illustration G.7: Language button 

Diagram G.9    

 

 

Diagram G.10    An average usage time of 12 seconds to switch to another language is fine result. Zero error in selecting the correct button says that the language‐button is known to all users. Language‐button redirects the user to a screen with the ability to select multiple languages. Users said that it is important to have this function for tourists and people who do not speak Norwegian, they can use it to find the information they need.   Results of follow up questions  Question 1 : What was your first impression? User 1: "When I first saw it, I thought ‐ what is it? But it was easy to find."  User 2: "I recognize some of the [points on the icons: line‐map and map]."  

 44

 

User 3: "It's always like that little frustrating, especially when one comes from Trondheim who have a completely different scheme that you're used at home and to come in and understand something new. It's always good to know where you are going. I often turn up in the yellow pages and look at the map, so it is well used to. And so I think it's very good to have that [pointing to the line‐map]."  User 4: "The first impression was that it was fairly transparent and easily. But when I came on the first task, I had a little problem to do the assignment."  User 5: The participant found that the interface was clean and transparent. User 6: "That thing was the icon, big buttons. No, it was all right. If I would like to have one thing to say, so maybe those [pointing to the text under the icons] could have been a little clearer."  Summary of results from questions 1  Users are able to understand the importance of buttons and links on the page. They have pointed out buttons that they have used before and they said that they usually use these function in other applications. A user who has been only a few months in Oslo believed that she always been frustrated to understand something new. She could do all the exercises but spent more time than the others. Good feedback as: “big buttons, bold font and detection of buttons” designer can use to create a better version of the prototype. Of usability principles as described by Jacob Nilsen you can find some of them in the feedback from users (easy to use, easy to learn). The users liked the prototype and found that the prototype is transparent and easy to use. It is a sign of usability of the system.  Question 2: Were the icons understandable?  User 1: "yes"  User 2: "yes"  User 3: "yes"  User 4: "Yes. Real‐time, I could not completely understand actually. Delays are perhaps a little more difficult. Ticket was fine, I knew it right away."  User 5: "He found the icons which were understandable, but said also that the real‐time and delay was almost the same."  User 6: "Yes, I think it absolutely. I cannot really say anything about it. It is very easy. The two [line map and map] is very easy to understand, and the [point out tickets] without the text so it can be difficult. "  Summary of results from questions 2  100 % of users said that the icons are understandable and it confirm that they can easy communicate with the interface. Users could see what the buttons do and they have seen some of them in other applications before, but someone were dissatisfied with real‐time and found that the delay button is difficult. Others say that it is difficult to understand buttons without text. The result shows that some of the icon does not exist in other applications so they are difficult without text. It takes time to remove the text under the buttons. Based on feedback from usability tests and interviews, we concluded to use the text under the buttons in the prototype.  Question 3: Is there any information that is missing?  User 1: "No, I think it was mostly about delays and time. Everything was there actually."  

 45

 

User 2: "No, I think the most are there. I cannot remember more than I see there."  User 3: "No, I do not know. I use bicycles, so I use rarely public transport. This [line‐map] is the only path. It should be possible to click on the stations in the line‐map to get more information about the selected station." User 4: "Maybe, if you go into the line map, perhaps you can press the stations, so go there to find the times and stuff like that."  User 5: "Nothing"  User 6: "No, no. That one [pointing to the delay] is very important, I think. It is this that tends to  missing. And so the [real‐time] is very well also. I do not think there is something missing there."  Summary of results from questions 3  Almost all users have said that the prototype covers the user's needs in a traffic stations and it is a good idea to have it in the stations. Others have talked about being able to have had links in line map page to select more information about the selected station and alternative transport. The users as a part of the design group have the opportunity to decide what they want and what they do not want by giving feedback to the designer. In this case, we tried to fulfill the most of the demands that users place on the prototype.  Question 4: Is there something you feel is not necessary?  Summary of results from questions 4  5 of 6 users said that they will not use the weather feature (Illustration G.8) when they are in the station. They believed that all other function is convenient to have. A user has said that it is good to have the help button standing on the screen but he will never use it. User characteristics capture key attributes of the intended user.  The user's ability and skills are an important part of the user's needs. This may indicate that he is proud of his knowledge, but the elderly people with little experience and knowledge often needs help. 

Illustration G. 8: “Weather” button

 Question 5: Do you have any idea about how the solution can be done better?  User 1: "No, I think it looks good. We need something like that."  User 2: "You can find everything here in different languages. No, it is okay I think"  User 3: "I do not know. I was thinking about the weather, what is combination between transport and weather? But it is very important that this [the prototype] as a unit, really agree with it." User 4: "It might be with real‐time, I do not know if it was the only one who has responded to that. Maybe go through the line map, and so on the station, and then see which lines that come and all that."  User 5: "He thought that function real‐time and delay can be joined as only one, so that you get all the information in a window."  User 6: "No, I think that perhaps the font was a little small that [under the icons]. No, but it [the prototype] was great. "  Summary of results from question 5  The majority of users said that they are satisfied with the prototype, and they need something 

 46

 

like that in traffic stations today. The users repeated that they are not satisfied with using the word “real‐time” (Norwegian: Sanntid). In a user‐centered design, designers should be concerned with designing products that support users. We try to use feedback from users to design a better version of the prototype.  Summary of usability testing and questions 

 

 

Diagram G.11    Users tested and discussed the prototype in the usability room. We used this feedback to improve the prototype through the cycle of design and user testing. Usually design of a product can end when both the user and the designer is satisfied with the final product in a specific time. In our case, we could not have more than one user test because of limited time. The goal of the evaluation study was to identify the range of usability problems.  

 

 

Diagram G.12    

 47

 

User number 3 has used public transport rarely, and here we see that she used the longest time to do the exercises (diagram G.12). One reason may be that they have seen the prototype for the first time and they got stress in the start of testing. User number 4 had a problem with the task but did other tasks quickly.  

 

 

Diagram G.13    The longest time is recorded for the first assignment (diagram G.13). One reason could be that because this is the first task, the participants used more time to understand the prototype and how it works. They tried to do the first task while getting familiar with other buttons and function at the same time, and therefore it was easier to do the other tasks. The second assignment, with the minimum time use, was also the easiest for the users. They could do the task in two pages: “Delay” and “Real‐time”. Therefore, those who searched for other information in real‐time page could do the task without having to change the page. This can show us that to have the same information in multiple pages can be useful for users to save time when searching information in a system. Second‐longest time is the task 5 (diagram G.13). To do this task the user has to click on two buttons while all other tasks need just one click. So it is expected that the time spend on the task can be more than others.  

 48

 

 

 

Diagram G.14    The graph above shows how users reacted to the prototype. We begin the analysis from the best results. Assignment number two, with minimum 0 and maximum 10 seconds, came best out in the test. It was difficult to find the right icon for “Delays” (prototype 3), since there is no standard icon for it. After testing several different icons, we understood that the combination of an icon and the word “delay” allowed users to do the task fastest. We have chosen to use the same icon in the final version of the prototype. Assignment 3 comes in the second place (see above graph). We have observed that users did this task in two different ways: some have used the line‐map and others have used real‐time. This may be the reason that the graph for this assignment is very flat. Assignment four is the same as assignment 3 but in the area for user number 3 the graph is much steeper. This can be interpreted that the ticket icon is not as simple as the other icons or the user has not seen the icon before. All those three assignments (2, 3 and 4) were almost at the same level for most of the users. Assignment number five comes in at the fourth place, with a maximum of 30 seconds and a minimum of 12 seconds. The difference between the minimum and maximum here is large. We have observed that some of users had not understood the task well and they searched information on the Norwegian page. They spent most of the time in the Norwegian page and when they found the language button they did the task right away. In task number one the gap between maximum and minimum is 50 seconds. Users reacted differently with this task. We have observed that the most users were unhappy with using the word for SANNTID (real‐time) for the function. They believed that SANNTID cannot give proper significance to the function.  

 49

 

Appendix H: Prototypes  The following features have been implemented in the prototypes:      Paper 

mockupPrototype

1 Prototype

2 Prototype 

3 Prototype

4 1  Tickets  yes  yes  yes  yes  yes 2  Line maps  yes  yes  yes  yes  yes 3  Phone numbers  yes  yes  yes  yes  yes 4  Delays  yes  yes  yes  yes  yes 5  Weather  yes  yes  yes  yes  yes 6  City map  yes  yes  yes  yes  yes 7  Time/date  yes  yes  yes  yes  yes 8  Change language  yes  yes  yes  yes  yes 9  Selected language  yes  yes  yes  yes  yes 

10  Home  yes  no  no  yes  yes 11  Information  no  no  yes  no  no 12  Help  no  no  yes  yes  yes 13  Station name  no  no  yes  yes  yes 14  Real‐time (renamed to “arrival 

times” in prototype 4) no  no  no  yes  yes 

15  Notification icon  no  no  no  yes  yes 16  Route planner  no  no  no  no  yes  All the prototypes are illustrated on the following pages, including the features that are represented in the table above. Note the numbering in the table above compared to the numbers on the prototypes, they show how the prototypes have changed from one version to the next. Black circles indicate changes from the previous version.  

 50

 

Paper mockup 

 Illustration H.1 

1  2 3

64  5 Menu

8 97 

Bottom panel

10

 The pictures below show the submenu of each feature in the menu (compare the numbers on the pictures below and the picture above). They give an image of what should come up when the buttons in the menu above are pressed.   

 

   

 

 

 

   

 

1  32

64  5   

 51

 

Prototype 1 

Illustration H.2 

31  2

4  5 6

8  9 7 

 Prototype 2 

Illustration H.3 

131  4

112  6

123  5

8  9 7 

 52

 

Prototype 3 

Illustration H.4 

13  1  4 9 

142  6

123  5

8 7 

15  10

 Prototype 4 

Illustration H.5 

1413  1  4 9 

16  22 66

123 3 

8 7 

15  10

 53

 

 54