the Technology Interface / Fall 97
Abstract: The need for a computer program to schedule
courses, teachers, students, and rooms became apparent after observing
numerous department heads struggle with the scheduling process.
All department heads I observed used some form of manual scheduling
procedure, with varying degrees of success. The idea that a personal
computer could be used for this task was born six years ago.
I first wrote a DOS based program in C, but it soon became apparent
that improving the graphics and database manipulations would be
very difficult, and that the scheduling process could benefit
greatly from a windows based program where schedules could be
more easily manipulated. The final program was written in Visual
Basic®, making the program windows based and allowing interfacing
with a standard Microsoft Access® relational database.
I. Introduction
I've always been interested in computers as tools for teaching
concepts that are hard to visualize and for doing tedious and/or
difficult tasks. There is a certain creative thrill in starting
a new programming project, with the hopes of finding an elegant
solution to a nagging problem. Much like building a house or
painting a picture; all the tools and equipment you need are right
in front of you, waiting to be assembled into a useful program.
Prior to writing the Course Scheduler program I wrote Tutorial
on P.I.D. Control, a DOS based program to simulate P.I.D.
(Proportional Integral Derivative) control on a personal computer.
I was fascinated that the computer could draw the integral and
derivative of an error curve as I manipulated it, and that the
program could show the control system become unstable as gain,
rate, and reset were adjusted. Then I wrote PC-PLC, a
DOS based program to simulate a PLC (programmable logic controller)
on a personal computer. I wanted a means for students to be able
to learn how to program PLCs on their personal computers at home,
and for the computer to provide real I/O through the parallel
port for students wanting to experiment with real time control.
Then I wrote Tutorial on Microprocessor Literacy, a DOS
based program to show everyone how microprocessors work. The
program graphically shows data moving between the microprocessor
and memory as an assembly language program executes. These programming
projects resulted in useful tools for use in the classroom and
provided vehicles for learning more about computers and programming.
II. Writing the Course Scheduler program
I have observed various department heads struggle with scheduling
their courses, teachers, students, and rooms. Most department
heads used some sort of manual scheduling technique such as overlays
or templates to varying degrees of success. The major problems
seemed to be keeping track of all the courses, teachers, students,
and rooms that had to be scheduled and avoiding scheduling conflicts
such as teachers and/or rooms being busy at a particular time.
It seemed that there had to be a better way, and that maybe a
computer could serve as a useful tool in the scheduling process.
I first wrote a DOS based program in C, but it soon became apparent
that improving the graphics and database manipulations would be
very difficult. I also felt that the scheduling process
would benefit greatly from a windows based program, where individual
schedules could be shuffled like cards in a playing hand. I had
not particularly enjoyed programming in C because of the terse
syntax, pointers, and memory management problems, so I decided
to try Visual Basic® as a tool for writing the window based
program.
Visual Basic® turned out to be easy enough to use that it
was fun, and I could produce a windows based program that would
run under Windows 3.1® and Windows 95®. By using multiple
document interface (MDI) forms, I was able to open and manipulate
schedules like Microsoft Word® opens and manipulates documents;
each in their own window that can be minimized, sized, cascaded,
and tiled.
I found that Visual Basic® could also manipulate a standard
Microsoft Access® relational database, relieving me of the
burden of doing the database coding manually. The database is
arranged with a separate table for courses, teachers, students,
rooms and time periods. Then, as the schedules are built by the
user, another table is constructed listing the teacher, students,
room, time period, days of the week, and course notes for each
course. The tables of courses, teachers, students, and rooms
may be built by the user before scheduling any courses by creating
"lists" of courses, teachers, students, and rooms.
And the tables are updated "on the fly" as the user
enters courses, teachers, students, and rooms during the scheduling
process which were not previously entered on the lists. All of
this database manipulation is done behind the scenes and is transparent
to the user.
III. What the Course Scheduler program does
The program schedules courses, teachers, students, and rooms by
allowing the user to enter course information on a teacher, student,
or room schedule. The schedules are a weekly grid with time periods
down the left had side of the form and days across the top. Up
to 30 time periods, of any designation, for each day may be entered.
Saturdays and Sundays may be included. If the course, teacher,
students, or room was previously entered on a list, it will be
available from a pull-down list. Otherwise, it can be typed in
and will be automatically added to its respective list.
Whichever schedule that the user chooses to work on (teacher,
students, or room), the other two schedules are automatically
built in the background. For instance, if the user chooses to
enter courses, students, and rooms on a teacher's schedule, he/she
can later view the students or room schedule just by clicking
on its name. This gives the user the flexibility of working on
whichever schedule(s) they prefer, and mixing and matching. The
teacher, students, or room may be left blank. For instance, the
electronics department head needs to schedule English 101 into
his students' schedules, but may not care who is teaching it.
If a scheduling conflict occurs, such as a teacher or room
being busy when the user is trying to schedule it, the program
displays a pop-up message and disallows the action.
Any number of schedules may be open at one time, and they can
be minimized, sized, cascaded, and tiled like any other window
allowing the user to move freely from one schedule to another.
You can cut and paste on the same schedule or across schedules.
Printouts of the graphical weekly teacher, students, and
room schedules are provided, along with a tabular printout listing
course name, teacher, students, room, time of day, and day of
week that each course meets. The tabular listing may be sorted
by course name, teacher, students, or room.
Other features include the ability to find common open (free) times among any number of teachers to schedule meetings, and the ability to find teachers, students, and rooms that are open during selected times for finding substitute teachers or rooms.
If you schedule the same courses, teachers, students, and rooms
each semester or quarter, you should build a template file.
Then start each scheduling project by opening the template file
and saving it under a new name that describes the schedules you
are about to build (i.e.: fall_qtr.mdb). Using a template file
makes the courses, teachers, students, and rooms available on
pull-down lists on the schedules so that they can be selected
by clicking on them instead of typing them in every time.
IV. What the Course Scheduler program does not do
The program does not track individual student demographics such
as name, address, grades, transcripts, or attendance. The term
"students" in this program means a group of students;
such as "freshmen", "sophomores", or "section
A".
V. Possible Future Enhancements of the Course Scheduler program
I tried to write the Course Scheduler program so that it would
be useful to the most number of users, realizing that different
people schedule in different ways. In future releases of the program
I'd like to incorporate features that would allow users to tailor
the program to their particular scheduling needs.
For instance, one feature that may be useful would be to make
the schedules "transparent" so that they could be laid
over top of each other and similarities/differences could be
observed.
If you know of any obvious features that have been overlooked,
please let me know.
VI. Hardware requirements
1. I.B.M. 386 or higher compatible computer.
2. Windows 3.1, Windows 95, or Windows NT.
3. 1Meg of Hard Disk Space
4. Mouse
5. VGA or higher resolution video.
6. 3-1/2" 1.44 Mbyte disk drive.
7. Graphics printer.
VII. Program Availability
E-mail Rick Miller at millerr@cot01.ferris.edu or write to P.O.B.
1066, Big Rapids, MI 49307, for price and availability.