Moodle

From Martin Dougiamas (martin at moodle.com) Thursday, 8 July 2004, 09:42 AM:

Perhaps you have some good ideas about how the interface should work.

From Jurgis Pralgauskis (jpral at yahoo.com) Thursday, 23 September 2004, 08:47 AM:

I would say subscribe per topic, as thread imight be too dynamic..

in my post http://moodle.org/mod/forum/discuss.php?d=11448 I said little more (bout interface <- phpbb

From Martin Dougiamas (martin at moodle.com) Wednesday, 29 September 2004, 07:04 PM:

discussion topic = thread (in Moodle). Same thing.

Interface ideas still wanted (there are none at the previously mentioned discussion). What we need are specific clean ideas for making it work within the Moodle form framework.

My brain is tired so I can't even get started thinking about it.

From jaime alamo (jaime.alamo at uv.es) Monday, 13 December 2004, 11:53 PM:

As some forums are overposted thread subcription, instead of forum subcription, should be more effective for personal interests and server load.

From jaime alamo (jaime.alamo at uv.es) Tuesday, 14 December 2004, 12:17 AM:

1. Add to the forum list of subscribers a thread list of subscribers for each thread.

2. In each post add links to subscribe to this thread and unsubscribe to this thread

3. In the liked page, check the user is not already subscribed to the forum or the thread and proceed accordingly. People wanting thread mails should unsubscribe to that forum.

4. For each new post, the mailer should send mails to both lists

From brian king (free.as.in.speech at gmail.com) Thursday, 8 December 2005, 08:34 PM:

I've implemented this for a moodle 1.5.3 installation, and would be very happy to share it - especially if it gets implemented on moodle.org!

Personally, it's always something that bothered me about the moodle.org forums - there are certain discussions that I'd like to follow, but not necessarily all discussions in a single forum.

How I implemented it:

When creating / editing a forum, I added a question whether or not to allow subscriptions to single discussions.

If discussion subscription has been allowed for a forum, then there is a (un)subcribe to this discussion link at the top of each discussion. Entire forum subscriptions work as they did before; I didn't change how they function.

Technical details:

• added a 'discussion' column to the forum_subscriptions table

• added an 'allowthreadsubscription' column to the forum table

• minor changes made to the files:

lang/en/forum.php

mod/forum/mod.html

mod/forum/lib.php

mod/forum/discuss.php

mod/forum/subscribe.php

From Brian Sea (sea at umr.edu) Monday, 12 December 2005, 03:29 AM:

This should be added to CVS, IMO. I don't see how providing the option can hurt, especially since it's coded.

From Robert Barreca (rob at electronicinsight.com) Monday, 3 April 2006, 06:23 AM:

Could you upload a patch for this? I'd like to implement it for School Engine.

From Martin Dougiamas (martin at moodle.com) Monday, 3 April 2006, 10:49 AM:

Yes, I'll implement this if we get a patch

From brian king (free.as.in.speech at gmail.com) Wednesday, 5 April 2006, 04:35 PM:

as i last left the code, there was still some buggy behavior. seeing as people are interested, i'll dig out the code and debug it - and should have a patch in the next couple of weeks.

I'd put forth that this whole issue, which is a big one (spam vs. keeping in touch) can be resolved by subscribing users to the threads to which they post. Otherwise, it'd inherit their settings.

In both cases, their choices should be a bit less implied. Currently there's a profile setting (auto subscribe when i post) that most don't know about, and it catches folks off guard.

There's an option at the bottom of a post, and other places where you can subscribe/unsubscribe, but why not include that within the text of the button- so you could have two buttons:

