Project Goals

Our project involves presentation of several kinds of data: apartment listings, geographic points of interest that users input and neighborhood information such as shops, stores, Bart stations etc. In addition, we have prototyped a visualization of a suggested area or blob that the user should look for apartments in, based on their requirements.

The interface for our project is aimed at the following tasks:

• Visualization of a target or suggested area that is roughly central to all the points of interest given by the user: We also wanted to display the locations of all of the available apartments in that area.We wanted to suggest a geographic area overlaying, but not obscuring, the points represented.


• Visualization of quality of life data: When looking for a location, the address itself tells the user very little about things such as proximity to transit stops, local stores, and entertainment venues. Our visualization displays all of these things (which again are geographic points) and leaves the controls for when to display it up to the user.


• We wanted the user to be in control of what gets displayed and when: Since the interface visualizes information not just about the apartment (number of bedrooms, baths etc) but the surrounding area as well, there is a lot of information to be represented. We aimed to solve this problem by having the user decide how much or how little information to see at one time by providing check-box filters atop the mapped locations.


• Interaction between the visualized area and user: In addition, we wanted to allow the user to manipulate the targeted area themselves instead of just having the computer suggest it each time.


• Intuitive interface: Our project involves representing different kinds of data:
  • Geographic points: apartments, users specific points of interest, shops, bus stops etc.
  • Textual information: details of apartment locations search results.

  Given the amount and variety of information we want to represent in our interface, we wanted to make the interface self-explanatory and intuitive without giving a list of instructions.

Back to top

Related Work

craigslist.org

The craigslist website offers a very simple, text-based way to search and browse through apartment listings. To search through the apartment listings, an apartment searcher would first select an area to live in, such as the entire North bay, the East bay, etc, unless the searcher is interested in the entire S.F. Bay area, the default search region. These serve as nominal categories organized by geographical constraints that help focus the searcher's listings. The searcher has the option then to filter the returned listings through a simple form, specifying apartment qualities such as the number of bedrooms, the min and max price, and any other general keywords. The title of each listing is shown, organized in descending order of the date of submission. To get more details about that post, the searcher would click on the listing to retrieve the full text description of the apartment.

The craigslist interface is generally very straight-forward to use and offers a basic way to filter and browse through listings. However, what the craigslist interface lacks is giving the apartment searcher some context about the apartment location, such as the actual geographic location, how close/far the apartment is from freeways and public transit, and whether the location is considered a safe neighborhood. To find such information, an apartment searcher would typically rely on other sources, such as Yahoo Maps, 511.org, and personal references.

Housingmaps.com

Housingmaps is an early mashup of craiglist rental listings and Google Maps. Craigslist listings are parsed to extract information such as the actual street address, the number of bedrooms, and the date submitted. Apartments are then marked on a map, indicating the location of the rental property.

Apartment searchers using housingmaps would first select on the map what region of the U.S. they are interested in. At that point, the map is zoomed in and populated with red and yellow bubbles to show where apartments are located in that region. The color of the bubble encodes the nominal information of whether the craigslist listing contains pictures of the property or not, yellow indicating that it does and red indicating that it doesn't (although there is no way of knowing this unless one of the markers is clicked on). When an apartment marker is clicked on, a details on demand popup displays over the map, showing the title of the post, the address or cross street, contact information if available, and thumbnail pictures, if available.

The right panel, next to the map, shows text listings of the apartment shown on the map. Clicking on the one of the apartment markers on the map does not affect the listings or highlight the selected listing. However, there are red and yellow circles in the text listings, encoded with picture information, in the "pics" column. When these circles are clicked on, a details on demand popup appears over the selected apartment on the map. In addition, apartment listings can be sorted by clicking on the column headings, such as price or # of bedrooms. Clicking on the title of the listing opens up a new browser window with the original craigslist listing.

