a problem shared...

Collaborative Information Gathering (CIG)

Introduction

Planning a trip overseas requires a lot of work, and there are many decisions to be made — choices of airline, hotel, rental cars... these are just a few of the possible components of an overseas trip. With the advent of travel companies on the World Wide Web, a traveller could, in theory, make all their own travel arrangements. Travel agents, however, provide a "value-added" service by having background knowledge and sometimes even personal experience of the destinations and airlines, access to wholesale fares, and experience with the booking systems and companies involved. When a travel agent and client work together to plan an overseas trip, the itinerary for the trip is a shared piece of information, into which the travel agent and the client both have an input perspective.

With this in mind the Collaborative Information Gathering (CIG) project was started; its aim to investigate and provide a means for travel agents and clients to visualise and edit some shared digital representation of a trip. To this end, the HCI group collaborated with a local travel agency for the purpose of both determining industry needs and testing software solutions.

 

two passports

Information Sharing for Problem Solving

back to top

When creating a travel itinerary, which is basically a plan for a trip away, a travel agent and their client will work closely together, the travel agent extracting information from a variety of systems (airline booking systems, hotels, the internet, etc.) to meet the needs of their client. The client in turn provides the agent with information about the trip they would like to take. This is perhaps best illustrated with an example (entirely fictional):

Dana is planning a trip to Canada to see friends and family. She needs to visit Toronto and Edmonton, and would like to spend a couple of days in Los Angeles on the way home to visit Disneyland. This means she needs flights to all her destinations, a hotel in Los Anegeles, and she also decides to pre-purchase her passes to Disneyland.

Dana calls her travel agent, and explains what she needs. She also specifies that she wants to leave on a Friday and return on the Monday two weeks later, and she wants to fly Air New Zealand.

The travel agent checks on flight availability for the dates Dana requires, and finds that there are no available Air New Zealand seats. United, however, still have seats available. Alternatively Dana could postpone her return to New Zealand by one day. The travel agent also makes hotel bookings at a hotel close to Disneyland that will be to Dana's taste. The travel agent calls Dana with the news about the flights, and Dana decides to travel United. Armed with definite dates, the agent confirms the hotel booking, and pre-purchases the Disneyland tickets.

This is a very simple example, yet it shows that arranging an itinerary is a process of negotiation. The CIG project has produced a piece of software that helps to manage this process, by allowing the travel agent and the client both to access an up-to-date version of the travel itinerary in an online system, and use "alerts" to pass messages to each other. An example of how alerts work is as follows:

The travel agent tries to call Dana to let her know that there are no available Air New Zealand seats, but can't get hold of her. Instead the agent puts an alert on the flights in the itinerary. When Dana logs on to check the itinerary later in the day, she calls the travel agent and confirms that she will travel United.

Alternatively:

Dana finds out that a family member is sick and decides not to go to Disneyland after all. The travel agent is not in when she calls, so she logs on to her travel itinerary, and leaves an alert asking the agent to cancel the arrangements for Los Angeles. The agent does this, and the itinerary is automatically updated. When Dana checks the itinerary later on in the day, she sees that her stay in Toronto has been extended and her plans for LA cancelled.

This simple example gives some indication of the negotiation process that goes on for even a simple trip away; for longer or more complicated trips the process can span many days, sometimes even continuing while the client is overseas. The CIG software allows both clients and agents to alter the itinerary and ensures that both parties always see an itinerary that is up-to-date. Furthermore the itinerary facilitates message passing between the client and the agent to further support negotiation.

 

Information Visualisation

back to top

