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.
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.)