Sharescape: An Interface for Place Annotation - GroupLens

Proceedings: NordiCHI 2008, October 20-22, 2008

Full Papers

Sharescape: An Interface for Place Annotation Ken Reily, Pamela J. Ludford, Loren Terveen University of Minnesota, Department of Computer Science 4-192 EE/CS Building, 200 Union St SE, Minneapolis, MN, USA 55455 {kreily, ludford, terveen}@cs.umn.edu

ABSTRACT

at present does not do as well at finding geographic places of interest as it does finding information of interest. For example, the authors know of one popular neighborhood dining establishment that does not have a sign out front, let alone an Internet presence. If you were to search for good restaurants in the area using presently-available web technology, you probably would not find it. However, patrons often find themselves waiting for a seat on most evenings due to its popularity. As a new resident or visitor to the neighborhood, how would you bring together information in the physical and virtual worlds that leads to this popular place to eat? The prevalence of geographic information on the web is hardly lost on the marketplace. Over the past few years, the web has seen the development of sites and applications that allow users to process geographic information in innovative ways. For example, many sites that began as strictly mapping sites (Yahoo! Maps) have now expanded to become local search engines, allowing users to enter a typical content query (“restaurants”) along with a geographical base for the search (“New York, NY”). These applications represent an interesting intersection of new technology (content-based search using Internet search engines) with old (maps). This paper explores three research questions related to this technological niche:

Many people use the Internet to search for geographically local information, with a growing number of websites dedicated to this task. However, it is not clear exactly how users integrate geographic search with content-based search, nor how to obtain reliable information about places in a geographic region. We created Sharescape, a map-based application in which information is contributed by community members. We conducted a user study to evaluate the utility of this means of obtaining information and to investigate how users integrate geographic and content-based search. Our results suggest that 1) maps create an implicit context in an interface that designers should honor, 2) communitymaintained information about local geography has important benefits over information mined from web sites, and 3) users often are not aware of the privacy implications of their actions, and therefore designers should incorporate special privacy safeguards.

Categories and Subject Descriptors H.5.3 [Information Interfaces and Presentation]: Group and Organization Interfaces—Web-based Interaction

General Terms

1. Geographic and content-based search: How do users integrate geographic search with content-based search?

Design, Experimentation, Human Factors

Keywords

2. User-contributed content: Does community-maintained geographic information have any advantages over geographic information mined from the web and centrally maintained?

community, interface design, mapping, privacy, tagging

1.

INTRODUCTION

According to a 2005 study by Himmelstein, 25% of all Internet search engine queries are for merchants “near my home or work.” [6] In addition, the same research mentions that 20% of web pages include “one or more easily recognizable unambiguous geographic identifiers, such as a postal address.” However, unlike information content, the Internet

3. Privacy: Are there privacy considerations unique to community-based mapping applications? Our results show that maps ultimately create an implicit context that affects the user’s ability to successfully search, that community-maintained information in such applications has important benefits, and that interface designers need to be aware of the privacy implications of their designs. The rest of this paper discusses related work, describes the Sharescape application and the accompanying user study, and then presents detailed results along with an extended discussion.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. NordiCHI 2008: Using Bridges 18-22 October, Lund, Sweden Copyright 2008 ACM 978-1-59593-704-9 ...$5.00.

2. 326

RELATED WORK


Full Papers

We begin our look at related work by surveying previous research with respect to geographic applications. Locationbased messaging systems are of particular interest because they involve users contributing information of which geography is a significant component. In addition, we briefly explore research related to using technology in geographic spaces. Finally, we examine a number of existing web applications related to mapping, some of which have a social or community element to them.

2.1

Related Research

