Building a Class Helper: A Proposal, Part 2 of 3
- By Emmett Dulaney
- 02/10/16
The need for a single, simple, utility that can be used within the classroom and perform many functions currently not capable of being done well was outlined in the first article in this series. Dubbed Class Helper for lack of a more suitable name, the nine tasks that the tool should be able to do include:
- Take attendance
- Sequentially call on a student
- Randomly call on a student
- Selectively pull students from a pool
- Keep track of participation
- Require a response within a given timeframe
- Randomly create groups
- Create a randomized seating chart
- Send notes to a student or group of students
Having provided an outline for the functionality, this article proposes a workable structure that can make those functions possible. Bear in mind that that this is a proposal only and a more ideal structure may be achievable.
The Need for Self-Containment
No matter how much IT may believe they are standardizing classrooms, there are always subtle differences between them — one has a newer projector, one has a slower Internet connection, one has weak Wi-Fi and so on. Since it is rare for an instructor to always have the same classroom for every class they teach, they should prepare by adapting to the lowest common denominator. In many cases, that amounts to a USB port that a flash drive can be plugged into and run.
By creating a tool in which everything exists on the flash drive — executables, log files and so on — it becomes possible for the instructor to carry something small and portable with them, enter any classroom and use the tool, and always have up-to-date information about any course at their ready. Bypassing the need to authenticate, connect online or download, a great deal of time and frustration can be saved before, during, and after class.
The Present Working Directory
The executable file (class_helper.exe) should be able to be located within any directory on the flash drive and that directory then becomes the present working directory. This can be the root directory of the drive, but would, for aesthetic as well as functional purposes, be better if it were a subdirectory. For purposes of illustration, assume the flash drive is E: and the executable file is placed beneath a directory called FALL15_CLASSES, then the present working directory (which can be referenced in most programming languages as app.path, or some derivative thereof) is E:\FALL15_CLASSES.
When the executable begins, it should first look to see if it was started with a parameter of NOIMAGE or NONAME (easily configured by creating a shortcut to the file and calling it instead of the file directly). If called with one of those two strings, then the checkbox associated with that value should be turned off, otherwise the default for both is on.
The name of every subdirectory beneath the present working directory should be used to represent a course the instructor is teaching and thus populate the radio button options in the upper left frame as shown in Figure One.
FIGURE ONE: The options for courses to choose from come from the subdirectories beneath the present working directory.
In this case, there are three subdirectories beneath the present working directory, BSNS 2550, BSNS 3400, and BSNS 4310 so those values populate the radio buttons (as illustrated in Figure Two). For adaptability purposes, the number of radio buttons that can be displayed in this frame should range from one to 10, though it is very probable that most instructors teach five or fewer courses during any given semester.
FIGURE TWO: The structure of the subdirectories beneath the present working directory, which become the option choices.
Each subdirectory beneath the present working directory represents a course being taught this semester and there are a number of entities that must exist beneath each. The first is an index file consisting of several fields, only two of which really need be filled in. The first field is the name of the student that they will be referred to as (adjusted, therefore, for any nicknames, preference of middle name over first, and so on). The second field holds the name of the image file to be used for the student. Assuming a colon (:) delimited file, a sample entry would look like:
Kristin Spencer:spencer.jpg:::::
The file is read into a temporary array (ALL_STUDENTS) and used to populate the attendance boxes as well as constitute the pool from which to choose students (alphabetic, random, shuffle, etc.) so the names should appear in the file in alphabetic order based on last name to simplify operations. Some students may not ever want their image displayed, in which case the second field can be left blank to abide by their wishes. Other students may not mind having an image displayed but there is not one available: for those cases it is recommended that a stock photo of a blurred image (one for male and one for female) be used as a temporary placeholder and Figure Three offers an example of one possibility.
FIGURE THREE: An example of a blurred male image that can be used as a placeholder when the actual student's image is unavailable.
An IMAGES subdirectory should exist beneath the directory for each class holding the student photos to be used (.jpg is recommended for ease of loading) and the area in the program in which they appear should be configured to stretch for fit.
Two other subdirectories, ATTENDANCE and NOTES should also reside her for self-explanatory purposes. Figure Four shows an example of the subdirectories beneath one of the course directories.
FIGURE FOUR: The structure of the subdirectories beneath each of the course directories.
With the necessary subdirectories created and the index file in place, the Class Helper program has all it needs to operate. On startup, it looks in its present working directory and takes the name of each subdirectory it finds and uses them to populate the choices for courses. Once a course has been selected from that list, the program then reads in the index file beneath the subdirectory for the values to use to populate the ALL_STUDENTS array. This array completely replicates, in memory, the contents of the file and the index file is closed.
A duplicate of only the first two columns of ALL_STUDENTS (the names and image file) are used to create another array called PRESENT_STUDENTS and both are used for various operations throughout the program. When taking attendance, for example, the checkbox choices of students present comes from ALL_STUDENTS. When a student is checked as being absent, three things happen:
- Their entry is removed from the PRESENT_STUDENTS array. The way this is done is addressed in the next section.
- The date is written to ALL_STUDENTS in the next open field for that student. If, for example, October 5 was Kristin’s second absence, her entry would now resemble: Kristin Spencer:spencer.jpg:9/23/15:10/05/15:::
Before closing out of the program, this array will replace the index file to keep it up to date (writing over the existing file and not appending to it).
- A file with today’s date as part of the name is created beneath the ATTENDANCE subdirectory and it contains the name of each student not present on that date. Figure Five shows an example of this:
FIGURE FIVE: The ATTENDANCE subdirectory beneath each course holds a file for each day there were any absences.
With the absence noted in three different locations, it can come into play three different ways. The first is that by not having it in the PRESENT_STUDENTS array, their name will not come up when randomly calling on students and it could, theoretically, be left out of random groups assignments created for that day alone. The second is that by writing into the index entry for each student, a report can quickly show the number of absences that student has as well as the dates of each. Third, having a file specific to each day makes it possible to later refer back to that day and see if there are trends (clusters of the same students that are always absent on Monday or Friday, for example).
Operations: Working with PRESENT_STUDENTS
The PRESENT_STUDENTS array starts each session being equal to all the students in the class and an integer (tot) refers to the total number of students. When a student is marked as absent (as represented numerically by the variable absent), their values are overwritten by those appearing in the array below it and the value of tot is decremented by one.
As an example, if there are 26 students in the class (tot) and the 20th one (alphabetically ordered) is absent, then the code would resemble:
If tot > absent Then
For b = absent To tot-1
PRESENT_STUDENTS[b]["name"] = PRESENT_STUDENTS[b+1]["name"]
PRESENT_STUDENTS[b]["image"] = PRESENT_STUDENTS[b+1]["image"]
EndFor
EndIf
tot=tot-1
And it would replace what was in the 20th spot with what was in the 21st, what was in the 21st with what was in the 22nd, and so on. This operation runs for each student marked as absent and overwrites their values with those that were below (while continuing to decrement the integer). In theory, if the last four lines of the array originally resembled this:
Kristin Spencer:spencer.jpg:
Evan Turner:turner.jpg:
Karen Walters:walters.jpg:
Madonna Zurawski:zurawski.jpg:
and there are two students absent, those last four lines now look like this:
Karen Walters:walters.jpg:
Madonna Zurawski:zurawski.jpg:
Madonna Zurawski:zurawski.jpg:
Madonna Zurawski:zurawski.jpg:
Since the value of tot is now equal to 24 instead of 26, the repetitive entries at the bottom of the array do not ever get called upon and do not matter.
Operations: Randomizing Groups
As currently configured, radio button options allow for choosing whether you want to create groups that have 2, 3 or 5 students in them. There may be times, however, when groups of other sizes are preferred. To account for that, one possibility is a prompt that asks how many students should be in each group and then reads that value in (num). A modulo (or remainder, as some languages refer to it) can then be used to divide students into groups of that size.
The heart of this logic thus becomes similar to:
remainder = Math.Remainder(zz, num)
If (remainder =0) Then
groupno=groupno+1
EndIf
Wherein zz is an incrementing number from one to the total number of students in the course (or the total number of students present). This approach allows for the creation of groups of all sizes and isn’t limited to just the radio button choices.
Continuing this Discussion
The purpose of this article was to look at the core logic operations behind the proposed tool outlined in the original article. In the third and final part, some of the reporting functions, configuration operations and other possible enhancements and suggestions will be discussed.