...
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 helped to solve that problem.
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.
Sample Error Class with Tooltip:
-insert error course with tooltip-
Another issue we observed while running usability tests, was that even with significant prompting, users had trouble editing course data. They did not realize the panel to the left of the grid held controls for modifying currently selected courses. As a result, when they were asked to modify a selected course, they spent a significant chunk of time clicking around the course tile and in some cases tried deleting and re-adding the course. An adaptation we added to our design was to change the color of the course information panel whenever a course was selected. Whereas different course types are assigned different colors, we set the color of the course pane to match the color of the currently selected class. This helps to both notifying the user of a change in mode, as well as to draw their focus away from the grid and over to the course modification panel.
Course Panel Color Change:
-insert picture-
Finishing the project, we realized that the concept of direct manipulation was still not as implicit as we had hoped. Even with all our added visibility features, many users faced a difficult learning curve of what to do with our interface. Once they were aware of the features they could manipulate, the tasks became incredibly simple, but it was this initial awareness we needed to account for. As a result, our application provides an information screen to all first time users. This screen lists several of the key features of the application, which are not immediately apparent. With the aid of this screen (for those users who actually took the time to read it), the initial learning curve was greatly reduced.
-insert info screen pic-Information Screen Displayed at Start-Up: 
Overall, the greatest design challenges we faced were to improve the intereface visibility. This was to be expected, because we elected to take a direct manipulation approach, which gains its power from good visibility. We had to tie all of the components of our UI together to ensure that the user manipulation provided adequate feedback.
...