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