Final Writeup
Design
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.
Each school has attribute values associated with it for each of the different search criteria (GPA, SAT, and ACT); users who are logged in will also have attribute values for each of those criteria. The search functionality(the "Find Schools" button) runs a matching algorithm between student attribute values and college attribute values.
We combined the "Select Schools", "Plan Itinerary", and "Review Itinerary" options into one page using JQuery UI Tabs.
We used Google Maps clustering in order to
Each event is tied to a particular college and a particular timeblock. When the trip dates are changed, CollegeRoute will nbsp;
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.
...
Search Page
...
Each school has attribute values associated with it for each of the different search criteria (GPA, SAT, and ACT); users who are logged in will also have attribute values for each of those criteria. The search functionality(the "Find Schools" button) runs a matching algorithm between student attribute values and college attribute values. When the user hits the "Find Schools" button, a new Trip object is created in the database.
...
Select Schools Panel
...
We combined the "Select Schools", "Plan Itinerary", and "Review Itinerary" options into one page using JQuery UI Tabs; whenever a user searches from the Search Page or selects this tab after being on another tab. The latency associated with loading the search results and the map features in the Select Schools Panel search result page was one of the primary usability issues with our interface. Our interface gives the user some feedback about the latency associated with that page through the use of a "loading spinner" and text which indicates that our application is "Finding schools for you...". However, we do not direct the user to a cached version of the search result page if they want to revisit their school selections; the page only displays once it has been reloaded. We were concerned about potential race conditions between AJAX requests to modify the list of selected schools on the cached page and the refreshing of the page. We did not analyze the implementation bottlenecks that were causing these delays, but in future work, we would want to understand better and address the source of these delays. We would also want to implement a stronger result caching scheme, either in our data representations or in the manner in which the tabs are loaded.
Plan Itinerary Panel
Our application uses the FullCalendar to allow users to display events within a date window specified at the top of the page. When we began the design process, we expected that users woud select their trip dates before selecting the events that they wanted to attend. As we shifted to a calendar-based itinerary in the latter stages of the iterative design process, it made more sense for users to be able to update the dates of their visit on the same page as the calendar. One alternative for implementation would be to dynamically update the contents of the calendar as the view display changed. In this alternative model, there would be no concept of trip start and end dates. This design could be more efficient for the user; users would not have to enter their trip dates. However, given the logistics involved in a college visit, we would expect that most users would have start and end dates for their trip in mind. Users would still have to navigate to their desired timeframe, limiting any potential efficiency benefits. Our design also offers safety advantages; users won't accidentally select events that are outside the trip dates that they have in mind.
Review Itinerary Panel
The implementation of the review itinerary panel was fairly straightforward. Print functionality was added via standard javascript methods.
Evaluation
Users
We tested our interface on three users. Our two original user classes were students and parents who were applying to colleges and planning to visit those schools. The three users tested were broadly representative of those user classes. The users in the evaluation were personal contacts of our team members (either
...