FareBrowser: An Interactive Visualization Tool

for Finding Low Airline Fares

Bill Shapiro and Hench Qian
Department of Computer Science
University of Maryland
{billshap, qian}@cs.umd.edu

Abstract

Introduction

In the past, airline reservations were made either through travel agents or a particular airline. With the emergence of online travel sites, many individuals are now purchasing airline tickets over the internet. Finding cheap airline tickets on the internet remains a formidable task. In particular, budget conscious travelers may want to choose their travel dates, in part, based on which dates the cheapest fares are offered. However, most travel sites require that users specify the exact dates and times they wish to travel. Additionally, the complicated fare structure employed by airlines makes finding inexpensive flights nearly impossible without a sophisticated query mechanism that presents fares in a manner comprehensible to the user.

In this paper we describe an airline fare visualization tool, called FareBrowser, for finding the cheapest round-trip fare that matches the user's travel constraints. FareBrowser allows users to browse the cheapest fares between two cities and filter out unavailable and inappropriate flight combinations to focus on the best ones. FareBrowser presents an overview of available flight combinations for a specified time period (day, week, month, etc.). The user can then interactively filter the display to arrive at the flights that meet the user's constraints. FareBrowser also provides additional details on demand. When the user moves their mouse over a particular flight, additional details about the flight are revealed in a separate box. Additionally, when the user zooms in on the display, additional details about each flight are revealed.

In designing FareBrowser, we attempted to balance two primary objectives. First, the tool should be simple enough that it can be used by the average internet user with little instruction. Second, the tool should provide enough functionality that it is capable of effectively handling sophisticated user queries. In order to characterize how well FareBrowser achieves these objectives, we present a user study that compares FareBrowser to the Best Fare Finder visualization tool available on Travelocity.com's web site.

Related Work

There has been a significant amount of research on visualization of temporal data [6][7] [10], and a small amount of work on the particular problem of visualizing airline flight schedules. Timelines are commonly used for visualizing temporal data [2]. LifeLines [9] is an environment for visualizing events in a person's life (e.g., medical patient records). The visualization consists of facets of a persons life, each of which may contain multiple timelines. A common time scale is provided at the top of the screen. Events are displayed as small boxes or icons and retinal properties are used to distinguish different types of events. There are also several productivity packages, such as Microsoft Project, that employ timelines to visualize schedules.

Casner and Larkin [4] [5] compare several different methods for visualizing airline flight schedules. They argue that graphical presentations are more effective than tabular ones and present a supporting user study. However, they only discuss the visualization of flight schedules for a single day. Nonetheless, they provide several techniques for graphically encoding flight information that are more broadly useful. Norman [8] also briefly discusses techniques for visualizing airline flight information.

Dynamic queries are used in FareBrowser to allow users to interactively narrow the flight search space. HomeFinder [11] and FilmFinder [1] are two visualization tools that provide early examples of how dynamic queries can be used to dynamically filter out irrelevant data through the use of sliders or selection of buttons.

There are several travel sites on the web that have tools for finding airline flights, including Expedia.com and Travelocity.com. The most common tool for finding airline flights consists of a form, where the user specifies the dates on which she wishes to travel and the preferred times and possibly airlines. A database is queried with the provided information and a list of flights that match the criteria is returned, often sorted by price. The user may also be presented with the option of listing flights based on itinerary or price, however, only flights for the specified dates are returned. These tools are relatively efficient if the user have strict constraints on travel dates. However, distinguishing between the results would still be facilitated by presenting them in a graphical form.

Travelocity.com also features a tool called Best Fare Finder for finding the cheapest round-trip fare between two cities when the travel dates are flexible. The primary drawback to this tool is that, because it is menu-driven, it is very tedious to use. The user must first select the fare she wants from a list of fares and then see if departing flights are available in the desired date range. Next she must check if returning flights are available during the desired dates. Finally, she must choose the departing and returning flight times. If acceptable dates and/or times are not available, they must start the whole process over with another fare. If available flights are scarce (as is the case close to holidays), a user may need to search many fares to find one that meets their requirements.

The FareBrowser Interface