Finally, housingmaps.com provides form fields to filter the retrieved apartments. These filters are similar to the filters available on craigslists. However, the craigslist filters are slightly more powerful than the housingmaps filters when trying to specify price ranges. Where craigslist allows the apartment search to specify both a min and a max price, housingmaps only allows you to selected predefined ranges, via a dropdown menu.

In general, housingsmaps is a great improvement over the craigslist search interface for people who want to be able to see the actual location of the apartment on a map. In addition, parsing out details such as price and number of bedrooms and displaying and sorting major information in a table like format makes it easier to compare apartment listings. However, one of the big problems with housingmaps is that it's very difficult to see the association between the apartment markers and the entry in the side listings. Although there is an attempt to map from the listing to the apartment marker, using the "pics" icon to do so is quite unintuitive. Also, currently, the search filters only performs a search on the title of the listing, not the full text of the apartment listing. Finally, it is questionable if the pics/no pics in a listing is so important that it should be encoded in so many ways (the color of the markers, icons next to the listings, pictures shown in details on demand). More user testing would be necessary to determine whether people care more about encoding that information versus information such as pricing.

Ontario Student Housing

http://terrill.ca/maps/

This student housing website is similar to housingmaps.com, using university student housing listings as its data source. One of the major differences between the Ontario listing and housingmaps is that the Ontario listing organizes the lists by meaningful categories. The first set of categories consists of the listing of the supported universities in the Ontario area. Once a university is selected, the listings are categorized by price ranges. Once a university and a price range are selected, the map populates with apartments. One nice feature about the price range category selection is that multiple price ranges can be selected at the same time. In addition, each apartment is color coded by the price range it falls in, dark red being the most expensive price range, yellow being the least expensive. This use of color coding seems to support the apartment search task better than housingmaps use of color coding, since, according to our survey, price and location are the two most important features of apartments.

When a particular listing is selected, the listing is highlighted and a details on demand popup appears on the map corresponding the apartment marker. This brushing and linking works both when you click on the listing and when you click on the marker. The details on demand popup gives some additional information about the listing and provides a link to the full listing on the appropriate university housing website (opened in the same window, not a new window).

The Ontario housing site also allows you to add transit routes and potentially other types of overlays in the "Map Options" tab, which sits next to the "Rental Listings" tab on the left panel. Once in this tab, you can select what type of additional map information you would like to display. Although it's a great idea to allow the apartment hunter to select additional overlays, it doesn't seem to make much sense to have these options as a tab on the left panel next the "Rental Listings" tab. I would expect these custom overlays to be checkbox options exposed and placed near the map.

Another UI problem with this housing listing is that the default viewpoint of the map is far too zoomed in, effectively not giving an "overview" look at the apartment listings. This is frustrating because several of the apartments listed on the side panel might not be shown on the map. Once that hidden listing is selected, the map scrolls to that location, now hiding other previously visible apartment listings. If the site at least offered a focus + context view, it would be much more usable.

Dynamic HomeFinder

Christopher Williamson, Ben Shneiderman (1992)