Many technologies attempt to combine Internet content with geography. Location-based messaging systems such as E-Graffiti [3], DeDe [7], and GeoNotes [11] are one such technology commonly studied. Such systems build databases of places and content (messages) that users “leave” at their places. These datasets are one means of obtaining information about places in a community. Here we explore another: letting users directly contribute information about places they are familiar with. PlaceMail is a representative location-based messaging application that allows users to leave a message for themselves at a particular place, and receive a reminder as they approach the place [9]. The messages that users leave for themselves often reveal interesting connections between places and the activities one can perform at them. In addition, other user activity, such as the number of users who bookmark a place or the number of messages left at a place, might give users a sense of a particular place’s popularity. Ludford [10] describes a proof-of-concept implementation of local search that uses data culled exclusively from everyday use of the Placemail system. However, that implementation did not study the issues involved in asking users to contribute places directly, or the design issues involved in searching for the contributed data. We extend the concept with a practical implementation that allows users to contribute places directly and search for places of interest within the database. Brown et al. explore the concept of geography as it relates to technology [2]. They discuss the common notions of place and space and use artifacts such as maps and guidebooks to study how the technology affects subjects’ mental map of the surrounding area. However, they direct their research towards bringing technology into geography (through locationand context-aware applications on portable devices) rather than the other way around. We focus on applications designed to be used from the home or office where the device being used may not have any specific relationship to the geography of interest to the user.

2.2

Web Applications

A number of publicly available web sites allow users to search for geographic information on the Internet. These sites differentiate themselves with respect to how they obtain information. Some sites, commonly called local search engines, retrieve their data by crawling web sites in much the same way as content search engines. Other sites encourage community contribution of geographic content. Both of these categories are closely related to our work. Local search engines such as Google Local (local.google.com) and Yahoo! Local (local.yahoo.com) have become increasingly popular for tasks one would ordinarily carry out using a phone book. While their search engine counterparts work

327

remarkably well for finding Internet content (web sites), it is not clear that they work equally well at finding geographic content (places). For example, we recently used Google Local to search for toothpaste in a neighborhood that contains at least several stores that sell this necessity. The search returned two entries: a gardening store and a lawyer. One reason might be that the metric used for determining the relevance of a web site (such as Google’s PageRank) does not yet have an effective analog in the geographic space. The number of Internet citations of a particular address or shop name might not necessarily equate to its popularity in the community or relevance to the query. As another example of how local search engines might miss the mark, we used Yahoo! Local to search for a laundromat in the same neighborhood. While all the results were relevant (places where one might do one’s laundry), one highly-ranked store has been closed for at least 6 months. In contrast to content search engines and local search engines, which attempt to gather information autonomously, community-based information repositories have become increasingly popular. Well-known web sites such as Wikipedia (www.wikipedia.org), del.icio.us (del.icio.us), and Digg (www.digg.com) allow their respective communities to generate and maintain their content. Such sites have very mature models for facilitating user involvement. However, these sites also share the distinction of asking users to directly contribute or annotate content in the digital domain (articles and bookmarks). We focus instead on systems where users are asked to maintain information about the physical world. The concept of community-maintained geographic content is not novel in and of itself. Platial (www.platial.com) allows users to create individual maps. The maps are often organized by subject (ex. “My Favorite Beaches” or “USA National Parks”). In addition, Google recently introduced “My Maps” (maps.google.com), which expands upon the Platial concept but adds innovative methods for describing places such as clicking or drawing directly on the map. While these maps often tell interesting stories about their respective creators, their utility for discovering a neighborhood hot spot might be limited unless you happen upon a map describing such a thing. A host of other sites offer subtle variations on the above themes. Panoramio (www.panoramio.com) allows users to associate photos with a place and tag their photos. Google integrates the site content into their mapping applications, such as Google Earth, allowing users to get a picture of selected places. Wayfaring (www.wayfaring.com) allows users to create personalized maps similar to platial.com, but also integrates a social networking aspect. Unlike these applications, we focus on creating a single repository for geographic information rather than multiple maps each with its own subject or story. Finally, there exists little or no public data about how users interact with many of these sites. We expand on their concepts by conducting an empirical study to gather data about how users search for and contribute information using these systems.

3.

SYSTEM OVERVIEW

We based the conceptual design of the new system on the basic concept of a wiki, namely that the content of the system is added by its users. The basic entity managed by


Full Papers

