Scenario
Our scenario builds off of our persona, Aly, from GR1. Aly is an MIT sophomore who has a flight home to Florida at the end of the semester, on May 17th at 6 AM. She always buys cheap flights, which often leave in the early morning before the public transportation system operates, as is the case for this particular flight, so she wishes to take a cab to the airport. Aly uses RideShare to find people to share a cab with her for this flight. The tasks she needs to perform are:
- Search for a ride share
- Post a new RideShare listing for her desired time and destination
- Invite friends to see her RideShare post
Design
Our final design (shown above) consists of a few main parts: the header, the 'find a ride' panel, the 'post a ride' panel, and the rides listing (which can either show all rides or just the users rides). We decided on a minimalist design in which all of the site's functionality is plainly visible on the main page, including the functions of searching, posting new rides, and viewing ride posting. We did this to improve efficiency and visibility for the user. 
The user can interact with the 'Find a Ride' panel to filter rides according to three distinctions: Purpose, Date, and Time. Since we expect that the total number of rides on the site will be pretty low at any given time, we did not include a search for location. It isn't necessary and the user might feel like they have to know exactly where they're going. It is easier to have them browse ride listed for the category they are interested in.
Filters are applied right when the user adds or changes them (using ajax). We decided to do this because it gives the user immediate feedback. During paper prototyping, we considered using a standard form with a search button or having a filter button for each category, but testing made it apparent that immediate ajax response was the best option and made the most sense to most users.
When filters are applied, the user is shown a message that contains the tags they are searching for (as in the above image). The user can easily clear all search filters by using the standard 'x'.
Ride listings are laid out as shown above, with an icon to indicate category, a bolded origin and destination, and color-coded date and time information. Rides are laid out to convey the information as clearly as possible, using different visual variables to distinguish between fields. Using the different colored icons helps users locate rides of different categories more easily. The most important information, origin and destination, is the largest and darkest text so that the user will see that first. These decisions were made after we created out first computer prototype and received feedback on it; the ride listings didn't use the available space well and it was difficult to find the information needed. This version is a big improvement in both design and visibility.
Note that, if a ride belongs to a user, an 'X' is added in the top right corner so that the post can be removed (all of a user's rides can be found by clicking the 'your rides' tab).
Each ride also has a 'share via email' and 'join ride' (if the ride belongs to someone else) link. When clicked, the above dialog pops up so that the user can contact the poster or share the ride with friends.
To add a new ride to the listing, a user can fill out the 'post a ride' form, shown above.
Implementation
Our interface front end was implemented using a combination of JavaScript, JQuery, HTML, and CSS. We decided to use a separate CSS stylesheet and incorporated aspects of the JQuery-UI module, such as for out-of-the-box widgets like the date picker, time slider, and autocomplete. We tried to make our website have a Web 2.0 look-n-feel; we utilized rounded corners for all boxes, and made every search field use AJAX to filter the matching rides in real time. We also decided to include a throbber to signal to the user that a request was being processed. Additionally, we decided to implement login as a necessary component to access the website, which meant that we could use MIT certificates to facilitate login and not require a user to enter information or click a login box to enter the website's functionality.
We used PHP to communicate with the persistent storage. Some issues we encountered with using PHP from scripts.mit.edu were that various configuration settings needed to be set in the php.ini file for certain PHP functions to work. PHP as far as logic layers go was a bit clunky and perhaps We tested the website on three MIT undergraduates who entered Baker House on May 8, 2011, which are representatives of our target user population. The scenario tasks we gave them were taken from GR3 and GR4:
h5. Scenario Task #1
- Find all rides to the airport.
- Search for a ride to Logan Airport from MIT on May 17th at 6AM.
Scenario Task #2
- There are no matches; post a new ride listing advertising a taxi ride to the airport on May 17th at 6AM.
Scenario Task #3
- Invite some friends to share the ride with you.
We briefed them with a short oral description of the purpose of the website. We didn't give a demo before testing because the functionality of the website should be immediately learnable to new users.
USER #1
Observations |
Notes |
|---|---|
The user tried to find a ride by filling in the "Post a Ride" form. He realized that he had made a mistake after he pressed the "Post Ride" button and saw the result of the action. |
This may be prevented by making the "Find a Ride" and "Post a Ride" labels more prominent (using more noticeable colors, etc). |
The user manipulated the "Find a Ride" form. He couldn't find the ride he wanted because it didn't exist, but he kept narrowing the filter a few more times before realizing that the ride really didn't exist. |
A label specifying the number of rides matching the filter (e.g. "_One _ride found on May 17, 2011") may have prevented this. |
When the user posted a new ride, he didn't use the autocomplete feature when he filled in the "From" field, but he did when he filled in the "To" field. |
The autocomplete feature is learnable. |
|
|
|
|
|
|
using another framework like Ruby on Rails or Python/Django might have yielded cleaner, less repetitive code.
The back end was a MySQL database hosted by scripts.mit.edu. Since there were two major entities that we needed to model and store persistently, our database had a user information table as well as a ride information table. We did not need any relation tables since every ride was associated with exactly one user who posted the ride.