You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

1 Design

The most important design principles that guided TravelTech's final design are: user control/freedom, consistency, learnability, and feedback.

1.1 Design Decisions

Paper Prototyping

During paper prototyping, several important design decisions were made.

  1. Discard TravelGroups
  2. Include two calendars
  3. Develop the new map / data representation interface
  4. Place the calendars and map on the same page
TravelGroups

TravelGroups, lists of people going to the same area as the user, were cut from the final design because we realized that users' travel plans were dynamic and frequently subject to change. Instead of TravelGroups, we focused on saving trips and providing easy means for the user to change details about their trips. We also decided to generate a list of emails for users to contact rather than relying on TravelGroups.

Two Calendars

Many users were confused about selecting a start date and an end date on the same calendar. To adapt to user demand, we decided to use two calendars, one labeled "start date" and one labeled "end date" in order to reduce user confusion. The calendar also grays out dates before the start date in the "end date" calendar after a start date is selected. This prevents errors and gives the user basic feedback.

Figure 1. Two calendars are used to represent a start date and an end date to reduce user confusion that arose when using only one calendar.

New Map and Data Representation Interface

Initially during paper prototyping, we had a sequence of three pages: an initial map page to enter a destination, a calendar page to select a date range, and a data/summary page to display other people traveling to a close destination within a similar time range. Originally, we represented our data in the form of Figure 2.1. Several users had trouble deciphering this graph. In order to make our design more simplistic and consistent with the real world, we decided to change the data representation page to a map, seen in Figure 2.2. Finally we combined this map page with the first map page where users enter their destination information. This made the design more simplistic and reconciled inconsistency issues with the first and second map pages. The summary page's map was slightly different from the map on the first page because it had adjustable bars to change the date range and change the radius. For many users, they were confused by the two really similar but slightly different maps. They also could not see direct feedback as they were setting their traveling dates and destinations. Moreover, we decided to discard the adjustable bar for dates and instead allow users to adjust their date range directly on the calendar. The radius adjuster was kept.

Figure 2.1. Users found this interface because people are not typically represented as line graphs in the real world.

Figure 2.2. The new interface allowed users to adjust the radius from their destination as well as the date range.

Figure 2.3. The final map interface combined the initial map page where users entered their destinations with the map page that displayed data about other people in the area. This was more consistent with the real world and across the TRavelTech site.

Calendars and Map on the Same Page

We also decided to place the calendar and map on the same page for the sake of simplicity and consistency. The user was also able to have more direct feedback; as he adjusted the dates on the calendar, he would see people pop up or disappear on the map if they fell in or out of his selected date range. This decision gives the user maximum control and information scent.

Figure 3. The calendars and map placed on the same page to reduce complications, give users direct feedback, and increase consistency.

Heuristic Evaluation

Feedback from heuristic evaluations and TA meetings made us realize that we should give the user even more feedback and information scent. In response, we did the following:

  1. More interactive feedback on the map in response to changes on the calendars
  2. A chart to tell the user how many people are near him on each of the days he is traveling, as well as several days before and after his range.
More Map Feedback

After heuristic evaluations and feedback from our TA, we linked selection events on the calendar to more direct feedback on the map. After entering a location selecting a start and end date, the map immediately centered and zoomed-in on the user's destination. Then, people within a user-settable radius of the destination and within the user's given date range are displayed as clickable blue markers. Clicking on the blue markers displays a pop-up containing the name, email, and travel information of the person at that location. See Figure 4.1.

Chart to Display Other People During Similar Time Range

What if people have adjustable start and end dates to their trips? They might extend their trip by one day if they know that a certain friend is also traveling on that day. We decided to include a histogram of the number of people traveling for each day within the users's date range, as well as five day before the start date and five days after the end date. The chart is redrawn each time the user changes his date range. By mousing over the bars in the histogram, the user can see how many people are traveling on a certain date, as well as how many more/fewer people will be traveling on the extra five days at either end of his range. In the future, we want to make the bars clickable: a pop-up will display a list of people and their emails if the user clicks on a bar.

Figure 4.1. Selection of a destination, start date, and end date gives the user immediate feedback in both the map and the chart. The chart displays to the user the number of other people who will be traveling to his destination during his date range. The chart also shows the user the number of other people who will be traveling 5 days before his start date and after his end date, giving the user feedback about how many more people he could be traveling with if he were to extend his stay by a few days.

Figure 4.2. This is a date range with people who are near your destination. The people are clickable.

User Testing

Because user testing occurred after our final implementation, we could not incorporate their changes. Below are some proposed changes and solutions:

Other Design Decisions

Other design decisions include:

  1. Autocomplete on destination textbox
  2. Navigation bar on top
  3. Reset button
Autocomplete

Autocomplete was included for the destination textbox to make the user's experience simple.

Figure 5. Autocomplete box for better user experience.

Navigation Bar

We included a navigation bar on the top for the user to easily navigate between the map page and the trips page.

Figure 6. Navigation bar for easily flipping between pages.

Reset Button

We included a reset button (which can be seen in Figure 5) in case the user messes up his trip planning and wants an immediate reset.

1.2 Alternatives

2 Implementation

2.1 High Level Discussion

2.2 Potential Problems

3 Evaluation

3.1 User Test Setup (Demo?)

3.2 User Backgrounds

3.3 User Briefing and Tasks

3.4 Usability Problems and Proposed Solutions

4 Reflection

4.1 Lessons Learned

4.2 What Would We Do Differently? (Meta-Level)

  • No labels