A Few Key Pain Points with Checkpoints

[mwolfenstein]

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.

[jenn_stevens]

These are excellent points that get at really being able to reward the behavior we want to see in async discussion-based classes. I hadn't realized that a reply to a reply wouldn't count for participation, and I agree that this is important behavior that we want to encourage and credit.

[am-bristol11]

I agree they need to be counted as participation!

[hesspe]

Hi Jenn,

The other side of this argument also makes sense to me.  If replies to replies are encouraged, that might place all of the focus of the discussion on a single topic, which could potentially descend into acrimonious or narcissistic debate.  If the second level replies are distributed among first level replies, it seems to me that is less likely to happen.  Without better understanding of the advantages of giving credit for replies to replies, I think I like the existing requirement better.

-Peter

[mwolfenstein]

Hi Peter,

That's an interesting take. Although I've personally never encountered this problem in a course, I could see how it might be a potential issue with some student populations. I would also say that the tone of discussion is something that can often be managed through methods that don't involve technical limits to the platform, much as norms in the physical classroom can serve to prevent acrimonious or narcissistic debate in person (even if it sometimes requires instructor intervention).

Nonetheless, your reply introduces the consideration that different instructional cases might be best served by having this be another option in the discussion UI rather than a feature that is locked one way or the other. I can say for sure that although the current design may work for some, it definitely defeats the purpose for others.

Best,
-Moses

[lshulman]

Peter,

I do have some discussion assignments that require the original poster to respond to replies they receive. These replies are to ask questions regarding or otgerwise challege the initial post. Then the author of the initual post is to respond, answer the questions posed to them and/or defend their position or even acknowledge being swayed by the response they got. Shows they are reading and thinking about what others say about their initial posts.

[hesspe]

This seems to me like sound pedagogy, but I think it could be a very heavy lift to code.  Checkpoints have been on the docket since 2015.  They were originally expected to arrive with the discussion redesign and have been put off and put off.  I believe this is not because the coders are incompetent but because due dates in Canvas are like a climbing vine that reaches into many points in the Canvas system.  At some point in the cost-benefits calculation features that would be beneficial in certain use cases have to be taken off the table. 

[mwolfenstein]

I'd say that there's no doubt some of the features I've mentioned would be a heavier lift to code. I'm not convinced that they should be if one were building a system from scratch, but if there's one thing that the threaded discussions option debacle has evidenced it's that there are aspects of Canvas that might have made sense to build that way back in 2008, but present challenges as legacy code in terms of changes or new features.

More than two due dates is likely a steeper hill to climb and that may well be the case with closing out an opportunity to score points before a checkpoint arrives, but I doubt that if you were considering it from scratch tethering the second due date to replies only was the easiest build. It was of course the build that satisfies what most users were already doing with a data model and interface that reflects that type of activity, but that's separate from whether it was the only or easiest way to build checkpoints. It was stated that one of the reasons that they slowed their roll on checkpoints was because they realized that the feature should be implemented in other assignment types (e.g. peer review). If that is in fact the case, then it should definitely be possible to loosen up the arbitrary restrictions on whether replies to replies count or for that matter whether top level replies are/aren't allowed to count after the checkpoint..

[jenn_stevens]

Hi Peter!

I don't think that replying to replies HAS to descend into narcissistic or acrimonious debate? And if it does, then that's something that would be handled by classroom netiquette policies.

I'm not arguing that it should work that more replies -> more points -> higher grades and that poster's madness will give you a towering pile of internet points - I'm more saying that even though "post once and reply twice" is a cliche, I DO want to see students get credit for meeting the base level of participation, even if they are replying further down the chain or to a commenter on their own post.

Hope you and yours are well!

[CindiKerns]

Agreed. I am especially concerned about replies to replies not being counted. This discourages the exact behavior we are trying to promote!

[gouldt]

This is a little late to the discussion, as it has been implemented. But here is my take. We were looking forward to checkpoints, but it became available the same weekend that the majority of our online courses began. So it could not be enabled prior to the start of class. It would be impossible to implement for this semester. Add to that, now instructors are not able to view the number of replies unless they are using checkpoints, which make it extremely difficult to grade when we require 2-3 replies and 1 initial post. We are looking at disabling it quickly before it upsets too many instructors.

[mwolfenstein]

I was actually considering having us turn it off today (we're in the middle of a short winter term), but some instructors already have discussions set up that use it and if there's one thing I've learned from prior implementations it's that the last thing you want to do is change any kind of setting on an assignment or activity where activity has already taken place. If Instructure doesn't offer a fix before our spring term starts, we will definitely be disabling it during our brief intercession.

[venitk]

@gouldt @mwolfenstein could you please elaborate on what your instructors are seeing? I'm not sure I understand what you mean that they can't see the number of replies unless they're using checkpoints... Do you have it enabled at the account level and if instructors aren't using it at the course level, they can't see ... something? What exactly can't they see?

This will be very helpful as we've been debating whether to turn checkpoints on at the account level, though we don't think it's ready for use at the course level yet.  

[mwolfenstein]

It can only be enabled at the root level and that changes the view in SpeedGrader regardless of whether an instructor is using the checkpoints feature on individual discussions. There is no way to manage it at the course level as a Feature Option. They can't see all of a student's responses at the same time in the new view in SpeedGrader, just one response at a time.

[gouldt]

@venitk Prior to this update when an instructor graded discussions in Speedgrader, when they brought up a student they were able to see this single students initial post and the number of replies to other students. This is important to our grading processes. I am sure there is some kind of logic to the new way of grading discussions, but it will require some training. This feature was implemented the weekend of our online courses beginning. So, no time for that training, and the instructors were unpleasantly surprised. We have already disabled this new feature until we can prepare the instructors for the Speedgrader changes, and prepare the courses to use Checkpoints prior to students being in those courses.

[RonniTyger]

I have asked our IT folks to reach out to our Success Manager to turn on Checkpoints. Is this the way to go? I appreciate the key pain points and will be on the lookout for those when we start using this feature.