Schedule Wiz
Computer assisted class search and scheduling –
Version II
D. Abe Mirrashidi
D. Paul Mais
D. Kirk Wylie
Rona Yang
Proposed tasks for usability test
Easy as Pie:
You are a wondering undergraduate and wish to take easy courses
while being an active protestor for NAIVE (Nice And Interesting
Vegetarians Everywhere). You hear that database is an easy course
and that art teachers always give A's.
Generate a schedule with the following classes:
CS 286
Art 8
Economics 100A
Moderation:
You are a cognitive science major interested in human computer
interactions.
Generate a schedule with the following criteria:
CS 169
Any course taught by Professor James Landay
An arbitrary upper division art course
Most Amazingly Difficult:
You are double majoring in theoretical chemistry and EECS option A.
Because you need to stay up late taking many courses, you try not
to have early morning discussions.
Try to create a schedule with the following courses and adjust
accordingly. Change sections to accommodate your sleeping and
eating habits.
Chem 3A
Chem 130A
Physics 7C
CS 260
CS 152
Overview of UI design changes
The major design changes of our prototype include an additional feature of showing course descriptions during search, checking lecture conflicts before a schedule is generated, and modifying the existing schedule via click and click where conflicts are displayed and removed on-the-fly.
When there are lecture conflicts among the classes to be scheduled, we display a dialog window (see Figure2) where we list the list of classes whose lectures are in conflict and the user is suppose to select one of the list items that they want to keep among all and click OK to continue scheduling. Conflicts between different lectures of classes are dealt with separately, i.e. we display one conflict at a time until there is no more lecture conflict among the classes remained to be scheduled.
After a conflict-free schedule is generated, we allow the user to modify the existing schedule via click and click. Specifically, the user can click on a discussion section to view all its alternative sections, which are displayed in frames of a different color for distinction(see Figure3.) If the user decides to pick one of the alternative sections other than the existing one, they can do so by clicking on that section, which automatically hides the display of all other alternative sections. (see Figure 4)
Major usability problems addressed
NOTE: All Violations are referred to by the number they were presented in the HE Violations report
The following violations were not severe enough in their own right, but we fixed them because they were easy to fix and/or improved usability
1) Added a label
2) The Course level reverts to "Any course" when the Department is changed
4) Alignment of "Selected Classes" label was fixed
6) The program will not add a duplicate class to the selected classes list
13) The handicapped icon has been replaced. In addition, many of the buttons have been rephrased, or undergone a graphical facelift.
14) The "Start Over" button has been removed. See #20 below.
20) The button has been changed to "Modify Classes to Reschedule." When the user selects this option, the program returns to the "Search and select classes" window, with the classes in the current schedule already in the "Selected Classes" list to be modified.
These violations rated either a ‘3’ or a ‘4’. We agreed and fixed them
3) We decided we no longer needed a cancel function, so we removed the button.
8) The remove button is now greed out when the "Selected Classes" list is empty, or no class is selected.
9) All main screens now have an "Exit" button
10) The original problem was due to a Visual Basic "feature," which prevented us from always using the left button. Drag and Drop will not been implemented. Instead we use a "Click-and-Click" metaphor to allow students to change sections.
11) The checkboxes have been removed.
16) We have added a new dialog which alerts the user when they are trying to schedule two lectures that conflict. This was part of our previous design, but we couldn’t support it until a large chunk of new implementation was completed.
17) We added a help button to the Search window. Note that a help system has not been implemented (And probably never will be!)
19) This problem is addressed by our new implementation (See #10 above)
21) We fixed this by graying out the "à " button when necessary.
22) We now allow the user to remove multiple classes at a time.
These violations rated either a ‘3’ or a ‘4’. We chose not to fix them, either because we didn’t agree they posed major usability problems, or they required functionality we couldn’t implement
15) We don’t agree this is an error. The user is not supposed to switch between the two main windows at will, so we don’t provide a feature to do this.
Prototype Overview
Visual Basic was used to create the software prototype. It was chosen over
Java for a few reasons. For one, the ability to easily lay out various icons
was a plus. More importantly, the vast amounts of widgets included in
Visual Basic allowed for a lot of extra functionality with minimal
amounts of coding. Tabs, grids and tree-views (this was later removed) are
all standard components of Visual Basic that are not trivial to implement in
Java. Swing and Cafe offer some widgets but are not as stable. The group
also considered using Power Builder but chose Visual Basic instead because
of its availability. Perl was used as a supplemental tool for parsing through
the data to convert Infocal's gopher information into various data structures.
Visual Basic definitely had its limitations. The debugging tools are lame
and questionable, at best. There is no object orientation and most functions
were written as hacks due to language and familiarity problems.
Prototype screen dumps
Figure 1
Figure 2
Figure 3
Figure 4