[post this message and email me responses to it] [post this message but don't send me related emails]
you could even have another that says [post this message and email me all discussions on this FORUM]

for layout, you could simplify by having a message:
click one of the buttons below to post your message and set your email subscription options. ( ? ) <-- help button
[email me responses to my message][don't send me related emails][don't send me any emails from this whole forum]

Or you could have 3 radio buttons and a [submit post] button - the radio button could inherit from a setting profile.

The 2nd option here would unusbscribe someone to a thread where they were already subscribed, and would not be available when the admin had forced subscription on all.

Assigning to me temporarily because Vy-Shane no longer works for Moodle HQ.

Since my first contact with Moodle, a couple of years ago, one of the things that surprised me the most was Forum subscription instead of the omnipresent thread subscription. I can see pedagogical and technical advantages of course subscription, but thread subscription is a must in certain situation.

Technically, I think that thread subscription settings should be the value to check when sending emails. Forum subscription and unsubscription choices should reset the values of all threads and be the default value for new threads in that forum, but this could be overridden later by particular thread choices (unless forced forum subscription, of course).

Regarding the interface, apart from looking at consolidated forum systems (phpbb and the like), here are my suggestions.
Generally speaking, there should be duplicated options for subscribing/unsubscribing to/from a thread or the entire forum.
In the profile, for example, the "Forum auto-subscribe" setting option should have 3 options, adding one named "Yes, when I post subscribe me to that thread" and rewording the negative one "No, don't automatically subscribe me".
The settings in the new post form should be similar, with 4 options:

• "Send me email copies of posts to this forum"
• "Send me email copies of posts to this thread"
• "I don't want email copies of posts to this thread"
• "I don't want email copies of posts to this forum"

The default value should be the current option (in this order: no subscription to thread, forum subscription enabled, thread subscription enabled; no subscription to forum should always be explicitly choiced, giving its consequences). The profile setting should only be used for the first post to a forum.

The same duplication philosophy should apply to top-right options while viewing a forum, and to mail unsubscribe options.

There should be new options while viewing a discussion, similar to the top-right option while viewing a forum, to subscribe/unsubscribe to/from the thread.
There should be a new column in the "forum view" page for each discussion, "Subscribed", with the same behaviour that the same column in the "forums index" page, but, of course, at a thread level.

I hope this help.

This seems quite complicated. Would a simpler solution be:

• Fourm subscription settings as now.
• If subscribed to a forum the user receives the initial post of every new dicussion and subsequent replies until they unsubscribe.
• The subscription links in emails of posts, the drop down in the post interface and user profile change to manage subscription to discussions not forums.
• Unsubscribe forums links on forum page and forums index page remain as now.

It does seem complicated, but I do agree with Alejo that it is needed. I really want to be able to subscribe to individual threads and not necessarily forums as a whole, especially on moodle.org. An additional option would be to have an automatic thread subscription if you post to a forum, and maybe a separate option to not subscribe to the forum, or the thread as a whole, but only to any replies to a specific post made by you.

Interface wise, I think checkboxes/toggle links at the top of forums, threads and own-posts, as well as a whole site subscriptions interface, showing forums and threads you are subscribed to in tree format (course-forum-threads) so you can unsubscribe to many at once.

It would also be very useful to have a block showing recent posts only in my subscribed forums/threads, which would suit me better than the emails to be honest. It would be good if I could turn off subscription emails without turning off all emails and still see subscribed threads amalgamated on site somewhere

Thanks. The effect I was trying to get to was a simple method of allowing users to manage subscription to individual discussions but retain a simple way of alerting them to new discussions (which they could then opt to subscribe to).

Although it may be desirable to only subscribe to reply to posts of one's own a student may do this inadvertently and receive a very partial view of the discussion. And of course it may not be what the teacher intends.

+ 1 for being able to disable subscription emails and not others. Has this been logged a feature request before?

I'm coming in a bit late, but I'm all for minimal defaults and maximum options. It's a bit irking to post a focused request or response (Moodle forums) and wind up getting daily updates on everything else in the place. On the other hand, there are times when you want to be kept abreast of the whole big discussion.

Grats and kudos to everybody trying to help with this.

I think this is a much needed enhancement.

Where are we at now?
Do we need more clarification of a best implementation? I can see a workable solution in the comments above.

I notice it says "Fix version 2.0" Does that mean it is in the 2.0 plan?

I think "rss for thread" may be good alternative solution? And it is easy to implement...

I would also like to see the ability to subscribe to a specific thread within a forum, instead of the whole forum.

Hi all.

I had for quite a time felt that this was a significant shortfall in the forum module, which most particularly shows up in the General Problems forum where it is quite plain to most regular contributors that new users are completely shocked and overwhelmed by the email storm that results from their first post, such that they hurriedly switch of their subscription to the forum and never get to see the responses they may have had!

It is almost equally a problem if you unsubscribe and just keep a browser tab open and refresh it periodically - if you have answered half-a-dozen queries, then within a few days you can have forgotten which titles/users you replied to (would I EVER write that down?), they become so spaced out in the list, you may never get to see that you were asked a follow-up question! This is a less than fabulous situation.

However, instead of complaining, I have, as I have posted in moodle.org forum and the Forum module forum, done something about it.

I am posting up a patch (originally on 1.9.3) that implements subscription by discussion thread (discussion <=> thread here). Tim Hunt will I hope, in due course, check the patch to make sure I have got that part right - I believe so!

To work this patch you need an extra column in the table (mdl_)forum_subscriptions, so you must first run the sql statement:

ALTER TABLE `mdl_forum_subscriptions` ADD COLUMN `thread` BIGINT(10) UNSIGNED NOT NULL DEFAULT 0 AFTER `forum`, ADD INDEX `mdl_forusubs_thr_ix` (`thread`);

I have also left off a tiny (and non-critical) bit from theme/standard/styles_layout.css...

#mod-forum-discuss .subscription {
float: right;
text-align:right;
white-space: nowrap;
}

But for the rest - the changes in 11 files - are in the patch.

I have annotated all changes, and you can search to find each marked by the initials JWC (later we will of course want to remove such egotism!!)

I have tested it as thoroughly as I can - it is implemented on a training site in the UK, and I've got a team of people roped in to comment on it, but I am very open to suggestions for improvements. I can think of one myself: on a big site you might appreciate a check box to 'show me discussions I'm subscribed to' on the forum page, or even 'show subscribed discussions first' to alter the listing order!

I too agree that this could all seem a bit overwhelming to course leader and to users. For that reason I have tried to keep the options as simple as possible and to give useful (but brief) information in the help. In short I have given three extra options for the forum itself, and what the user can see is based on which of these is chosen:

