|
[
Permlink
| « Hide
]
Lance Speelmon added a comment - 29-Jul-2007 08:58
This is by design to support pedagogical use cases where the instructor wants to ensure the student reads a posting. We know this is different than your run-of-the-mill forums application - I am not sure how to respond to this request. Let me have an instructional technologist take a look and provide some input. Thanks, L
David,
Could you please weigh in on this change request? Thanks, L I see what you're saying.
Of course, we can't mark it as read when the full set of messages display (otherwise you wouldn't know which ones were unread). One could perhaps compromise by taking further advantage of the "Mark as Read" permission (which currently if checked means to show the "Display Entire Message" command and allow users to "Mark All as Read" by clicking on the "Mark All as Read" command). If Mark All as Read is allowed, then auto-marking of a fully-displayed set of messages could be supported. If so, the question is when to auto-mark all of them as read? When they click to reply on one of the messages? (No) When they click to post a new Thread? (No) Perhaps when they click on previous/next topic or in the breadcrumb list, or when they refresh the tool? (Possibly) But not all use cases infer that the full list of messages has been read. For example, if one is scanning for a prior message but still doesn't have time to look at all the new ones, it would falsely mark messages as read when, intentionally, they haven't been. So, Perhaps when they click on one of those (previous/next, breadcrumb, refresh), instead of auto-marking everything as read, they could be prompted, "Do you want to mark all as read? Yes/No". It would prevent false markings, but likely would irritate users to always be getting that message when there remain unread messages. In the end, it a trade off... either avoid false positives (and assume lists of messages have been read) or avoid false negatives (and assume messages are unread unless seen individually, marked individually, or selected "mark all as read". It's a close call, but I'd suggest avoiding false positives, and leave it as is instead of always assuming that everything is read or always asking to confirm that everything has been read. The once exception is when the thread is a single message (and has no additional postings or replies), then when one clicks on the thread, you've seen the thing in its entirety. But when there are multiple postings and replies, can it be assumed that everything has been glanced at? In email (perhaps not the best comparison), though I can see previews of messages, the system doesn't mark them as read until the individual message has been shown in isolation or shown in the viewing panel. In Forums, the Display Entire Message has a primary purpose as a convenience for scanning and printing full sets of postings. In class settings, many faculty want intentional reading, and don't want students to merely scan and get credit for having read. The compromise was to have "Mark All as Read" as an optional permission and still require an intentional acting of marking as read even if it is only clicking a command to mark all as read. Just a quick response before I head off on vacation for two weeks - D After playing with the behavior of "mark as read" and the new envelope Icon, I have a few points to add:
Clicking the envelope makes it disapear, but does not provide any confirmation that the message is now marked as read, save for the envelope icon disapearing. Additionally, the unread count does not update after the envelope has been clicked and only changes once you navigate away from the tool and then back to it. Secondly, the messages tool does not have this envelope icon and exhibits a similar problem. The mark as read link for this tool does not appear to do anything, but the synoptic tool counts are updated when the mark as read link is used. Both of these instances are pretty significant usability issues concerning appropriate feedback and also consistency between tools. This is becoming an acute issue locally. Users do not see the 'Mark all as read' link at the top, and assume they have to click every item to make it read. In practice, this means the read/unread distinction becomes useless for them, leading to significant dissatisfaction and users abandoning Forums (i.e. stopping to read Forum postings because it's too hard to find the new messages).
I would like to suggest that if there are use cases that require the current behaviour that are important to some institutions, then there should be a configurable setting, so that it's possible to make it work as suggested (displaying the full text of one or more messages, i.e. in topic or thread view, marks them as read) while institutions that want to follow another practice can continue to do so. Bump...our faculty have been commenting/complaining about this issue as well and are requesting that there can be some sort of setting toggle that can enable an "automark as read" behavior (i.e. when replying to or clicking on a thread subject)
The faculty at our institution would also like to see something like this. A toggle per site (or forum perhaps) to preserve the original behavior would be ideal. Has any work been done on this so far?
We'd be happy to spend some of our development cycles helping get this implemented. Lance, is there anyone at Indiana actively working on this issue? If not, it sounds like Matt would be willing to take it on. How about if he works up a patch to contribute here, and then works with you or someone on your team to review it and get it merged in to trunk, if its appropriate? Thanks.
No - the current design was intentional so that instructors know if students are reading posts. The suggested change does not support the pedagogy around requiring students to read forum posts. L
I think the pedagogy case around the current design is arguable. The current behaviour annoys students, and leads to the 'read posts' count getting undercounted because people don't mark posts as read that they've actually read. The statistics are also mostly unusable for instructors because they're too slow (a related JIRA).
Irrespective of that, there is strong support in the community to change this behaviour, so +1 for a (default) option to support more standard behaviour. I agree with Stephen M's comment above. The statistics page in Forums is pretty much unusable with a reasonably large number of users in a site (reported here:
An configuration option sounds like a good solution here. I would suggest the new behaviour as the default as well.
Users these days are getting more and more used to forums/bulletin boards/message boards/news readers/etc. that behave somewhat automatically in terms of marking what you have viewable on the screen as read after a certain time period, rather than having to manually flag it. Some good examples to look at are Google Reader, Outlook with its preview pane. If anyone has time to take this solution in that direction, I think it would be a better long-term solution and one that could be applied elsewhere in Sakai to the read/unread issues. My intention was to incorporate Steve Swinsburg's suggestion of including a toggle per forum which would turn on and off the automatic read functionality. Also, I intended to include a sakai.properties setting configurable at the institution level, forums.autoMarkAsRead (or something like that), that would allow institutions to override the default behavior where students manually mark messages as read. This would preserve existing functionality while allowing institutions to override it with a minor amount of work.
Well, we think we've got it working pretty well. I deployed it in a dev environment and had our designer walk through it to see if we could find any obvious bugs and we think it's in good shape so I wanted to submit my work to the community to get more feedback. I created a single diff file of all of the updates we made and included it as autoMarkThreads.diff If you want me to break it down further just let me know.
I also added two sql files (SAK-10869-mysql.sql and SAK-10869-oracle.sql) which contain the sql queries to update the MFR tables and add a column to track the Auto Mark Threads Read feature. I haven't run those queries exactly as they are in the file, but those are the commands I ran at one time or another in the development process to update our tables, if you find any bugs let me know. And finally, the sakai property which will control the default setting for the Auto Mark Threads Read feature when creating a new forum tool in a site is msgcntr.forums.default.auto.mark.threads.read. It is expecting a boolean (true or false) and if the property is not specified or an invalid value is given, it should default to false. Let me know what you think, and if you have any comments, suggestions, etc please just send them my way. Hi Matt
Thanks for the patch, had a look at it and found 1 bug and one problem: 1) When you view a thread the entire topic is marked as read rather than the thread 2) The messages are marked as read before being rendered. So if a user clicked on a long thread with some read and some unread messages, they wont be able to see which ones they have read. Idealy they should be marked at the end of the render cycle (not sure how one does that in JSF) Also if you want to switch views in the thread view page from Thread to Unread, everything is read so there's nothing to see.
The only way to handle that if messages are auto marked as read would seem to be ajax controls, i.e. re-display the page sorted accordingly without a server-side refresh. Noting that UCT plans to address this task for 2.7.
Thank you very much for the feedback and especially for catching the bug where all threads in a topic were being marked as read. I re-examined my changes, found where I made the mistake, and will post new diffs.
Now, about displaying messages that were unread at the time that the thread was opened. When I wrote the code, I added two calls, one to persist the message as read and one to mark the message object that was going to be displayed as read. If I remove the second call, (line 1740 in the new DiscussionForumTool), the message will be marked as read in the database but displayed as unread. This will also allow the view page to be switched from Thread to Unread and work!! Now, I originally added that second call because I was uncomfortable displaying messages as unread when they were actually marked in the database as read. As I see it, I could remove that call and the messages would display as unread even though they are read. Or, we could change the way the JSP so that instead of read and unread options for messages, we have read, unread, and ...... pending??? (I don't think pending is the right word but you know what I mean). Or we could leave it as is and try to do this in an ajaxian mode somewhere down the road. What do you think? OK, I renamed the original diff to autoMarkThreads-attempt-1.diff and uploaded two new diff files to use to install this, autoMarkThreads.diff and DiscussionForumTool.diff. You should use the latter two files to get this working on your installation.
We just discovered a bug that the work I did introduced into this tool while duplicating sites. Essentially there is a not null constraint on the new automarkthreadsread value and while duplicating a site we were not setting the value to a default. I'm attaching a new patch which should be installed as well, it adds I think three lines of code and is pretty straightforward. If you have any questions, holla back!
Assigning this back to IU as UCT is not actively working on incorporating this feature into our branch at present.
Matt, any chance this can be rolled into one patch?
Um... I think this should do it. I had to do a little manual cutting and pasting but this will work. It also includes two bug fixes that we applied to our trunk later that were a direct result of this auto mark functionality.
Bug 1: Forums in new courses were not loading properly because the auto mark value was not being set. Bug 2: Importing content from Forums was missing the topics and messages I hope this works for you, just let me know if you have any questions. Thanks for the latest all-in-one patch Matt. I re-rolled your patch to remove a couple of items related to grading, made tabs/spaces consistent with each file, and removed a couple of extra deletions to present a clean patch for the developers.
Devs, any chance of picking this patch up? This patch does not modify the default behavior of the Forums tool. It simply adds a new feature, defaulted to false, that allows instructors to change the default behavior to mark all items as read when reading them on one page. Patch should apply cleanly to latest 2.6 branch. I would be glad to re-roll for trunk if interested. What I think I see here:
- UCT has a Vula branch, which I assume meets their concern - Separately, there is a patch from Matt and Sam. It's not clear where the behavior of this solution may differ with that of the Vula branch - IU mainly wants the option for things to behave in the UX more or less as they are If this is to be considered for 2.7, it's not clear which route to go, and it sounds like further discussion is called for, both to find consensus on a solution and figure out who can support it during QA. Correct me where I've missed something. We don't currently have this in our Vula branch. IIRC we backed it out later because of functionality issues (possibly corrected in the later patches here).
Hi Clay,
The patch I re-rolled was based off of Matt's work. The re-rolled patch cleaned up spacing/tabs issues and removed a bit of extra code related to local modifications. The re-rolled patch (msgcntr-forum-read-all.patch) defaults the new behavior to false and should meet the IU requirement of not altering existing behavior. If there is continued interest, I am glad to re-roll against trunk and am happy to test. A couple more questions about the patch, Sam and Matt.
Where/How is the instructor option represented in the UI? Also, it sounds to me like the choice to have the behavior defaulted to false and have the instructors turn it on would not really meet UCT's concerns. Could the patch be extended to include a sakai.property which allowed it to default to true, to be set as a matter of institutional configuration? The way I set it up, Instructors can modify the setting at each level in the Forums tool (Default Settings Template, Forum, and/or Topic). I've attached a screenshot of what the option looks like in the new/edit Forum page.
I also wrote in a sakai property initially which would allow the institution to override the default behavior. For us, we have it set to true so, by default, new courses will automatically mark the threads as read. The setting is: msgcntr.forums.default.auto.mark.threads.read I hope that helps, and if you have any other questions, just let me know. Matt et al,
I am working on merging this jira into msgcntr trunk for the msgcntr release and have been running into an error with caused by: java.lang.NullPointerException at org.sakaiproject.tool.messageforums.ui.DiscussionForumBean.getAutoMarkThreadsRead(DiscussionForumBean.java:217) I believe this may be caused from something to do with the default setting of the value for AutoMarkThreadsRead. This error is thrown when I try to create a new Forum (works fine when I try to create a new Topic) and when I try to edit an existing Forum (also works fine for editing topics). When I set the value for this column in an existing forum via an SQL update, the error doesn't get thrown when trying to edit a forum. I've attached the diff for what I have merged in locally for testing. I had a few issues, but I believe I worked through them alright. Does this error sound familiar? Did I miss something? Thanks, Bryan Matt et al,
Nevermind, looks like the SQL scripts you added takes care of this. I got it to work. Thanks. Bryan applied patch and committed it to msgcntr trunk.
r69060 Didn't mark this as resolved since the mark all as read doesn't seem to work when a user click "Display Entire Message". I would think it should mark all messages as since all the threads and their messages display when the user is taken to this page. Is this something that got lost in the patch I applied? Thanks Bryan Matt,
It sounds like, from previous comments above, that this option was at least discussed, if not agreed upon. I was just double checking that the patch I applied was applied correctly. I am marking this as resolved. If someone watching this has a different opinion, then they can speak up. Thanks, Bryan Is there supposed to be two different sakai properties?
msgcntr.forums.default.auto.mark.threads.read msgcntr.forums.auto.mark.threads.read The first one is referred to by AreaManagerImpl.java and the second one is referred to by MessageForumsForumManagerImpl.java In any case, it only matters what the Area setting is set to. And once an area has been created (the forum tool has been added), the particular default is set to whatever it is. The default doesn't get changed, even with a restart and a change of the property value, since the DiscussionForumBean is passed in a new forum object, who's settings are set to the default values of the area for AutoMarkThreadsRead, as seen at line 997 in DiscussionForumTool. Thanks, Bryan Does not seem in 2.7.x to me
No, the one in MessageForumsForumManagerImpl is definitely a typo, thanks for catching it. Although reading through your comment, it looks like we can eliminate the call in MessageForums.... completely, am I reading that right? It would explain why the typo never caused our institution any trouble. If so, go ahead and delete it, or I'll submit a patch if you'd prefer. Just let me know.
Also, we have a lot of watchers on this issue, so I thought I'd try and get a quick poll, what does everyone here think about marking the threads read if a user clicks Display Entire Message and the thread is flagged as auto.mark.threads.read == true? Is that behavior something the community would like to see?
Reopening because of the typo.
> Is that behavior something the community would like to see?
Matt, I'll be honest, I don't entirely understand the "Display Entire Message" terminology. I am testing on latest trunk code, and I see "Display Entire Message" when I am viewing the various threads associated with a topic (dfAllMessages.jsp). "Display Entire Message" seems like it is really "Display all messages in all threads"... If so, by default, I don't think that functionality should mark all messages as read. That said, I expect many others will want the messages marked as read. Matt,
>Although reading through your comment, it looks like we can eliminate the call in MessageForums.... completely, am I reading that right? What I'm thrown off by is line 997 in DiscussionForumTool: forum.setAutoMarkThreadsRead(areaManager.getDiscusionArea().getAutoMarkThreadsRead()) Here you are setting the default property value to whatever the area is saved as. I would think that you would leave the default value of the forum to what the sakai.property value is, instead of over writing it with the area value. This way, if the sak.prop ever changes, the tool will pick up on the changes for sites that have already been created. If anything, I would think you could get rid of the AreaManagerImpl reference to AutoMarkThreadsRead completely, or, at very least, remove the over ride at line 997 in DiscussionForumTool. I looked through the code and I couldn't find anywhere that referenced area's AutoMarkThreadsRead property except for line 997 in DiscussionForumTool. What do you think? Thanks, Bryan r69316
I have changed the type in MessageForumsForumManagerImpl. I have also created another jira Sam and Bryan,
Wow, sorry for the long silence, I made the mistake of not answering your 11/19 messages right away and then they just slipped my mind. First, Sam, I actually completely agree with you, I think Display Entire Message is a different function and should be handled with different settings. I will not add the auto-mark as read portion for that unless we hear otherwise. Bryan, my intent with line 997 was simply to set the auto-mark threads read portion at the time of Forum creation. I added the setting to the area because there were already a large number of area settings which instructors could control. Essentially, this allows instructors to create their own default on a class by class basis. My intent was: 1) At the time the area is created, default the area's value to the one in sakai.properties 2) At the time a forum is created, default the forum's value to that specified in the containing area 3) At the time a topic is created, default the topic's value to that specified in the containing forum This allows the instructor to override the default settings at any level of the tool. I think we could have forums get the information from sakai.properties, but then instructors would wonder why there is a value in the forums' settings that is not in the "Template Settings" screen. Thanks Matt. I agree with the reasoning behind this functionality and closed
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Task
Resolved
Critical
Displaying all messages should mark them as read
