Showing results for 
Show  only  | Search instead for 
Did you mean: 
Community Member

Discussion Multiple Due Dates Not What I Hoped...

Jump to solution

When I first heard that Canvas would *finally* add multiple due dates to discussions, I was hoping it'd solve a huge problem I have in my classes, and that I know from talking to fellow faculty members is a common pain point.

What we had *hoped* we'd get is the ability to set more than one due date to a discussion post. We want to be able to say that students have to post at least twice: the first time by one date, and the second by a date a few days later. 

Instead it appears that we're getting a feature that lets us assign one due date to one subgroup of students, and a different date to another subgroup? I'm not going to claim that there aren't faculty that will find this implementation useful, but is there any hope for getting the feature described above?

1 Solution

Thank you all for your feedback! Since current functionality allows more than one due date for different students, sections, or groups of students, we have been referring to the new feature (currently in discovery) as "Checkpoints." This feature is intended to work as you described: one due date for initial replies to the Discussion topic and a separate due date for the response(s). I hope this helps! 

View solution in original post

15 Replies
Community Member

I would very much like to see this. 

First Due Date: Students make Primary Response to the topic.

Second Due Date: Students respond to another student's primary response.

And thus, a conversation is born. And graded. Boom*

*RiP John Madden.

I like this idea too:


First Due Date: Students make a Primary Response to the topic.

Second Due Date: Students respond to another student's primary response.

Community Champion

Thank you both for voicing this feedback. I will add that our faculty would be expecting the same experience you have described, when they are thinking of having multiple due dates for discussions.

Community Champion

I believe this is the feature request everyone is hoping for:  Multiple Due Dates (checkpoints) for Discussions - Instructure Community



Community Champion

+1 for someone hoping for each student to have multiple due dates: one for the original post and one for the followup. That's what I thought "multiple due dates" meant, so I'm really sad to learn that's NOT what was meant. 

Community Champion

Although, maybe they're coming. This page lists "checkpoints" under the 3rd phase, which is in discovery: 

Community Participant

Is the new "checkpoints" option currently available or if not, when will it be active?

And is it only going to be available if we are using the new Redesign? I would LOVE to have this "checkpoints" feature in the old discussion format (which I continue to use as I opt out of the Discussion Redesign for multiple reasons already under discussion in the Redesign forum).


Thank you all for your feedback! Since current functionality allows more than one due date for different students, sections, or groups of students, we have been referring to the new feature (currently in discovery) as "Checkpoints." This feature is intended to work as you described: one due date for initial replies to the Discussion topic and a separate due date for the response(s). I hope this helps! 

This is not user-friendly. What nearly every teacher utilizing the discussion board needs is ease of use and functionality. A simple update would have been to include a second due date on the same edit page entitled 'Response due date" which a teacher could utilize if they wished. Simple and easy. No need to go through hoops or additional training.

Canvas, please utilize actual teachers in your testing phase. What use are these forums and suggestions if these suggestions are not implemented per the end users' needs?

Community Participant

"Checkpoints" - that would be great!

What does it mean to say this feature is "in discovery"?

Any idea when it will actually be implemented (go live)?
I will look forward to this feature and would find it quite valuable/useful. 

Community Participant

I'm not exactly sure how Instructure handles the Discovery phase, but Discovery is typically a pre-Design phase and Design should be a pre Development phase. What does that translate to? Discovery is the phase in which you do pre-design research, scoping, and planning. This typically includes defining the user group, collecting available quantitative data about the users, doing qualitative research (e.g. interviews, focus groups), and ideally doing both mock-up and prototype testing. Then you can define the scope and develop a product roadmap. In Agile development, you aren't locked into the results of your Discovery phase, because in principle Design involves more user testing, and then ideally you do distinct alpha (incomplete product) and beta (minimum viable product) testing before rolling out the software, and of course you'll continue to not just support but enhance and/or modify the product which is why the term is SaaS (Software as a Service) rather than SaaP (Software as a Product).

The part about what constitutes a minimum viable product can be tricky. This is part of why I posted about the importance of feature parity in this thread. From my perspective, even a product in beta that's a replacement or improvement needs to have feature parity with all of the features you're planning on keeping. If it doesn't your users are going to be confused and angry that the product is being made available for use in their actual work. It's also worth noting that although beta testing can be public or private, it's really not supposed to be the same thing as going live in the production environment (e.g. where the users are doing there real work). In the context of things like productivity software and educational software, the stakes are way too high to roll out applications that are incomplete or aren't well tested for public use. In entertainment software your product can fail and you can get a lot of angry reviews, but in software people use to work and learn, the consequences of the software not doing what it needs to do for the users is a lot higher. Sure, it's not as bad as the potential life and death consequences of incomplete or buggy software in the healthcare or defense sectors, but it's still going to have consequences that are much greater than just angry users.