4. Allow thread or forum subscriptions
5. Automatic thread-based subscriptions
6. Force thread-based subscriptions

I'm sure there needs to be a debate about these settings to. You need to consider, particularly, what effect each would have if the teacher subscribes all course users to a the forum, when the default setting is one of the above. This issue has been considered and I hope you will appreciate the subtlety of the results.

Regards,
John

Patch as described in comment by John White

I thought I would add a little about what it is you are meant to see with this patch...

Obviously in the Forum settings panel the teacher/administrator has 3 extra options in the 'Force everyone to be subscribed?' drop-down.
4. Allow thread or forum subscriptions
5. Automatic thread-based subscriptions
6. Force thread-based subscriptions

Also in the Forum page itself the t/a sees an extra fast link 'Automatic thread-based subscriptions' (if not already chosen), below 'Force everyone to be subscribed'.

• This seems to be to be the most likely option to want.

When option 4 is chosen 'This forum allows everyone to choose whether to subscribe or not' appears as a reminder to all users.
With option 5 the text is 'This forum provides thread-based subscriptions automatically'
and with option 6 the text is 'This forum forces thread-based subscriptions'

With either option 4 or 5 all users (with a subscribable role) see an extra column in the discussion list: 'Thread subscribed?'
This contains yes/no buttons for instant thread subscription.
Neither option stops the user from subscribing to the entire forum.

Switch to option 6 and these buttons become yes/no text only, because you can only be subscribed to a thread by posting in it (this state does not recurse backwards to posts you have already made if the forum settings are changed).

None of these settings stops the t/a from subscribing users to the forum, such that they appear in the forum subscribers list (which is unchanged), but if this is done the 'Thread subscribed?' column disappears as it is irrelevant!

With options 4 or 5 the user can unsubscribe from the forum (because that is not forced) and then the yes/no thread subscription buttons appear, though if you move from forum-subscribed to forum-not-subscribed, all the buttons will be in the No state, and the user can change any.
[Note: It could be argued that for state 5 these should all default to Yes, see below.]

In state 4 or 5 you also get a fast link for 'Subscribe to this discussion thread' or 'Unsubscribe form this discussion thread' on the discussion page,
and 2 extra options in the 'Subscription' drop-down on the posting page:
'Send me email copies of posts to this discussion', and
'I don't want email copies of posts to this discussion'.

The difference between these to states is that whereas in state 4, the user's profile setting for autosubscribe is used to pre-load this 'subscription' setting,
in state 5 it is always pre-loaded to 'Send me email copies of posts to this discussion'.
So state 5 is automatic, not forced!.

In state 6 this option box disappears, as do the fast links and buttons for subscribing and unsubscribing.
In place you find that the user is subscribed to any thread they post in.

But what if all students have been pre-subscribed to the forum by the t/a with thread subscriptions in state 6?
Then the user receives mail from all threads until he/she posts to a discussion (new or old), then their forum subscription drops out and they are subscribed to the newly posted thread only.
The principle of this one is that whereas the teacher may wish to hail all course participants with the merits of their forum, NOT removing the forum subscription would render it the same as Option 1 'Yes, forever'!!!

The result of all of this is that mdl_forum_subscriptions now keeps track of who is subscribed and to what forum/thread. The value thread=0 means the whole forum, which is why this must be the default setting for column 'thread' so as to keep all existing subscriptions intact.

Then the cron has an additional task to do. As well as collecting all forum subscribers, it must collect all thread subscribers but it must do so in such a way that the user profile data is collected only once for all cases; and this it does.
Then a very small change to the condition that allows emails to be generated is all that is required.

So far my tests appear good, but I have to admit to two untested areas,
1. Does read-tracking upset this regimen - I think that unlikely, and
2. What happens where groups are used for subscriptions.

On these, or any other matters, I am keen to receive feedback.

Regards,
John

Thanks so much, John. This will make a very big difference for moodle.org especially (I maintain that getting email you did not specifically expect can be a useful thing in a smaller constructionist learning environment).

I've not looked at the patch yet, but would also really appreciate feedback from others about the usability of the interface. Perhaps someone could post some screenshots too?

Martin,

Thanks. And I too have this squarely aimed at moodle.org, but I can see it also running internal teacher support help on larger sites perhaps.
Or homework support 'clubs' and the like.

The most significant difference in the interface, but a modest one at that, is the extra column that any (subscribable) user sees when options 4 to 6 are used.
I have placed a sample of what this would look like at: http://moodle.org/mod/forum/discuss.php?d=115149#p505235 along with the mtrace() output in the cron.
As noted above, when option 6 is chosen (if ever) the yes/no buttons shown in that screen shot for option 4 or 5, become just plain text yes/no, no longer links.

I have a couple more screen clips I can post up in the same place, though these are very simple: the drop-down the teacher sees in the forum settings, and the drop-down all users see when posting.

I have got one more development that I have spotted as necessary...
When the user clicks: 'Subscribes to this forum', but is already subscribed by thread, all their previous thread subscriptions have no meaning (and are therefore wiped), so there needs to be a confirmation page (that ONLY shows if you have 1 or more thread subscriptions) stating something like:

