views:

136

answers:

2

I am designing a threaded message display for a PHP/MySQL application - like comments on Slashdot or Youtube - and am wondering how I should go about ordering the comments and separating it into pages so that you can have, say, 20 comments to a page but still have them nested.

Comments in my app can be nested unlimited levels, and this structure is represented using what I believe is an Adjacency Relation table, a separate table containing a row for each pair that has any ascendent/descendent relationship. That relationship table has CHILDID, PARENTID and LEVEL where a level of 2 means "great-grandparent", and so on.

My question is one of both usability for the end user, and of practicality of constructing an efficient DB query. I have considered these options:

  • Splitting results into pages by date, regardless of position in the tree, so that all comments within a certain date range will appear together even if they don't appear with their parents. Any comment which was posted at a similar time to its parent will appear on the same page and in those cases we can display them 'nested', but there will be comments that are orphaned from their parents. This is probably acceptable - it is the way things are done in YouTube comments - a comment made much later than its parent will not appear on the same page as its parent (if the parent is not on the latest page), but instead appear with the other newest comments.

  • Retrieving the nodes in order like you would traverse a tree. This gives priority to the tree structure rather than the date, though siblings can still be sorted by date. The benefit to this is that replies are always placed with their parent (the comment they are in reply to) even if that parent is a number of pages from the most recent comments. This is how things are done on apps such as the icanhascheezburger blog. I don't like a few things about it, like the way that everyone is tempted to add a reply to whatever is the biggest tree branch.

  • The third option is to do like Slashdot does, where it doesn't separate comments into pages, but has one big tree - in order to keep the page size manageable it starts culling low-rating comments instead.

I think the first would be the simplest DB query given my relation table but would be open to other ideas.

Some such systems, of all three kinds, limit the nesting level in some way - this is easy enough to do, once we have recursed over X levels everything else can be combined together as if they are siblings. For example, YouTube comments only render to one level. Other systems sometimes say "nesting level exceeded" after 5 or so levels.

A: 

Hi, I think what you need is storing a hierarchical data in a Database. You should start with this articles: Article at sitepoint Article at MySQL's website

Thanks for comment. Yes I am familiar with that article (I used to work for SitePoint) and those techniques and I have a database schema already for heirarchical data, cheers. I was wondering more in terms of presenting the user interface.
thomasrutter
+2  A: 

I assume that the reason you want nested comments at all is because your users tend to want to read through a single thread of interest at a time. That is, you have reason to believe users will create threads of coherent chains of thought, and/or what gets discussed in one thread will interest some users but not others.

If that’s the case, I don’t know why you would ever want to arbitrarily split a thread across pages by date (Option 1). Using a single page with culling of low-rated comments (Option 3) seems a little harsh and may discourage users from posting comments. That may be a good thing if you’ve got an audience mass like SlashDot, but it may be undesirable for sites with more typical visitation rates.

Perhaps you can have something like Option 2, with all threads on the same page, but if a thread starts getting too long, it gets rolled up into a single link that takes the user to a page dedicated to that thread. Alternatively, long threads can be reduced to just display their subject lines and authors, each which in turn link to the appropriate place in a dedicated page for the thread.

I suspect the tendency for users to post irrelevant comments in the largest thread is a product of users not wanting to be bothered with scrolling around to find the end of the thread, or find a thread that’s more suitable. By automatically compacting long threads, leaving the root of all threads displayed on a single page of manageable length, users can easily scan for a thread of interest and add to it if desired.

Michael Zuschlag
Thanks for the in-depth answer. Experience with forum software showed some users don't like threaded mode and like it to behave like it's one linear discussion, even if under the hood it isn't. Maybe a way of switching is the answer. Thanks for suggestion of rolling sub-threads into a single link.
thomasrutter