...
Most of the problems that the users encountered we had either noticed ourselves during development (and hadn’t had time to address) or had been anticipated based on classmate feedback. A brief list of the issues is below, separated by catagory, accompanied by comments..
Critical
- Subject don’t initially realize they must edit courses using the sidebar (Visibility and Efficiency) - We’d added the color-changing sidebar based on earlier feedback, but that didn’t seem to help enough. This ties into the fact that people REALLY want to be able to directly edit the courses on the boxes. This was a feature we’d planned to implement if there were more time.
Major
- How to edit new courses isn’t obvious (Visibility) - New courses are white, so if nothing is selected, the sidebar doesn’t change to indicate something new was selected. This would be simple to fix by choosing another color for new courses.
- Tooltips for errors are not obvious (Learnability) - Even with the info screen explaining the tooltips, subjects had a hard time figuring out how to find out what errors meant. Need a better method for explaining errors. (*see below)
- More course info should be explained on the boxes. (Visibility) Adding ‘semester offered’ is probably most critical.
Minor
- Subjects didn’t realize they could type in the autocomplete box (Visibility) Affordances could be improved, maybe by providing a blinking cursor when the box is selected.
- Initial course schedule is confusing. (Learnability) - This should probably be explained in the opening info screen as an example for their selected major. Also, when students don’t put all the classes on the schedule themselves, they aren’t aware of what already exists.
- No Undo (Error Prevention) - This only comes up occasionally, but might be useful.
- Warnings don’t occur when a course is added to the schedule twice. (Visibility) - This was a planned feature that we ran out of time to implement.
- The meaning of the AP credit column is unclear. (Learnability) - This could be explained at the start. It could also show up in an explanation of what GIRs are missing (*see below)
Cosmetic
- Entering grades is tedious (Efficiency) - We could set up a separate interface to enter all the grades for a semester at once, for instance.
*Note on explaining errors and requirements: A good suggestion we received from a user was that in order to help explain some of the errors and requirements, we could add a feature that would allow users to click on the categories which could provide a brief explanation of each along with a list of any issues (not meeting the bio requirement, for example, or how many classes were in the wrong semester) This is something we would explore if we had more time.
Reflection
First of all, we learned a great deal about properly scoping a project. We came into this project with a grandiose vision of what we wanted to accomplish. Unfortunately, many of our features did not make the final cut, simply because of time constraints. Some of these, like the constraint solver, had initially been tagged as “reach features”. We’d hoped to get that far, but recognized that this may be beyond what we could do in one semester. As we continued in the prototype, we realized other features that we hadn’t initially considered. Errors, for example, were something we never really prototyped. We had been more concerned with the behavior of our interface, so error notifications and error checking were not really present until our final implementation for GR5. If we had another round of iteration, we would work on increasing the effectiveness of our error notifications based on feedback from later user tests.
...