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 decided not to include a search for location or vehicle type after receiving feedback on our initial designs. These fields aren't necessary when trying to find the ride you want and the user might feel like they have to know exactly where they're going before filling out the search. It is easier to have them browse rides listed for the category or date 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.  One design decision that we considered was making a full text search available so that if a user wanted to search by poster or by location, the user would have the control and freedom to do so. We decided against this because we didn't want the search panel to be too cluttered, though in retrospect this design feature may have added more benefit than we realized. 

When filters are applied, the user is shown a message that contains the tags they are searching for (as in the above image). This makes it clearly visible what is being shown and 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). There is not an edit function yet because there is so little information to be input to post a ride that it is almost just as easy to delete the ride and repost it if a mistake is made (although edit functionality might be something we'd want to add in the future).

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. It is auto-filled with a suggested message so that the user understands the purpose of the e-mail, but it can be changed to whatever the user would like.

One major alternative we considered to simply putting the user in contact with the ride poster in order to 'join a ride,' was to have a 'roster' of users that have joined a ride. This might have been better because it provides a clear indicator that you are part of the ride and it shows how many people are interested. However, we decided that this could also be a bit messy, because the poster probably has a limit on the number of people who can go and would still have to organize things like cost and meeting location. Would a poster be allowed to kick users out of a ride? There are many questions that we would have to ask before implementing this feature, but it might be something we'd want to consider if we continued with the project.

To add a new ride to the listing, a user can fill out the 'post a ride' form, shown above. We use the icons that are consistent with the rest of the site and try to use form elements that are as easy as possible and restrict the user to only valid inputs (like the calendar widget for date, the drop down lists for time, and the radio buttons for vehicle). The style of the form is familiar to most users and very easy to use. When a ride is posted, the user is taken to the 'all rides' tab and receives a confirmation message that the ride has been posted.

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

We felt our code files were a bit sloppier and less organized than they should have been. In future iterations, we would attempt to comment our code more, repeat block of code less often, and abstract away more parts of our website into distinct files.

We found our user interface to be rather usable and think that the implementation framework we selected allowed us to build a product with few usability bugs.

Evaluation

We tested the website on three MIT undergraduates who entered Baker House on May 8, 2011, which are representatives of our target user population. 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. The scenario tasks were taken from GR3 and GR4: 

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.

USER #1

USER #2

The user had no problem at all finding and posting a ride. Her actions exactly followed what we had intended.

USER #3

Miscellaneous Observations

• The users had no problem using the category buttons and the time slider, indicating that the features were learnable.
• All three users used the Facebook "Share" button instead of the "Share via Email" button.

Reflection

The iterative design process allowed our team to really focus on one stage of development at a time when building our interface. We appreciated that the prototypes we built increased in fidelity as time went on and allowed us to focus on achieving a usable interface as the ultimate goal of the entire project. One of the most important things we gained out of building a paper prototype was the idea to pare down our interface complexity and try to implement something simpler both to improve usability and augment ease of implementation. The computer prototype we built focused on the front end, using canned responses for server queries and trying to make the interface look good. Because our interface was so close to done after the first computer prototype, we could focus on adding the "meat" behind the server calls to populate fields with real data and only make minor adjustments to the UI's look. 

One feature that made use of the iterations was the "tag" feature: every search yielded a comment explaining what was being searched for. At first, we envisioned this as a list of tags, but when we implemented it we decided a sentence format with the parameters visible in a different color would be more visually appealing.

To minimize the risk of our most important features, we made sure to prototype them in both the paper prototype and computer prototype. Then, we implemented these features first in the final computer prototype and kept a running tab of which features were most important to the functioning of our website in order to make sure our final product met specifications.