User Notification Improvements

  • Notifications help you and your users to keep in touch with the community and to be always aware of what happens around you. During the development of Burning Board 4.1, we've taken a closer look on the current approach and evaluate the various levels of feedback received by our customers. A common wish was to receive notifications for likes and the ability to keep notifications instead of instantly discarding them once they were confirmed.



    The image above represents a simple notification, it provides the author's details as well as a single line of text to describe the actual event. This is fine for unique notifications, e.g. someone invited you into a conversation, and we want to keep it this way.


    Yet, these kind of notifications raise a few issues when it comes to more complex use cases. Consider notifications for new replies in a watched thread, you'll only receive a notification for the first new post, but every consecutive reply slips through unnoticed unless you visit the thread and indirectly mark the notification as confirmed, starting the cycle again. While most people are used to this behavior, adding notifications for received likes raises the same concerns again, yielding a notification for the first like only might imply that there is only one like, even though there might be a lot more likes for the very same post.


    We're closing the gap with the stacking feature for notifications:



    The new stacking feature will track the individual authors and the times the notification was triggered. No matter how oft the same notification will occur, only a single notification will be triggered (this includes email notifications), but it will automatically reflect what is really happening.


    In addition we're improving the notification count, previously the page title was dynamically changed into something like "(3) Page Title". Changing the page title isn't the best idea and some browsers do not really show it or hide it under certain circumstances (once there isn't enough space available). Most browsers offer another great way to reflect the notification count: Overlays for the page icon (also recognized as "favicon").



    The favicon is dynamically updated through favico.js and does not alter the file stored on the file system. The software periodically causes the browser to send a single request to the server in order to keep the current session alive. By default a session expires after 30 minutes of inactivity, this request is send after 29 minutes (in fact 1 minute before the session expires) and marks the session as active again for user convenience. This request has been modified and will now return the number of outstanding notifications, allowing the page icon to be updated every once in a while to keep you and your members posted.

  • Concerning the favicon notice. I usually add this code just below <head> I wonder how that will playout


  • It doesn't influence the Apple Touch icon at all, and neither the M$ specific things.

    "A life is like a garden. Perfect moments can be had, but not preserved, except in memory. LLAP" — Leonard Nimoy