Computer Assisted Class Search and Scheduling Prototype III DePaul Mais DAbé Mirrashidi D. Kirk Wylie Rona Yang 1. Problem Students at U.C. Berkeley face several challenges in devising their academic schedules. First, the existing resources for searching for classes are rudimentary and have poorly designed interfaces. Second, the existing scheduling programs don't take into account the specific needs of academic classes, such as only being concerned with one week at a time and needing to quickly change discussion sections and other recurring "meetings" without the lengthy processes common to other scheduling programs. These differences are especially clear when considering multiple meeting times available for classes such as discussion sections. Finally, there is no way to easily integrate searching for classes with scheduling them. This means that considerable time and effort is wasted in using multiple, poorly interfaced services and integrating them. 2. Solution Overview The solution that we devised is one unified application that combines class searching and scheduling. The primary benefits of this application are assistance in searching for classes, automatically generating a schedule based on these found classes, and easing the replacement of scheduled classes with alternative ones. This solution allows for easy access to all electronically available information on a class and is intuitive enough for someone marginally familiar with scheduling programs to use. Finally, it takes into account the special circumstances surrounding scheduling classes at U.C. Berkeley to allow easy changes to schedules in an intuitive and graphical way. 3. Tasks The three tasks chosen are intended to simulate three different uses of the application, and all follow the usage of the system from initial contact through successful generation and approval of a schedule. They also are intended to show the widest variety of possible user interactions with our specific design elements. Simple Task Text Generate a schedule with the following classes: Computer Science 162, Art 8, Economics 100B. Description The first task involves generating a schedule with specific classes that the user already knows he wishes to take. This is intended to simulate a student who just wants to see what a schedule with certain classes would look like. We designed this task to insure that the users could discover how to search for specific classes and generate a schedule based on these classes. _____________________________ [Image45.gif] [Image46.gif] _______________________________________ [Image47.gif] [Image48.gif] Scenario _______________________________________ _______________________________________ Search for computer science 162. Selecting CS162 Search and select Art 8 Search and select Econ100B [Image49.gif] Generate schedule Moderate Task Text Generate a schedule with only afternoon discussion sections that includes Architecture 100B, any course taught by Professor Wang, and any lower division Electrical Engineering class. Description The second task involves generating a schedule that has certain parameters and search criteria, and then modifying that schedule slightly. It is intended to model a user who knows that he wants to take classes that fulfill certain parameters, such as a specific department or professor, but isn't sure exactly what classes satisfy those criteria. This task is designed to make sure that the users can find the search criteria they are looking for, and make sure that our interface to the search criteria is intuitive to the user. Finally, it is designed to test the usability of our discussion-section-changing functionality and design. [Image50.gif] Scenario _____________________________________________________________________ [Image51.gif] Search and select Architecture 100B Search and select CS186 that is taught by Wang ___________________________________________________________ [Image52.gif] Search and select a lower division EE class [Image53.gif] Generate a schedule [Image54.gif] Click the CS186 morning discussion, alternative sections are shown in blue [Image55.gif] Select the afternoon CS 186 discussion section, done. Difficult Task Text Generate a schedule that includes the following classes: Electrical Engineering 40, Civil Engineering 60, Anthropology 2, and Chemistry 10. If there are any lectures that conflict, remove one. Make sure you don't have any classes before 11am. Description The third task involves generating a schedule with specific courses that you think you want to take, and then changing the schedule. The courses that were chosen have a lecture conflict, between Anthropology 2 and Civil Engineering 60. This is designed to show whether our interface for indicating conflicts and the work-around for it that we implemented were effective and whether the user could discover how to remove one or more of these conflicting lectures. Finally, it stresses changing discussion sections. We feel that this is a reasonably complex task because it involves many different interface components and a great deal of user control to complete the task. Scenario [Image56.gif] Search and select all 4 classes in turn (the process is similar to the previous two tasks) [Image57.gif] Generate a schedule, the reds show conflicts between Anthropology 2 and CE 60. [Image58.gif] Select Anthropology 2 from the `Current Schedule' list , the `Remove Class' button is highlighted. [Image59.gif] Remove Anthropology 2 from `Current Schedule' list; the calendar is refreshed and there is now no more conflict, so the task is done. 4. Design Evolution Low-Fidelity to Prototype 1 : (see Figure 7, 8) * We realized that there was no point in displaying a calendar before a user selects his or her classes. * Instead of using a text-field to input data, a pull-down menu was used. InfoCal had the particularly annoying trait that if the user did not input the proper keyword, no classes would be found. A pull-down menu removes this problem entirely, but creates other problems. A `Selected Classes' list-box was added so that a user would always know what classes they are currently trying to schedule. * The tree-view was replaced by a simpler, easier to follow list-box in the calendar window. In addition, the functionality for changing discussion sections that had been exclusively embodied in the tree-view was moved to clickable sections on the calendar view itself. Prototype 1 to Prototype 2 : (see Figure 9, 10, 11) * Many cosmetic changes were made after users tested the first Visual Basic prototype. * The widgets on both the Search window and the Calendar window were moved so as to create a more aesthetic and usable flow from left to right. * An additional dialog box was created to warn the user that two or more classes had lectures that were in conflict. * The idea of showing course information was present in our original sketches and the Low-Fi Prototype and was added to the second prototype. * The confusing checkboxes next to the selected classes in the calendar window were removed. Because this was removed, it was also necessary to remove the "Regenerate Schedule" button that was associated with the checkboxes. * Functionally, the prototype now started to gather all data on available classes from an external database, and generates schedules based on this data (i.e. almost all Wizard-of-Oz techniques were eliminated from the prototype). Prototype 2 to Prototype 3 : (see Figure 12, 13, 14) * The `Search' and `Show Course Information' buttons were removed. When a user clicks on a class or search criterion, the information presented is automatically updated. This was a result of the final user testing step where users were often confused about the "state" of their search. * Buttons were added to allow users to switch between the calendar and search windows as desired. A "New Schedule" button was also added. This would have been helpful during the user tests where users had to perform distinct tasks or in a real situation where a user would like to look at several completely different schedules. * The pull-down menus were replaced with list-boxes accompanied by a text-field that supported word-completion. Users often had problems looking for a specific professor, but by typing a single character, the previously difficult task is now nearly trivial. * The "à " arrow was removed and an "Add to List" button was added to match the "Remove From List" button. The ability to double-click on items in both list-boxes to use these functions was also added. * The conflict dialog box was completely removed. It was confusing to users and restricted their ability to schedule classes as desired. * Conflicting lectures are now displayed in the calendar in red. The user needs some clear cue to know that the classes are in conflict, but should not be forced to choose a particular course. This is intended to be a work-around for our final design on how to indicate lectures that are in conflict. * Course information was added to the calendar window. Providing information at the user's request seemed like a reasonable idea and one user thought that it would be nice to retrieve information such as when a course has its final exam. * The ability to remove a class without having to go back to the search menu was added. When this is done, the prototype automatically regenerates the schedule with the remaining classes. This became more important once conflicting lectures were allowed to be displayed in the calendar view. * All remaining Wizard-of-Oz techniques were removed. The application is now fully connected to an external database for all functionality. 5. Final Interface There are three main pieces of functionality that we support. The first is to search for a list of classes that users want to schedule based on different or combined search criteria. The second is to take a list of classes and automatically generate a schedule with or without conflicts as users desire. Finally, we offer a way to modify specific parts of the user's schedule so that he can switch between or delete sections that have conflicts or are scheduled at inconvenient times. The user is allowed to search the `Schedule of Classes' using one of the three search groups we provide. The first group allows a search according to the department and the course level, such as undergraduate or graduate. The second allows a search by the instructor. The final search group allows a search by the time and day a class meets, as well its number of units. The division into three groups is intended to model the way in which users actually search for specific courses and eliminate combinations of search criteria that aren't intuitive. As he searches, the user can add any of the resulting classes into a list of classes to schedule. Once the user has finished creating a list of courses and clicks on the Generate Schedule button, the program automatically generates a schedule. We can't guarantee the schedule our program generates is acceptable for every user, especially when it has conflicting classes. Thus, our final bit of functionality allows the user to manually manipulate the generated schedule to change or delete sections. When the user is viewing the schedule in the Calendar view, by clicking on any section the program will automatically show all alternative sections for that course of that type in a contrasting color. In the case of lecture sections, all alternatives will be shown. In the case of supplementary sections, such as discussion or lab sections, only those sections that don't conflict with existing courses will be shown (this was because many different supplementary sections are often available, and one of the user's primary goals is to generate a list of discussion sections that don't conflict with any others. Furthermore, actively creating conflict drawings when the user simply wishes to change to a new section would be extremely confusing to the user for those rare cases when that functionality was desired.). The user clicks on the alternative section and the section is changed. User Interface Design Search Window Design: First, to search for the classes they want to take, the user can choose from three different tab options provided under `Search Criteria' (see Figure 1), which are search by department, instructor and time and units. If the user chooses to search by department (see Figure 1), he can either select the department from the list of available departments or type in the first few letters of the department name, which will automatically match the department in the list with our partial completion mechanism. If the user wants to search by instructors' last names instead (see Figure 2), he can select a department from the left list-box to display a list of instructors who belong to the department in the right list-box. Alternatively, the user can type in the first few letters of the instructor's last name, and our partial completion mechanism will match a corresponding instructor in the list. The search by time and units search option is left unimplemented due to time constraints, but we display the tab in order to demonstrate that we believe that this useful search criterion should be supported in a complete version of the program. The search results are automatically displayed in the search results list as the user selects different departments, instructors, etc. Then the user can add any classes from the `Search Results' list to the `Classes to Schedule' list. This can be done either by selecting a class and clicking on the `Add to List' button below the bottom of the list or by double clicking on the classes to be added. The user can also view a course description in the bottom left text window by simply selecting the class from either list. Additionally, the `Back to Schedule' button we added for the final prototype is used to switch back to the previously generated schedule if one exists. Calendar Window Design: Now the user is ready to click on the `Generate Schedule' button to generate a schedule with the selected list of classes (see Figure 3). As you can see, the `Current Schedule' list-box contains classes in the current schedule. For classes that have their times To Be Arranged(TBA), we put `TBA' at the end of the class name to tell the user why the class is not shown on the schedule. The user can remove a class from the current schedule by selecting a class from the `Current Schedule' list and clicking the `Remove Class' button. In addition, the user can select a class in the `Current Schedule' list to view its related information like time, instructor and units in the `Course Information' text box. To view alternative sections, the user can click on the section of interest and all alternative sections will then be displayed on the schedule in blue color (see Figure 4). The user then has the freedom to select any section in blue in order to keep it, following which the calendar will be restored to its regular color (see Figure 5). This change of section mechanism is applicable to lectures, discussion sessions as well as labs and other type of courses, even though our current implementation only covers discussion sessions. Our interface design also involves simultaneously showing all conflicting classes. Much as in Microsoft Schedule+, when two sections are scheduled for the same time period, the column that represents each day's schedule is split in half and each scheduled section takes up one half of that column. Although they might only overlap for a portion of their scheduled times, each section appears split throughout the scheduled time to give further visual cues that these courses conflict. Since splitting a column for two or more classes could result in very narrow class listings, all columns are resizable. This involves the visual cue in the header row for grabbing to widen the column. This part of designed is not implemented in our final prototype, but we have a very rough sketch of design idea in Figure 6. Unimplemented User Interface The only significant piece of unimplemented user interface regards conflicts in scheduling on the Calendar control. Implementing this interface design in the control that was chosen for our calendar control, the Microsoft Flex Grid, is infeasible. Dynamically splitting cells or columns into multiple cells or columns, and dynamic resizing of columns and cells, is virtually impossible using this control. Some of this functionality and design has been simulated through the use of including the names of all conflicting classes in the cells in which they conflict, and coloring those cells red. Furthermore, choosing a different lecture section in the same way as a discussion section wasn't implemented, because it couldn't be determined based on our choice of how to visualize the conflict which course should be changing. We don't feel that this is a good representative of our interface design, but we are unable to implement our selected interface using the tools that we have chosen. Additionally, changing lecture and lab sections in the same fashion as discussion sections wasn't implemented because it added little to the understanding of the problems inherent in them, since they are treated the same as discussion sections in our design. Finally, when a class name is too long to fit into the given number of cells on the schedule calendar, we intended to show a pop-up tool tip that will display the complete class name as the mouse moves over. This would be similar to how it is done in standard window's programs, but we didn't have time to implement this functionality. Tools The database was developed in a combination of Access and Perl. While Access is very non-full-featured, it was more than adequate for our needs. Although we could have done the entire project in five lines of Perl, this would have caused debugging and testing problems so we limited our use of it to automatically modifying data in the database. The only development tool that was used for the prototype itself was Microsoft Visual Basic 5.0. Everyone in our group has extremely mixed feelings about this development tool. On one hand, it made quite a bit of functionality extremely easy to implement. Its ability to easily add user interface elements and map their behavior to the behavior of other elements in a simplistic way is very nicely implemented and makes for fast prototyping. One significant functional problem that we had was with regard to using a Visual Basic Grid as a calendar. Although we were able to get much of the functionality that we wanted out of the existing control, the functionality that we wanted to add was impossible to add correctly. While we were able to show some indication of what our correct user interface would have been in these cases, in others were weren't and it negatively impacted our ability to fully execute our design. Furthermore, the structure of Visual Basic would have required doing a phenomenal amount of work to separate the code we had already done from any new Grid or Calendar object that we might have written. In general, we cannot recommend this program for any program requiring complex interaction with the user. It lacks far too many functional abilities that are necessary for real application development. It is highly unstable as a development environment, leaking up to 20 megabytes of memory every hour and crashing frequently. Its language is very confusing to developers used to a lower level language, such as C++ or Java, and caused us some difficulty and wasted time.. Due to its project, rather than file, focus, it lacks the ability to easily integrate it with a proper source control and versioning environment. Finally, its IDE is extremely poorly designed and actually obfuscates any reasonable development efforts. We recommend PowerBuilder or Next's Interface Builder as these programs resolve most of these conflicts. Appendixes [Image60.gif] Figure 1: Search by Departments [Image61.gif] Figure 2: Search by Instructors [Image62.gif] Figure 3: Schedule Window with a TBA class that is not shown on the calendar view [Image63.gif] Figure 4: Schedule Window showing multiple discussion sections, as a result of clicking on the original discussion [Image64.gif] Figure 5: Schedule Window after an alternative discussion section is selected. [Image65.gif] Figure 6: Design of Conflicting Lectures This drawing shows two lectures that are conflicting over a half-hour time slot. In the actual program, these would be outlined in red. _____________________________________________________________________ [Image66.gif] [Image67.jpg] _____________________________________________________________________ [Image68.jpg] [Image69.gif] [Image70.gif] _____________________________________________________________________ [Image66.gif] [Image71.gif] _________________________________________________________________________________________ [Image72.gif] [Image69.gif] [Image71.gif] [Image73.gif] [Image72.gif] _________________________________________________________________________________________ [Image70.gif] [Image74.gif]