When we organise our lives, we use calendar dates and times to discuss time. These dates and times are an important part of a travel itinerary, and can be easily represented by using a calendar (picture, for example, the travel agent checking a desk calendar to find out the date of "the first Monday of the month"), or ordinary text (as in an ordinary Microsoft Word™ printed itinerary). However, mix in changing time zones and the international dateline and the calendar representation of time begins to lose meaning (12 noon or 12 midnight? departure or destination time?). To account for these issues in discussing time, the CIG project allows three visualisations of an itinerary.

  • Calendar visualisation

    The user views the itinerary as a calendar, with events marked as on a desktop calendar. Days can be clicked on to add or alter travel events. This provides a good way to get an overview of the itinerary.

  • Microsoft Word™ visualisation

    The traditional printed itinerary that travellers are familiar with. This visualisation has been shown in usability studies to be comfortable for travellers to use (probably due to its familiarity), and particularly useful when the traveller wants detailed information on a travel event (for example the exact departure time of a flight).

  • Timeline visualisation

    This visualisation was developed particularly to deal with the confusion created by traditional visualisations when the traveller is changing timezones. It is simple to work out time-related information using this visualisation. For example, how long a flight takes, or what time it will be at home when the traveller arrives at their new destination. It is a graph-like representation, with locations shown on the vertical axis and time on the horizontal axis. Day and night (local time) are represented by shading, and travel events such as flights and hotel stays are represented by the lines on the graph. Clicking on the lines that represent travel events allows the user to get more information or change the events.

    To the right is an example of the timeline visualisation in use, the trip shown is from London to Auckland and back again. The flights are represented by the yellow lines, and the one-day stay in Auckland by a green line. Arrival and departure times are shown in boxes.

    an example of the timeline visualisation

Obviously, these are just some of the potential ways to view a travel itinerary, and there is research potential for developing new visualisations and methods of interaction.

 

System Architecture

back to top

For this system to be effective in allowing collaborative creation and maintennance of a travel itinerary, it is vital that any updates to itinerary information are immediately propogated through the system. So, for example, if the agent changes flight information via the booking system, this must immediately be reflected by the timeline view of the itinierary. To facilitate this immediate update, a client-server architecture is used, where itinerary information is stored in a central database, and all visualisations/modifying applications are clients. This architecture is illustrated in the diagram below.

the system architecture

 

Research Directions

back to top

There are a variety of directions in which research on this project could devleop: developing collborative information gathering software for other domains, creating new visualisations, and integrating new interface tools to the exisiting system to name just a few. The HCI group is currently pursuing two directions:

  • Mobile CIG

    There is vast potential for the CIG system to be used on the move; while travelling, or simply while out of the office. A laptop can be a cumbersome piece of equipment, and more and more people are carrying smaller computing devices to remain connected.

    Work has already gone into modifying the CIG software to allow use from a mobile phone, and the system is currently being adapted to a Personal Digital Assistant. These devices present special challenges both technically (the mobile phone, for example, doesn't have the computing power to allow modification of an itinerary), and in terms of interaction (displays for small screens have to be stripped down to be usable, for example).

  • Testing

    The CIGS system still requires evaluation for long term system soundness. Moreover usage testing and usability testing could reveal areas for further development and improvement of the CIG software. The use and usability testing is particularly important in the use of CIG on mobile devices.

These are only some of the possible research opportunities in this project.

 

Selected Publications

back to top
  • Masoodian, M., and Lane, N. (2002): "MATI: A system for accessing travel itinerary information using mobile phones", in Proceedings of HCI '02, The 16th British HCI Group Annual Conference, London, UK.

  • Masoodian, M., and Lane, N. (2001): "Access to personal travel itinerary information using mobile phones", in Proceedings of OzCHI '01, The CHISIG Annual Conference on Human-Computer Interaction, Perth Australia, p 90-95.

  • Apperley, M., Fletcher, D. and Rogers, B. (2000): "Breaking the copy/paste cycle: the stretchable selection tool" in Proceedings of First Australian User Interface Conference, AUIC 2000, Canberra, Australia, Australian Computer Science Communications, 22(5), p 3-10.

  • Apperley, M., Fletcher, D., Rogers, B., and Thomson, K. (2000): "Interactive visualisation of a travel itinerary", in Proceedings of Working Conference on Advanced Visual Interfaces, Palermo, Italy, p 221-226.

For more publications from this group, see our publications page.

top

Valid HTML 4.01 Valid CSS