GR5 - User Testing
Design
Final Design
In our final design, we divided our website into three pages: Search, Results, and Friends. These pages were navigated with a tab interface. The search page allowed users to input their search criteria. It included a widget that allowed users to efficiently select times for which they were busy, as well as a drop down menu for selecting specific departments. The results page displayed the results of their search in a gigantic table which was organized by starting-time of the class. Finally, the friends page allowed a user to search for their friends and see what classes they were taking.
...
- We implemented the backend with php and a mySQL database. All of the class data is stored in the database. Using mySQL was very useful because it makes searching for different criteria very quick and efficient.
- We chose scripts.mit.edu to take advantage of features such as certificates login. The certificates allow us to save the sidebar data to a particular username, so that no login is needed to use the site.
- We also used php and mySQL to implement the persistency of classes in the right sidebar. Every time the user added or removed a class from a balloon, we would use an AJAX call to update a table in the database. This increased simplicity of the interface by removing the need for a "save" button. It also increased reliability of the website because the changes were always saved as soon as the user made them.
- Friends were also implemented with a mySQL database. The friends page is pre-populated with the names of everyone who has an entry stored for "classes I'm taking" in our database. This allows for fast,efficient searching of friends.
Wiki Markup \[jqueryui and draggable\]
Evaluation
Reflection
We've learned a lot over the course of the iterative design process. Being forced to sketch out three user interfaces that were significantly different from each other showed us that there really are multiple approaches to arrange the inputs and outputs to our software. The paper prototypes showed us serious usability problems early on in the process, before we became attached to any code that we might have written. Our first paper prototype had a lot of a problems, which were easily fixed in the second and subsequent versions.
...