Academia Stack Exchange is a question and answer site for academics and those enrolled in higher education. It only takes a minute to sign up.
Sign up to join this community
I was talking with some instructors, and we noticed that there is a pattern of claims about technical difficulties. I wonder if there are any rules to follow of whether to allow or don't allow students to retake exams. My university and department have not set any such rules.
For example, don't allow to retake the exam unless the server is down for all students. Or allow to retake a new and different exam, but students should share their screens with the TA or instructors.
Unless we somehow want students' grades to reflect the quality of their home Internet connection, the quality of their hardware, and their tech savvy (or their families'), there is not a sane alternative but to take seriously essentially all claims of technical problems. No, it it not really possible to "prove" technical problems, nor is it reasonable to try to insist that people with technical limitations be astute enough to document the tech problems!
Yes, from a traditional enforcement-oriented viewpoint this is "impossible". Yes, indeed, so, manifestly, that traditional adversarial viewpoint is not really (meaningfully) sustainable in plague times. So, indeed, what instead? Very context/culture -dependent, to begin with. Are classes gauntlets to be run [meaning adversarial situations in which one proves virtue by survival]? Or do we want classes to be fundamentally educational opportunities, and helpful to the students [as opposed to skeptical and adversarial]? In plague times, at least, what are viable (and useful) goals?
Goals???)? Classes (goals in themselves)? Exams? Or more generally, the entire education system?
– Peter Mortensen
Nov 25 '20 at 20:29
I suppose this is rather off-topic, but a different individual mentioned at the end of their post that project-based learning may be the best of all solutions. Speaking from personal experience, for whatever that is worth, I have very fond memories of my project-based curricula and indeed really believe that I learned the most from them. A project-based course in a certain undergraduate course put me on the trajectory to study that topic at the graduate-level.
By contrast, my more traditional courses – bluntly, those that taught more basic concepts that had to be mastered and recited on homework and exams – are far less memorable. Although the foundation they provided for the more advanced courses was surely useful, I do not believe that they require one to parse and understand the content as clearly and carefully as successful project-based curricula. Of course, what a successful project-based curricula looks like will vary greatly from domain to domain and may not even be feasible given the size of some classes and resources available. So I suppose this is more of a shoot-for-the-moon solution.
Technical difficulties exist. More noticeable the more important the action they are impeding.
On the other hand if they only suffered a minor issue (if any), it could be great to have an excuse to retake an exam they did poorly!
The issue should be approached much earlier than the exam. First of all I would do a full test a few days before. And by full test I mean that it is setup exactly the same way as in the online exam. Even if it's the same platform used for the rest of the course 'with some minor changes', as those might make it no longer work. Or some intervening update might have broken it precisely that day. For example, it would be somewhat riskier than other to plan an important exam the second Wednesday of the month (Microsoft release Windows updates the second Tuesday).
Also, the user may not have been able to test the platform on its own. They may not be able to log in to a room like the one that will be used. The program could crash when talking with other people. It might work for them except when there are many people connected at the same time. They may not be aware that their microphone is not functioning/too low without someone at the other end.
It is also very important to make crystal clear what they should be expecting, e.g. the instructor will be sharing a screen and explaining orally what you must do. You must be viewing their screen, you must hear their instructions, your microphone must work (it will be tested when doing roll call at the beginning) and you shall share your desktop; and what they need to do if any of them fails even in the slightest way, such as calling xxxxxxxxxxx where HelpDesk (or some TA/instructors) will be ready to help them.
Some issues will be simple helpdesk calls (tell the user how to unmute/change volume, describe where button X in the new interface is located), others will depend on external factors such as their connection, and other will be even driver related such as the hardware not being detected properly (no microphone listed, sharing produces a blank screen...) up to completely head-scratching issues.
As an instructor such service serves a double purpose: (a) it helps fixing the minor problems (b) documents the existence of the error. A student that calls you in the first 5 minutes is likely to have a genuine problem. Whereas one that only tells you about that a week later would be met with more suspicion. You will need to actively request errors to be reported, though. You may also want to include it in the exam as 0-point "feedback/suggestions" question (or one showed after finishing). Even if they weren't much affected, you might find things to polish/improve (e.g. setting deadlines of 23:59 rather than 00:00 really improve usability, with almost zero effort. But you need to realize the problem caused by the software showing / users noticing only the day it must be turned in).
Plus, it actually provides a better service and helps the students be more confident in that the technology won't ruin their exam. Then, with more data you will be able to make a better decision. Or even accommodate for the issue on-the-fly (such as having the user joined by phone).
What you definitely don't want is to discover when the exam is about to finish that several students were unable to view the instructor screen [where needed data was provided] during the exam, as they were joining via web interface -the screen only showing on the native app- since the app wasn't opening the room for them!
Even when having two identical installs, on identical hardware, you may find one user is unable to perform an action (such as sharing the screen) which works perfectly for the other. Computers are that funny.
PS: You suggest "allowing to re-take a new exam but have students share their screens" but (a) I don't think that will really avoid someone determined to cheat and (b) if it does help keeping people honest for the exams you do, that should already be happening in the original exam. Another interesting possibility would be to allow an optional re-take for everyone.
I have been teaching online for many years and used many LMS versions. In my experience, all of the mainstream systems, Blackboard, Canvas, Moodle, ... and even the older versions like WebCT and eCollege are supported via the use of a commercial quality database system. I wrote this because it has also been my experience that systematic technology problems and errors are captured in the data logs.
The result is a record that can be accessed via the system administrators, which a school could utilize to confirm widespread issues. More important though would be that any mainstream system would have online technical support that would also be used to verify and head of any issues. All that said, I don't recall ever having to check the logs or even help desk records for a systematic failure.
There is always the occasional technology issue, and the best policy is a preemptive one. In other words, plan for the event, create a policy, stick to it, and update it when necessity forces the change. Along with the policy, create a well thought-out support system with processes for the issue during testing.
Finally, in my experience, project-based learning is the best of all solutions (a subset of problem-based learning), where testing is not relied on to measure achievement, but learners are required to demonstrate real-world solutions to actual problems.
