Order Discussion Posts from Newest to Oldest

[canvas_admin]

Currently, the discussion posts are ordered from oldest to newest.  A student/professor has to scroll or go to the last page and then scroll to get to the latest post.

Canvas REALLY needs to re-order this so that newest discussion posts appear at the top of the first page so that it is easy to find current conversations.

This topic had 100+ likes in the old community and I was really surprised not to see it on here already (I searched for this using several different search terms).   I sure hope we don't have to go through and re-idea every single feature request that had at least 30 likes and was years old with no action or response from Instructure.

This idea has been developed and deployed to Canvas

For more information, please read through the  Canvas Release Notes (2021-06-19).

[SPARROWR]

Providing the option would be a great tool for users--not everyone would need this, but I know others that would love this feature!

[ejackson]

I agree that faculty should have this option. Some would welcome it with open arms, and some may want to keep it the way it is now. I would love to see them have that choice.

[rgo877]

I agree that this should be an option, not a default.

[cfranklin]

This would help a lot for students who use their phones.  

[peytoncraighill]

If the need is to quickly navigate to unread posts, I think there are several ways we could address this, including an option to sort by newest to oldest posts. We could also potentially direct you to the oldest unread post in a thread, by default, when you revisit a thread that you’ve already visited.

The current design, which sorts by oldest to newest post, was chosen for its consistency with traditional forum design, but this is great feedback to hear.

I’m adding this item to our Discussions backlog, and will include a link to this idea in the description. I’m marking this thread “Archived,” as we don’t have capacity to address it in the short-term, but please continue to post any additional comments.

Thanks for the feedback!

[canvas_admin]

Peyton,

I gotta say, "Aarrrrrrrrrrrrgh" in reading that this is Archived due to lack of capacity to address it in the short-term.   What exactly does that mean? For example, are there 10 more pressing fixes/updates in queue related to Discussions?   I would just appreciate a little more clarity on this since it has quite a number of votes, but is now archived.

[peytoncraighill]

I get your frustration, and I AAARGH with you. There aren’t necessarily 10 more pressing updates to Discussions, but we plan capacity at a platform level due to finite resources. I attach the discussion link to the development story as a reminder of the community’s support for the idea. There’s no plan to get to this in the next few months, which is why it's archived, but it’s not at all forgotten to product planning.

[scottdennis]

Hey  @canvas_admin ​,

I'm not sure if it will be helpful or not but scanning through the comments on this thread it occurs to me that a little info into the development process we employ might be helpful.  With changes coming to production Canvas every three weeks and beta releases and warm fixes coming even more frequently it might appear that we rapidly introduce changes start to finish in a matter of weeks.  Compared to traditional software development models with quarterly or even biannual releases, Canvas is developed rapidly but what isn't easily apparent from the outside is that we have six month development cycles. 

Leading up to a new cycle we unpack all the things that need to be changed or fixed or added and scope them, or estimate how many weeks or hours of development time they will require.  Then we prioritize based on how important individual items are and how much dev time they would cost to implement. 

Community input is important in this process for two reasons.  First, knowing how badly or how many people want something based on votes, comments, etc.  Secondly, and maybe even more importantly because community input helps our product managers and engineers understand not only what but also why users need a given fix or improvement.  So many times I have heard exchanges that go something like this, "That is strange.  Why would someone want Canvas to do that?" Followed by, "Read this comment.  You see in big universities they have a challenge with....."   "Oh!  That makes sense.  Well, we could..."

When you open up a component of the product, say discussions for example, and make changes that entails testing how those changes will affect other aspects of the product and user experience.  Then you have to QA the changes, document them, train and update everyone who uses the product or is customer facing and then all of you have to communicate those changes to your teachers and students.  There are efficiencies inherit in making several changes at one time rather than constantly changing all components with equal frequency - think of someone undergoing more than one major surgical procedure in one operation.

When  @peytoncraighill ​ refers to a story, he is referencing agile software development methodology​ which describes the big picture with this cyclical process.  When the user community suggests an idea and it gets voted up, we look at it, determine whether or now it could fit in between the big goals in the current cycle.  If it is an easy fix (paper cut) or something that could be realistically fit in between larger development projects (is squishable) we try to get it done immediately.  If it is too big for that but is something we think is important, it goes into a holding pattern for consideration in the next cycle.   @peytoncraighill ​ cannot mark this idea as planned or in development because he won't know if it will beat out all the other competing ideas and priorities and earn itself a place in the next cycle or not.  That is why it is marked Archived for now.

I hope that helps you understand what happens internally.

[canvas_admin]

 @scottdennis ​, thank you for taking the time to explain that process.  That at least clears things up for me and helps me understand better what is going on. Somehow I missed the 6 month development cycle part of the process.  I will try to tone down my aggravations from now on.

[scottdennis]

You are very welcome, Mark. 

Part of the reason for having the six month cycle that I didn't explain is that, in addition to prioritizing and planning being labor intensive, having a schedule sort of protects the engineers from being hit by requests from every direction and lets them concentrate on getting work done.