GR6 - User Testing
Design
Design
For the most part, our final design followed the overall proposed design, which includes a grid containing eight semesters of courses and each semester containing a button to add new classes. Next to the grid is a panel, which allows for editing selected courses. Our initial vision for the interface involved a direct manipulation of courses, making it easy to shuffle around and add prospective courses while allowing for a visible handle on the course map. The entire application prefaced by a user login screen.
Demonstration of the Direct Manipulation feature:
Login Screen:
Those three features (grid, panel, direct manipulation) were the driving motivation for other design decisions we needed to make. One of the more notable undertakings was the concept of autoscrolling. Without a very high resolution monitor, it is impossible to fit an entire course map onto the screen and maintain readability. As a result, we needed to embed our course map into a scroll viewer. Mixing a scroll viewer and direct manipulation creates a demandsfor autoscrolling when the user tries to drag a course to the left or right of the visible area. Through several iterations, we were successful in implementing effective autoscrolling.
The autoscrolling was a feature which we chose to implement in order to improve the efficiency of our application. An additional feature we implemented for efficiency the concept of autocomplete comboboxes. These comboboxes (not native in Silverlight) are capable of searching through all of their contained items, searching for items whose key contains the entered text. This is useful for students who know that they want to take a class that begins with ‘6.8’, but do not know the rest of the course number. It prevents them from needing to scroll through the entire contents of course 6. It is also handy for students who are filtering by major and know that they want a chemistry course, but do not realize chemistry is course 5.
Autocomplete Combobox:
-insert auto complete picture-
Through various iterations of user testing, there was a high demand for better visibility of the course map status, in particular which requirements are met. This concern for visibility raised several design questions. Should we show the student which requirements are met? To what detail of the requirements should we show them? Should we provide explanations of how the requirements are met (with which courses)? etc. Because one of the main objectives of our utility is its simplicity, we chose to move forward with a minimalist approach, and not overcrowd the interface with too much information. We accomplished this by adding two status bars to the utility. The first status bar occurs in the grid itself, and is responsible for keeping track of how many units are being taken each semester. As the user adds and moves courses, these unit counters are updated accordingly.
Credit Counters:
-insert counter pic-
The second status bar served three purposes. First, it kept track of how many of each requirement were being met. Second, provided visual feedback to the user if a requirement was not being satisfied or if other errors occurred somewhere in the map. Lastly, it served as a legend to make sense of the course tile coloring scheme. Many students in early iterations of the interface, were confused what the various color assignments meant on our course objects. This This helped to solve that problem.-insert status bar pic-
Requirements Status Bar: 
A feature that ties in closely with the status bars, is our handling of scheduling errors. Errors currently occur in two ways - if a class is duplicated in a semester, and iif a class is placed in a semester when it is not offered. To handle errors, we felt it isimportant to notify the user as well as provide optional information as to why the error is occurring. Originally, we sought to prevent users from making these errors. This could have included graying out a semester when they tried placing an invalid course into it. We realized, however, that there are sometime extenuating circumstances that allow classes to be taken in contradiction to our imported course data. As a result we chose to give the control to the user, instead focusing on providing adequate visibility and control. We accomplished this by changing the color of error courses to red and providing an option to ‘Ignore Error’. Additionally, for users who are unclear why an error is occurring, tooltips are activated for the error courses and hovering over an error will provide a brief explanation of its cause.
...