Our goal in developing FareBrowser is to allow users to quickly locate the cheapest flight that matches their travel constraints. Consequently, our design emphasizes price. Figure 1 shows the FareBrowser interface. The interfaces is divided into two frames. The left frame is dominated by horizontal boxes, outlined in black, that represent round-trip fares. Each fare box contains the name of the airline that offers the fare and the round-trip price. Additionally, each fare box contains several long white bars that represent the departing and returning flights that are offered within the fare. Each white bar is a timeline, with blue rectangles in a bar representing available departing flights and yellow rectangles representing available returning flights. A common time scale at the top of the left frame displays the dates corresponding to each timeline and allows the user to change the date range with left and right arrow buttons. A status line at the bottom of the left frame displays the number of fares that were found.

Figure 1: The FareBrowser interface

Figure 1: The FareBrowser interface

The top section of the right frame, called the control panel, contains menus for selecting source and destination cities. The user's selection is submitted with the "Find Fares" button just below the menus.

Zooming

A zoom slider in the control panel allows the user to increase or decrease the number of days shown. FareBrowser is capable of effectively showing flight availability for up to two months in a single view as shown in Figure 2. The time scale at the top adjusts to different zoom values by increasing or decreasing the density of dates displayed in order to prevent the time scale from becoming overly cluttered.

Figure 2: FareBrowser showing the lowest fares for a two month period

Figure 2: FareBrowser showing the lowest fares for a two month period

FareBrowser uses an approach similar to that used in the Pad++ [3] Zoomable User Interface, where additional details are revealed as the user zooms in. In particular, when the user zooms in to the single day view in FareBrowser, additional details about each available flight are graphically presented. Figure 3 shows FareBrowser's day view¹. The time scale is changed to hours and the position of each available flight represents its departing and arrival times. Layovers are encoded by white space between flight segments. The size of the white space represents the length of the layover and the lengths of the yellow and blue rectangles represent the lengths of each flight segment. Using this encoding, a user can quickly distinguish between direct flights and flights with layovers, as well as long flights vs. short flights.

Figure 3: Additional details are revealed when the user zooms in to the day view

Figure 3: Additional details are revealed when the user zooms in to the day view

Dynamic Filtering

A user may obtain further details about a flight by moving the mouse over a flight bar. Detailed flight information is then displayed in the Flight Information Box on the lower right. To select a flight on a particular day, the user clicks on a rectangle representing an available flight. When the user selects an available departing flight, for example, FareBrowser dynamically filters available flights by graying out all flights that are no longer applicable, given the user's selection. Figure 4 shows how available flights are filtered when the user selects a departing flight. Currently, only simple filters exist. For example, all return dates before the departing date are grayed out since one cannot return before leaving. Additionally, flights from fares other than the one selected are invalidated because both the departing and returning flight must be from the same fare. If the user clicks again on the selected flight instance or presses the clear button, the flight is deselected and the grayed out portions are returned to their original state.

Figure 4: Dynamically filtering available fares based on the user's selection

Figure 4: Dynamically filtering available fares based on the user's selection

The filtering mechanism can be used to effectively express additional constraints. For example, some combinations of departing flights and returning flights may not be permitted for a given fare. These restrictions may be extremely complicated, but can easily be conveyed to the user by graying out flights based on user selections. The current FareBrowser prototype does not enforce these constraints.

Finally, buttons at the bottom of the right frame allow users to clear and purchase the selected itinerary, respectively.

Overview Capability

The number of fares shown in a single view depends on the number of flights contained in each fare. At the current size, FareBrowser displays 35 flights in a view. If the zoom is set to the maximum value of two months (56 days), then FareBrowser can display the availability of 1,960 flight instances in a single view. It is often true that not all fares will fit in a single view and the user would be required to scroll in order to view additional fares. However, because fares are sorted by price, the user can scan the display from top to bottom to find the first available flight that matches his criteria. The bargain-hunting user would only need to scroll if the visible fares did not contain any acceptable flights.

Implementation

FareBrowser was implemented in Java to run as an applet or application. It heavily uses the Swing component library from Sun. The reader is encouraged to try a demonstration applet that uses real data for selected flights from November, 29 1999.

User Study

A simple user study was performed with eight subjects to evaluate the ease-of-use and performance in solving common and sophisticated tasks of FareBrowser. We compared FareBrowser with Travelocity.com's Best Fare Finder (described above), which is available at http://www.travelocity.com.

Hypotheses

The study tested the following hypotheses:

