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 [Image1.gif] Figure 1 [Image2.gif] Figure 2 [Image19.gif] Figure 3 [Image20.gif] Figure 4