This isn't "Solved" yet, and won't be until "Checkpoints" are released, right? At this point, the "Solution" = "we recognize that this has been asked for since 2015, but we're only making promises, putting it in timelines (Phase 3), and then delaying timelines." 

When can we expect this? Please give us a date rather than a phase.

Sorry if this sounds a bit snarky. I just feel like it's been a bait and switch (now we're getting anonymous discussions instead?) for the past 7 years...

(P.S. Anonymous Discussions are needed, but not as badly as checkpoints, imho)

New Member

I would like that feature too. I did find a small work around by creating another “assignment” with the same name ( e.g., discussion week 5 - follow up posts due) and putting the second due date in there. It shows up as a due date in the calendar but obviously doesn’t have any submission.  Hope this helps a little

Community Champion

Still dreaming of Checkpoints to be released. I *love* the idea of it being implemented in the old Discussions because I agree that the Discussions Redesign version is functionally worse than the "Coke Classic" version.

Community Participant

There's been some effort to address this through communication (which I appreciate), but I think there was a lot of confusion on this because the Discussions Redesign was made available with a few key features not having parity with current Discussions. This feature is a pretty prime example.

I would just like to offer, for future reference, that based on my experience with this redesign, assignment enhancements, and New Quizzes/, it's problematic for the community to have a feature option that can be turned on in a live course when it lacks parity with core functions of the feature that it's replacing. Let me break this down with some considerations of the big 3:

  • New Quizzes/ The list is really quite long of features that didn't work at some point in the process when campuses were being encouraged to turn this on. The biggest problem by far has been with banks and groups not being ready for import from Classic, but even something like matching questions not having feature parity for grading was a huge issue for many of my faculty until it was finally fixed.
  • Assignment Enhancements: As things stand, if I were to choose to make this option available for my faculty it would create a totally different UI for students depending on the type of assignment. It's a great UI improvement, but we're not turning it on unless it includes group assignments and peer reviews because providing a consistent experience to our students is really important to us. With this one, I at least felt like there was very clear communication about why I wouldn't want to turn it on.
  • Discussions Redesign: Obviously there's this thread. Beyond that and without getting into the "focused" 1 reply debacle, this feature redesign rolled out without the next/back buttons which is one of the most essential/core functions of Canvas. It's clearly deeply ingrained in the product design philosophy which puts modules at the center. Having those buttons is essential for the new feature to work within the way that every teacher/designer who is trying to create a clear/intelligible path through their course does design for their students. I will add that at least the messaging about this product was much more cautious that what I remember with quizzes.

I know in theWhat is the feature development process for Instructure products? post it states that, "For Canvas, all features are available for testing in the Beta environment unless otherwise noted. The beta environment allows users to explore new features without affecting their live data." but, there are a few problems here:

  • Most users who might want to try features don't have access to beta instances.
  • Features like the Discussions Redesign don't actually test well in beta where most of us have a very  limited number of users with access.
  • Most importantly: The way Feature Options works isn't limited to beta, so if you choose to enable a feature option, you're turning on something that is incomplete for potential use by your whole population, or at least a section of it.

I understand that Canvas is taking a very Agile approach to product development, but I find that the specific implementation of Agile feels like a mismatch with user needs. We're talking about the LMS with the largest share of the global market rather than the scrappy ed tech start-up company Instructure once was. In that context, users need stability in the product, and if there's a new version of a feature that can be turned on, it needs to at the very least have parity with the feature it's replacing. Otherwise, it's a really bad idea for us to turn it on because we can't reasonably help test it without essentially compromising the learning experience and outcomes for our learners. In some instances, those learners are paying a lot of money for the learning experience. In other instances, it's deeply tied to equity in the populations that our institutions are serving. In all instances, it touches on the users' time (admins, faculty, designers, and students) which is the most valuable resource any of us have.

I respect the intention behind how the Agile design process is implemented for the Canvas product, and please believe me when I say that I understand how SaaS is different from old school SaaP development, and why Agile is the right fit. I just think that given the scale of the product, it's absolutely essential that a Feature Option is at the very least in full parity with all of the features users expect in relation to the feature it's replacing.

Without ensuring that's the case, it feels like the product is being rushed out in an incomplete state, and this leads to a whole lot of unnecessary user frustration. Speaking personally, I'd be much happier seeing videos released of incomplete features in development and literally only having those feature available in beta and being tested with groups that aren't live classrooms, than I am with the current approach. Then once those features have full parity with the feature they're replacing, roll them out at scale and we'll understand if there are still some bugs as long as they don't mess with students' submission process or grades.

Just to end on a positive note, I can point to the new RCE, Gradebook, and Analystics as great examples of this. By the time they were really being promoted, they were feature complete and had a lot of great improvements. There were a few fixes they still needed, and there are ways that I certainly hope they will both be extended, but they all stand as really successful examples of Instructure rolling out a product improvement to a core functionality without making an incomplete feature available that can lead to user frustration.

Thank you for coming to my TED Talk 😝