The Dynamic HomeFinder is an application that visualized real-estate listings on a map and implemented dynamic, visual queries to filter those results. Yellow markers were placed on a map to indicate the geographic location of real-estate property. To find details about each property, the home searcher would select the yellow marker on the map (although it's not clear from the paper where or how this information would be displayed). In order to filter these properties, there are sliders and buttons on the left panel to query within these results. For example, in order to query by price, instead of using formed based text boxes or dropdown menus to select ranges, a range slider is used to dynamically query the results. If the home buyer is looking only for condos, the buyer would select the "Cnd" button in the "Look at" section. Similarly, if the buyer needs a condo with a garage, he would select the "Grg" button in the "Features" section. Both the "Look at" and "Features" sections would probably be more intuitive if checkboxes were used, instead of buttons.

The most novel idea presented in this design is being able to place markers on the map to represent your office, school, or any other point of interest. The application lets you place two markers, A and B, on the map. At that point, you can adjust the "Dist to A" and "Dist to B" to help the home buyer filter the real-estate listings according to proximity to those locations. This functionality helps support new scenarios not supported in other housing/apartment search listings, such as finding a home within walking distance to school but driving distance to work, etc.

The use of sliders and buttons to create dynamic queries is a great improvement over boolean queries required to search for real-estate in systems existing at that time. Dynamic queries would be valuable for apartment search as well, because it allows the apartment searcher to quickly and directly see how the queries are filtering their results. This makes it easier to compare the results of different queries, versus sending a query back to a server and retrieving a new set of results in an asynchronous fashion. In addition, the use of points of interest markers supports new search scenarios that can be very relevant for apartment searchers living with one or more roommates.

Back to top

Visualization

We based the layout of our visualization on the layout of the new Beta version of Yahoo! Maps. We feel that this choice will provide a familiar grounding for most users. We also felt that the layout corresponded well with our needs.

Yahoo! Maps

HomeSkim

For our purposes we divided the screen into three sections. The section on the left is a modification of the addresses section of Yahoo! Maps. The top part of the section is used to enter the information used to determine the dimensions of the suggested area. Space to enter addresses for only two points of interest are provided by default to save space. If the users needs to enter a larger number of address, they can click on add another address below the lowest Point of Interest field. We have also provided a list of general points of interest that users can select as part of their specification. Multiple selection is allowed.

The lower part of the panel is used to enter search criteria for the apartments. Based on this information, appropriate apartments are selected and displayed within the suggested area.

Once the user fills in the necessary information and presses Go, the suggested area is calculated and displayed on the map as a colored transparent shape. Relevant apartments are visualized as markers within the suggested area. Points of interest are also displayed on the map via markers that correspond to the type of the point of interest they represent.

At this point, color and text are used to differentiate the different types of markers. More research and user testing is needed to determine if there are specific colors that users associate with specific points of interest. We chose color as opposed to shape because it is much easier for the human eye to differentiate color than shape when objects are presented in close proximity to each other. As the number of categories grows, however, this solution might become problematic, since it becomes difficult to keep track of the meaning of each color after the threshold of 7-9 is crossed. This is why text is used to give an additional clue.

As new points of interest are added, the suggested area is recalculated and the apartment list is adjusted accordingly.

The apartment listings that correspond to the markers on the map are displayed in the right-side panel. For each listing, price, location, number of bedrooms and posting date are displayed to give users an overview of the post. Below the basic information, a short description of the apartment that also serves as a link to the original posting is provided.

We used brushing and linking to connect the listings on the right to the markers on the map. When a user selects a listing, the marker for that apartment expands into a balloon which gives the users a more detailed description of the apartment together with pictures if available. Conversely, if users click on a marker, they not only expand the marker but shift the listings on the right to bring the listing that corresponds to the selected marker into focus.

In order to make the interfaces functionality more flexible, we wanted to provide users with a way to see points of interest without having to recalculate the suggested area. To accomplish this, above the map, we provided a toolbar with a list of points of interest and a checkbox next to each of them. When users select a checkbox, markers for the corresponding point of interest category appear on the map. Currently only three point of interest categories are shown but we hope to add more in the final implementation of the interface.

In designing the visualization, we also had to account for the possibility that users might want tighter control over the shape and size of the suggested area. We came up with several schemas on how to accomplish this task and farther user testing is need to determine which scheme or a combination of schemes holds the most merit.

The first idea we came up with was to give control over the suggested area to the user by providing him/her with a means to reshape it by clicking on an area of the map and having the suggested area contract or expand to fit the edge of the area to the selected point on the map. We realize that a better approach would be to allow users to either click and drag or even draw their own outline. Unfortunately these options might be too complex for us to implement in practice.

Because clicking and dragging is already used by all map interfaces for positioning the map, we decided to implement two modes of operation. The Navigate It mode is the default mode and clicking and dragging in that mode serve the traditional function of positioning the map. The Map It mode changes the cursor from a hand to a pencil (to provide a clue to users) and allows users to modify the suggested area.

To allow switching between the two modes, we placed two toggle buttons labeled Map It and Navigate It above the map area of the interface. The button for the active mode remains pressed until the user switches the mode. This provides an additional clue for the user as to what mode he/she is currently in. We considered having one button instead of to that changes based on the current mode. So, if the user is currently in the Map It mode the button would show as Navigate It to alert the user to the mode he/she can switch to. We felt that this approach was problematic because it hid the current mode from the user, making it easier to make mistakes. This is especially undesirable in the Map it mode, when users can by accident change the suggested area when they are simply trying to reposition the map.

One problem we see with this approach is that even with the cues that we have provided, the functionality might be difficult to discover. Another concern is that using it requires a considerable number of steps and a substantial involvement from the user. Testing needs to be done in order to figure out if users will think that the benefits of the effort outweigh its costs.

Our second approach to user-driven control of suggested area was providing a slider for each of the points of interest. Moving the slider to the left would shift the suggested area closer to the point of inters, and moving it to the right would shift the slider away from it. Each side of the slider is labeled as either closer or farther to provide context to the user. Each slider is also labeled with the corresponding marker symbol.

This approach might only be appropriate for single points of interest such as specific addresses. It might be less useful for point of interest categories such as public transportation because these categories represent more than one point on the map. If we were to provide a slider for each of these points, the list would become unmanageably long. However, providing a single slider for the entire category is also not useful because that makes the manipulation too rigid. Users might be interested in some public transportation stops more than in others.

We also wanted to enable the users to be able to visualize the route from a selected apartment to the points of interest. When a user hovers over an apartment marker, the other markers fade into the background and route to the points of interest are displayed on the map. Route distances are also shown to allow a more quantitative comparison.

This approach also has the downside that showing more than a few routes at a time becomes unmanageable. For now, we are only planning to display routes to the points of interest specified by a given address in order to avoid clattering the map beyond the point of usefulness.

Another idea we are considering is making the relationship of apartment listings to points of interest more explicit in the right panel textual display by subdividing listings into categories. The categories would group together apartments based on their proximity to the points of interest. Because equidistance to all points might be an important criterion, we separated it into a category of its own. We realize that virtually no apartment would be perfectly equidistant, but we might be able to determine a distance range that most users would consider to fit the category. More testing is required to determine this.

We also considered removing the outlines of the suggested area in this version since this information is already conveyed by the category. That danger in that is that the users might be confused by the fact there are no apparent boundaries to the search area. This version also does not allow for any direct manipulation of the suggested area by the user.

Another problem that is readily apparent is that as the number of points of interest grows, the number of categories will become too large to become useful. The list of apartments might also become so fragmented that there is a danger of ending up with too many one member categories.

Even with the challenges outlined above, we believe that enabling users to visualize apartments based on points of interest will satisfy a real need that has been ignored by other applications.

Back to top

Usability Study

Number of participants: 5

How they were recruited:
Participants were recruited from among SIMS Masters students as well as outside acquaintances that best matched the target demographic for our application. The target user is between 20-40 years of age, either student or working professional with at least a basic level of computer proficiency.

Basic demographics:
Participant 1:

• Undergraduate degree in Computer Science
• 29 years old, male, single
• occupation: software engineer
• highly proficient in computers

Participant 2:

• Undergrad degree in Microbiology
• occupation: financial consultant
• highly proficient in computers
• 28 yr old female, single

Participant 3:

• Undergrad degree in Business
• 29 yr old male, single
• occupation: marketing consultant
• highly proficient in computers.

Participant 4:

• Undergraduate degree in Computer Science and Engineering
• Occupation: Advanced degree student
• Computer Proficient
• 25 years old, male

Participant 5:

• Undergraduate degree in Psychology
• Occupation: Sales representative
• Computer proficient
• 23 years old, male

Description of the tasks given to users:
We had a high fidelity, non interactive prototype. We created the following general task list for the participants. Because the tests were purely qualitative in nature, we used the questions as guidelines but allowed the participants to ask questions and do as much exploration as the prototype would allow. We also took particular care to distance ourselves from the interface as much as possible in the eyes of the participant and to encourage them to speak their mind.

Interface 1
Enter specifications left had panel,
Enter points of interest.
What does the blob convey to you?
You do not have a car so how might you want to modify the results you got to accommodate that?
How will you find the grocery stores without modifying the suggested area?
Modify your search area to be closer to the malls/shops (already highlighted on map) but you dont want the computer to do it for you so how would you do it manually?
Did you find this task easy/moderate/hard?

Interface2:
The interface was presented with the search results displayed on the right hand side. What do think the sliders are for?
You want to move your search area to point-of-interest A, how would you do that.
Did you find this task easy/moderate/hard

Interface3:
Do you find the categories helpful?
What do you like about them/ dislike about them.
Did you find this task easy/moderate/hard

General/Overall
Suggestions?
What did you like the most?
Dislike the most?

Responses of participants to the interface:

This section contains a general summery and analysis of participant responses. For detailed notes on each participants session refer to the Appendix section of this documents.

After analyzing the responses of 5 participants we were able to discern some general trends. However, their reactions to some parts of the interface were very diverse and even contradictory with each other. We plan to conduct more tests in the future to try to see if we can get a clearer picture of user preferences for these parts.

Interface 1:
It is important to note that because Interface 1 was the first one participants saw, general problems that exist in all three interfaces were encountered here first. Because the other 2 interfaces are variations of the same basic layout, difficulties with common features such as the left side panel, the checkboxes at the top of the map, as well as brushing and linking and details on demand are described here but can be assumed to be applicable to all versions of the interface.

4 out of 5 participants found Interface 1 moderately difficult to use. 1 participant found it to be difficult.

All of the participants were confused about the difference between the list of points of interest in the left panel and the checkboxes at the top of the map. 2 participants also noted that the public transportation category is too general. It is not clear what types of transportation are covered.

2 participants noted that the brushing and linking we used to connect apartment markers on the map to apartment listings in the right panel needs to be reinforced by numbering the listings on the right and having the numbers displayed on the markers.

All participants initially struggled with the suggested area idea. 2 participants believed that it represented city boundaries. However, as the tests progressed, all said that they see it as potentially useful. Participants 4 and 5 noted that the confusion might be due in part to the non-interactive nature of the prototype. Participant 1 mentioned that even with its shortcomings, having the suggested area would be an improvement over current alternatives.

All five participants felt that the Map It/Navigate It labels did not convey useful information and gave no clue about the functionality they represented. Participant 5 said that they left him in complete confusion. All participants were lukewarm at best at the idea of being able to click and drag the suggested area.

Interface 2

4 out of 5 participants found the slider interface easy to use. 1 participant judged it to be moderate because he felt better labels were needed to designate it as easy.

2 participants were not sure if the sliders were independent of each other. Both believed that they should be.

All participants like the routing functionality. However, 2 participants mentioned that they would not have known to hover over a market to bring up the routes because the interface provides no clue to the availability of the option. Participant 5 pointed out that representing different routes with one color is confusing and suggested that different colors are used for routes to different points of interest. All participants liked the numerical distance values.

Interface 3

Interface 3 proved to be the most controversial of the three. While all 5 participants found it easy to understand, 2 of the participants found the categories extremely useful, 3 others found it completely useless. There was absolutely no middle ground.

Those that found the categories view useful thought it conveyed more information than suggested area and was easier to understand.

Those that found the view useless felt it provided no information that wasnt already conveyed by the suggested area view and unlike the suggested area view provided no context for where the boundary for the listings was on the map. Participant 4 also pointed out that the term Closer is too subjective to be used for categorizing listings.

General observations, comments and suggestions:

Participants 2 and 3 suggested adding the ability to sort listings by price, number of bedrooms, etc.

Participant 5 suggested that it might be useful to be able to see one route at a time as opposed to all routes being displayed together.

Participant 1 suggested that it would be helpful to be able to click on the name of a city on the map and have that city included in the suggested area

Participant 5 thought that apartments at a preset distance outside the suggested area should also be displayed. The same participant commented that he really liked the layout of the interface. He felt that barring the lack of adequate labeling, it was very clean and had the right things in the right places. However, he voiced concern that there might be no room to add any other features should we decide to do so.

On the other hand, Participant 3 pointed out that the right side area of most websites has been surrendered to advertisements, and so he has conditioned himself not to pay attention to that area of the screen. This made it difficult for him to even notice the apartment listings. He suggests placing the listings along the bottom of the interface, under the map.

Back to top

Results

Plans for Second Prototype

Based on the results of our usability test, we feel that we need to conduct further tests in order to determine which design we would like to implement for our master's project. However, there are a few changes we would need to make in our prototype before conducting our second round of usability tests.

First, the idea of modes for navigation and suggested area manipulation was very confusing for all participants. Although we could attempt to make mode selection clearer, perhaps by using radio buttons instead of toggle buttons or by using descriptive icons, it might be better to do away with modes altogether. Without modes, user can still pan and zoom through the map, using the Yahoo Map API's zooming widget.

Majority of participants found the design with sliders, design 2, much easier to use than the design with direct manipulation of the suggested area, design 1. It is difficult to determine whether this is a result of the low interactivity of our prototype. To better test the first design, we need to add more visual cues to indicate interactivity. First, we could get rid of the "Map It" mode and allow the users to alter the suggested area whenever they hover over a non-apartment zone in the "blob." We would show visually that something could be manipulated first by changing the appearance of the blob. In the image below, the blob has been outlined and given a shadow. In addition, the mouse pointer changed from an arrow to a hand, indicating that something could be dragged or moved. This would help the users understand that the blob is interactive.

In addition, several participants mentioned that it was difficult to see the relationship between the apartment markers on the map and the listings on the side panel. Currently, when a marker is clicked on, the listing would be highlighted. However, instead, we could have this highlighting appear when the mouse hovers over the apartment marker.

Finally, we need to more carefully choose our markers so that users can quickly and easily recognize what type of point of interests is being shown. In particular, public transit points for BART and the bus should be differentiated.

Additional user interface design changes are discussed in our writeup for IS290-2 Search Engines.

Limitations

Things we did not include but would have liked to:

1. Wider application:

We would have liked to visualize a wider application, not just apartments: The problem space with respect to finding location is very vast. As such we think this idea as wide applicability. There are several use cases we think this can be applied to, two prominent ones include:

• Geographically dispersed people in a metropolitan area, trying to find a central location to meet face to face
• Representation of locations where people looking for car-pools reside.

2. More neighborhood information:

Instead of just shops, malls and transportation we would have liked to display more information such as parks and tourist spots. However the main issue with this is the availability of this information in digital format. Even the subset of neighborhood information we plan to implement is hard to integrate, since it is very diverse in terms of formats. It is therefore harder to create one application that can translate and format this into location specific information. A possible solution we are looking at is using search results from Google to map this information on the fly, instead of storing it in a database.

3. Information Availability:

Some information as mentioned in (2) above, might not also be available for all areas. For example, not all transit authorities in different counties share bus, train or tram information digitally. In addition, locations such as bus stops and light rail/ MUNI stops are not readily available. While it is easier to gather locations of bus-stops from down town routes (since a bus stop name is almost always an intersection), it is much harder, if not impossible, to determine locations of other stops. For example "Chabot College" a popular bus stop on several AC transit routes has no street name or intersection.

Back to top

Tools

We used PaintshopPro 9.0 to create the screenshots. We created a series of them to represent different stages of the tasks and put the images in MS PowerPoint for usability testing purposes.

Back to top

Appendix

Thumbnail

Usability Test Documents

Notes from user tests
Session summaries for user tests

IS247-2 Search Engines Project Writeup

Plans for Second Prototype (excerpt from writeup)
Full Writeup (PDF)

Back to top