This system can help you keep a check on students' attendance at practicals, and also record their achievement of practical checkpoints.
This description refers only to use on PCs. Untested on other platforms, but it's Java, so portability shouldn't be too big an issue! "You/your" refer to a course organizer.
Java will need to be installed on your PC and the student lab PCs.
The system is organized as follows:
All the data is held centrally in the Division's Oracle installation - student and lab session details. (The tables belong to me, and are not accessible to anyone else. No personal text files for you to bother with.) The database is managed via a substantial bunch of servlets looked after by Tomcat as part of my servlet space. So, provided that Tomcat is up and running properly, there is no need to remember to start any special servers. The students run a small registration program from the lab at each practical - this contacts Tomcat to verify student id, lab session and to register attendance - this program is also used to record checkpoints later on. On your PC you have a single Java application for uploading class lists, configuring lab sessions, setting up checkpoint details, checking attendance records, checkpoint achievement records - again this contacts Tomcat for all data management.
At the lab end, the system is reasonably secure: the registration program makes use of environment data to determine the student username and lab name (ie students are not responsible for entering their own username, nor their location - each PC "knows where it is"). The time that each attendance registration request is made is determined by Tomcat. Therefore, it is very unlikely that a student will be able to fake either their own attendance at the wrong time or in the wrong lab, or the attendance of a colleague (unless they collaborate in the exchange of passwords, against which I have no remedy!). This works in CS labs as well as central labs.
Lab sessions are denoted by their start time (exact hour marks only), and may be 1 or 2 hours long.
When the system is up and running, a student runs a small application in the appropriate Groups module folder. They click on a button to register their attendance. The request is allowed and recorded if the student is known on the course, and if the lab is correct for the course, and if there is a lab session at the time, and if the request occurs within the first half hour of the session (this is customizable). Failure can occur in various ways: bad environment data, wrong lab, Tomcat not contactable, too late, etc - so it's advisable to have a paper recording system on hand for erratics (students turning up late, or forgetting to register until too late). The lecturer interface application allows you to make manual updates to the database - including adding and deleting students, or attendance records. Once a student has correctly registered their attendance, the application shows a drop down list of current uncompleted checkpoints, and allows a demonstrator to record achievement of available checkpoints.
Note that the registration system does not know anything about the sessions that individual students are supposed to be attending, and knows nothing about weekly patterns of sessions nor of attendance. It could be argued that this is a shortcoming, but it has great advantages when dealing with irregular events - such as students just happening to attend wrong sessions due to bus/illness/alcohol/etc problems, extra lab sessions, altered lab sessions. Another weakness is that each course module can only be using one lab at any one time - this should only occur rarely (and if it does, then we can make up a variant module code for one lab, though this means that the two separate attendance records would have to be manually combined). Further, no lab can be used for two or more course modules simultaneously - again, this is not usually a problem (when it is, in particular for PDMU9L6/7, we just make up a fictitious module code and set up a combined list of classes/checkpoints for that "module").
You will find the files and folders referred to below at \\fs0\home\courses\attendance\practicals\PracReg-deploy\ (or possibly \\cifs instead of \\fs0, and you may need full qualification such as \\fs0.cs.stir.ac.uk).
1) Drag a copy of the shortcut "Practical attendance" to somewhere convenient in your desktop environment. This is all you need to install on your PC. Double clicking the shortcut will launch the lecturer interface application. (Just having a shortcut to the actual code in PracticalAttendance.jar means that I can update it without you needing to re-install. You can copy the .jar file instead, if you wish.)
If you want to use the lecturer interface from home, just take a copy of PracticalAttendance.jar and double click that. [I guess that if you're using the CampusNet VPN via broadband then you should be able to just take the shortcut home if you wish!]
2) Open your course module folder on Groups (or wherever), and drag a copy of the shortcut Register and the whole folder Registration into it. [Register is a simply shortcut to launch the Register program in the folder. You can make the shortcut look a bit nicer by setting it to use the CAMERA.ICO image.]
3) When you first launch the lecturer interface you will be directed to the panel for selecting the modules you would like in your drop down selection lists in the various other panels. If you have not been configured to use the system then this step will fail.
4) Setting up students: This is a two phase process, which I will do as far as I can at the start of semester - although individual module organizers will usually need to make updates as the class lists settle down.
Phase 1: All students' details must be entered into the database (without being associated with any course modules) - there is a bulk load option in the main Load menu. Extra students can be added later using the Database/Edit student panel.
Phase 2: Indicating which students belong to a module: There is a bulk load option in the main Load menu - it requires a file with module code on the first line, followed by one registration number per line. The Custom Classlist Generator on the Divisional web site is able to generate a correctly formatted file, or the Portal class lists page. Individual students can be added/deleted using the View Module panel.
5) Setting up Practical sessions: There's a panel for it in the lecturer interface. Basically, you set up a weekly pattern, and then the system duplicates it for a specified number of weeks. If you need to configure the lab session length, or % of session allowed for registration, then use the View Module panel. You can check/delete the sessions in the View Practicals panel. Individual student attednances can be added after a class in the View Practicals panel.
6) Setting up/Editing checkpoints: There's a panel for it in the lecturer interface. For each individual checkpoint you give a title and the date that the checkpoint should first become visible in the students' interface. You can check/delete the checkpoints in the View Checkpoints panel, which also allows you to add/remove individual students' achievements of checkpoints.
7) Passwords: If a student attempts to register their attendance too late (but still within the session's duration), then a demonstrator can authorise the registration using a password that is configured on the View Module panel. Similarly, there is a password that the demonstrator must enter in order to authorise the recording of a checkpoint - I recommend changing this after each session/week. Note: the checkpoint passwords are not per checkpoint.
8) There is a basic help facility. I'm happy to help in any way! And to receive comments on anything that needs fixing/improving.
Have fun!
Simon