GR5 - User Testing

Design

Implementation

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

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.

If we had the project to do over, we might explore alternatives to the organization of the post it notes and the post its themselves. We chose to organize them by time of day, which is useful, but as a result, they cannot be sorted any other way. Also, it's hard to display a lot of information about individual classes because all of the info has to fit on a tiny post it note. The small square shape makes it even more difficult to wrap text intelligently and such.

One challenging aspect was the drag and drop for the post it notes. In our paper prototype, it was easy for the user to pick up post it notes and move them around the screen...coding this was much harder, of course. But the interface of dragging and dropping was very intuitive to all of our users, so we decided it was essential for our interface.

We took some design risks in our project. For instance, we designed a calendar interface which allows users to select and deselect blocks of time for when they are busy. The interface is completely unique - I have not seen one like it. It's similar to Google Calendar, but simplified because we don't need all of the functionality that they provide. Our users loved it! Everyone found it extremely intuitive to use and was able to perform the necessary actions to complete our tasks.

Another risk that we took was a compare for the details of multiple classes. We allowed users to open multiple info boxes by clicking on the post its. Unfortunately, it wasn't possible to get the info boxes to organize themselves in a visually useful way, so after the computer prototype we disabled opening multiple info boxes, and instead added a compare feature for classes added to two of the boxes on the sidebar.

For the paper prototype, we decided to do an iterative approach for our two designs, instead of two parallel designs. This benefited us greatly, as we had drastic changes between our two paper prototypes. We changed what content went where, as well as renaming navigation tabs (because our users couldn't find what they were looking for), and the organization of the pages themselves. User feedback was key in our design decisions. We made sure to address all of the issues/features that the users complained about. The computer prototype was useful in seeing what worked and didn't when used on a computer. We got most of our website working in the computer prototype, but we were far from having a usable site at that point - we made a lot of important changes, such as making the right sidebar be offset visually and fixed position, so that when the user scrolls down on the page, the sidebar stays put.

Over the course of this term, our interface has gone through many stages of improvement. It's amazing how an interface can really affect how well users are supposed to examine data. The registrar's course listing has a bad interface for selecting hass classes - even though it has the exact same data as we do. Luckily, with I Can Has HASS, students are saved, and can now figure out what hass classes they want to take!