'You are about to subscribe to this forum as a whole.
This will mean losing your current subscriptions to
separate threads. Do you want to proceed with this?
Yes / No'
...

But let's firstly see if what we have to date behaves itself.

And whether I have the patch IN THE RIGHT FORMAT!!!

Regards,

John

...and further to the above comment, an even more pressing requirement would be a confirmation page that is required if ever the teacher/administrator switches from any of options 4 to 6 down to any of options 0 to 3, AND there ALREADY EXIST some thread subscriptions.
Similar (though more robust) wording would be needed here:

'You are about to remove thread-based subscription from this forum.
This will mean wiping the current thread subscriptions your users
already have. If you change back to thread-based subscriptions at
a future date, doing so will not restore those users' subscriptions
automatically; users will have to do this manually.
Do you want to proceed with this?
Yes / No'
...

I'm sure other issues will be thought of too - but all of this is eminently doable!

John

I have almost completed a patch for 1.9.4. I will post this up in the next couple of days.
I not only patches 1.9.4 correctly, but also has virtually al of the features that I mentioned as 'to do' items above.

Regards,
John

At last I have finished the patch for 1.9.4, ready to attach here.

This addresses quite a number of issues or developments that I commented on above, (as well as running correctly onto 1.9.4 which the patch for 1.9.3 would not)...

For example,
(1) The teacher switching the forum to 'force-subscribed' does not remove prior thread-subscriptions from the database (there is no need to remove these because they become irrelevant and invisible), thus they will return in the forum is switched back, but

(2) the user clicking the 'Subscribe to this forum' link would remove their own thread-subscriptions, and is now warned:

'You are currently subscribed to one or more discussion threads in this forum!

If you wish to DELETE all such subscriptions so as to replace these with a subscription to the entire forum, click Yes.

Otherwise click No.'

...but this warning only appears if the user has prior thread-subscriptions.

(3) Similarly, if the teacher changes the forum settings to 'Subscriptions not allowed', when there were prior thread-subscriptions for some uses, she is warned:

'There are already users subscribed to this forum or its discussion threads!

If you wish to DELETE all such subscriptions, click Yes
You will then need to save the forum settings again.

Otherwise click No'

... I also believe that this overcomes a possible residual bug whereby it may previously have been possible for emails to creep through under circumstances where forum subscriptions existed before such a change - unless, of course, this was INTENTIONAL, in which case I had better modify a call to forum_unsubscribe_all() in mod_form.php!

(4) It would be a disadvantage for teachers not to be able to see whether users were subscribed to at least some forum threads, and would so easily result in the teacher forcing a subscription to the whole forum in the view/edit subscribers panel. So now, if some users have thread subscriptions a warning to that effect appears at the top of this view/edit panel (in edit mode), and the number of theard subscriptions appear in parenthesis after each username.

(5) I have given the user a button option to sort their subscribed threads to the top of the discussions listing if they so wish (view.php). This naturally only appears if 'forcesubscribe' is set to any of the new options 4 to 6.

This one was potentially the messiest of all the changes, so I have kept this simple, and left a lengthy comment in mod/forum/lib.php (marked with a TODO) as to the method chosen, and why, and two other processes considered - both of which require doing more than a few minor tweaks + functions (or code blocks) added - which is really all I've done up to now.

(6) I have modified Eloy's lovely AJAX to run the Yes/No buttons for thread subscription - no flashing back to refresh every time!!! But a method that works if Javascript is disabled in the local browser has been retained as well.

(7) Emails needed to be modified both in terms of who gets what, and in the unsubscribe links in the footer, which now reflect whether the user is subscribe to the forum or a thread.

(8) I have added in two features that might be considered completely superfluous (and hence need removing). The first of these is a 'ratings reminder', it would like this: If $CFG->forum_ratingsnudge==1 and ratings of some kind are enabled in the forum, then when the discussion ORIGINATOR chooses to unsubscribe from the thread they created, but that thread has been replied to by one of more users, if the originator has not rated any posts in the thread, they see a polite reminder.

(9) and, in a similar vein, if $CFG->forum_countposts==1 then the count of the number of forum posts a user has contributed in that course appears in parenthesis after the user's name. This latter one was in response to http://moodle.org/mod/forum/discuss.php?d=116200#p513188.

It is notable that (8) & (9) are both switched on or off globally, for all forums, as I have only provided control in mod/forum/settings.php (i.e. the admin settings page), realistically these might be more useful (or at least more acceptable) if they were controlled for the forum's own settings page, which of course would require new fields in the database!

Regards,
John

This patch should behave better than the previous one, in that I have done more to try to make the patch created on a local CVS work without objection, though you may find you have to use the --strip option (or supply the file location of each file).

If 3 files yesno.php, yesno_ajax.php, yesno_ajax.js, appear in you top level directory move these to mod/forum.

You still require the extra field in table mdl_forum_subscriptions shown in this discussion.

I hope developers will try this out and report back here if they succeed in uncovering any bugs - or have any other comments to make.

I hope developers will comment on this addition, in due course.

For my part I have found one bug that needs fixing - but superficially (at least) it is a surprisingly odd one!

