...
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 known. 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 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 with a calendar style representation. 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.
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.
Implementation
Our system, built with a Django backend, allows users to store and save the trips that they plan as well as the personal information used to match the user to particular colleges. The system is scalable in the sense that it would be easy to add additional attributes (top majors, etc.) as new search criteria in the future, but some aspects of our implementation have led to latency issues in loading different pages.
...