Users will be able to complete simple tasks in approximately the same amount of time and with few or no errors when using FareBrowser as compared to using Fare Finder.
Users will be able to complete complex tasks in less time and with fewer errors using FareBrowser as compared to using Fare Finder.
Users will be able to learn to use FareBrowser effectively in a short time.

The first hypothesis states that FareBrowser should not perform significantly worse than Fare Finder for simple tasks. A simple task may include finding the cheapest flight when the travel dates are fixed. The second hypotheses is that FareBrowser will perform significantly better than Fare Finder for complicated tasks. An example of a complicated task would be finding the cheapest fare when the travel dates are flexible. Finally, the third hypothesis is that FareBrowser does not have such a steep learning curve that users will require more than a few minutes to learn to use it effectively.

Subjects

Eight undergraduates at the University of Maryland participated in the study. Their backgrounds are indicated in Table 1.

User	Major
1	Non-technical
2	Engineering
3	Non-technical
4	Engineering
5	Non-technical
6	Engineering
7	Non-technical
8	Computer Science

Table 1: User backgrounds

One half of the students in the study were technical (either Computer Science or Engineering majors) and one half were non-technical. We felt that technical users may be more comfortable using a computer and are more likely to be familiar and experienced with analyzing graphs.

Procedure

Each user was presented a set of specific instructions on the usage of FareBrowser and FareFinder and were given up to ten minutes to familiarize themselves with the systems. Then, each user was presented with the following set of tasks:

Find (bring up the purchase screen of) the CHEAPEST fare from AUS to ATL departing on December 18th and returning on January 3rd.
Find (bring up the purchase screen of) the CHEAPEST fare from ATL to BWI departing between December 18th and 22nd and returning between January 3rd and 7th.
Find (bring up the purchase screen of) the CHEAPEST fare from BWI to AUS departing between December 28th and 29nd and returning between January 3rd and 4th.
Find (bring up the purchase screen of) the CHEAPEST fare from GTR to ATL departing on December 28th and returning on January 3rd.

Task 1 was designed to be a simple and straight-forward task to get the user started. Task 2 was designed as a task to find fares given a range of dates between a source-destination pair with high flight availability, meaning that the user should not have to search many fare to find one that is available. Task 3 was designed as a task to find the cheapest fare when both departure and return dates are flexible, but availability is low. When availability is low, the user is required to search through several flights before finding availability within the desired date ranges. Task 4 is very similar to task 1, but it is expected to better reflect the performance of an experienced user.

Users 1-4 were asked to perform tasks 1 and 2 with FareBrowser and tasks 3 and 4 with FareFinder. Users 5-8 were asked to perform tasks 1 and 2 with FareFinder and tasks 3 and 4 with FareBrowser. The tasks were performed in order from 1 to 4, and the elapsed time and fare found for each task were recorded. An equal number of technical and non-technical users were assigned to each of the two groups.

Results

The results of the study are shown in Table 2, and a statistical analysis is shown in Table 3. All values are in seconds. FareBrowser is abbreviated FB and FareFinder is abbreviated FF.

Task	User 1		User 2		User 3		User 4		User 5		User 6		User 7		User 8
Task	FB	FF	FB	FF	FB	FF	FB	FF	FB	FF	FB	FF	FB	FF	FB	FF
1	440		70		220		95			150		245		175		145
2	150		70		75		60			50		85		75		65
3		(x)65		105		(x)300		125	130		60		130		40
4		60		55		75		100	125		60		75		35

Table 2: Results from user study (in seconds)
(x) - indicates incorrect (not cheapest) fare

Task	FareBrowser			FareFinder
Task	Mean	Standard Deviation	90% Conf. Interval	Mean	Standard Deviation	90% Conf. Interval
1	206	146	(34, 378)	179	40	(132, 226)
2	89	36	(47, 131)	69	13	(54, 84)
3	90	41	(42, 138)	149	90	(43, 255)
4	74	33	(35, 113)	72	18	(51, 93)

Table 3: Statistical analysis of results (in seconds)

Task 1

Task 1, although simple, required the longest time to complete (with the exception of users 2 and 4). This can be attributed to the users' unfamiliarity with the systems, problem domain, and task demands. With FareBrowser, the main confusion was that a departing flight and a returning flight from the same fare box must be selected. Apparently, the fare box concept is not obvious in FareBrowser to some users (users 1 and 3). However, users 5-8, after using FareFinder first, had no such confusions. Another confusion was that some users did not immediately realize that fares were sorted by price, and had to look at the interface for a moment or re-read the instructions to figure it out. In all, the users were able to arrive at the cheapest fare, but the step-by-step procedure of FareFinder was more intuitive.

