Classroom Management

Building a Class Helper: A Proposal, Part 3 of 3

• By Emmett Dulaney
• 02/17/16

This is the third and final discussion on the need for a single, simple software utility that can be used within the classroom and perform a plethora of functions that are not currently able to be done well. Called Class Helper for discussion purposes, this conversation is about a product that does not presently exist in anything but a theoretical and piecemeal form but could be created by a programmer with sufficient skills. In that context, this dialogue should be viewed as one would a request for proposals and further discussion is both encouraged and invited.

The original nine tasks that the tool was proposed to be able to do include:

1. Take attendance
2. Sequentially call on a student
3. Randomly call on a student
4. Selectively pull students from a pool
5. Keep track of participation
6. Require a response within a given timeframe
7. Randomly create groups
8. Create a randomized seating chart
9. Send notes to a student or group of students

The previous two articles (part 1 and part 2) examined ways of implementing the front-end and back-end frameworks to accomplish these tasks. The purpose of this article is to expand on other possibilities. As the requirements for Class Helper has been shared with faculty from other institutions, they have expressed additional opportunities and enhancements to fit needs they've encountered. What follows represents a wish list of supplementary activities that could be of relevance and also managed by the core tool.

Group Creation Based on Major
The original premise of the grouping feature was to allow for randomization of students and the creation of groups of various sizes based solely on student names. There can be times, however, when you want to create groups based upon other values. A good example would be in an entry-level Business as a Profession course that all business students take, where it could be helpful to create groups in which there is one marketing student, one finance student, one accounting student and so on. There will never be a perfect distribution of students within a course, but the software can do a quicker job of working within the parameters of what are there than an individual can.

An easy way to approach this capability is to add another field to the index file — instead of all from the third field on representing absences, attendance can start with a later field and a number of fields can be used to hold other attributes for each student. Instead of a sample entry in the colon delimited file looking like:

Kristin Spencer:spencer.jpg:::::

The default entry could now look like:

Kristin Spencer:spencer.jpg:marketing:sophomore:female::

Once read into the temporary array (ALL_STUDENTS) at startup, sorts could be done based on major (third field), level (fourth field), or gender (fifth field). After the sort, groups could be formed with one from each group OR all from the same group if you wanted to put all the accounting majors together, all the finance majors together, and so on. There is no limit to the number of descriptors that could be added about each student and the choices as to whether or not they should be grouped together based on those descriptors. For example, one of the fields could hold current grades or grades on the last exam or any similar value and then groups could be formed such that underperforming students are paired with over performing students.

Group Creation Based on Restrictions
Just as you may want to create groups based on a criteria (put a marketing major with a finance major, etc.), there can be times when you want to keep certain people from being in the same group. The reasons for this could range from the individual students not being allowed to work together (restraining order), to being slackers who would likely be a recipe for failure when paired, to their having worked together on too many groups in the past.

Using one more field as a restrictions field and emulating the functionality of the uniq command in Linux can keep them for being put together in groups. Assuming the sixth field is used for this purpose, the entries would now look like:

Kristin Spencer:spencer.jpg:marketing:sophomore:female:Z7:
Evan Turner:turner.jpg:accounting:freshman:male::
Karen Walters:walters.jpg:marketing:sophomore:female::
Madonna Zurawski:zurawski.jpg:finance:junior:female:Z7:

This indicates that Evan and Karen can work with anyone. Kristin and Madonna cannot work together but can work with anyone else. The "Z7" has no special meaning as long as it is unique for each restriction and you can create as many restrictions as you want/need.

Add Multiple Timers
Adding optional timers into the tool and making them complementary to other tasks adds more possibilities. When randomly calling on a student, for example, a visible timer can give them a certain amount of time to answer before you move on to the next student. Adding a timer to the group randomization can give groups a specified amount of time in which to do their work, make their presentations, etc.

Having two or more timers available — and visible — at the same time could be used for in-class competitions such as lightning rounds. They can also be used to set one to a large task and another to a subset of it. An example of this would be if a group needed to come up with an elevator pitch, one timer could be set to the thirty minutes they are given for completing the assignment and another to the five minutes of the time they are to use initially to brainstorm a type of business they want to do the pitch on.

