...
We knew that planning a college visiting trip usually revolves a lot around location. Most logistics are determined based on colleges' relative locations to each other. For this reason, we used a map to allow the user to visualize the schools that s/he searched for. We decided it was most intuitive to pick a school to visit based on its location. Our map started out at the smallest zoom level, so we can display all school results. We did this by clustering schools in certain locations together. As the user zooms in, the granularity decreases and the specific schools are made knownpins appear for each school. This page allows users to select schools that they plan to visit. They can do this in two ways: users can either select the school from the panel at left, or, they can select the pin representing the school to view a detailed pop out that will allow him/her to select the school. We decided to give the user two options because the affordance of clicking on the pin was sometimes lost on those not familiar with the Google Maps API. Since selecting schools is a very important task, we give a lot of feedback when a school is selected - we add a green border, and move the school to the top part of the panel. We also change the color of the pin.
Planning the itinerary:
This part The itinerary planning portion of the website was the part that underwent the most changes. The task of event and trip planning is a tough task, in any context. Being able to represent different types of events at different schools at different times that are or aren't selected proved to be our most challenging problem. We went through multiple iterations of lists and panels, and ultimately ended up with a calendar style representation-based interface. We decided the intuition behind a calendar was the most consistent with the user's mental model, since they are trying to schedule what events to attend. To prevent information overload, we decided to split up the events by school so the user isn't overwhelmed by the display of many multi-colored events. One aspect we toyed with was how to represent selected events of different schools. Since we decided to use tabbing to filter our events, we wanted to make sure selected events weren't lost in the mix. Our main goals were to allow the user to choose events in an order that made the most sense. This means that the user will make decisions based on school location. This is why we have access to the map pane handy, so that the user can choose an order of events that minimizes uneccessary travel, etc. Adding tabs to the interface was a risky decision because the affordance of tabs can be vague. We try to fix this by color coding the schools and changing the entire background color to the school's color, so that the feedback from changing schools is very obvious.
Based on our user testing, we also changed how users select the dates associated with their trip. Originally, users had to select the dates and then select "Refresh Events" in order for their events to appear on the calendar. Based on user feedback, we changed this so that events will automatically refresh when a user selects a new start or end date for their trip.
We also introduced safety mechanisms to ensure that when deselecting schools or changing trip dates, users are made aware of whether they would lose any selected events as a result of their changes. If the changes do not affect the selected events, the changes go through immediately; otherwise, the user must confirm that he or she wants to make those changes.
Reviewing the itinerary
When the entire process is done, we realized that the user might want to summarize their plan. While a calendar may be useful for actual event scheduling, it is usually more efficient to refer to a list as an agenda. We fix this by providing an itinerary summary, and a print feature.
...