Guide to 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 ( ) others will show a minus icon ( ) and the rest will show no icon at all. The meaning is as follows:
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 button it will expand (even if the system has to retrieve from the server). Similarly, if you click on the button for comment 1, comment 1.1 (and its comments if showing) will be collapsed and the button for 1 will turn into a .
Note : if you see this symbol ( ) after you press a that simply means the system is loading your requested comments from the server. This symbol continues until the comments are on your machine and ready for use.
Explicit Expand and Collapse
When a user presses the or button, the system treats that as an explicit command. It will attempt to keep the explicitly expanded or collapsed threads true. But there are situations that affect this.
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.