This is to do with the Yes/No buttons in the 'Thread subscribed?' column - as shown at http://moodle.org/mod/forum/discuss.php?d=115149#p505241

In circumstances where the thread subscriptions are allowed and forum AJAX is switched on, these buttons use AJAX to subscribe/unsubscribe the user from the relevant threads perfectly, just as Eloy's AJAX ratings work! Even if Javascript is DISABLED in the browser (have you ever tried Google Maps without Javascript???) the buttons still perform correctly in their non-AJAX state (naturally this clunks, but thats life!).

HOWEVER, if thread subscriptions are allowed, but AJAX is switched OFF, then the FIRST yes/no button in the list does not perform its no-AJAX duty! ONLY THE FIRST ONE!!!
That's why I didn't spot it.

The cause is associated with the way the browser (well, Firefox in particularly) deals will one FORM inside another (which structure does not occur with AJAX enabled).
Now that I know the systems and the cause, I will find the solution soon enough.

Meantime, this has no bearing on the functionality with AJAX enabled.

Please let me add that I am still missing comments from people replying to my answers and asking for clarifications. (See: http://moodle.org/mod/forum/discuss.php?d=116610) This is bad... but I can't read each post of an entire forum to look for the message the maybe was sent to me. Moodlers remain without answers and this is not good at all. I believe this problem is matter of all moodlers not only a my personal problem.

Daniele,

Following Martin's enthusiasm for the idea, expressed above, and the other feedback I have received so far, it would seem that setting 'forcesubscribe' to option 5: 'Automatic thread-based subscriptions' in the new schema would seem to address this very issue best.
This will still allow users to decide they don't wish to thread-subscribe, or conversely, to subscribe to the entire forum, but the default position is that if you contribute to a thread you become subscribed to it. With this setting new users are no longer run over by the email traffic, so they are perhaps less likely to unsubscribe! And old users (that's a self-deprication) get email responses to their posts, and just leave a tab open to General Problems to check what else is coming up perhaps.

So, if this were running on Moodle.org, then personally - as a user, I would choose to accept the auto thread-subscription in the General Problems forum (immediately solving the problem you refer to), but I might subscribe to the entire 'Forum Module' forum, so that I can see if any related issues as they are raised. Useful flexibility.

Regards,

John

Waiting and hoping...

I've found the little bug I left the the 1.9.4 version

Technical:
In order for the buttons to run most efficiently (and compactly) when AJAX is enabled, each button holds only minimal information (the threadid and subscribe or not), the forumid is held in the overarching 'ajaxform' form which calls to 'yesno.php' or 'yesno_ajax.php'.
But without AJAX enabled each button becomes its own mini form, because it contains all the data including the forumid (wasteful, but I think necessary - especially if we have to provide for the no Javascript in the browser case).
However, I left the overarching ajaxform form in place (in this scenario its redundant), and this messes up the straight href call in the FIRST button ONLY (I presume that it reacts to the nearest </form> tag, not being happy with the fact that these forms are nested).

Fix:
In mod/forum/lib.php,
in function forum_print_latest_discussions(...),
the start and end of the form are wrapped by the AJAX enabled condition:

Thus...
About line 5347:
if (!empty($CFG->forum_ajaxrating)) { echo '<form id="ajaxform" method="post" action="yesno.php">'; echo '<input type="hidden" id="forumid" name="forumid" value="'.$forum->id.'">'; }

About line 5537:
if (!empty($CFG->forum_ajaxrating)) { echo '</form>'; }

Now all four scenarios work, for ALL buttons:
AJAX enabled at server; Javascript enabled in browser
AJAX enabled at server; Javascript disabled in browser
AJAX disabled at server; Javascript enabled in browser
AJAX disabled at server; Javascript disabled in browser

I will post an amended patch shortly.

Regards,
John

In case that wasn't clear. The above problem is fully fixed in the file...

moodle 1.9.4 (chk)-diff-2009-02-23-00-00-16.patch (111 kB)

...posted above on 23rd Feb.

Added UI Mockup: <thread_subscribe1>

Added UI Mockup: <Starred Discussions Mockup1>

Edited UI Mockup <Starred Discussions Mockup1>: Fixing some strings

Edited UI Mockup <Starred Discussions Mockup1>: some clarification in user / forum interaction

Deleting My mockup! I thought I was in test server. Apologises by the noise!

Hi John,

threaded subscriptions (or starred discussions, as I use to call them in my mind) are definitively a good thing. And I think that having them in forums would be awesome! B-) Great work!

Anyway, I'd want to comment here some basic concepts that have been in my mind since time ago related to this functionality:

1) The concept itself: Some lines above I've commented that always I've seen this as "starred discussions", and IMO that's the key concept: To be able to mark (star) discussions. Nothing else.

2) And then, the second (and more interesting) part. To be able to use those simple stars (marks) for a bunch of things. Obviously, the most prominent thing is to be able to receive personalised mails, containing only the starred discussions. But also can imagine the possibility of viewing (in the forum discussions page) only those starred discussions (instead of all them), or track only starred discussions, or as a tool for teachers to mark discussions privately, ... or whatever anybody more imaginative than me can do with those nice stars.

