Discussion Thread

[hsiangju_lien]

Hello,

Is there any way to highlight the instructor's name in the discussion thread? So far, I have tried to implement the following JS codes, but it highlights the names of all authors in the discussion page. Any suggestions would be greatly appreciated.

if($.inArray('teacher',ENV['current_user_roles']) === 2 ) {
      $('a.author').css("background-color", "yellow");
}‍‍‍‍‍‍

[themidiman]

If you're trying to exclude the student posts, you will need to adjust your jQuery expression to something like this (using the .not() selector😞

$(".author").not(".student_context_card_trigger").css("background-color", "yellow");‍‍‍‍

Also, are you only trying to target the role of instructor for this behavior, or all roles? Just curious why your logic is restricting it to that particular role?

Hope that helps.

[hsiangju_lien]

Thanks for your great help, Jeffrey.

No, I am not trying to exclude the student posts. I am trying to find a way to highlight only the instructor's name in all of the discussion threads so that students could tell if a discussion post is from the instructor or not. In this way, it is also easier for the instructor to see his/her post in a discussion.

Thanks again for any suggestions.

[themidiman]

The way the Instructure CSS/DOM is specified should then allow you to use that earlier expression just by itself then. No if-statement is necessary as the ENV variable provided by the instructure JavaScript is targeting the current environment in the browser.  Your original code in your statement was only going to show the highlighted instructor names for only the instructor. Students would not see the highlight changes if you leave that if-statement in there. 

$(".author").not(".student_context_card_trigger").css("background-color", "yellow");‍

Try pasting this in the developer console of your favorite browser and see if it doesn't do what you were intending to do. 

Note that you will have to do a fair bit of testing each beta release to be sure this CSS class name of .student_context_card_trigger hasn't changed to something else for that release. If so, this jQuery selector expression will break. 

[hsiangju_lien]

Thank you so much for your great help, Jeffrey.

I just tested it in the developer console, and it is working for highlighting the name of the instructor in the discussion thread. Nevertheless, the names of students who dropped the class are also highlighted; is there a way to exclude these students?

Moreover, after inserting this line of code into JS file and uploaded the file to apply it in the courses, the instructor's name in the discussion thread is not highlighted. Any suggestions would be great.

[themidiman]

I'd have to see if there are some different CSS classes applied to students who have a different status in the course. Our institution deletes students if they've been dropped which takes them completely out of the course roster. What does your institution do for dropped students? Are they classified as inactive for instance? 

You could inspect the CSS for those dropped students yourself using the inspect element feature of Chrome dev tools. 

[hsiangju_lien]

Thanks again for your prompt reply.

Yes, you are right that dropped students are deleted from the course roster. I was testing in an old course and saw some highlights besides of the instructor's name, and these students are not in the course roster.

I just inspected the CSS for the dropped students in Chrome, but I only saw the .author class for them. They do not have the .student_context_card_trigger class, so it makes sense that their existing discussion posts are highlighted.

[themidiman]

I forgot to mention, that you will want to put your jQuery customization inside a $(document).ready function block like so:

//Only executes after the entire DOM is ready
$(document).ready(function() {
    $(".author").not(".student_context_card_trigger").css("background-color","yellow");
});‍‍‍‍‍‍‍‍

[hsiangju_lien]

Thanks for reminding. Yes, I did put the jQuery customization inside the $(document).ready function block as suggested. Nevertheless, once uploading the JS file with this, the highlight is not applied to the instructor's name. It is working in the developer console though. Any suggestions would be greatly appreciated.

[themidiman]

Hmm, maybe a delayed execution is necessary then? 

Window setTimeout() Method 

Not sure how many seconds to apply here, though. I would experiment to find the minimum threshold. 

[hsiangju_lien]

Thanks a lot, Jeffrey, for your great help on this. Using the setTimeout() method makes it work now.

[themidiman]

Fabulous. Just curious how many milliseconds you put in your delay? That might help others who want to do this. 

I was also going to suggest putting in additional rules in your institution's custom CSS theme file and use the :not selector there. 

[hsiangju_lien]

Sure. I put 100 milliseconds for the delay.

It seems great if having additional rules in the custom CSS file with the selector. Would it make it work better?

[themidiman · Accepted solution]

I experimented with this in our test environment:

.author:not(.student_context_card_trigger) {
     background-color:#ffff00;
}‍‍‍

Alas, it will also highlight dropped students too. If only Instructure would give the instructor role author a separate CSS class, or actually even better tag the post itself with a badge of some sort. That would absolve the need to hack the CSS and JS code altogether.

[hsiangju_lien]

Thank you so much for your great help, Jeffrey. It is working in our test environment. It would be better to have a separate CSS class as you suggested, but for now, it could be beneficial for our students and instructors to identify the post within a long discussion thread.

[James]