Figure 1: Visual breakdown of the Sharescape interface the system is a place (a geographic location) and associated information. Users both enter information about places and search for it. At this point, the system does not support the full range of wiki functions; for example, we have not implemented “Recent Changes” or “Watch List” features yet. The Sharescape home page consists of the map, set to a default center point and zoom, populated with all places from the database that fit within the current viewport. To prevent overcrowding of map markers, we use a basic clustering algorithm to condense clusters of markers into a single, expandable marker. A major design decision was to decouple content-based search from map activity. In other words, users first perform a content search and then must map their results explicitly. The content search design borrows heavily from existing search engines. Users search by selecting the “search” link from the menu. This presents them with a single freeform textbox into which they enter a term or terms. The system searches every data field, including keyword tags, for the term(s) entered by the user and returns them in a list to the right of the search textbox. The user then has the option to further refine the search, or map the current set of results. Figure 1 shows a visual breakdown of the Sharescape interface immediately after the user searched for the term “school”. The top set of 3 panes deal strictly with the map, while the bottom set of 3 panes work relatively independent of the map. We designed the interface as a series of panes with somewhat strict rules for their interaction. The design was intended to allow users to work independent of the map until they had reached a point in their content-based activity where it was desirable to map the results. User actions in the bottom panes do not directly affect the top panes until the user explicitly issues a command such as “show all places in map”. Figure 2 gives a logical view of the relationship between the panes and the functions they support. Users contribute information by adding or editing a place. Selecting “Add Place” from the menu presents the user with

Figure 2: A typical search workflow. Here, each box represents a visual pane in the interface.

a single, freeform textbox into which they can enter an address or intersection. The system sends this information to a 3rd party geocoding service that returns latitude, longitude, and a standardized address. Assuming the user entered a valid address, he or she then enters a name, a phone number, a URL, freeform notes, and one or more tags (Figure 3). The user then saves their entry and it now appears on the map for them and all other users. Users may also edit places contributed by themselves or any other user. Users find information by searching or browsing. Selecting “Search” from the menu presents the user with a freeform textbox similar to most Internet search engines. Users enter one or more terms that are matched to virtually any field. Users may also select “Tag Browser”. This presents the user with a list of discrete tags. Users may select a tag, after which the system displays all tags related to the selected tag. Users may select up to 4 related tags, but in practice 2 is usually enough to identify a place of interest. Whether browsing or searching, the system displays results in the results pane located in the lower right hand corner. Users

328


Full Papers

Figure 3: The “Add Place” interface, showing the fields captured. This particular subject added his or her home address (address obscured).

329


Full Papers Task # 1,2 3,4 5 6 7 8

have the option to select a place (for display in the details pane), or to map all places in the result set. For example, assume that a user would like to map all schools in his or her neighborhood. He or she might begin by selecting the Search menu item in the bottom left. This would present the user with a search textbox in the bottom middle of the screen. The user would then enter a search term, such as the word “school”. The system would then present the user with a list of results in the bottom right corner. The user can then elect to display the results on the map or refine their search term(s). If the user decides to display the results on the map, the map centers and zooms appropriately. The user can select a place of interest on the map to view and optionally edit its information. The detailed place information appears in the upper right corner of the page. Alternately, the user has the option to use the Tag Browser. This allows the user to browse and recognize the content they are looking for rather than trying to come up with a term to describe it.

4.

Description Search for a specified place Browse for a specified place Register Contribute a place Find a grocery store Find a place you might like to eat

RQ RQ1 RQ1 RQ3 RQ2, RQ3 RQ1, RQ2 RQ1, RQ2

Table 1: The 8 subject tasks

might like to eat” is an example of an open ended task. We consider the task open ended because there are many different ways to satisfy this type of request. For example, you might decide you feel like a hamburger, and so you search or browse for restaurants that might serve you a hamburger. However, you might instead decide that you don’t want to invest much time eating out so you choose to focus on all of the restaurants within a specific area, regardless of what they serve. Of the 8 tasks, we selected 4 of them to directly help us answer RQ1. These 4 tasks explicitly requested the user search or browse for a place. In these cases the task included a specific place that was known to be in the data set. We selected 2 tasks to help better understand the privacy issues discussed in RQ3. These tasks asked the user to register for an account on the site and add a place to the database. The remaining 2 tasks were open-ended tasks with implications for all three research questions. We concluded each session with a debriefing interview. This let us clarify assumptions and further explore the trustworthiness of the data (RQ2) and privacy issues (RQ3). Subjects were asked about actions they performed during the session that had potential privacy implications. We also asked them how they felt about the data they had entered into the system persisting and being visible to other users.