But I'd separate 1) and 2) completely from start. First let's allow forum to have their discussion starred (really easy to do). We only need one configuration at global module level to enable/disable and another one at activity level (and probably one capability to decide who can "use" those little marks and everything associated with them).

And then the second part, which complexity is bigger, specially when talking about subscriptions / mailouts, where there are a lot of settings to control (digest types, auto-subscription when posting, manual subscription, forced subscription...) needed to be integrated in a clever way if one forum has "stars" enabled and the user has permissions to use them. Sure it can be done, in fact John has done a great job thinking and implementing about that.

But, once more, and as summary... I'd separated the "mark" thing from the subscription functionality. Simple but can give more power to the starred discussions in the future IMO.

My 0.5 cents... ciao

Eloy,

Thanks for your input. I certainly appreciate what you say about wanting to mark, tag or star discussions. But I also think that more clarity is needed.

First of all there is a great desire to choose to subscribe to some discussion threads and not others, whether this is achieved by yes/no or by a star (which then might have other uses) is in itself immaterial. But note, we either add a column in forum_subscriptions for thread or for star/mark but not for both. If we add both we for a matrix in which it is NOT possible to both STAR a discussion and NOT SUBSCRIBE to the forum. Of course the 'stars' should not be in this table, they do not belong here. But there is a problem putting them in forum_ratings too, since this refers to POSTS not discussions. So this would suggest that it requires a new table with id, userid, discussion, starmark - but this too will generate a problem further down the line, as someone if bound to ask to be able to star (in this sense) posts rather than discussions. And this fits better (I think) with your point about teachers putting a private mark on discussions, because surely this might pertain to POSTS instead.

Added to this, if I want to starmark posts, and/or subscribe to said discussions, does this mean that when I star a post I subscribe to it, and if I have a setting in my profile to say 'Yes, subscribe to starred discussions' does that mean that I will NEVER want to star a post but not subscribe to that discussion? In short, whilst I wholly applaud the idea of 'starring' a discussion (privately) for whatever purpose I wish, AND I would CERTAINLY want to then 'show only starred discussions', I think this is almost independent of the subscription issue!

Instead I want to suggest that we use the forum_ratings table for starmarks (unless we are serious about adding a whole new table) and the forum_subscriptions table for thread-based subscriptions (by adding 'thread') as I have done. In forum_ratings we need to add a boolean column for 'private' (default:0), which could be enough to do the trick, Then, if in the rating system, we have a very restricted type of rating (ONE STAR) that is allowed be Private (and that ratings can't be private and public at a whim - can you imagine the mess if the teacher didn't realize this was public or private!), then you could allow a one star rating to appear on the forum view page (if any post is starred), and that might be sufficient.

Finally, however you implement a starmark system, in a new table or in ratings, if you have to collect the star data and check on a user profile setting, to see who is subscribed to a discussion then we could run into a worse issue with the program load than Dan Poltawski has expressed concern over at: http://moodle.org/mod/forum/discuss.php?d=118619#p520820 .

Does this take us further?

John

...thinking about this more overnight, I believe it the mark/star implementation will require another table, with
id,
userid,
post,
mark,
applytodiscussion (default:0).

Theoretically you could leave out the mark column as any entry in the table would mean that a post is so marked - or, if post value is the initial post in a discussion and applytodiscussion=1 then the whole discussion is so marked. That way your need to star a discussion could be mated with the inevitable request to star a post.

But my earlier suggestion of using the rating system would be quite wrong!!! This would limit the use of ratings further [I already wonder that it ought to be possible to apply more than one rating scale in a forum, e.g. ratings on two different criteria (scales)], so using up the rating to facilitate this star-marking would be retrograde!

And having decided that this is independent of ratings then it is easier to conceive using AJAX to apply a star/mark/tag to either a discussion or a post, say, at the end of the title. At the Post level this would be binary (star off/star on), but at the discussion level this would be tri-state (no star/star on a post/star on this discussion) all held in the one table. It would be nice to use the extended character set here, but it this is going to cause problems in other languages, it could be 3 little gifs.

I would be very happy to set about writing this - if enough people want it. Or to hand it over to you (Eloy), or another. But I would re-iterate that this looks like functionality independent of thread subscriptions to me.

Dan Poltawski made a comment about Petr attacking subscriptions for 2.0 already, but I saw nothing about this in the roadmap.

Regards,
John

Just a quick comment on the terms in the proposed interface.

Typically "threads" are named "discussions" in Moodle.

Suggest use "discussions" instead of "threads" in drop downs.

Ray,

Thanks for the feedback. You are right that I have been liberal in my use of 'threads' in place of 'discussions', although I see them as equivalent as both can be used (recursively) to mean the whole or part of such (Wikipedia). Indeed where there is plenty of room for explanatory text I have preferred to use 'discussion threads' as this leaves none in doubt, I would hope.
Where I am a bit concerned is where brevity is important, so should be column heading be 'discussion subscribed?' in place of 'thread subscribed?', and should the button be 'Show subscribed discussions first', not 'Show subscribed threads first'?
I don't really feel that there is any confusion here - but if you and others tell me otherwise I will change it certainly.
SO, DO I DROP THE EXPRESSION 'threads' ENTIRELY?