Task 2

For task 2, the cheapest fare was among the first fares examined, so the two systems had similar performances, as expected.

Task 3

For task 3, FareBrowser performed better on average than FareFinder. In FareBrowser, if no available flights are found in the desired date range, the user need only scroll down to find the first available flight. In FareFinder, however, users had to follow each listed airfare to see if a flight was available for the desired date range. Due to the low availability of the flight, the user was required to go through several fares before an available flight was found. Two users (users 1 and 3) became frustrated and began skipping fares, ultimately choosing incorrect (not cheapest) fares.

Task 4

As expected, users performed much better on task 4 than task 1 even though they were equivalent in terms of difficulty, regardless of the tool used. This showed that experience can significantly improve performance. Task 4 suggests that FareBrowser and FareFinder are comparable in the basic case of finding flights when the departing and returning dates are known.

Qualitative Conclusions

There was a relatively high variance in the performance of the FareBrowser users. This indicates that FareBrowser is somewhat complex, and different users have varying success. In general, users from a technical background (users 2, 4, 6, and 8) had more success than users from a non-technical background (users 1, 3, 5, and 7). For FareFinder, however, the variance was lower, indicating that FareFinder was easier to understand for all users.

The zooming feature in FareBrowser was not well-utilized. The default view showed two weeks of flights at a time. To see flights outside the current view, the user could either scroll to the next two weeks or zoom out to expand the visible date range. While performing the tasks, the users often encountered situations where the departing date was visible, but the returning flight was not, or vice versa. Most users opted to scroll back and forth between the visible date ranges. The two users (2 and 8) that did use the zooming feature performed best. Some of the users had zoomed while experimenting before starting the tasks, but the two that worked with a two week date range (users 1 and 5) throughout the study had the worst performance. These results give a strong indication that performance on FareBrowser is strongly enhanced when both the departing date and the returning date are visible.

User comparisons of the two systems were mixed as well. Most users indicated that they felt they worked faster in FareBrowser than FareFinder because of the continuity, with everything in one screen. Some users (mostly the users with technical backgrounds) liked the fact that FareBrowser displayed all of the data, and put them in control of picking a fare. Other users (mostly the users with non-technical backgrounds) felt FareBrowser was too complex and not as straight-forward as FareFinder. They felt it relied too heavily on the user's ability to read graphs.

Quantitative Conclusions

We performed unpaired t-tests for each of the tasks in order to determine if the completion tasks were statistically distinguishable. However, not surprisingly, given the sample side none of the results were statistically significant.

Limitations

There were many potential limitations in this study. One obvious limitation is the small amount of data due to time constraints. Obviously, stronger conclusions can be made if more data was collected. Not only would more tasks give a better comparison of FareBrowser and FareFinder, but also a better indication of the respective "learning curves" and the performance of an experienced user.

Another potential limitation is the order in which the tasks were performed. Our results indicate that performance for tasks 2 and 3 using FareBrowser was similar while task 3 was expected to be more difficult. However, this is not a fair comparison since user knowledge at the time the tasks were performed was different. Task 2 was done with some experience with FareBrowser, but no experience with FareFinder. Task 3 was done with some experience with FareFinder, but no experience with FareBrowser. If the order of the tasks were shuffled, there would be an opportunity to give a fairer evaluation of FareBrowser on tasks 2 and 3 with similar user knowledge.

Also, as the study was being performed, it became obvious that the usage instructions given were not sufficient, especially for FareBrowser. This led to the struggles in task 1 as documented above. It also creates some uncertainty as to the level of understanding the user had while performing the other tasks.

Finally, performance issues of FareBrowser and FareFinder biased overall times. Due to time constraints in development, FareBrowser has many performance issues. Slow response in scrolling caused several impatient users to click many times and over-scroll, wasting precious time, and some minor bugs caused a few other confusions. FareFinder, of course, is on the internet. Its performance is partly influenced by internet traffic. Since this study was done at different times of the day, variance in internet delay may have contributed to some discrepancies in results.

Overall, the user study suggested that although it is more difficult to learn, FareBrowser is at least comparable with FareFinder for basic tasks, and can be more effective with finding fares given date ranges.