EXPERIMENTAL DESIGN

We conducted a formative user study to answer the research questions described in Section 1. Six subjects (4 male and 2 female) evaluated the application in a usability lab. We screened the subjects to ensure they had previous experience with similar Internet applications. All of the subjects were familiar with Internet mapping applications and the basic purpose and functions of a wiki. In addition, several of them contributed to an online community of some sort during the past 3 months. When asked about familiarity with the concept of tagging, subjects gave varying responses. Some of the subjects claimed to be familiar with the keyword tag concept. Others interpreted tagging in a binary sense; that is they felt an object was either “tagged” or “not tagged”. In this respect, they interpreted tagging to mean bookmarking or flagging. We set up the usability lab to imitate a typical office computer environment, with a desk, chair, and PC. Subjects were asked to think out loud and we recorded audio of them as they evaluated the application. We videotaped each session from several different angles. In addition, we used infrared eye tracking equipment to map the subjects’ eye movements against a screenshot of the application. We initially populated the application with data from another research platform, a community directory, and adhoc places added by the research staff. In all cases, the data closely approximate true user-generated content because they were provided by people familiar with the places in question. We started the evaluation by showing subjects the home page of the application and asking them to describe what they saw. Then, we explicitly told them the nature of the site (a community-constructed map). Next, we had them perform a series of tasks meant to assess the interface. We concluded with a debriefing during which we asked for feedback about the interface and followed up on the behavior observed during the evaluation. Subjects completed a series of 8 tasks; the first were relatively directed while later tasks were quite open-ended (Table 1). “Map all places tagged with ‘school’ ” is an example of a directed task. The purpose of this type of task is to see if the interface properly affords the intended actions and gather interface-specific design feedback. “Find a place you

5.

RESULTS

In this section we report results as they relate to the three research questions from Section 1.

5.1

Geographic- and Content-based Search

The existence of the map on the interface seemed to create an unintended and implicit context to the user’s actions. Because we were unaware of it, we did not design the application to work within the implicit context, and as a result some operations confused the users. For example, every user failed at least once when asked to enter a place, apparently due to the context created by the map. Clicking on “Add Place” in the menu presented the user with a simple but unstructured freeform textbox. The application required a street address, city, and state at a minimum. With the map centered on an area of interest, say a major metropolitan area, each subject entered a street address but omitted city and/or state information. During the debriefing we asked them why they did this and each one indicated that they felt the system would understand what he or she meant. In other words, each subject believed the system would understand their input with respect to the context created by the map. In addition, the presence of the map confused a couple of subjects when asked to perform activities that involved a search. At issue was whether or not the search or tag

330


Full Papers

Figure 4: When asked to search for a specific place, eye tracking results show users often tried browsing the “places in view” list before finding the search link.

331


Full Papers

browser functions were bounded by the current map viewport or not. Several users attempted to adjust the map viewport before initiating a search, believing that the map set the context for the search operation they were about to perform. In addition, a couple of users were confused when their search operation returned one or more places that were well outside the current viewport. One user even wondered aloud before entering a search term if the search would return places outside the current viewport. Further, as the composite eye tracking plot of Figure 4 shows, many subjects focused on the “places in view” pane, adjacent the map, when asked to search for a place. Since the home page map appeared “ready”, with places plotted on the map and listed in the top middle pane, subjects felt they could recognize the place they were asked to find in the list. However, eventually the subjects found this method of searching cumbersome with hundreds of places to look through. They went on to find the “search” menu item and every subject was successful in finding the requested places. Finally, decoupling the user’s content-based activity from their mapping activity ultimately proved confusing. The interface requires users to execute their search on the bottom half of the interface. Results are displayed in the lower right, and as explained above the interface requires users to explicitly map their search results. However, subjects clearly looked at the map to see their results. Disappointed at seeing no activity in the map, they eventually found their search results, but the explicit mapping step eluded all but two of the subjects. Discussion. Most generally, the geographic- and contentbased search activities should be tightly coupled. Subjects clearly expected their search results to appear on the map after executing their search. The fact that they did not caused confusion. Next, interaction should honor the context created by the map. Interfaces that contain a map, especially a highly interactive one such as that provided by the Google Maps API, need to honor the context created by it. Applications might do this in several ways. First, applications can perform all operations in the context of the map. Second, applications might offer a choice of contexts. Applications could honor the map context by searching, resolving addresses, or browsing all within the context of the current map viewport. For example, if the user centers the map on the Los Angeles metro area and enters the address “1234 Hollywood Blvd”, the user expects the application to find this address because, in his or her mind, the interface contains all of the proper contextual information. In addition, the map could be used in a variety of ways to rank or bound search results. When searching for a term, results might be ordered in terms of their distance from the center of the map. Alternately, the interface might interpret the current viewport position as a boundary for the search, limiting the returned results to those that fit within the current boundaries set by the user. Of course, many users might find this application behavior frustrating. There might be times when you want to quickly reset to a global context for searching or browsing. Therefore, making the context explicit to the user and/or selectable by the user seems to be an ideal approach. Many other applications employ this approach. For example, when searching the ACM Digital Library the user is offered a choice of the scope or context of their search. In the context

