...
- 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.
- We implemented the drag-and-drop functionality for courses using JQueryUI's Draggable and Droppable interfaces.
Evaluation
We tested our interface on four MIT students who had never seen our interface before. Three of them were asked to complete the tasks listed below, while the fourth was simply instructed to "Use this website to select your HASS classes for next semester." This allowed us to get feedback on not only the usability of all features in our interface, but also the discoverability of those features and on which features were most interesting to users.
We selected our test users from our friends and dorm-mates, trying to get a set of users that was as representative of our user population as possible. We feel that our test users were fairly representative of our target user base; they included both males and females, upperclassmen and underclassmen, students who enjoy HASS classes and students who simply want to fulfill their graduation requirements. One notable sub-group that was missing from our test users was freshmen, who are on the new HASS system. However, we felt that the difference in HASS classifications would not significantly impact usability or use patterns of our site.
We did not provide any demo as part of our user testing.
Briefing
I Can Has HASS is a schedule planning and course selection tool aimed at helping MIT students to select humanities courses each semester.
The site allows students to search for courses matching certain criteria, look at what courses their friends are taking, and keep track of courses that they are considering taking. Students can also construct a projected schedule based on their selections.
As you complete the tasks given to you, please vocalize your thought process as much as possible. This is especially important if you become confused or frustrated, because that means you have identified a problem in our design, and telling us what you are thinking will help us fix it.
Remember that you are free to quit the experiment for any reason, at any time.
Thank you for helping us to improve I Can Has HASS!
Tasks
- Search for HASS classes of the following criteria:
- All HASS categories except 4 and Elective.
- No final exam
- Don't care about CI-H
- Not interfering with your other class, which meets 1-4pm on Wednesdays
- From departments STS, 21F, and 9
- Select two classes and mark them as a classes that you are considering.
- Compare the details of these classes side-by-side
- Add Mark Zhang as a friend. Add one of his classes to classes you're taking.
- Decide you no longer want to take one of the classes you were considering.
- Decide you definitely want to take the other class you were considering.
- Remove Mark from your list of friends.
- Print the classes that you have selected.
Observations
Our interface received a lot of positive feedback in user testing. Some particularly noteworthy points were:
- users easily completed the tasks
- users instantly knew how to interact with non-traditional elements like our calendar and the draggable items -> good affordances
- when the search results page with the post-its first came up, several users exclaimed “Oooh!” or “Wow!” --> good user satisfaction and aesthetics
However, we also identified a number of points that our users struggled with:
- users didn’t know what all the department abbreviations stood for
- user tried to click on “I can has HASS” logo to return to Search page
- users did not immediately notice the legend at the top, as a result did not realize what colors meant
- users had trouble finding the “Compare” feature
- users were very confused that “print” link only appeared on results page
- some users had trouble closing the course details bubbles
- users were confused by the fact that when you add a friend’s class, the post-it disappears from the friend’s set of classes until page is reloaded. Asked, does he not have that class anymore?
- users weren’t sure whether friends’ classes were guaranteed to match their search criteria
- users expected results page to remain populated with results after they navigated away and then navigated back
- users were not sure what the difference was between putting a class in the “Trash” and dragging it out of the sidebar
Based on these observations, we have compiled the following table of usability issues that could be improved in the next iteration of design.
Issue | Severity | Possible Solution |
|---|---|---|
Department names not visible | Minor | Add tooltip text to department selection widget on Search page |
Logo is inconsistent with expectations | Minor | Make logo a link to Search page |
Legend not visible enough | Major | Move legend to a location closer to visual focus, or just print category on each class to redundantly encode this information |
"Compare" feature no visible enough | Major | Use an icon to draw visual attention and add affordances for interactability |
"Print" link not visible/accessible enough | Catastrophic | Add an icon, put "print" link on all pages (was actually supposed to be on all pages, this is more of an implementation problem than a design problem) |
Action for closing course details not easily discoverable | Minor | Make bubble close when the user clicks anywhere else, not just when they click on the post-it again |
Feedback for adding a friend's class is confusing | Minor | Keep a second copy of the post-it in the friend's box. Maybe an undraggable, faded-out image to indicate that the user has already added this class. |
Details like meeting time, category not very visible for friends' classes | Minor | Organize friends' classes spatially in a more informative way, or print more information on the classes. Also need to add a legend to the Friends page in case user doesn't remember what the colors represent. |
Results page does not behave as expected when user navigates away | Major | Results should persist on the page until a new search is initiated. |
Purpose of "Trash" component on sidebar not clear | Minor | Just get rid of this element. Users did not seem to need the functionality it provided (removing a class from ever appearing in search results again), it was just confusing, and it took up valuable space that could be used for the "considering" and "taking" buckets. |
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.
...