Once the comments to a post get big and grow into many trees (which get split off onto other “continue this thread...” pages), it becomes very hard to follow and find new replies to those threads.
Manually scanning through all the branches in the tree is time-consuming, and it can be easy to miss one or two new posts. Sometimes I find myself using the recent comments page, but then I have to scan through comments in other discussions that I’m not so interested in. Another technique I’ve tried is watching the comments page of the prolific posters in the discussion I am following, but that also gets time-consuming, and will lead me to miss comments from other people in the discussion.
Does anyone else find this a problem? Any solutions within the current features of the site? If not, is there anything that can be done to make this easier to follow?
The best thing I can think of would be a “recent comments” page for each individual post. It would basically be another “Sort By” of the comments that would take them out of their tree structure, and put them in a flat view ordered by recentness.
Let users mark a comment as “watched” so that they are notified of replies to that comment (like we are currently notified of replies to our own comments). Possibly have “watch tree” feature to mark a comment and all its descendants.
A couple of programmers have told me that it wouldn’t be that hard to write a version of trn for the the web, but it’s just too boring. I’m not qualified to say whether this is reasonable.
Any solutions within the current features of the site? If not, is there anything that can be done to make this easier to follow?
Not that I know of. My ideal solution would be to have the site keep track of post-readness; each post would have some little marker (a bullet or a star or something), something visible enough that you could quickly scan for it when scrolling through many posts, and clicking anywhere on a post would clear it.
This could be implemented on the client side through JavaScript and HTML5 local storage, and may not even need any assistance from the server if something like Greasemonkey is available. I’ll write a script to do this if anyone’s interested.
The big advantage to doing it on the server would be that you’d have the same information shared between multiple computers, and it would also be able to do other things with the information that couldn’t be done in a purely client-side solution, such as generating a page that shows only new posts (whether for one article, one thread, or the whole site). The big disadvantage would be the amount of space that would be needed to store all that information, and the amount of time it would take to look up the needed information on every page view. Many forum systems do something similar with apparently acceptable efficiency, but they’re mostly flat (non-threaded), so they only need to keep track of when each user has last viewed each topic. This would be quite different, since it would have to track that information for each post. Are there any public statistics on how many posts and active users exist on LW? If there are, I could do some rough calculations on the feasibility of this.
I forgot to mention another strategy I use for mitigating the need to scan through multiple child pages of comments: I figure out which comment the big discussion is in response to, and click “permalink,” then I keep refreshing this page and scanning through it. Doing so mitigates the number of comments I need to scan, but it has a few drawbacks:
I will miss replies to other comments in the original thread that might be interesting, which are at the same level of the comment I am re-examining
Multiple comments at the same level are the parents of discussions I want to follow; to scan through the permalinks of both costs multiple page views
Sometimes even if I hit a permalink to a comment that sparked a discussion and exclude a lot of the comments, there are still so many comments, falling into so many “continue” child branches that I must do 3-4 page scans to find the new responses to a single comment in a single thread
Exactly, Alicorn… It’s the tree threading that causes the problem.
The tree structure is useful while the comments are on one page (and better shows the relationship of the comments), but once a couple branches of a tree require that you continue to another page, then you must recursively scan all the branches of the tree to find new comments. This operation quickly gets more expensive than scanning a flat view would be. The reason is that with a flat view, you always know that new comments are at the bottom/top, depending on which way it is ordered. But with the tree view, you never know which branches subsequent comments are going to fall into; even if things are all on one page, you can miss things while scanning. And once the branches get so big that they require a “continue...” link to a child page, then things quickly get ungainly.
A long thread in a flat view takes less than a page scan, because you can skip to the page you were last on, and skip to the last comment you remember.
Yet if you have a thread with two child comment pages, you have to do 3 page views to scan for new comments. If one of those child pages gets a child page, then you have to do 4 page views, etc… If you are only interest in responses to one comment on the original page, then at least you don’t have to view all the comments on the page, but you still have to scroll through them to find the “continue” link to the child pages you want.
The tree view is good for showing the relationships between comments, and for being able to skip over responses to comments you aren’t interested in. But it quickly gets ungainly when a discussion falls into multiple branches and your main priority is finding new replies to comments you are interested in; a flat view option would be better for that purpose.
For anyone who does databases:
The tree view requires a full table scan of the comments (usually; you can exclude replies to comments you aren’t interested in with a “where” clause)
A flat view ordered by date (paginated if necessary) basically gives you an index on comment date and page number, such that you can skip to the most recent comment on the most recent you remember, and start scanning from there.
EDIT: Did this get downvoted because someone thinks I’m lazy, or because I got the database analogy wrong, or some other reason? In the case of the second two, please explain.
This would definitely help. Increasing the comment depth on the main comment page of a post might make the page load potentially too big. But at least, increasing the depth on child comment pages would help, because then we would see less “children of children,” which is really a killer to follow.
Does anyone else find this a problem? Any solutions within the current features of the site? If not, is there anything that can be done to make this easier to follow?
I definitely find it a problem. I don’t know about solutions within the current features of the site, but a relatively cheap solution would be some color code for comments based on recency.
I have a suggestion: recent comments for threads.
Once the comments to a post get big and grow into many trees (which get split off onto other “continue this thread...” pages), it becomes very hard to follow and find new replies to those threads.
Manually scanning through all the branches in the tree is time-consuming, and it can be easy to miss one or two new posts. Sometimes I find myself using the recent comments page, but then I have to scan through comments in other discussions that I’m not so interested in. Another technique I’ve tried is watching the comments page of the prolific posters in the discussion I am following, but that also gets time-consuming, and will lead me to miss comments from other people in the discussion.
Does anyone else find this a problem? Any solutions within the current features of the site? If not, is there anything that can be done to make this easier to follow?
The best thing I can think of would be a “recent comments” page for each individual post. It would basically be another “Sort By” of the comments that would take them out of their tree structure, and put them in a flat view ordered by recentness.
A feature request that could solve this problem:
Let users mark a comment as “watched” so that they are notified of replies to that comment (like we are currently notified of replies to our own comments). Possibly have “watch tree” feature to mark a comment and all its descendants.
This doesn’t need to be invented from scratch. trn (a very handy way of reading usenet) has all the features you’ve listed, and much more.
Having an interface as bandwidth-light as USENET’s would also benefit people with poor connections.
A couple of programmers have told me that it wouldn’t be that hard to write a version of trn for the the web, but it’s just too boring. I’m not qualified to say whether this is reasonable.
How much money would make it interesting, do you imagine? I’m fairly sure I could throw a twenty into the pot were such a venture feasible.
I”m not sure.
I’ve raised the question.
If you think this is a worthwhile project, I hope you’ll raise the question, too.
Meanwhile, assuming there’s interest, how would you identify who should be doing it?
Autopope’s analysis there seems spot on to me. Doing it right is a biggish problem, on the order of a programmer-year of work.
That’s the $64,000 question. I’m not competent to identify good coders.
I wonder if there shouldn’t be a focus on a specific application, here—phpBB, for example.
Yes.
Not that I know of. My ideal solution would be to have the site keep track of post-readness; each post would have some little marker (a bullet or a star or something), something visible enough that you could quickly scan for it when scrolling through many posts, and clicking anywhere on a post would clear it.
This could be implemented on the client side through JavaScript and HTML5 local storage, and may not even need any assistance from the server if something like Greasemonkey is available. I’ll write a script to do this if anyone’s interested.
The big advantage to doing it on the server would be that you’d have the same information shared between multiple computers, and it would also be able to do other things with the information that couldn’t be done in a purely client-side solution, such as generating a page that shows only new posts (whether for one article, one thread, or the whole site). The big disadvantage would be the amount of space that would be needed to store all that information, and the amount of time it would take to look up the needed information on every page view. Many forum systems do something similar with apparently acceptable efficiency, but they’re mostly flat (non-threaded), so they only need to keep track of when each user has last viewed each topic. This would be quite different, since it would have to track that information for each post. Are there any public statistics on how many posts and active users exist on LW? If there are, I could do some rough calculations on the feasibility of this.
I forgot to mention another strategy I use for mitigating the need to scan through multiple child pages of comments: I figure out which comment the big discussion is in response to, and click “permalink,” then I keep refreshing this page and scanning through it. Doing so mitigates the number of comments I need to scan, but it has a few drawbacks:
I will miss replies to other comments in the original thread that might be interesting, which are at the same level of the comment I am re-examining
Multiple comments at the same level are the parents of discussions I want to follow; to scan through the permalinks of both costs multiple page views
Sometimes even if I hit a permalink to a comment that sparked a discussion and exclude a lot of the comments, there are still so many comments, falling into so many “continue” child branches that I must do 3-4 page scans to find the new responses to a single comment in a single thread
Right before the comments for any article there should be a little tab labeled “Sort by:” that will let you put the newest comments at the top.
This preserves threading. New replies to old comments don’t appear at the top if you do this.
Exactly, Alicorn… It’s the tree threading that causes the problem.
The tree structure is useful while the comments are on one page (and better shows the relationship of the comments), but once a couple branches of a tree require that you continue to another page, then you must recursively scan all the branches of the tree to find new comments. This operation quickly gets more expensive than scanning a flat view would be. The reason is that with a flat view, you always know that new comments are at the bottom/top, depending on which way it is ordered. But with the tree view, you never know which branches subsequent comments are going to fall into; even if things are all on one page, you can miss things while scanning. And once the branches get so big that they require a “continue...” link to a child page, then things quickly get ungainly.
A long thread in a flat view takes less than a page scan, because you can skip to the page you were last on, and skip to the last comment you remember.
Yet if you have a thread with two child comment pages, you have to do 3 page views to scan for new comments. If one of those child pages gets a child page, then you have to do 4 page views, etc… If you are only interest in responses to one comment on the original page, then at least you don’t have to view all the comments on the page, but you still have to scroll through them to find the “continue” link to the child pages you want.
The tree view is good for showing the relationships between comments, and for being able to skip over responses to comments you aren’t interested in. But it quickly gets ungainly when a discussion falls into multiple branches and your main priority is finding new replies to comments you are interested in; a flat view option would be better for that purpose.
For anyone who does databases:
The tree view requires a full table scan of the comments (usually; you can exclude replies to comments you aren’t interested in with a “where” clause)
A flat view ordered by date (paginated if necessary) basically gives you an index on comment date and page number, such that you can skip to the most recent comment on the most recent you remember, and start scanning from there.
EDIT: Did this get downvoted because someone thinks I’m lazy, or because I got the database analogy wrong, or some other reason? In the case of the second two, please explain.
The biggest annoyance seems to come from the child comment pages. Is there any way I can increase the “comment depth” displayed on a single page?
This would definitely help. Increasing the comment depth on the main comment page of a post might make the page load potentially too big. But at least, increasing the depth on child comment pages would help, because then we would see less “children of children,” which is really a killer to follow.
Er right. And it looks like this was in the original, should have read closer.
That won’t organize sub-sub-sub-branches above grandparent branches though.
(What Alicorn said.)
I definitely find it a problem. I don’t know about solutions within the current features of the site, but a relatively cheap solution would be some color code for comments based on recency.