of Sharescape searching or browsing, this might mean offering the user a choice of a global action or one bounded by the current map viewport. When entering an address, the application could present the user with the current assumed city and state. In addition to honoring the context, the interface should be explicit about the current map contents. Most subjects, when asked to search for a particular place, first attempted to recognize it in the map or the place list. This ultimately proved frustrating. However, had the interface made it clear to the user up front that the place was not in the list, the user would be motivated sooner to find the search functionality.

5.2

User-Contributed Content

All of the subjects expressed a preference for communitymaintained information over information gathered by crawling the web. Nearly all of them suggested a central advantage: the timeliness of information. Many times, paper or even online phone books as well as popular Internet search engines contain out of date information. The subjects who identified this scenario each felt that a communitymaintained site might improve the accuracy of information as it changes over time. For example, the Wikipedia entry for Senator Craig Thomas of Wyoming was updated several hundred times during the few hours following his death. Information in phone books or even local search engines might be incorrect for months or even years. Of course, community-maintained information suffers from imperfections as well. For example, one subject mentioned she would like to somehow assess the “consistency of experience” among the contributors to the site. She said that one thing she often finds with typical sites that offer information about places in the community (restaurant reviews, etc.) is that contributions are dominated by people who went to the place a small number of times and had a bad experience. Instead, she would like to lend more weight to those who visit a place consistently over a period of time. In addition, vandalism is a serious issue for most community-maintained sites. Many of them implement a number of measures to counteract its effects, such as the ability to “lock” particularly hot or controversial topics. Discussion. Given the perceived advantage of communitymaintained geographic content, it is important to bring community-centered design principles into the realm of geographic applications. One obvious improvement would be to extend the interface to include the information management tools normally found as part of community systems, such as the edit watch lists that were intentionally omitted. However, further research might explore bringing more sophisticated community design techniques to the domain in order to increase participation in the community. Prior research [8] indicates that informing users of their uniqueness increases community contributions when dealing with ratings of and discussions about movies. One might extend this concept to the domain of community-maintained geographic systems by identifying unique places that users might have visited, based on their list of entries maintained, and ask them to contribute something about the place. Additional further research might explore applying intelligent task routing [4] to this domain, which has also been shown to increase community participation.

5.3 332

Privacy


Full Papers

