Moodle

I have the same problem, the discussion page is too long, in some cases there are too many post

Interface ideas would help .... how do we retain context within page 3 of a discussion for example?

Example: if here (http://moodle.org/mod/forum/discuss.php?d=73873) there were 100 posts, you can see 20 posts for page: < 1|2|3|4|5>

Yeah, simple like mauro suggests. Copy the way Moodle does it already when displaying discussion topics, e.g. "Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 (Next)", to keep things consistent. There should also be a setting added to allow you to specify how many posts appear on each page.

Retaining context - I'm not exactly sure what you mean by this. I would assume users would understand that they could view the start of the discussion by clicking on the "1" link.

I have implemented this change for the flat view, but what do you think should be the behaviour for the nested and threaded views? Should the posts in the, say, second page, appear all shifted or should they start at the same horizontal position as the original parent post?

Here is the patch. The maximum number of posts per page can be change by adding a &perpage parameter to the discuss.php URL and defaults to 30.
I have left the posts correspondingly shifted in each page in the nested view, which I think makes most sense.
As for the threaded view, since only one post is displayed and the rest is only the subjects ,I didn't think necessary to have several pages in this case. What do you people think of this? Should I add a limit to the number of subjects appearing in the threaded view too? If so it would be fairly easy to add, but we probably want a larger limit.

Laia - I think this goes along with my comments on long lists of things. I have wondered if it would be helpful to be able to collapse parts of a forum perhaps using AJAX functionality. Peace - Anthony

Hey Laia/Anthony,

Yeah, AJAX functionality would be a bonus, but not essential. The way you've dealt with the nesting seems most logical. The threaded view shouldn't have multiple pages, as users would be confused by this. I don't think we need a limit to the number of threads as the individual links don't take long to load.

Great work, thanks!

Marty

From just the screenshot I'm not 100% on that nested+paging view ... it could be difficult to see where you are in the conversation if you were suddenly sent into the middle of it, and the page is reloaded a lot (making new usability issues). Can we provide better context? I'm not sure about keeping the fullindenting, either, we'd have the same problems we have now for really big discussions. But I need to try it out, perhaps it works better than it looks. What are other people's opinions/improvements for paging on the nested view?

Try slashdot for some ideas .... eg http://news.slashdot.org/news/08/07/08/1832255.shtml

I do like the use of containers around the parent discussions as it helps make it easier to focus. Further I wonder if +/- signs in one of the corners would allow for sections to be expanded or collapsed which would provide some control of what is displayed. The idea of offering pagination is not bad but I think in terms of looking at forum discussions I actually prefer to have the entire conversation. In fact I have often considered that one of Moodle's advantages over other systems. I would imagine from a grading perspective that most teachers would prefer to have the whole conversation as it allows for them to do ratings all on one page which results in fewer mouse clicks which I would think is improved usability. Peace - Anthony

I think that it could also be possible to put an option so that the user could chose the number of questions per page. With this way, it would be possible to select only an option per page if he/she wants. The problem is when the conversation is too long a single page becomes less usable.

It would be also possible to expand or collapse (+/-) in each page (to combine both methods).

Let's see what feedback we can get from the community on containers and (+/-) and per page options. It may be best to treat them as three separate options or let users give feedback about which combination they would find to make forums more readable. Peace - Anthony

I've been thinking about this issue again lately and have come to the following conclusion. It would be best if users could control this feature, e.g. add another drop down menu next to the 'Display replies...' menu that gives the user a few options, e.g. Number of posts per page: 10, 20, 30, 50, All. There should also be a setting that forces this setting at the forum level, e.g. Force posts per page. This is in-line with other activities.

Not so sure how the nesting should be handled though, this is a tricky one. I agree that feedback from the community is needed to find out which approach would be best.

Marty

We at ULPGC have been suffering from this.
Students in our community courses (populated by up to 40.000 users) very often get engaged in very loooong threads. We have regularly discussions with 100-200-300 posts. Some disscussions scale up to 2500 posts!!! Those threads are on "social" forums, not "academic" ones.

We enforced a limit to the number of posts per discussion, but that has drawbacks and were about to start a project on this pagination. So this solution is much welcome. Thanks Laia!!

However, I am not sure that as it is it will address the problem completely. In addition to usability, those large discussions are a problem for performance. I see that even with pagination ALL posts are been loaded into memory like
$posts = forum_get_all_discussion_posts($discussion->id, $sort, $forumtracked);
and then the whole $post array is passed to the forum_print_discussion() helper functions.

I think that this should be avoided by using recodset and fetch_next_record.
$posts array is NOT modified within forum_print_discussion() prior to passage to helper functions, so the fetching of those posts could be delegated to the forum_print_posts_flat/nested functions.

What they do in Slashdot is still not the best solution and still has some big problems. Any way, it is a good step as it mixes the importance of selecting just some answers to be shown when there are too many.

If we are really following a thread and want to catch it all, the option of Laia is better since I can read them sequentially. Anyway I also agree with Enrique Castro that we should take into account performance and maybe change the way we are retrieving the posts. So for now, the one Laia proposed + Enrique´s proposal + add a few context information (row number, title of the parents, etc.) seems a good step for me.