You may also note another, more subtle measure here... I made the column 'thread subscribed?' with a ?, and changed the equivalent column in the forum index page to 'subscribed?' with a ? [programmers note: I have added an extra language string (one of many) 'subscribedq' just for that, not messed with the existing one],
I did this because the Yes/No buttons, being a button i.e it implies you click to make it act, made little sense otherwise. I have also been much more POSITIVE about the button alt/help line, the 'No' button reads 'CLICK to ALLOW emails from this discussion' - so you know you will switch to 'Yes'.
SHOULD THE SAME BE TRUE OF THE FORUM Yes/No BUTTON TEXT?

As you know, when the user is allowed thread/discussion subscribe, I currently add 2 extra items in the subscription drop-down on the edit page.
I NOW THINK THIS IS A MISTAKE!
Its confusing, AND it causes an extra unnecessary weight of code in validation, in these circumstances we should only offer the new two...
'Send me email copies of posts to this discussion', and
'I don't want email copies of posts to this discussion'.
...because you always have the option for subscribing to the whole forum at the forum level.
So I propose editing the code again.
ARE WE ALL AGREED ABOUT THIS?

Finally, I add two extra features which were not subscription issues using settings:
$CFG->forum_ratingsnudge==1 and
$CFG->forum_countposts==1
described as items (8) and (9) above, WELL above!
Do these say in?
My own view is that the 'ratings nudge' is a code-extravagant luxury and should be removed!
I think the 'count posts' option is much neater, addresses concerns (documented above) and only invokes code if enabled, so it can always be ignored not heavy sites.
IS THERE A CONCENSUS ABOUT THIS?

And finally finally, IS IT BETTER TO GO DOWN ELOY'S SUGGESTED ROUTE, OR NOT, OR BOTH?

Regards to all,
John

Sorry about the capitals but I note that this issue has been raised to Critical, so their are things to resolve lest in delay 2.0 development.

Hi John,

Phew. Lot's to digest.

I just wanted to flag my concern on this quickly. I think brevity is important and that the wording needs to be ultra clear. I need a little time to think about this and I don't have that time today. Will be back soon...

Ray, & ALL,

There were so many typos in my last comment I must apologize for.
I hope its just about readable.

Cheers,
John

Hi all again,

I want to add one other issue that could readily be solved at the same time as any implementation of thread-based subscriptions.
This I have documented in MDL-18581. At this time I don't see any way of having a list of subscribers fixed by admin or teacher, so that students are unable to opt in or out, except the 'Yes, forever' option where the list is ALL those who have the initialsubscriptions capability set. So it CAN be done by adding a special role and unsetting the initialsubscriptions from the student role, but it could be done by adding a 'Fixed subscriber list' option in the forum force-subscribe settings. This would hide the 'Subscribe to this forum'-type links and drop-downs, which is all that is necessary!

If such an item is to be added in it would be logical to decide on this and make it item 4 of the force-subscribe list.

Regards,

John

John,
A bit late in commenting – hope not too late.
Re comment of March-18:
>I have also been much more POSITIVE about the button alt/help line, the 'No' button reads 'CLICK to ALLOW emails from this discussion' - so you know you will switch to 'Yes'.
SHOULD THE SAME BE TRUE OF THE FORUM Yes/No BUTTON TEXT?

My opinion (and it is only that) is that the rollover for the buttons should display the current state and not what would happen if you changed that state. Thus, rather than 'click this to do something else' it should state "emails currently enabled / emails currently disabled" and if the user wants to change the state they click the button. Similarly with the Forum Yes/No button. I believe this is the way other buttons work in Moodle (though I could be badly wrong). I think the advantage is that it easier for the programmer and the user to relate to a current state than a future potential change and extrapolate from that.

> "ARE WE ALL AGREED ABOUT THIS?"
Yes I agree. Simple is good. And your logic is impeccable.

>My own view is that the 'ratings nudge' is a code-extravagant luxury and should be removed!
I think the 'count posts' option is much neater, addresses concerns (documented above) and only invokes code if enabled, so it can always be ignored not heavy sites.
IS THERE A CONCENSUS ABOUT THIS?

I consense with your position here too.

>IS IT BETTER TO GO DOWN ELOY'S SUGGESTED ROUTE, OR NOT, OR BOTH?
Nope – I think your route is well argued.

>At this time I don't see any way of having a list of subscribers fixed by admin or teacher. This would hide the 'Subscribe to this forum'-type links and drop-downs, which is all that is necessary!
I would encourage you to add this feature. I think that it would be useful.

Thanks for all the work you're doing on this John.

Mark (and all),

Thanks for the help.
I am now well underway with the changes and refinements I should be able to post up a new version next week, but at the moment I have family over from Oz!

I'm in accord with all your comments, I will add the 'hide' subscription button functionality, which is not difficult or code-heavy to implement. And I have now taken out the 'nudge'.