We explicitly told subjects during their orientation that the application was community-based and all contributions were public. However, they seemed to forget this fact during the evaluation. For example, one of the tasks asked the subject to add a place to the database. The instructions for the task directed them to an Internet Yellow Pages site to look up the address of the (presumably public) place they wanted to add. However, despite this fact five of the six subjects entered their home address and gave it a relative name (ex. “My House”). Three of the six subjects indicated that they usually thought of mapping on the Internet as a relatively private activity. When confronted with the fact that he just plotted his home on a public map, one of the subjects responded, “I guess that was dumb!” Investigation into a couple of related web sites seems to confirm this general pattern. WikiMapia (www.wikimapia.org) allows users to enter geographic places by drawing a rectangle and entering some notes. A quick visual search of the local metropolitan area nets numerous non-descript places in residential areas bearing names such as “home” or “house”. Some of these were marginally intended for public consumption. For example, one place description reads, “X and Y spent much of their youth (1946-1958) living in the house at this address. The house is still there.” (We chose to withhold actual names) However, others seem less intended for the public with descriptions such as, “My mom’s house.” Discussion. Privacy is a design problem in many communitymaintained applications, and community-maintained geographic applications like Sharescape present an interesting design problem. Subjects indicated that they assumed mapping activities, such as finding a place or computing directions, to be relatively private. Designing a collaborative application around activities normally done by users in isolation poses a challenge. Privacy critics such as those described in [1] might provide an additional layer of protection for users who are new to the concept of primarily user-generated content. The implementation of Sharescape described in [10] employs some of these techniques. These techniques guard against the explicit revelation of something unintended that might compromise user privacy, however some privacy violations rely on more subtle means. Further research is needed to explore such “second-level” privacy concerns with this type of application. Research in information retrieval reveals interesting ways in which various contributions to communities reveal potentially private information about the contributor [5], [12]. These associations are not always obvious to the contributor or the system designer. For example, consider a conscientious user who does not add his or her workplace directly to a community map. Might other users be able to infer information about him or her, given a list of places contributed or edited by the target user?

6.

CONCLUSION

This paper highlights some of the primary design considerations for community-based geographic applications. We suggest that system designers need to be conscious of the context created by a map on an interface. There also exist benefits to community-maintained geographic information as well as privacy concerns designers need to address. These conclusions reveal a very rich application landscape that merits further exploration.

333

Acknowledgements The authors would like to thank Zach Snow for his hard work designing and implementing the Sharescape application. This research was funded by NSF grant IIS-05346932.

7.

REFERENCES

[1] M. S. Ackerman and L. Cranor. Privacy critics: Ui components to safeguard users’ privacy. In CHI ’99: CHI ’99 extended abstracts on Human factors in computing systems, pages 258–259, New York, NY, USA, 1999. ACM. [2] B. Brown and M. Perry. Of maps and guidebooks: designing geographical technologies. SIGGROUP Bull., 22(3):28–32, 2001. [3] J. Burrell and G. Gay. E-graffiti: evaluating real-world use of a context-aware system. Interacting with Computers, 14(4):301–312, 2002. [4] D. Cosley, D. Frankowski, L. Terveen, and J. Riedl. Suggestbot: using intelligent task routing to help people find work in wikipedia. In IUI ’07: Proceedings of the 12th international conference on Intelligent user interfaces, pages 32–41, New York, NY, USA, 2007. ACM. [5] D. Frankowski, D. Cosley, S. Sen, L. Terveen, and J. Riedl. You are what you say: privacy risks of public mentions. In SIGIR ’06: Proceedings of the 29th annual international ACM SIGIR conference on Research and development in information retrieval, pages 565–572, New York, NY, USA, 2006. ACM. [6] M. Himmelstein. Local search: The internet is the yellow pages. Computer, 38(2):26–34, 2005. [7] Y. Jung, P. Persson, and J. Blom. Dede: design and evaluation of a context-enhanced mobile messaging system. In CHI ’05: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 351–360, New York, NY, USA, 2005. ACM. [8] P. J. Ludford, D. Cosley, D. Frankowski, and L. Terveen. Think different: increasing online community participation using uniqueness and group dissimilarity. In CHI ’04: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 631–638, New York, NY, USA, 2004. ACM. [9] P. J. Ludford, D. Frankowski, K. Reily, K. Wilms, and L. Terveen. Because i carry my cell phone anyway: functional location-based reminder applications. In CHI ’06: Proceedings of the SIGCHI conference on Human Factors in computing systems, pages 889–898, New York, NY, USA, 2006. ACM. [10] P. J. Ludford, R. Priedhorsky, K. Reily, and L. Terveen. Capturing, sharing, and using local place information. In CHI ’07: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 1235–1244, New York, NY, USA, 2007. ACM. [11] P. Persson, F. Espinoza, and E. Cacciatore. Geonotes: social enhancement of physical space. In CHI ’01: CHI ’01 extended abstracts on Human factors in computing systems, pages 43–44, New York, NY, USA, 2001. ACM. [12] L. Sweene. k-anonymity: A model for protecting privacy. International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 10(5):557–570, 2002.