A Few Key Pain Points with Checkpoints

mwolfenstein
Community Participant
a week ago

Hello All,

I've seen a lot of feedback both in this user group and on the update posts about expand/collapse and preferences as well as rubrics, but there are a few other issues I've run into with how checkpoints have been implemented that I wanted to surface at this stage. I know that some of these resonate with many or even most of my faculty members (I'm a Distance Education Coordinator), and I hope that you collectively (the community) find this useful and that the dev team finds some actionable elements in this.

OP Replies to Replies In A Thread Need to Count

At current, if the original poster (OP) student replies to a reply within the thread that they started it appears as though it doesn't count as participation for additional replies. I recognize that sentence is a nightmare to read, but I figure that this particular user group can parse it well enough. The bottom line here is that if I have a student reply to my prompt and then I or another student replies to them, I specifically want to give credit to the OP for continuing the conversation. It is in fact exactly the kind of behavior that we aspire to have in course discussions when we talk about them being authentic or deep. This is the main point that my faculty have resonated with when I've told them about why they should be judicious in deploying this feature.

There Is A Use Case for Not Requiring An Initial Reply

This one follows directly on the prior issue. Although it's not quite as resonant for my faculty in conversations so far, that's mostly because a lot of my faculty haven't come to the conclusion that the post once/reply twice formula is a design choice that tends to create soulless discussions where students will usually at best satisfice. The bottom line here is that live discussions in a classroom basically never involve every student being required to say something original before getting to react and reply to other voices in the classroom discourse. This doesn't mean that there are never use cases for requiring the initial post first, but there are a goodly number of my faculty who have arrived at this conclusion. Additionally, when you require students to post first before replying (and to limit their access to other replies), you are definitely creating a dynamic that incentivizes them turning to LLM AI. All of this is to say that there are use cases where checkpoints still make sense (you want everyone to re-engage the discussion later in the week or the next week), but you don't want the arbitrary soul deadening structure of must post to see responses, then reply twice.

There Is A Use Case for Counting Subsequent Posts After a Date

This is closely related to both of the prior issues. There are circumstances where I don't care whether a student is replying to another student or starting a fresh thread, I just care that they're returning to participate in the discussion after a certain amount of time has passed. I suspect that this is a far less frequent use case for faculty in general, but if you're going to take a look at how student participation in discussions is credited in a more expansive way rather than coding the most restrictive course discussions approach into the model, then it would be beneficial to think more broadly about the milestones in terms of participation dates in the discussion at large without tethering them to posts and replies.

There Is A Use Case for More Than One Checkpoint

This is probably the least common need, but it's one that I would like to see accounted for. It goes with the same philosophy as the other two features above all of which rest on giving faculty more options about how they want students to engage in the discussion. Yes, it will make the UI for creating checkpointed discussions more complex, but rather than assuming that faculty are not going to be able to pick up a more sophisticated UI, I think it's worth exploring how a UI that can be expanded to give more options can meet the needs of faculty who want to make asynchronous learning experiences better and deeper. All of this is to say that there are contexts where a faculty member may want students to return to a discussion more than one additional time, and if the tool doesn't provide that capability, it restricts not only what faculty can do but what they can envision.

Nobody I've Talked To Likes the Student Module View of Checkpoints

Obviously this is anecdotal, but at this point every faculty member who I've shown the student view of a checkpointed discussion in modules has been non-plused. The fact that it creates non-clickable elements in the module that just make modules longer is a huge turn-off. The bare minimum approach to improving the UI would be an element on the checkpointed discussion item in the module showing that it is checkpointed. The ask I'd love to see instead is that faculty could choose to have the checkpointed discussion either appear as a single item in the module with a checkpoint indicator, or that it could create clearly marked clickable module elements for each checkpoint so that faculty could place these in sequence within one module or across multiple modules for those use cases where students are expected to do other activities prior to returning to the discussion to re-engage with it. Ideally, in this latter case students could actually be locked out of engaging in the next checkpoint. In other words, students must do their initial interaction during one time period, and the faculty member could choose to have that initial interaction close out and have a different set of dates for that discussion to re-open for additional posting. I know this would be a big ask, but it's the kind of approach that would allow faculty to do much more progressive instructional design with asynchronous learning.

2 people also had this question