Guide to Threads
Threads
Comments on an article tend to split into threads of discussion. A thread is a topic comment along with its set of reply comments. The topic comment typically focuses on an aspect of the article and, properly done, the replies would do likewise. The current hierarchic structure of NewsTalkers facilitates threads by organizing comments into a basic hierarchy as shown below:
Using the diagram as a reference, here we have three top level comments: 1, 2, and 3. Each would be directly addressing the article and each might focus on a distinct aspect. For example if the article was about renewable energy, the first comment might focus on political aspects, the second on environmental concerns and the third on technological feasibility. In this example, comment 3 has 5 replies - comments 3.1 through 3.5. Comment 3 along with comments 3.1→3.5 are a thread. Note that comment 3.1 and 3.3 also have their own structures. These replies mean 3.1 and 3.3 are themselves topic comments for distinct threads. In all, the above structure has three threads:
- 3: 3.1→3.5
- 3.1: 3.1.1→3.1.2
- 3.3: 3.3.1→3.3.6
Threads have been in use on NT for a while, but up to now they have simply been a way to organize the ' threads of discussions ' within an article. The new threads functionality takes advantage of the existing structure to give new benefits to users.
Collapsible Threads and Browser Performance
Browsers are limited in resources. The more comments accumulated in an article the longer it takes for the browser to prepare the article for use. The delay is mostly the time it takes to download comments from the server coupled with the time spent by the browser to prepare the comments for viewing. The more comments downloaded and shown, the slower the operation. The best way to deal with this situation is to work with fewer comments. This is where collapsible threads become quite powerful. Collapsing a thread means shrinking it down to its topic comment. If we collapsed thread 3.3 in the above graphic, comments 3.3.1 through 3.3.6 would disappear leaving only comment 3.3.
A user would typically collapse a thread when the user has read it and no longer wants to see it. Once a thread is collapsed, the system remembers the user's request and will leave it collapsed until the user decides to expand it ( exceptions to this discussed later ). When the user later returns to the article, the collapsed threads are not even downloaded from the server thus the user saves all the processing time and the article loads (typically substantially) quicker. If the user has collapsed a thread but then has a change of heart, that is easily remedied. The user can expand any thread at any time. If the comments within the thread have not been downloaded they will be dynamically retrieved from the server and shown to the user. In result, collapsing a thread offers no loss to the user but provides a great potential gain in performance.
Collapsing and Expanding Threads
There is nothing difficult about collapsing and expanding a thread. Basically this involves a single mouse click. When the user looks at comments some will show a plus icon (
In an article, these symbols appear next to the avatar and to the left of the Like button:
Comment 1 has one reply (1.1). Comment 1.1 also has one reply (1.1.1) but this is not showing (but the count is showing). If you click on the
Note : if you see this symbol ( 
Explicit Expand and Collapse
When a user presses the
First exception situation is when the user creates a new REPLY comment. If a user replies to a collapsed thread (by REPLY ing to the topic comment) the system will automatically expand the thread. This is necessary because the new reply cannot be shown unless the thread is expanded (showing its comments).
Second exception is that all threads containing a currently tracked comment will be expanded. Basically if your tracker contains comments, the system ensures that the tracked comments are available to you when you go to the article. To stop this automatic expansion, simply cease or discard in your tracker.
The third exception is when you open an article using a link to a comment. When this is done, the thread containing the target comment is automatically expanded.
Effective Use of Collapsible Threads
The main idea is to collapse all threads that you have read (or are done with). Collapsing a thread makes it easier to navigate around the comments you are interested in reading, but also dramatically saves system resources. The more collapsed threads the faster your browser will operate.
Given the tracker, you can aggressively collapse threads and not miss anything. If a new comment is posted to a thread you have collapsed, the system will automatically expand the thread. So the net result is a win-win. You can tuck away comments that you no longer need to see, boost your browser's performance and not miss anything.
When an article reaches a certain size (configured by the site) the system will automatically start collapsing the least recently used threads. These will typically be threads you would want collapsed, but if not you can stop this. If you explicitly expand a thread, it will remain expanded until you explicitly collapse it (unless one of the above exceptions apply). That is, the system does not automatically collapse threads that you have explicitly expanded.
Closing threads reduces clutter but, importantly, also reduces load on your browser. The result is faster load times.
TiG, thank you for the explanation of
Collapsible Threads and Browser Performance
Clarifies a concern when first noticed.
Great new feature, TiG. This will be a very efficient way to keep the clutter in check as well. Well done!!!
This release has a number of optimizations in it as well. You and others could not have done anything to actually test the optimizations during the Beta test so I did not mention them. Hopefully we will see a modest improvement in site responsiveness - at best it will be a 'feeling' that the site is a bit quicker. My hope is that the lower powered machines will notice a quicker posting of comments.
You are right about the optimizations, they would not have been able to be tested during the Beta testing. The new feature appears to be functioning well and as intended. It is requiring less scrolling through the many comments that I have already read, yet, the new comments are readily available.
Ya gotta love it when a good plan comes together. (big grin)
Great Job Tig!
This will really improve page loading speeds a whole lot of scrolling. I love it!
You are da bomb!
Realistically, as you know, it is the only way to retain the HTML-rich comment functionality of NT (with videos, etc.) and still perform on client machines. We needed to reduce the workload of the client machine browsers and that pretty much means processing fewer comments. Not having to download a ton of comments on each interaction is also helpful since network latency consumes noticeable time. This, as you know, has been in the plans for quite some time and it is good that we now have the technical infrastructure to support a dynamic comment hierarchy.
So now if users collapse threads they have read, they will have a less cluttered experience and a substantially faster response from their browsers.
FANTASTIC! Possibly because of where I am, or the condition of my decade-old computer, or the internet service here, I have to wait long long times to do anything, especially on articles/seeds that have a greater number of comments. In fact I've even given up trying to comment when it takes so long. This improvement is really a benefit.
This should help quite a bit. The system will automatically collapse threads for larger articles when it can (tries to not be presumptuous). So if you proactively close threads that are of no further interest you should see substantially better performance.
Remember that collapsed threads will be reopened to show new comments so you do not lose anything by closing threads.
Great new feature! To repeat Perrie...you are da bomb!
Does collapse only apply to computer you are using or to everybody?
Collapsing (or expanding) a thread does not affect anyone else. These are personal functions that affect only your view for your account.
That is what I thought, sounds like a good thing. Thanks
Question TiG:
I just clicked on a comment on the FP, which was a comment made to a part of the Article it was in that I had collapsed. After I clicked on the new comment, it did not re-open the section of the article in which the new comment had been made. I had to reopen all the sections I had collapsed in order to find the new comment.
Is this the normal way the new feature is to work? I didn't see this during the Beta testing.
If so, it will make it harder for the user to find a new comment once they have collapsed a section that a new comment has been made to, which may discourage users from collapsing sections in active seeds/articles lest they have a hard time finding new comments in collapsed sections.
Just a thought.
I have been working on this all morning. The problem is the damn cache. It is blocking all attempts to get the new page.
In other words, the system does indeed know that the comment you are looking for is not there. In response it dynamically opens the thread (on the server) and issues a reload on the client to get the new data. The cache, however, ignores the reload and delivers the same page.
Have not found a way around this yet.
Ahhh...OK...that explains it. It must be something recent, as I said, I did not notice this happening during the testing period.
Seems like there is always something that has to gum up the works in an otherwise well functioning product. I've had that happen to me in developing Access Databases, and it is soooo aggravating having to first locate the culprit, then try to find a way to correct it. Even more so when it works well in testing and then mucks up when put into application.
If I can be of any help at all, further testing, or otherwise, just give me a yell.
Found it. This was very tough to find because it dealt with the cache (always a pain). But I have found the culprit so see if your test case is working now.
Also, it is rather cool that our lead Beta tester was the first to report this.
Will do and let you know what I find.
As you may know, with BT's, testing never ends. (grin)
OK....I've now tested with 7 various comments and all seems to be working again.
I chose a comment from the FP, opened it in the seed/article.
Then closed all related threads.
Then went back to the FP and clicked on the same comment to see if it would open in the article.
With all 7 test situations, all new comments were opened and displayed as they should.
Well done!
Caching is the biggest pain to deal with. It changes the rules of physics.
Thanks for verifying this Raven.
Indeed they are. They truly are a PITA. Thankfully, you found a way to put them in their place.
No problem. Glad to help. (smile)
Okay....noticed another one for you......but, it may be meant to work that way..
When I open a new comment from the FP, the new comment will display as it should. However, when I click the back arrow in the upper left corner to rerturn to the FP, it only takes my back to the top of the article page. Then I have click on the back arrow a second time to return to the FP.
Is this how it should work? I didn't not notice this before during the testing.
Yes that is how it must work. This is a result of special logic needed to detect when a comment must be loaded and then issuing a dynamic load. The result of this is to add another item in the history. Also, history is affected by Navigating through tracked comments. In short, we get the important behavior (finding the desired comment) at the expense of extra history.
Ahh...I see. I just never noticed it working that way during the Beta testing. However, once it is moved into actual play there may be other circumstances that must be considered.
Thank you for the update on the functionality. (smile)
I've been collapsing every thread as soon as I've finished reading it, and pages are loading so much more quickly. Well done, TiG, and thank you!
Thanks Sandy.
Another good practice is to discard or cease entries in your tracker.
The system will automatically open threads containing actively tracked comments. So the less you are tracking the fewer threads will be automatically opened by the system.
On occasion, if I've collapsed some threads, I can't use the compass to navigate to the next new comment. Does that indicate that that comment is in a collapsed thread, and I just haven't noticed, or is that a bug?
The Navigator will navigate through (i.e. skip over) comments that are within threads you have closed. However if you have any comments that are on your tracker when you open the article, the appropriate threads will be automatically opened.
But I have noticed situations where (based on resources it seems) the Navigator will not operate properly. Not sure what causes this since all the comments to be tracked are literally strung together (under the covers). Hitting refresh fixes the problem.
Thank you for the explanation of sandy's find. I don't use the navigator so I did not notice the issue myself. A very good find on sandy's part so it can be explained for her and others who may have the same thoughts.
I keep mistaking it for a tally of downvotes for some reason, even though I know that's not what it is.
Does it have to be right next to the thumbs up?
Hey Tig, I have a question and didn't know where to post it.
Sorry to post it here as it is not about the collapse feature.
Is there any way to delete more than one private note at the same time? After I have read them they always stay until I manually delete them. They add up after a while and it seems that I now have hundreds. Is there a limit to the amount that stay? And also is there a way to delete multiple at the same time instead of having to check them one by one? Maybe like a way to delete a page of 100 at the same time. I don't know if there is a possibility to be able to do that or a way that exists that I don't know about.
Not really a big deal but I have been being lazy and they just seem to add up.
Thanks for all you do and again, sorry for posting this here. You can delete it if you want as it does not pertain to the new feature.
The platform provides a function for this.
If you look at the top left corner there is a checkbox that (when checked) will automatically check every private note on your current page. You can then go down to the Delete Selected button and click it. That will delete all the private notes you have checked.
If you are showing 100 notes per page then this operation will delete 100 notes at a time.
Ah, Thank You! I found it. I didn't realize it did that.
There is a ton of functionality in NT. I continue to discover new things.
I had 40 pages of 100. That helped me clear them.
Been here for a little while and still learning all the ins and outs.
Are you using private notes to track new comments on your articles?
Since the tracker rollout, I've changed my settings so that new comments don't result in a private note, and my NT life is much easier for it.
Yeah, I am so use to checking those to see if anyone responded to a comment.
This is all helpful but there's still no direct way to track only the responses to one's comments. That would sure help navigating.
In the tracker, every response to one of your comments is marked as 'replied' (vs. 'posted').
see: Guide to the Tracker