The only thing I feel needs seeing - in the flesh - to appreciate to value of is the issue over the alt/help text. From my point of view the current state (1.9.4) is deeply confusing to newer users (old hands never read that text because the don't need to hang around long enough). By heading the column Subscribed? or Thread subscribed? as appropriate, the button state answers the question Yes or No, but without the help telling you what clicking does the users asks: do I click Yes when I mean Yes, or do I click Yes when I mean No? !

More info soon I promise!

John

Hi John,
re the last one.
The buttons will take more space, but potentially they may state the same as links do: Subscribe (No) and Unsubscribe (Yes). Track vs Untrack. hmm...

Sorry - I have not read the comments above, so maybe it has already been mentioned. Just for the reference: from the today's Moodle Developers jabber chat

(18:46:21) david: mahara allows you to subscribe to a given thread and it is very nice feature. What I would really love is being subscribed to any new discussion (ie the initial post) and I can choose to subscribe to a whole thread then
(18:46:47) Eloy: yes, I love that too. Exactly implemented that way.

My +1 for that! (Subscribing to discussion starters, and then being able to individually subscribe to any replies for each discussion).

Usability risks:

• As the number of places that can be subscribed will dramatically increase as a result of this change, it will become difficult for a user to know which items they are subscribed to. This knowledge is needed for example if the user wants to unsubscribe from all items in a specific moodle site.

• Subscribing to a forum and subscribing to a thread within that forum are mutually exclusive. It may be difficult for a user to understand this intricacy unique to Moodle. Special care must be taken that users understand the consequences of unsubscribing from a forum when they still have thread subscriptions within that forum, or vice versa.

It doesn't seem that bad to me

• As the number of places that can be subscribed will dramatically increase as a result of this change, it will become difficult for a user to know which items they are subscribed to. This knowledge is needed for example if the user wants to unsubscribe from all items in a specific moodle site.

Solution: Provide unsubscribe from all forums in this course option. Do we need to change the current option?

• Subscribing to a forum and subscribing to a thread within that forum are mutually exclusive. It may be difficult for a user to understand this intricacy unique to Moodle. Special care must be taken that users understand the consequences of unsubscribing from a forum when they still have thread subscriptions within that forum, or vice versa.

1. I'ts not unique to Moodle, I can subsribe to single discussions in all manner of public fora.

2. Solution: When user unsubscribes from forum they also unsubscribe from all discussions - existing and future. Being subscribed to a forum will mean automatic subscription to initial post in discussion, and the option to sunscribe to future posts.

Easy

Really sorry but this has to wait until 2.1 and the big forum revamp

Note that the OU's Forum NG already has this, and other goodness: http://moodle.org/mod/data/view.php?d=13&rid=2927. (Feel free to have a look and vote for MDL-21538, but note that ForumNG is still only beta release until about June.)

Setting a fix version of DEV backlog for consideration for inclusion in next Moodle version.

Hi again all. It's been two years since I commented on and worked this issue, and that time has gone in a flash for me!
But I am really keen to help move this on. I now have one site on 2.0 (.2 very shortly), I can move a test site to the same. I'm expected to take a 3 million records site up to 2.0+ in Summer.
I could re-write all my code edits to conform with Moodle 2 and make that work in each environment in turn (though they all use MySQL).

But I gather a major re-write of Forum module is on the cards, so do I need to:
. wait and do nothing because it out of my hands
. wait and do nothing because we may move to ForumNG (OU)
. re-write for 2.0.2 knowing that 2.1 will need yet another re-write, but at least helping to INFORM that revamp
. work with developers who are looking at 2.1 forum

I do have a few comments to put into the melting pot...
1. That at least the Forum module works and has some strong functionality (the same can't be said for NWiki in 2.0 regrettably - pity the poor souls who thought moving to NWiki in 1.9 would help the transition!)
2. That my mods would at least give administrators / teachers / users OPTIONS about subscriptions
3. That we CAN keep the interface simple by hiding most of the new subscription models in Advanced settings, so that they can be ignored
4. That it's in moodle.org that these subscription functions are most needed... I can't hack 500 emails a month just because I want to try answering someone's post!

I'll be pleased to help in whatever way I can. I thought I'd retired once ... Ha ha!
As always

I can absolutely guarantee that this feature will be in the rewrite of forum when it happens.

I finally finished a local plugin that implements this feature.

The plugin is not so much tested (I'm the only one tester) but it works fine for me.

https://github.com/jleyva/moodle-local_dsubscription/zipball/master

http://docs.moodle.org/22/en/Forum_discussion_subscription_plugin

I apologise to those who will get this message twice since I also posted here: http://tracker.moodle.org/browse/MDL-21538 which is a tracker item to suggest including ForumNG in core.
ForumNG has the functionality in this tracker item (subscription at the discussion level,avoiding the term 'thread') Plus a lot more.

It is a complex issue. Dan has asked a question here: http://moodle.org/mod/forum/discuss.php?d=195094#p851412 "a question which we have been discussing, what are the compelling features in ForumNG which you are keen to see in core?" I've had my say (long and rambly sorry). In summary: I'd like to see major improvements in the forum in the core.

Some of you watching this tracker item may like to have a say in answer to Dan's question.

-Derek