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
Line 15: Line 15:
* Reduce the real estate consumed by forum notifications and visually differentiate them from personal messages using css. With IMs the version that is displayed on /message/index.php doesn't include the footer that is appended to the version that is emailed out. This condenses their display and prevents the inclusion of standard boilerplate like "This is a copy of a message posted on the CF101 website." being displayed over and over. 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. Additionally, css could visually differentiate IMs from notifications.
* Reduce the real estate consumed by forum notifications and visually differentiate them from personal messages using css. With IMs the version that is displayed on /message/index.php doesn't include the footer that is appended to the version that is emailed out. This condenses their display and prevents the inclusion of standard boilerplate like "This is a copy of a message posted on the CF101 website." being displayed over and over. 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. Additionally, css could visually differentiate IMs from notifications.


* Differentiate messages and notifications.
* 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


* Try to avoid putting forum notifications through the messaging system.
* 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.


* Are there any other alternatives?
* Are there any other alternatives?

Revision as of 03:15, 11 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. 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:

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

Possible solutions

  • Reduce the real estate consumed by forum notifications and visually differentiate them from personal messages using css. With IMs the version that is displayed on /message/index.php doesn't include the footer that is appended to the version that is emailed out. This condenses their display and prevents the inclusion of standard boilerplate like "This is a copy of a message posted on the CF101 website." being displayed over and over. 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. Additionally, css could visually differentiate IMs from notifications.
  • 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
  • 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.
  • Are there any other alternatives?