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.

...

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

h5. 

Scenario Task #1

• Find all rides to the airport. 
• Search for a ride to Logan Airport from MIT on May 17th at 6AM.

...

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. 

...