Add the Current Grade and Email
While the original intent of the Class Helper was to simplify the time in the classroom to make it easier to administer the course once you left the room, there is little reason why it can't provide additional functionality within the room as well. Two of the most commonly asked questions of many instructors are "Can you tell me my current grade?" and "Can you send me that?" whatever that happens to be.

The current grade can be a static value updated as frequently or infrequently as the instructor wants (such as after the last exam or midterm) and accessed via the report options (discussed shortly). An email field can hold that value for cutting and pasting along with whatever attachment is expected to be sent. For purposes of simplicity, the ideal location for these two entries would be after the name and image file. If everything discussed thus far is added to the image file, then an entry for a student currently earning a "C" would resemble:

Kristin Spencer:spencer.jpg:C:[email protected]:marketing:sophomore:female:Z7:

While calling the email program directly is a possibility, it adds a significant amount of complexity and weight to the program and takes it away from its primary goal of being a small executable file capable of running on almost any machine from a flash drive.

Adding Security
Whenever student records are involved, there is always a question of data security that needs to be addressed. In this case, even if all the enhancements discussed are added to the tool and files, valuable identifiers such as social security numbers and student IDs are not present. Nevertheless, there isn't any student who would be comfortable knowing that their current grades, email address, and other attributes run the risk of being seen by prying eyes.

To alleviate that trepidation, it is suggested that two levels of security be added: one internal and one external.  Internally, every time an operation is performed, Class Helper should check to see if the flash drive is still installed in the machine (accessible) and it should terminate immediately if that is not the case.  This will prevent a situation where a rushed instructor pulls the flash drive from the machine at the end of class without exiting the program and dashes off to yet another meeting and accidentally leaves data viewable by students who linger after the class has ended. Requiring a check to see if the flash drive is still installed limits the only data those lingering students could possibly now see to what was up on the screen at the time the drive was unplugged.

Externally, all the data on the drive should be encrypted. While it would be possible to add encryption to the tool itself, that is a meaningless (and, most likely, weak) operation that is better performed for the entire drive rather than just for the Class Helper files. Almost every flash drive manufacturer includes encryption software that is available with — or downloadable for — their drives. Much of this is available for free, but it is also possible to find some very high end software on pricier drives. The level of encryption is at the discretion of the user, but it is recommended that the minimum considered employ 256-bit ciphers and be FIPS 140-2 compliant. By having the entire flash drive encrypted then if it is stolen or lost, the data on it (not just associated with this program) cannot be accessed without the correct password.

Reporting Options
Not only is the tool used for manipulating data by creating groups and randomly calling on students, but one of its biggest features is the ability to store data during class that can be accessed later. A key piece of collected data is attendance and reports can be run by day or by student. If you want to see how many times an individual student has been absent, those values are recorded in the index file and can be read as dates directly from there. The two possible options are to read the values for only one student (as illustrated in Figure One), or for all students in a particular course (as illustrated in Figure Two).

The display can be shown on the screen, as Figures One and Two demonstrate, or written to a text file to be imported into Excel, Word or any other program.

The second way of viewing attendance is by day. These values are not read from the index file, but instead come from the attendance text files created each day (and which also provide a convenient backup should the index file be in question). Figure Three shows an example of the output coming from this way of viewing the data.

Once again, this display can be viewed onscreen or saved to a text file for importing into any other program capable of reading .txt files.

While an interface similar to that shown in Figures One, Two and Three can be used to read the note files created during class (participation, group assignments, etc.), it is far easier to simply import them into any document editor (Word, Google Docs, etc.) and work with them there. Those same editors can be used to create the index file at the beginning of a new semester (or copy an old one over for use again).

Concluding this Discussion
The purpose of this series was to look at a proposed tool that could be helpful in simplifying classroom operations. The need for it was outlined in the original article and the core logic behind the operations was examined in the second while this one focused on possible enhancements and reporting functions.