Conclusion and Future Work

Finding the cheapest airline fare is much more difficult when the user is flexible with regard to travel constraints. FareBrowser is proposed as a visualization tool that uses a fare overview, zooming, details on demand and dynamic filtering to quickly focus on the best available fare. The user study suggests that the simple menu-driven approach used in Travelocity's Fare Finder is initially easier to understand, but experienced users can perform complicated tasks more efficiently using FareBrowser.

The user study also suggested several ways in which FareBrowser can be improved. Step-by-step instructions for using FareBrowser would be extremely useful for guiding the novice user. Additionally, The zooming capability was not utilized by most of the participants in the study, although it was very useful when used. Zooming may be more intuitive if it is integrated into the time scale component, which already contains the arrow buttons for changing dates.

There are several additional features that could improve the range of functionality offered by FareBrowser. First, there is much room for improvement in the dynamic filtering facility. Currently, filtering is based only on user flight selection. It would be useful to add sliders that allowed users to narrow the search space by specifying the ranges of acceptable departure and return days, number of layovers, length of flights, and possibly other attributes. Double-box sliders like those used in HomeFinder [7] and FilmFinder [1] that allow users to specify both upper and lower thresholds on attribute values would be an effective way to implement additional filtering.

It may also be useful to implement a more compact view of a fare. Currently, each flight that is available with a fare is shown. A less detailed overview could simply show the dates on which a departing or returning flight, as opposed to providing the information separately for each departing and returning flight. This would significantly increase the number of fares that would be visible on a single view. In the case where availability is scarce, the user could quickly search the fares from top to bottom until she found a fare that matched her criteria. She could then zoom in on that particular fare to see the individual flights offered on the desired dates.

The mechanism for specifying the displayed date range can be improved. Currently, if the zoom is set to a week view, for example, the user can move ahead or back by a week at a time, but cannot center the date range on a particular date. It would be useful for the user to center the displayed dates on the range that she is considering. One possible solution is to use a scroll bar instead of arrow buttons to change the date range.

Finally, significant improvements can be made in speed/responsiveness, space utilization and usability through incremental refinement of the interface.

Work Cited

1: Ahlberg, C. and Shneiderman, B. Visual Information Seeking: Tight coupling of dynamic query filters with starfield displays. Proc. of ACM CHI94 Conference (April 1994), 313-317.
2: Allen, R.B. Interactive timelines as information systems interfaces. Symposium on Digital Libraries. Japan, August 1995.
3: Bederson, B.B., Hollan, James D. Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics, Proceedings of UIST '94, (Marina del Rey, California, November 2-4, 1994), 17- 26, ACM, New York.
4: Casner, S. and Larkin, J. Cognitive Efficiency Considerations for Good Graphic Design. Congnitive Science Society Proceedings. August, 1999.
5: Casner, S. and Larkin, J. Drawing Pictures Worth Ten Thousand Words: An Information Processing Model of the Design and Use of Visual Displays of Information. Cognitive Science. January, 1990.
6: Hibino, S., Rundensteiner, E. A. User interface evaluation of a direct manipulation temporal visual query language. Proc. ACM Multimedia 97 Conference, ACM, New York (1997), 99-107.
7: Mackinlay, J.D., Robertson, G.G., Card, S.K. The Perspective Wall: detail and context smoothly integrated. In Proceedings of SIGCHI '91 , (1991) 173-179, ACM, New York.
8: Norman, D. Things that Make us Smart. Defending Human Attributes in the Age of the Machine. Addisson-Wessley, 1993. pp. 55-60.
9: Plaisant, C., Milash, B., Rose, A., Widoff, S. and Shneiderman, B. Lifelines: Visualizing Personal Histories. CHI'96 Conference Proceedings. NY:ACM Press, 221-227.
10: Sanderson, P., Scott, J., Johnston, T., Mainzer, J., Watanabe, L., and James, J. MacSHAPA and the enterprise of exploring sequential data analysis (ESDA). Int. Journal of Man-Machine Studies 41 (1992), 633-681.
11: Shneiderman, B. Dynamic queries for visual information seeking. IEEE Software 11, 6 (1994), 70-77.

1: Flight lengths are distorted by differences in time zones. The current prototype does not account for time changes that result from crossing time zones.

William Shapiro

Last modified: Tue Nov 30 15:32:28 EST 1999

Web Accessibility