Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Forum notifications as messages: Difference between revisions

From MoodleDocs
 
(13 intermediate revisions by 3 users not shown)
Line 4: Line 4:


==The problems==
==The problems==
Forum notifications are now done via the messaging system rather than by the forum sending out emails itself. Unfortunately forum notifications then appear on /message/index.php which is proving to be annoying and confusing on a site with busy forums. There two closely related problems:
Forum notifications are now done via the messaging system rather than by the forum sending out emails itself. This reduces duplicate code and, once more modules report events via messaging, allows users to view what amounts to an activity feed for their contacts instead of just their personal messages.
 
Unfortunately forum notifications currently appear on /message/index.php in a form which is proving to be annoying and confusing on a site with busy forums. There two closely related problems:


[[Image:Forumnotificationsinmessaging.gif]]
[[Image:Forumnotificationsinmessaging.gif]]
Line 10: Line 12:
* Each forum post notification consumes a lot of screen real estate. See the screenshot for an example. This makes the whole interface less usable as it requires lots of scrolling past unnecessary and repeated text.
* Each forum post notification consumes a lot of screen real estate. See the screenshot for an example. This makes the whole interface less usable as it requires lots of scrolling past unnecessary and repeated text.


* Forum notifications appear to be coming from the author of the forum post and so are displayed among personal messages exchanged by the two users. For example if two users, Mary and John, are having a conversation via personal messages and Mary posts in a forum, John's notification of that post will appear among their personal messages as if it were a personal message from Mary. This is potentially confusing and interrupts the flow of conversation.
* Forum notifications appear to be coming from the author of the forum post causing them to be displayed among personal messages exchanged by the two users with no clear indication of what is going on. For example if two users, Mary and John, are having a conversation via personal messages and Mary posts in a forum, John's notification of that post will appear among their personal messages. This is potentially confusing.


==Possible solutions==
==Possible solutions==
* Reduce the real estate consumed by forum notifications. With IMs the version that is displayed on /message/index.php doesn't include the footer that is appended to the emailed version. This condenses their display and prevents the inclusion of standard boilerplate like "This is a copy of a message posted on the CF101 website" on the messaging screen. The messaging system could be enhanced to allow the calling code to supply a header and footer which could be included in the emails but then discarded.
* (DONE) Reduce the real estate consumed by forum notifications (MDL-24563). The notification message could be reviewed to reduce its overall size. Additionally, with IMs the version that is displayed on /message/index.php doesn't include the footer that is appended to the emailed version. This condenses their display and prevents the inclusion of standard boilerplate like "This is a copy of a message posted on the CF101 website" on the messaging screen. The messaging system supports both "smallmessage" and "fullmessage" but we do not currently make use of this. If we utilize them both processors and the messaging UI can choose which to display For example the forum post notifications small message could be set to something like this (then displayed on the messaging screen):
 
 
Andrew posted in (forum name)
 
