IP.Board 3.1: Notifications

It's a well-known fact that one method of ensuring continued visitation of your site is to email members frequently to send reminders and notifications. For instance, if a user posts in a topic, they may forget that they posted after a day or two. If an email is sent to that user after someone else replies, however, it can remind the original user to return to your site to check on the updates.

IP.Board has a strong system of notifications, however we found that much of the code to handle this is scattered and duplicated throughout many files in IP.Board 3.0. The methods of managing your notification preferences are also inconsistent, making it confusing and difficult for new users to determine how to control notification preferences. If you are a moderator, you manage your report center notification preferences in the report center. You are only able to get email notifications of tracked topics. You can select to get email or PM notification of new comments and friend requests in your user control panel. Through these few examples, you can see that managing notification preferences can be made easier.

IP.Board 3.1 introduces many improvements to notifications, both on the backend and within the user interface of the board itself.

Inline Notifications
In overhauling the notification management options in IP.Board 3.1, we decided to add inline notifications. Essentially, this is a notification within the board itself, without actually issuing a private message or an email. There are many instances where a visitor might want to be notified of an action, but might not want an email to be sent to their email address, or they might not want a private message for such notifications (especially if your board has limits on the number of private messages an individual can store).

Visually, when an inline notification is first triggered, it will look identical to the existing private message popup. In fact, private messages no longer directly initiate the popup you have become familiar with - instead, they issue an inline notification (which initiates this popup). This was done on purpose for consistency, and for code reduction and reuse purposes.

A "Mark Read" button has been added to the popup so that, in addition to closing or viewing the notification, you can mark it as being acknowledged without having to leave the page.



A new option has been added to the profile dropdown to allow users to quickly access their inline notifications, as well.



Administrators can control how many inline notifications a single user can store on a per-group basis. If a user is allowed to store 50 inline notifications, and notification number 51 is issued, the user's oldest notification is automatically pruned. The user will see a notification popup on the board the next time they click a link. There is also an area in the user control panel where each user can list, view and prune their notifications. Additionally, a new board index hook will show up when a user has unread notifications (and automatically disappear once all of their notifications have been acknowledged).



Stronger control of notifications
A new area of the ACP has been added to allow administrators to better control notifications as well. Any registered notification events will be listed, and the administrator can control which methods to use by default for each notification event, which methods cannot be used at all, and will also have the ability to disallow users from overriding the admin-defined selection. For example, an administrator might want the default notification method for new private messages to be inline notifications (show a popup on the board). Administrators may also want to disallow users from electing to get an email notification when comments are made on their profile to reduce the number of email messages sent from the server. An administrator may also want to enforce that all users (with appropriate permissions) get an email notification when content on the board is reported. All of these things, previously not possible, can be configured from one page within the ACP of IP.Board 3.1.



Easier user configuration options
In addition to the new UserCP page to view your inline notifications, there is a new notifications page where all notification settings and options have been consolidated. New configuration options are available to control your notification preferences, as well. Each user will be able to select whether they want to receive email, PM, or inline notifications (or a combination of the above, or none of the above) for each notification event from one page. Methods that are not available per the ACP-defined preferences are removed from the user's options, while notification events that an administrator does not allow users to override are disabled but still displayed (so that a user can know how they will be notified when one of those events occur). A couple of screenshots should help clarify this.



If an administrator makes the following configuration in the ACP



A user can expect to see the following in their notification preferences



You'll also note from these last 2 screenshots that we've added the ability to get notified when someone quotes a post that you made.

Easier for developers
IP.Board 3.0 has well-abstracted code to make sending private messages and emails easy for developers. While this is true, code is duplicated throughout IP.Board 3.0 that is meant to handle sending either PM or email notifications. As a general rule, duplicated code is not a good thing to have. We also had to find a way to easily implement inline notifications (without adding yet more if/else style statements everywhere that sends notifications).

We have created a new notifications class which developers can easily use to allow third-party applications to plugin to the new notifications system. This reduces the workload needed to set up notification capabilities (and management) for new applications significantly.

A developer will first need to create a plugin file for their application to define notification events. A sample plugin file might look like this

/** * Notification types */ $_NOTIFY = array( array( 'key' => 'report_center', 'default' => array( 'email' ), 'disabled' => array() ), );

<?php

(Yes, this is the actual code for the "core" application of IPB to handle report center notifications). You define the default selections, and the options to disable by default. For example, you would not want a private message to issue a new notification by private message. This allows the developers to define the default handling of notifications for their applications.

Then, to send a notification, the following code can be used

// Notifications library //----------------------------------------- $classToLoad = IPSLib::loadLibrary( IPS_ROOT_PATH . '/sources/classes/member/notifications.php', 'notifications' ); $notifyLibrary = new $classToLoad( $this->registry ); $notifyLibrary->setMember( $user ); $notifyLibrary->setFrom( $this->memberData ); $notifyLibrary->setNotificationKey( 'report_center' ); $notifyLibrary->setNotificationText( 'This is the text to show to the user' ); $notifyLibrary->setNotificationTitle( 'This is the title of the notification' ); try { $notifyLibrary->sendNotification(); } catch( Exception $e ){}

//-----------------------------------------

The most common implementation will be to use the email library to first "build" an email, and then to assign the subject as the title, and the message as the text. As you can see, however, it is quite easy to use the notifications class. The class itself will determine what the administrator has defined as being allowed and disallowed, and what the user has selected for their notification preferences, and issue all appropriate notifications automatically based on the ACP and user preference selections. You don't have to worry about ACP settings or user cp settings either, using this method. All of it is taken care for you!

Closing
Through implementing the new notification capabilities, we hope to be able to expand the notification capabilities in IP.Board easier in future versions. As you can see, we've already added one more area where a user can get notified of changes in activity, and have some ideas of other areas where we would like to have the ability to issue notifications as well. With the refactored code and easier configuration management, implementing these changes will be easy.

Also, please keep in mind that the screenshots you are seeing are very early screenshots taken of a development build. Rikki hasn't had a chance to put his magic touch on these pages, so most likely the final look and feel will be touched up a bit. We just wanted to share the new capabilities, complete with some screenshots to help you visualize them, as soon as we possibly could.

Please let us know if you have any suggestions or feedback about the new feature.