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.
This is the final major change to comments. The first was to provide the new format with refer-backs and hierarchic numbering (e.g 1.2.3). The second was to provide a hybrid hierarchy (where the third level automatically becomes a list instead of continuing the hierarchy). This now takes supreme advantage of the NT hierarchic functionality to provide dramatic performance improvements and the means to better tailor one's view to the comments of interest.
Let's test that theory!
Ahh! Really 'cute.' I like.
Testing. . . .
The really good part is that when the articles get very full of comments, the threads you have closed will not even be downloaded. That saves a ton of time. But if you do change your mind you can click
and the comments will be dynamically downloaded.
( I am just testing another feature that is part of this release. When you select a portion of a comment and hit REPLY the system will do some surgery on the HTML to preserve color, bold, italic, underline but disable font-size changes, embedded artifacts, and dangerous HTML. )
Oops. Nevermind. I see SP asked my question.
Very nice. I look forward to it (all).
Indeed this will save a LOT of time in the downloading, especially, when the number of comments reach over 200. I know the log loading time is a big complaint by some of the Members here so this should help bring the loading time down a good deal.
I am really liking the many 'User Choice' functions and features that are being added to NT, as that does help give the Members the freedom of choice in many ways. A great job being done by all!
If I delete a comment ( other than the last comment in a thread)
will it remove all of the daughter comments?
This has not changed. Deleting a comment does not delete its 'child' comments.
and if I don't like that answer ,I no longer have to look at it, lol
Interesting. If a user deletes the parent comment but those below it are not deleted, would that not cause so confusion for others reading the thread? And if more than one comment in the given thread would it not create even more confusion? I am sure this would not happen that often, but, when it does, it could create some confusion as to the direction or continuance of the thread.
Just a thought.
Now there IS an upside.. and also less complaining.
This is how the system works today. No changes needed. If a user deletes a parent comment, the comment is still there - just has no content.
That makes sense.
OK....that might work.
That is how deletes on NT have operated for as long as I can remember. I have never made any changes regarding this behavior.
WoW!! This is a really great way to layout the comments in the threads. The user can read as many extended singular discussions as they wish, or close up the ones they don't want to read or participate in.
Great job!! This will be a really helpful system for the threads. Kudos!!
I for one will be doing a lot of closing. The good thing is that new comments will cause closed threads to reopen so that I can see the comments. So closing a thread does not hurt you - nothing will be missed.
This is good. That way, when new comments are posted to a thread that is closed, the thread will automatically reopen to display the any new comments. And one the new comments are read the thread can be closed again. Great idea.
The logic is tied to the tracker. All the comments showing on your tracker will be visible when you go to the article (even if closed threads need to be opened). If you discard comments from your tracker, those comments no longer will trigger threads to open. So this is a good reason to discard comments from your tracker when you are done with them.
I normally do discard the comments in the tracker when I am no longer in need of them. It helps keep the clutter down.
I am unable to respond to or to test the two test articles you set up as they lock up my browser. I have tried several times and still get the same result. At the bottom left it says "connecting" yet it does not do anything. Also, even when I try to reply from the first comment window with the graphics it says "waiting for YouTube to load and locks up. So there is no way I can test it for you.
That is because (ironically) you logged in while I was doing a load test.
I turned off the load optimization so you were experiencing the normal load without the benefit of the collapsed threads (i.e. all threads were open).
Imagine trying to open an article with 1235 comments on NT. That is what you were experiencing.
Try now.
Hi TiG,
I did try the test threads again and they did load much faster. Closing and expanding worked fine. However, in order to test the way new comments would show up in the threads I posted three separate comments to the first comment in each thread and none of them showed up. The last one I posted was to #28, but, when I checked the entire expanded thread the new comment did not show up. Was this test article not to include the adding of new comments? Just the closing and expanding of the threads? I'm a bit confused.
The comments are supposed to be there. I will look into it.
Thanks. Can't remember where I posted the first two, but, the third one was in #28.
I found the root cause. The underlying platform has (as a design assumption it would seem) placed a limit of 1000 on the number of comments drawn from the db for an article. (It actually goes beyond articles, but ....) Given this is an assumption of the platform I am not going to try to work around it. So the smart course of action (which we will take) is to limit our articles to at most 1,000 comments.
Not really going to mess us up, but it is a shame because with this new system we could have easily gone well past that.
So it goes. I will adjust the test cases tomorrow to work within the limits so that you do not get odd results. By the way, there was a 750 limit in there too (which I have changed). That is what was screwing up the other test case.
Fun stuff, eh?
But, that is the 'fun stuff' we do, and love it. The challenges are the best part, next to the successes. The platform seems to be testing US as well, to find how to work with its unexpected limitations and allowances. At least it will be better than what we have now, even with the limitations. And that will be the 'fun stuff' for the Members in the end.
Will test it out more once the test article is adjusted. Have a good night.
OK...I have done some more testing on the article and all seems to be working as intended. I have closed all the primary comments and then added new comments. The new comments were immediately shown when posted. However, so all all the other many comments. I am not sure about this. Question;
If the ability to close and expand the comments by Members on their end, and they have already closed all existing comments and no longer wish to see them, why would the posting of a new comment need to expand all existing comments other than the one the new comments was made to? Especially, if it was the only new comment made to an existing comment.
Perhaps I am missing something in the process and not fully understanding how it is intended to work regarding new comments. I understood that only new comments would be shown once the existing primary comments was closed, and not all other comments would be reopened, only the one that the comment was made to. So perhaps I need a bit more clarification on this part.
If a user has explicitly closed a thread then it will remain closed except for the following conditions:
Creating a new comment should not open threads other than that which holds the comment. However, note that the system remembers the state of sub-threads. So if you have a thread such as: 3 and it contains an open sub-thread 3.2 then even if you close 3 the system remembers that 3.2 is still intended to be open. So if you later add a comment to -say- 3.5, the system will open thread 3.5 to show the new comment. But it will also have to open thread 3 to show 3.5. If it opens up 3 then any threads marked as open (e.g. 3.2) will be opened too.
Short and sweet - add a comment and the enclosing thread will be opened, but the major thread will also be reopened along with any of its opened sub-threads.
Thanks for the clarification. I understand the relative functionality now. While, IMHO, it would be more efficient to only open the sub-comment the new comment is addressing in order to save time and space, I can see where that would take a great deal of work to achieve, even if it were possible.
You've done an excellent job of providing this feature to make things easier for the Members to navigate through the numerous comments and that is truly commendable on your part. As merely being a BT that just tests the end results of your work, I can't see all the limitations and parameters with the platform and what is and is not possible. And you extract the most possible as it is.
Kudos for all you do for NT. (smile)
The reasoning for this is to preserve user intent. Basically the system does everything it can to preserve explicit open and close instructions from the user. So when it opens a thread it tries to do so in a way that holds true to the conditions in play when the thread (the major thread) was closed.
Very good, understood. Thank you for the clarification of functionality.
I also find it helpful that the number of comments in a parent comment are listed at the bottom of the parent comment when it is closed. That way Members know how many sub-comments there are to each parent comment. I find that very helpful.
I have also created a new parent test comment to see how the sub-comments flow from there and I can better play with the functionality from my own perspective.
The updated Reply with Quote functionality ( included in this feature update ) now accepts certain formatting . It will allow color , font , bold , italics , underline , etc. but will disallow font size changes, images,
videos and other aggressive HTML constructs.
It will also support quoting multiple paragraphs at once.
To use the new RwQ , simply select what you wish to quote and then press REPLY .
The above quote was generated by selecting my entire comment @9 and pressing REPLY. No other action.
Oohhooo, I like that part. Often I would like to quote more than one paragraph at a time, but, as it only now will quote only one, I have to copy/paste the other paragraph that I want to also quote. So this new capability will be really nice to have. Says me. (grin)
New test comment
TiG...something I have been noticing and not sure if it supposed to work this way for the users...
Each time I open a new comment in an article of seed that I have collapsed all the threads for, all the threads are all opened again, not just the one with the new comment. This means that, no matter how many times I close all the threads on my end, it only takes one new comment in one thread to cause them all to open again.
To say this is tedious is putting it mildly, and because all the threads are open again with the one new comment, it takes longer to load again.
Is this how it is supposed to work? When only one new comment is made to one part of the article/seed all the other threads have to open as well?
I'm really confused about this.
The threads for comments in your tracker are reopened too. The idea is that if you are currently tracking a comment then you would want to see it.
I suspect that is what you are seeing. If so, discarding comments from your tracker should make a big difference.
OK....now I am really confused. Why would my having a Tracker on a given article/seed have to do with all the threads that I closed previously be reopened when only one new comment is posted? I can understand the thread where the comment was posted being reopened to show the new comment, but, why would all the other non-related threads e opened as well. That is what is confusing me. If all the threads are going to be reopened because one new comment is posted in one particular thread, then where is the advantage of collapsing all the threads, or even most of them, by the user before leaving the article/seed, only to have them all reopened due to one new comment being posted?
That is what I can't seem to get my head wrapped around it to see the advantage to collapsing all the threads.
Here is a scenario:
Pretend you are tracking an article and your tracker shows 5 comments which have the following id numbers:
These five comments are treated special by the system. In particular, the system presumes that since you are still tracking these comments that you want to see them when the article is reopened. Accordingly, even if you have manually closed every thread in the article, when you reopen the article the system will ensure that the threads needed to show these 5 comments are reopened. That means the following threads will be reopened:
If you do not want these threads to be reopened simply use the discard function on your tracker for this article. If a comment is discarded it will not appear on your tracker and thus the threads will not be reopened to show it.
I am guessing this is what you are seeing. Let me know if I have guessed correctly.
In short, clear your tracker for an article and threads will not be reopened (except for the comment you are focused on).
OK...so if I open a new comment in an article which then registers in my Tracker, if I don't want to have all the treads opened again, then I have to secondarily delete the Article/seed from my Tacker. So now I have a two step process instead of one.
At this point, it seems to be less time consuming as a user to just leave the threads all open even if it takes a bit more time of everything to load. As closing all the threads before leaving the article/seed will not necessarily ensure the article/seed will load any faster due to all the threads automatically opening when a new comment is made anyway at the time the comment is opened. And if I want that to happen, then I have to do a secondary step and clear my Tracker as well.
When participating in many articles/seeds during a visit which will add many articles/seeds to the Tracker, having to clear the Tracker after each visit to each article or seed can get very confusing, and time consuming.
I'm going to have to give this a lot more thought, as right now I don't see the advantage of closing all the threads to get a quicker load time.
Clearing the tracker for an article requires pushing a single button. If you take the time to close each thread in an article then I do not understand why pushing the discard button on the tracker is a problem. Not sure what else to say at this point other than it would not be desirable for the system to presume that by closing a thread the user wants the (now hidden) comments removed from their tracker. I am pretty confident that would be a very confusing and likely unwanted side-effect. Also, it goes against the design philosophy of not be presumptuous - letting the user decide how to manage their content.
One more thing. When you close a thread, the system remembers that as an explicit user action. It remembers that you want that thread closed. Even though it will reopen the thread to show you comments that are currently in your tracker, when those tracker comments are discarded the thread will be automatically closed. The system will not forget your original request.
Thus, in your case, all those threads you have closed are still remembered. Clear your tracker (discard comments that you no longer wish to track) and you will see that those threads will indeed be closed in the article when you return.
OK...thank you for the further information and clarification on the interacting relationship between Tracker and closing the threads. Rather than having to re-close all the open threads that have been opened by a new comment, all I need to do after having close them in the beginning is to discard all the comments in the specific article/seed and they will all automatically reclose at that time. That makes more sense. I will give that a try and see how it works.
Thank you.
Yes. Closing a thread is an explicit command that the system remembers. The tracked comments are simply exceptions. Without those exceptions the system (happily) keeps your threads closed.