(Andrew's post content)
 
To view: (link to the post)
 
 
with the full message, used by the email processor, looking something like this:
 
 
This is a copy of a message posted in CF101 -> Forums -> (forum name) -> (discussion name)
 
Andrew posted in (forum name)


* Differentiate messages and notifications. Add a new column called notification to the message table (and maybe message_read). Messages would be read and then moved to message_read and are displayed on /message/index.php as they are now. However, messages that are marked as notifications could be dealt with then either deleted or moved to message_read and ignored by the code that retrieves the messages to display on /message/index.php Alternatively, once we can tell notifications from personal messages css could be used to visually differentiate between messages and notifications.
(Andrew's post content)


* Try to avoid putting forum notifications through the messaging system. When the forum cron code is constructing the forum post notifications instead of handing them over to the messaging code it could check the user's messaging preferences and if they have selected ONLY email as handler for forum posts it could send the emails itself and simply not use the messaging system. Popup and Jabber notifications would still need to be handled by the messaging code so this measure would mitigate but not fully resolve the issue.
To view: (link to the post)
 
To unsubscribe from this forum: (unsubscribe link)
 
 
* Differentiate messages and notifications (MDL-24771). Add a new column called notification to the message table (and maybe message_read) to flag messages that are notifications rather than a message from another user. Messages continue to be read and then moved to message_read and displayed on /message/index.php as they are now. However, messages that are marked as notifications could be dealt with by the message processors then either deleted or moved to message_read and ignored by the code that retrieves the messages to display on /message/index.php Alternatively, once we can tell notifications from personal messages, notifications could continue to be displayed on /message/index.php but css could be used to visually differentiate between messages and notifications. If we were going to do this we'd most like want to also do #1.
 
* Try to avoid putting forum notifications through the messaging system. When the forum cron code is constructing the forum post notifications instead of handing them over to the messaging system it could check the user's messaging preferences and if they have selected ONLY email as handler for forum posts it could send the emails itself and simply not use the messaging system. Popup and Jabber notifications would still need to be handled by the messaging code so this measure would mitigate but not fully resolve the issue.


* Are there any other alternatives?
* Are there any other alternatives?
:Here is one idea:
:Change message.useridfrom to message.contextidfrom. That would not messages not only come from other users, but it would also let things like "Forum X" but the sender of the message. That seems like a more sensible option.
:Of course, for outputs like email, you would then need some way of constructing a from email address for that notional sender. Hmm.--[[User:Tim Hunt|Tim Hunt]] 09:49, 11 October 2010 (UTC)
:Why not add contextidfrom in addition to userid from? That way it can say 'in General Development Forum (from sam marshall)' or something, and it knows how to use from addresses [supposing you have the 'from real address' option turned on] [[User:sam marshall|sam marshall]] 09:08, 12 October 2010 (UTC)

Latest revision as of 02:28, 20 October 2010

Moodle 2.0


WARNING: Under construction RIGHT NOW!

The problems

Forum notifications are now done via the messaging system rather than by the forum sending out emails itself. This reduces duplicate code and, once more modules report events via messaging, allows users to view what amounts to an activity feed for their contacts instead of just their personal messages.

Unfortunately forum notifications currently appear on /message/index.php in a form which is proving to be annoying and confusing on a site with busy forums. There two closely related problems:

Forumnotificationsinmessaging.gif

  • Each forum post notification consumes a lot of screen real estate. See the screenshot for an example. This makes the whole interface less usable as it requires lots of scrolling past unnecessary and repeated text.
  • Forum notifications appear to be coming from the author of the forum post causing them to be displayed among personal messages exchanged by the two users with no clear indication of what is going on. For example if two users, Mary and John, are having a conversation via personal messages and Mary posts in a forum, John's notification of that post will appear among their personal messages. This is potentially confusing.

Possible solutions

  • (DONE) Reduce the real estate consumed by forum notifications (MDL-24563). The notification message could be reviewed to reduce its overall size. Additionally, with IMs the version that is displayed on /message/index.php doesn't include the footer that is appended to the emailed version. This condenses their display and prevents the inclusion of standard boilerplate like "This is a copy of a message posted on the CF101 website" on the messaging screen. The messaging system supports both "smallmessage" and "fullmessage" but we do not currently make use of this. If we utilize them both processors and the messaging UI can choose which to display For example the forum post notifications small message could be set to something like this (then displayed on the messaging screen):


Andrew posted in (forum name)

(Andrew's post content)

To view: (link to the post)


with the full message, used by the email processor, looking something like this:


This is a copy of a message posted in CF101 -> Forums -> (forum name) -> (discussion name)

Andrew posted in (forum name)

(Andrew's post content)

To view: (link to the post)

To unsubscribe from this forum: (unsubscribe link)


  • Differentiate messages and notifications (MDL-24771). Add a new column called notification to the message table (and maybe message_read) to flag messages that are notifications rather than a message from another user. Messages continue to be read and then moved to message_read and displayed on /message/index.php as they are now. However, messages that are marked as notifications could be dealt with by the message processors then either deleted or moved to message_read and ignored by the code that retrieves the messages to display on /message/index.php Alternatively, once we can tell notifications from personal messages, notifications could continue to be displayed on /message/index.php but css could be used to visually differentiate between messages and notifications. If we were going to do this we'd most like want to also do #1.
  • Try to avoid putting forum notifications through the messaging system. When the forum cron code is constructing the forum post notifications instead of handing them over to the messaging system it could check the user's messaging preferences and if they have selected ONLY email as handler for forum posts it could send the emails itself and simply not use the messaging system. Popup and Jabber notifications would still need to be handled by the messaging code so this measure would mitigate but not fully resolve the issue.
  • Are there any other alternatives?
Here is one idea:
Change message.useridfrom to message.contextidfrom. That would not messages not only come from other users, but it would also let things like "Forum X" but the sender of the message. That seems like a more sensible option.
Of course, for outputs like email, you would then need some way of constructing a from email address for that notional sender. Hmm.--Tim Hunt 09:49, 11 October 2010 (UTC)
Why not add contextidfrom in addition to userid from? That way it can say 'in General Development Forum (from sam marshall)' or something, and it knows how to use from addresses [supposing you have the 'from real address' option turned on] Sam marshall 09:08, 12 October 2010 (UTC)