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. 

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 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 

• MIT undergraduate who has several siblings currently looking at colleges
• Mother of three children with one child currently looking at and visiting colleges and two children who have already completed the college search process
• Mother of two children who have already completed the college search process

Tasks

Our users were given the same tasks that had been given to those testing our paper prototype. Namely:

1. Imagine you are a high school junior with a 3.6 GPA and the following SAT scores: Math: 640, Reading: 690, Writing: 710. Find schools in New England that might be a good fit.  Note: for this prototype the SAT, GPA, and ACT data for each school was randomly generated and does not reflect the actual data associated with that school.
2. Select a few schools that you would like to visit during summer vacation (June 1-8^th, 2013).
3. Plan an itinerary for visiting the schools selected in Task 2.

Users 1 and 3 were briefed on the task in person; User 2 was briefed on the task over Skype (screen-sharing was used to allow for remote observation).

Usability Problems

1. Calendar view does not default to selected trip dates - Major (Fixed)
   Both Users 2 and 3 could not find events on the calendar originally because the calendar view did not default to the selected trip dates. Therefore, users had to navigate through an unfamiliar calendar interface to the dates they desired. This issue was not fully apparent to the developers because the start date of the trip defaults to today. This issue was easily fixed by changing a setting in the calendar initialization.
2. Users must hit refresh button to apply new date range - Major (Fixed)
   After selecting the dates, Users 2 and 3 struggled to apply their changes; they expected that the new dates would take effect immediately. They did not realize they had to hit "Refresh Events" in order to apply their changes. This issue 
3. Users did not understand the map affordances - Major
   Users 2 and 3 did not select schools from the map or click on the map in their initial run through the tasks; older users may be less familiar with viewing and clicking on map clusters. User 1 discovered the affordances associated with the clusters and the map pins by accident. Help text would be a convenient way to allow users to discover these affordances.
4. Users did not immediately understand the relationship between displayed search results and map display - Minor
   The displayed search results only include those search results that are within the viewport of the map. Text which explicitly labeled the list of results could help explain this (e.g., "Results in map view") 
5. Users did not understand the ordering of the search results - Minor
   User 3 did not realize that the schools were ranked according to how well they matched the user's search criteria. Using more explicit text for the results list woud also clarify this issue; a header like "Top Results in this Area" could be an effective fix.

General Feedback

All in all, the feedback for CollegeRoute was positive. Users were generally excited about the idea and thought that the overall experience was well-designed and implemented. Very little comments were negative in such a way that required immediate and drastic change or improvement; instead, any constructive criticism seemed to point to features that could be implemented and added on top of the current design.

Users found the website to have high usability and seldom ran into dead-end situations. While some features of the current website can be tweaked to improve usability, most of the functionality has been streamlined through our iterative design process.

CollegeRoute is very simple to use and also to learn. Users were very excited to be able to save their own information by creating an account; the idea of saving itineraries, returning to the website, changing said itineraries was very appealing.

Multiple users commented on the desired functionality to be able to directly view trip logistics and book traveling tickets from CollegeRoute. While this was on the horizon for most of the semester, the ability to interface with actual transportation providing agencies is very possible and would be a welcome addition as a feature to CollegeRoute.

Reflection

Our iterative design process benefited from a solid understanding of the problem; this familiarity with the problem was developed during the need-finding stage of the project. We quickly narrowed down 

The computer prototyping and implementation would have been made much easier had we paper prototyped additional designs for the itinerary planning component of our application. Throughout the semester, we grappled with the issue of figuring out how to design the itinerary planning portion of the site such that user interactions would be intuitive, efficient, and safe. Our design evolved significantly over the course of the semester, and we ended up implementing the itinerary planning page about four times.