Interesting conversation here. I'm working on a Canvancement that will allow someone to click in the header area of a discussion and it will highlight all of the posts from that user, optionally using different colors to indicate the nesting level of the post. At the time, I noticed that teachers are handled differently than students.

In the latest issue (timing), I would advocate against using setTimer and going with Mutation Observers instead. That way when the document changes you can react, rather than having to sit there and continually poll waiting for changes.

[themidiman]

Having not had experience with Mutation Observers and just now researching, what DOM element would you think would work to observe to achieve the same effect that the originator of this question is/was pursuing? It seems like discussion_container would be a good candidate. That would be interesting to see.

Be as it may, I'm wondering if the discussion had a particularly long thread with several posts made by the instructor user. I can't recall if the entire discussion thread DOM loads in the browser when the topic is first accessed or if gets loaded in stages as the user scrolls. So...if the JavaScript method/solution I proposed first in this topic would leave out the later posts as the user scrolled down the page and loaded more of the thread. The CSS method would take care of it immediately I would think. But if the DOM doesn't change at all during the same user page request, then why use Mutation Observers at all?

Either way, the lack of a specific CSS class for the role of instructor prevents it being accurate in the first place as the .author class is the only class applied in the DOM for dropped students. The best case scenario is to have a CSS class such as .instructor added to the DOM element, but it's not there yet until a feature request adds it in. By that time maybe Instructure would have done this themselves similar to how they've applied a visual MISSING or LATE tag to certain views of the student grades and assignment submissions in the latest beta release notes as of 7/24/2017. 

[James]

I used the div with id = discussion_subentries. In my testing, all of the entries were posted at the same time, so it wasn't even necessary to check what was in the mutations, just that it happened.

Here's the relevant portion of my code

var subentries = document.getElementById('discussion_subentries');
if (subentries) {
  var observer = new MutationObserver(function() {
    // Threads are loaded once you get here, so do your stuff
    // Done doing your stuff
    observer.disconnect();
  });
observer.observe(subentries, { 'childList' : true });
}‍‍‍‍‍‍‍‍‍

I have gotten bitten if I try to disconnect before I've done my stuff, but if you want to future-proof, you could not disconnect and keep listening for changes. 

The childList part just looks for adding/removing nodes, not changing attributes (like showing or hiding) on existing elements. I did not include subtree because it was an immediate child of div#discussion_subentries.  In general, you want to find the nearest parent that is there in the initial page load (Ctrl-U to view source, not the DOM inspector). If it's not an immediate parent, you need to include the subtree.  

You can also attach event listeners in a similar way. I didn't show it above, but I added an event listener to the subentries element instead of to every single discussion thread. When I was talking to an Instructure engineer after Project Khaki, he told me there wasn't a problem with doing it to each element, but the current JavaScript recommendation is to put one at the top and then look at the target to see where they clicked. I was also able to do that before the MutationObserver since I wasn't attaching them to the threads.

Another note that isn't illustrated in my code above -- there is a chance that your element might already exist, so you should check for it before you load the mutation observer. If it's something that gets loaded through pagination (like the People course roster page), then you need to run your code on what is there but also look for additional information to come in (don't use the disconnect).

That may need to change for what you need, but that's what I used for my current discussion project.

If you need to look at the mutation events to look for something specific, then pass mutations as a parameter to the anonymous function inside the observer. Then do a mutations.forEach)function(mutation){}); to iterate over them.

If you want to look at what I've done with MutationObservers with Canvas, you can look at my Canvancement GitHub repository and search for MutationObserver. I can't guarantee that they're all done right (I may not have checked for the existence before loading the observer).

The specific code I'm talking about here is still in development and not on GitHub yet.

One other note I saw as I paged through this -- my understanding is that the document ready is no longer recommended. As of jQuery 3.0, it's been deprecated, but still works. I know Canvas isn't using that new of a version of jQuery, but it is loading the scripts at the bottom of the HTML page and so the DOM should be ready before it gets executed. Enclosing your code inside a function to not pollute the global variable space is a good idea, so I use an iife. But as you discovered here, the DOM is ready to be used before the discussion item is added to the DOM. That's where the mutation observer comes in. Waiting for the document to have loaded, which means waiting for all of the images and scripts to load as well, doesn't always work (and sometimes needlessly slows things down) because the Canvas JavaScript has loaded, but then makes additional AJAX calls that aren't picked up by that.

I imagine many JavaScript programmers use document ready and timers because that's what they've always done. Those people are probably much more skilled than I am as I haven't been programming in JavaScript for very long (couple of years) and taught myself by researching how to do things (spending a lot of time on StackOverflow and then finding the right way to do it from Mozilla Developer Network). But one of the side benefits is that I don't have old JavaScript habits (just those from all the other programming languages I've used that influence how I write JS).