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